Sprite System?
BlitzMax Forums/BlitzMax Beginners Area/Sprite System?
| ||
| Hi! Is there already a free Sprite System for Max? I am making one called MaxS and need to know what kind of features should be usefull for you Guys. Already Got the base: - Most of Max2D stuffs accessible by methods - Parenting - Z sorting - Advanced Text with special actions (</> carriage return, <$FFFFFF> colour, <#255> special char, <%0.5> alpha) here is a short code example:
Graphics 640, 480
MaxS_Init()
Global piv:TMS = MaxS.CreatePivot()
Global logo:TMS = MaxS.Load("MaxS.png", 255, 0, 255, piv)
piv.SetPos(320, 240)
logo.SetPos(100, 0)
While not KeyDown(KEY_ESCAPE)
Cls
piv.Turn(0.5)
logo.Turn(-1)
MaxS.Update()
MaxS.Render()
Flip
Wend
Any suggestions ? |
| ||
| Yes there are several. Both free and commerical. I've also developed a complete sprite engine for Bmax, but I have no idea when I will make it available. I'm using it for internal game development currently. There are some incredible things being coded outside the USA, but I can't speak German, etc. There's so much code here in the forum, someone could easily piece together a sprite, particle engine by themselves in a matter of minutes to be honest. |
| ||
| So, what kind of stuffs a minutes coded engine should have??? |
| ||
| One thing heavily requested and I get email on occasionally, but I have no time to pursue it, is a 2D RPG system. Code that and you'll have tons of followers. ;) |
| ||
| I think he's talking about what features a 2D engine can do like at the sprite level not at the `type of game` level. Although I'm writing my own, useful features would be a general particle engine which lets you animate the sprite, move it, scale it, rotate it, change its transparency, add tinting, stretch it, render it warped or in different blend modes, perhaps tiling, more 2d drawing functions, glowing lines, splines, that kind of thing. |
| ||
| Based on what I've done at the moment, a Particle system will be easy to implement. I'd like to implement a simple Physic Engine too but haven't got the skill to. Already have some ideas for a simple GUI library. So, I will focus on more drawing functions and glowing lines. Thanks! |
| ||
| A robust hierarchy transformation handling would be what I would start with as anything else bases on that. |
| ||
| Dreamora: Like my sprite system? :-) |
| ||
| You can see my sprite system in action here: http://jgoware.com/mge/downloads/asteroidblast.zip Like I said, everyone's writing their own sprite system, but very few are writing game engines. I still think a cool 2D RPG system in Bmax with networking would be very popular. |
| ||
| sswift: Don't own yours, so I can't say :-) But last time it seemed like it supported quite some stuff. I know that mine has hierarchy matrix propagandation support to allow any kind of position, rotation and scale beeing applied on hierarchy or per instance base, including support for propagandation of the offset to the childs. I think this is just a too elemental thing to not do it first and correctly before trying to extend it with nifty eye candy stuff. JGO: Thats the direction in which the system goes that uses the sprite system (and a few other things). Not sure if it will be full RPG. The original idea was a CORPG (connected online RPG - means player can host their own subworlds with a central main world and the game would include editors to create these worlds) |
| ||
| Dream: I think yopu mean propagation, not propagandation. The root is "propagate" not "propaganda". :-) I don't use matrices to do my transformations, but position, scale, and rotation all propagate to the children, if you want them to. (Propagation be selectively turned on or off per property per child with flags.) |
| ||
| Args ... german -> english error ^^ I use matrices to cut down the amount of calculations drastically, as scale and rotation can be combined and rotation offsets can be easily pushed through by vector matrix operations. As it is 2D, you can even optimize the matrizes to a 2x2 for scale & rot + a 2x1 vector for position. Another pro of the matrix approach is that you actually can store an internal and a global matrix and only need to recalculate it if something has changed on this object or the parent if it uses parent transformation. Plays out very usefully if an object is added to a part of the hierarchy and not at its end or you want it to ask for the local coords of a child instead of the global ones or vice versa ... But I'm sure yours uses similar optimations without using this :) |
| ||
| Actually it doesn't, because that would require updating the state of the parent's children every time a change in the parent is made, which would add another bit of code to every transformation function, and add this transformation matrix that gets stored with the sprite and make the whole of the code that much more confusing. That and: 1. It's not often that you have a parent object that just sits there and doesn't animate, so most of the time you have to update your transformation stuff anyway, so this would add more calculation. 2. You can't use a transformation matrix to transform an object into "path" space, so you'd have two different ways of transforming stuff to keep track of making things more complex. 3. I haven't run into any instance where it's not plenty fast enough to just step through the heiarchy tree to calculate a sprite's current position/rotation/scale/alpha/color/fog/etc each frame. You don't generally have a child with more than two parents. 4. Speaking of which those other properties would also not be covered by the standard transformation matrix. And none of that means you can't request a local or global position in my system, because you certainly can do that, and there's no recursion or anything for getting a local position obviously. |
   |