Particle Origins on Sprites
BlitzMax Forums/BlitzMax Programming/Particle Origins on Sprites
| ||
| Does anyone have any ideas for having sprites that originate from specific points on sprites? I could do this the obvious canned hard way but I think I would like to have it baked into my sprite storage format. Think of the origin points for gun muzzle flashes, or ice particles dripping off a sword. One thing I had thought of was having certain specific colors that were replaced by my engine at draw time, to re-color armor and weapons. Any ideas? |
| ||
| I would make a simple MaxGUI application that loads your animation frames and you can zoom in and visually specify the in-sprite coordinates for those special-effect sockets, per frame. These sockets are just objects that have an ID and a coordinate pair [x, y] that's positioned relative to the sprite handle, wherever it may be (as you might happen to use something other than top left). This tool would also save this socket data to a file so that you can load it in your game engine. |
| ||
| or, of you know the vertex data of your model I would make a simple MaxGUI application that loads once you have the model loaded, just locate the required vertex for spawning sprites. this could be a vertex range (start..end), a single vertex, or you could have an additional data per vertex which your engine uses to reference sprint emissions |
| ||
| He is talking about sprites, not textures. So eg. he has a spritesheet containing a figure holding a weapon in the hand while shooting and walking. He now wants to store the information of the weapon so he could add some effects ("muzzle flash"). Idea: it adds a specific offset but keeps it "visible": each sprite you have could get a X-sized-Pixel-Border. (X = amount of special positions on the image). So you end up with eg this: +-------------+ |+-----------+| || ,=, || || (o o) 1| || \~/ || || o |2 || .--' '--. || || ... || |+----1-1----+| +------2------+ +-----2-----+ | ,=, | | (o o) 1 | \~/ | 2 o | | .--' '--. | | ... | +----1-1----+ 1 and 2 define special positions on the sprite (the top and left pixel rows/cols could also get used - for me they contain 9patch-pattern information or "content area"-definition). In our case you see two definitions of the "1"-x-axis: so we have two spots of this effect, both on the same y-axis. Yes, you cannot create multiple definitions in one set of "col-row" - except they share a coordinate (either X orY). Of course you could add different colours - but you still could not mark "two spots of the same effect on the same coordinate" - except of cours for another color coding, but this just makes it harder to "paint". So as long as you keep it simple (2, 4, 6... effects) you can do it with the pixel-border-method. I prefer color codes too - you even could do something like "255,0,0" = dropping blood, "0,0,255" = dropping melted ice .... . hope you got the idea. bye Ron |
| ||
| I'm just going to go with color codes and roll my own copyrect. That way the information will be baked into the bitmap. Derron, your way is super original. Did you think of that yourself? Do you have any demos of this effect? Interesting other ideas gents-- is there anything interesting you can think of to do with this system? The plot thickens: since the game is top-down, the particle origin needs to be rotated along with the sprite! Probably the best way to do this is to do the sprite rotation as normal, then put the particles into screen space on the res-up pass. Hrm. |
| ||
| @think of that yourself Yeah, I did that - but I assume others did that before. Like said I reuse the idea of androids nine patch configuration (the use the left and top added pixel line to mark stretchable areas of a 3x3 grid , the bottom and right added pixel line defines content areas of the grid). While it adds the benefit of "the designer could add them graphically" it really lacks of a flexible configuration - if your sprite is loaded via a ressource loader - just add more configuration details in a XML. This xml then just contains
<sprite name="bla" url="url/to/image.png" offsetLeft="-10"
<effects>
<effect x="10" y="20" type="1" />
</effects>
</sprite>
while this adds some entries to an XML it allows for a way more flexible configuration of your sprite, no need to do this in your paint program. BUUUT ... you might do it for simple effects (if no additional configuration data like "drop amount" is needed) but advanced ones should be done in a more versatile environment -> ini/xml/... bye Ron |
| ||
| You could also have particle origins on the top and left lines and stretching information on the bottom and right. Lots of people seem to use sprite stretching for quick and dirty animations. |
| ||
| Derwin, [DERRON, thanks very much autocorrect] I decided to do it your way, there are just too many possibilities and it's much easier than having to deal with another format to parse and bother with. It will also work for room templates! Something else I am going to do with the sprites is to have pixels to indicate eyes and possibly head origins so I can procedurally generate sprites like paper dolls. Probably I will pre-build sprite sheets for these at map creation to minimize number of draws. It's a dungeon game-- one thing I am going to do is to have a fullbright flag for things that glow in the dark, like eyes. Any other ideas? Since I am coding an editor and format I would like to really milk it for all it's worth. |
| ||
| just use XML ... it is versatile and easy to extend (new flag/option? just store it with them). Especially if you use an custom editor this will be the best deal to accomplish. In your "paper doll" approach: you have a "mydoll.xml", which describes parts of the body - and a body which has "parts"-children with coordinates where to attach the parts. Each part could have custom properties like "offset", "handle location" etc. Means: while your body says: the left arm belongs to x5,y4, your "part type='leftarm'" defines a handle of x2,y2. Result will be that the left arm is is positioned at x5+2,y4+2 because it took care of an individual declared offset/handle. This all are things which can be easily done in XML - you then just have to extend your xml-reading-function and types. Way better than to code them into the image itself. Such things just should be done if the encoded information is existing in nearly all of your graphics or is very generic. bye Ron |
| ||
| Mmmm... I will think about it, maybe I am just being a luddite. The 9patch format borders on genius... |
   |