Is 3000+ sprites normal? :)

[jongjungbu]

Aah, he may be familiar with the groundhog then.

[Phantom]

Digby, I tried your demo. Pretty awesome performance you got there. If I can find the time, I'll give you another demo to think about later this week. More sprite stuff.

[Digby]

Jacco,<br><br>Thanks for checking out the demo.  I don't have a lot of free cycles these days, but I'd be interested in hearing any ideas you have.<br><br>Hey let me ask you something.  If you were going to write a sprite library which of these features would you support and which would you consider to be higher priority?<br><br> - Alpha blending<br> - Color key transparency<br> - Rotation by any arbitrary angle<br> - Scaling<br> - Clipping to edge of screen (viewport?)<br> - Mirror, flip vertically/horizontally<br> - Z sorting (sprite has a single depth value)<br> - Image loading (bmp, jpg, png?  which formats?)<br><br><br>Of course this question is open to all, but I would be most interested to hear from people who have at least used, if not developed,  sprite libraries and what sort of things are absolutely necessary and what sort of things aren't.  Or maybe things you would have liked to have that weren't available in the library you used for your game.  Thanks.<br><br>

[suchiaruzu]

As a graphic artist I say:<br>Support Alpha blending and PNG, BMP and TGA. Also Z-sorting and rotating the sprite.<br>The other ones are not that high priority, but implementing them would be neat.<br>Is that your secret project? Is it??

[Digby]

No secret projects here.  I have more than enough to keep me busy.  I'm just trying to get a conversation going that has something to do with actual development rather than muffins.<br><br>Thanks for the feedback.  As an artist, why do want the loader to support more than one image format?  Don't your tools support multiple formats?<br><br><br><br>

[MirekCz]

ok I'm currently developing my own sprite library for PPC which is partially ready and that's what I would go for:<br>1.Image loader (first tga, then jpg/png or own format)<br>2.Clipping to the edge of screen(this one is very important)<br>3.Color key transparency<br>4.Alpha-blending<br>5.Mirror/flip (might save you a lot of space used to store sprites<br>6.Z-sorting, if you need that<br>7.Scaling, if you need that<br>I wouldn't even think about creating an arbitary angle rotation procedure, cause it's quite slow and creates POOR results most of the time.(Partially true about the scaling procedure as well...)

[Phantom]

Digby wrote:<br><br>> Alpha blending <br>> Color key transparency <br>> Rotation by any arbitrary angle <br>> Scaling <br>> Clipping to edge of screen (viewport?) <br>> Mirror, flip vertically/horizontally <br>> Z sorting (sprite has a single depth value) <br>> Image loading (bmp, jpg, png?  which formats?)<br><br>Here's what I did in the Nutcracker: I wrote a really simple sprite class that does the most basic stuff that a sprite should do: Draw itself, nicely clipped to the screen area. That's all. I did use alpha blending, but that trick could easily be done in the simple sprite class I just described. I also needed 'white sprites', like when the player gets hit (for that authentic flashing effect). Added that too.<br><br>My point is: You don't want a bulky full featured sprite library. You want some code that is reusable, fast at it's core, and extendible. I would never release a sprite library with my white flash effect (since probably no one will ever use it), but still I needed it. While on the other hand, I did not need rotation and scaling. If that would have been in my sprite library, it would have made the sprite code much more complex (especially the clipping), and my executable would have been larger.<br><br>One question: Are you creating this library for yourself, or for the general public?<br><br>And one last remark: Loading PNG/GIF/Whatever is not the core business of a sprite library. The sprite library should retrieve it's data from an arbitrary buffer. A PNG/GIF/Whatever library should take care of the image loading. That way, your paralax scrolling library can benefit from the same code.<br><br>Just some ideas.<br><br>- Jacco.

[Paul Johnson]

My guess would be a span sorting algorithm whereby you bucketsort spans of sprites for each line of the screen and deal with overlaps.<br><br>No overdraw whatsoever!

[Digby]

Great comments.  Thanks and keep it coming!<br><br>MirekCz,<br>The rotation will be fast and it will look good. It's the same algorithm used in texture mapping, however it's nowhere near as fast as pre-rotating the image and displaying a strip of the images.  You could still use the rotation routine to save space though.  You load the single sprite image from disk, then generate the strip of multiple, rotated images using the sprite rotation function.  Imagine a game that allowed the player to choose from 25 different vehicles, all of which would need 32 frames of rotation.  If you did this on the fly when the game loaded you won't have to store all of those images on the user's device.<br><br>Jacco,<br>I don't think I need a sprite library for what I'm doing, so to answer your question I suppose this would be for public consumption.  I'm not signing up to do it though, I'm just gathering ideas.  You've made some good points.  Image loading is pretty simple to write and could be used in a number of other places in a game.  It probably shouldn't be part of the sprite library.<br>No one should have to pay the price for a code path that goes through things like clipping or rotation when the app doesn't need it.<br><br>Paul Johnson,<br>What about sprites that must be alpha blended with what is already drawn into the frame buffer?  I see 2 ways to handle this, either defer the rendering until an EndDraw marker is found in the display list, then draw the sprites back-to-front, or use a depth buffer and draw the sprites as they are submitted.  You would have to force the app to draw all of it's opaque sprites first, then draw any translucent sprites in back to front order.<br><br><br>

[MirekCz]

Digby:well, you have got it wrong in few places:<br>1.assuming a 32x32x16bpp car each picture takes 2kb of ram, so we get 8 pictures into 16kb... so 25 cars aren't a problem at all.. and why only 8 pictures? because we can use a routine that will rotate a sprite by 90/180/270 degrees on the fly - while drawing... it's almost as fast as normal drawing and allows to keep you only 8 pictures to give you a total of 32pictures for a full rotation. And you don't lose quality!<br>2.About the rotating engine.. it will really bring poor results comparing to pre-drawing it

[suchiaruzu]

[Digby]

[Phantom]

[MirekCz]

[Digby]