You guys talk about making a single surface system like it's incredibly easy to do, (So WHY not implement it if you get 1 fps extra? You'd be CRAZY not to!) and/or will have major benefits.
But I ask you:
How would you make a single surface system work, when all your sprites have to be drawn in random orders, and you can't use the zbuffer because either it doesn't exist in Max, or will not work with anything that has transparency, like all your nice antialaised sprites done with alpha mapping?
For general sprites, I just don't see the benefit. Take my Lego game for example. At MOST, there were like 100 sprites on the screen at once. And at MOST, there might have been 6 copies of a particular sprite.
For a single surface system to be worthwhile, you'd have to have a game where you have LOTS of identical sprites on the screen at once, using the same order, and so drawn on the same layer.
That sort of thing is the realm of particle effects, and you'd be much better suited to use a particle system for particle effects like that than a sprite system.
Download this and run it. It draws 2000 sprites on the screen at once, each with a randomly selected image out of four different images.
http://www.seamlesstexturegenerator.com/systems/sprite_system_demo_1.zip
Press TAB to see the framerate. I get 60fps in this.
Still think a single surface system is neccessary?
What on earth are you planning to do that needs more than 2000 sprites onscreen at once?
And how do you suggest you implement a single surface system which would tackle the issue of just not having that many of the same sprite onscreen at once that need to be rendered on the same layer in most applications, which is precisely what you need to see any real benefits?
But I ask you:
How would you make a single surface system work, when all your sprites have to be drawn in random orders, and you can't use the zbuffer because either it doesn't exist in Max, or will not work with anything that has transparency, like all your nice antialaised sprites done with alpha mapping?
For general sprites, I just don't see the benefit. Take my Lego game for example. At MOST, there were like 100 sprites on the screen at once. And at MOST, there might have been 6 copies of a particular sprite.
For a single surface system to be worthwhile, you'd have to have a game where you have LOTS of identical sprites on the screen at once, using the same order, and so drawn on the same layer.
That sort of thing is the realm of particle effects, and you'd be much better suited to use a particle system for particle effects like that than a sprite system.
Download this and run it. It draws 2000 sprites on the screen at once, each with a randomly selected image out of four different images.
http://www.seamlesstexturegenerator.com/systems/sprite_system_demo_1.zip
Press TAB to see the framerate. I get 60fps in this.
Still think a single surface system is neccessary?
What on earth are you planning to do that needs more than 2000 sprites onscreen at once?
And how do you suggest you implement a single surface system which would tackle the issue of just not having that many of the same sprite onscreen at once that need to be rendered on the same layer in most applications, which is precisely what you need to see any real benefits?