next »

[Lynx]

I've been puttering around on this game project and running into various limitations - how many sprites I can have on-screen at a time, doing reasonably complicated things.  Right now the limit for my Python-based game appears startlingly small - it starts to drop under 60fps at about 200 sprites, and goes to about 30fps at 400-500 sprites.  It could be I'm doing something wrong; a different example program manages 2400 sprites without breaking a sweat, after all.

Note that I don't mean just drawing sprites on the screen, I mean things like rotating an explosion between several different textures and varying its alpha, color, and size so it appears to be fading into the distance.

What are your engine or game limitations like, and how do you deal with limits that seem surprisingly small?  Any general design optimizations that you like?

[JLJac]

I work in a flash-like tool, and then you have to adjust to that software's limitations instead of creating your own, like when programming in more low-level languages. That is a pain. I can't show more than 1000 sprites at a time, ever. If they are transparent or has images with alpha channels I can't have more than about 200

But it's okay, because the mathematics are relatively fast, and I can create pretty complex collision detections and such. There are actually kind of few games that need to show more than 200 sprites as a time, that is only if you want to create extremely complex particle systems. I mean, there are few games that can have 200 enemies at the time, at least if they are to have a somewhat interesting AI. Still it sucks to have to adjust to set standards.

I guess that what I'm trying to say is that you're lucky if you work in phyton, because even though your limititations might be tight they are at least elastic and adjustable.

[ஒழுக்கின்மை (Paul Eres)]

I notice that a lot of people say that modern computers have eliminated many of the limits 2D had to deal with in the past, but in my experience that's just not the case. I could make much, much prettier 2D games if I didn't have the limits of my current computer (and it's not that bad -- core 2 duo 3.0h ghz, 8500 GT video card).

The main factor seems to be the fill rate -- the fill rate of most video cards is still not fast enough for everything that you'd want to do in a 2D game. Large numbers of sprites and particles still slow even modern systems down to a crawl. One day, this may not be the case, and certainly the limits are a lot higher than they were in the 80s and 90s, but there are still very crippling technological limits even in 2009 for 2D games.

I suspect part of the reason for that is that video cards nowadays are optimized for 3D polygonal games. Games in general would be very different if they were optimized for 2D sprite games, or even for 3D voxel games.

[BorisTheBrave]

You have to wonder if you could design 2d games to take advantage of graphics cards better. If fill rate is the problem, then developers should draw sprites front to back, setting some fake depth. Course, that doesn't help with semitransparent images, and thus anti-aliased ones too. But maybe someone who actually knows their hardware would be able to do something about it.

[Eclipse]

I notice that a lot of people say that modern computers have eliminated many of the limits 2D had to deal with in the past, but in my experience that's just not the case. I could make much, much prettier 2D games if I didn't have the limits of my current computer (and it's not that bad -- core 2 duo 3.0h ghz, 8500 GT video card).

The main factor seems to be the fill rate -- the fill rate of most video cards is still not fast enough for everything that you'd want to do in a 2D game. Large numbers of sprites and particles still slow even modern systems down to a crawl. One day, this may not be the case, and certainly the limits are a lot higher than they were in the 80s and 90s, but there are still very crippling technological limits even in 2009 for 2D games.

I suspect part of the reason for that is that video cards nowadays are optimized for 3D polygonal games. Games in general would be very different if they were optimized for 2D sprite games, or even for 3D voxel games.

what language\tools do you use? i can easily fill the screen of sprites having always a fixed 60 fps.
Also, graphics cards are not optimized for 3d, they're only very fast rasterizers with the possibility to do transform and lighting, that means they're optimized for 2d too, having vertices and polygons doesn't mean it's 3d, it's just the best way to transform and rasterize

[ஒழுக்கின்மை (Paul Eres)]

GM and Flash.

Filling the screen full of sprites is often not enough -- for some effects it's best to be able to fill the screen dozens or hundreds of times per frame, not just once, with sprites and particles being placed over one another with different transparencies and blend modes. Filling the screen full of sprites works if they're all opaque, but (as BorisTheBrave mentioned) as soon as you get into transparency and blend modes and anti-aliasing and so on, you need to do more than fill the screen once per frame.

Often reducing the resolution helps (my current major game uses 640x480 exclusively for that reason), but that too is a limit.

[ஒழுக்கின்மை (Paul Eres)]

Another thing is that a 2D game is often more than just sprites and particles -- there's the background, often with multiple layers; there may be overlay effects, like weather, fog, different lighting effects, and so on. They all add up.

And yes, you can always work around the limits, but that kind of misses the point of my post: that there are still major limits that you have to work around. The best-looking 2D game I've seen to date is

, but even that still felt like it was hindred by the limits of the PS2 hardware.

[mirosurabu]

Python, GameMaker and Flash are all virtual machines, so apart of slowdown coming from rendering, slowdown can easily come from logic part as well. I know that Python+PyGame with no drawing and just main loop runs at approximately 30fps on my 1.7GHz PC. (though, ActionScript seems a lot faster)

Additionally, Flash renders in software mode which imposes well-known limitations.

I haven't tried pushing the limits using my own hardware-accelerated renderer, so I can't really argue how much capable modern computers are when it comes to 2D graphics. But judging from number of 2D games I have seen, I'd say they are. (multiple parallax layers, multiple alpha-blended sprites and a lot of particles do not impose problems to me)

[ஒழுக்கின்மை (Paul Eres)]

Yes, sometimes the CPU is the rate-limiting factor, but usually you can tell the difference between when it's that and when it's the fill rate. When it's the fill rate, it'll vary drastically depending on the video card, whereas when it's the CPU, it'll remain mostly the same speed on different computers.

Also, being capable and being limited aren't exclusive or incompatible. Modern computers are very capable of making great 2D games, but they're also very limited as well.

[TheSpaceMan]

I have handled a couple of thousand, can't remember the exact values. I got a lot of crazy results based on differnt things.

The engine at the time was my own homemade directx engine, it, could only handle hard alpha trough the shader, those pixels where never drawn, as well as it only handled 3 or 4 diffrent depths, didn't sort in each depth.

The slowdown came first when I tried to make a Defered shading rendering solution for the project due to my limited knowledge in those areas.

But it's one of those projects where optimization the existing code can give incredible increase. The camera held renderable objects in one vector, the world in another. The camera would on a per frame basis go trough it's frustrum, and sort the objects into a scenegraph based on shader, texture, and mesh, finally it, if any of the steps didnt' exist it would create that node and from that point reuse it. One of the best speedups was just to clear the matrises in the last step, keeping shader, material and mesh in the correct order in the graph. Each new object was then just a pushback of a new matrix for position and rotation.

There are so many crazy ways to optimize this stuff if you know what you want and need. The problem comes down to when you use premade things that you don't know how they work with it internally. In this case I sacrifised decent alpha support.

[rogerlevy]

The "engine" of my game making tool in progress was shown the other day to handle 4000 sprites at 60fps on a 1.7ghz laptop with a radeon mobility 9700. 

If you are developing your own engine, use display lists.  They tend to gain huge yields.  Also do not use an interpreted scripting language if you need speed, because they are slow.

[ஒழுக்கின்மை (Paul Eres)]

How large are those sprites? The number of sprites is not really what matters in terms of slowdown, but the number of pixels filled. 4000 sprites is simple if they're 16x16 in size, but hard if they're 200x200 in size.

Additionally, sometimes 4000 sprites just aren't enough (as mentioned earlier).

[bateleur]

My current (AS3) game drops below 60fps with about 600 images on screen, though that's pre-optimisation so I expect I'll be able to get it faster.

The big problem is trying to work out what's the minimum spec I can support. The above is on my 2.4GHz machine with 1GB RAM, but I can't assume everyone has something that shiny.

[Eclipse]

GM and Flash.

so you're limited by the tools you use, not by todays tech i believe

i've just finished a flash game and i know what you mean, i had several layers in blending to do dinamic lighting and i needed to optimize a lot of code and even to cut some features to have a decent framerate on 640x480.
The same thing on my engine i believe would run over 3000 fps at that ridiculous resolution, flash and GM sucks

[Lynx]

These sprites are about 32x32 and 64x64, on a 640x480 window.  They're transparent, yep - most of these sprites are particle effects.  Agreed that interpreted scripting languages are slow.  I'm offloading as much as I can to rabbyt's bindings.

Having reviewed rabbyt's 'lotsosprites' example and trying a few alterations, it seems weird - the example is able to hit 7k sprites before it even starts slowing down.  There must be something that I'm doing wrong.

But if I can't work that out, then I'm going to have to figure out how to minimize the number of sprites I use.  How do you make good low-particle-count explosions and smoke trails?

[JLJac]

An explosion can be one single sprite, but that depends on the game's grafical style. A smoke trail has to have at least ten sprites at every given instant, otherwise it will look more like the rocket or burning object is leaving small puffs of smoke behind it. Ten sprites will make a pretty short trail though, you can't have any spaces between them or you will get the puff effect again.

I always give smoke and explosion sprites a random initial rotation, then in a smoke trail or such you can't tell that they all have the same bitmap reference.

If you can have 200 sprites at a time I think you don't need to worry

[Lynx]

Woo!  Good news, I pushed the limit up to 700 or so. 

The problem turns out to be that the pyglet and rabbyt schedulers are both actually fairly slow when you want them to run a ton of little events.  I set up the expiration times for particles to be on 50-msec boundaries and implemented a batch-mode expiration scheme for them.

Still not great, but progress.

[ஒழுக்கின்மை (Paul Eres)]

GM and Flash.

so you're limited by the tools you use, not by todays tech i believe

i've just finished a flash game and i know what you mean, i had several layers in blending to do dinamic lighting and i needed to optimize a lot of code and even to cut some features to have a decent framerate on 640x480.
The same thing on my engine i believe would run over 3000 fps at that ridiculous resolution, flash and GM sucks

Yes, but it's not just those tools, I've used other things. Some are less limited than others, but all have limits that limit how much you can do with 2D. My point was that until we're at the point where we can use trillions of sprites on screen at 200 fps, we're limited.

[TheSpaceMan]

GM and Flash.

so you're limited by the tools you use, not by todays tech i believe

i've just finished a flash game and i know what you mean, i had several layers in blending to do dinamic lighting and i needed to optimize a lot of code and even to cut some features to have a decent framerate on 640x480.
The same thing on my engine i believe would run over 3000 fps at that ridiculous resolution, flash and GM sucks

Yes, but it's not just those tools, I've used other things. Some are less limited than others, but all have limits that limit how much you can do with 2D. My point was that until we're at the point where we can use trillions of sprites on screen at 200 fps, we're limited.

Yeah thats the way it's allways going to be,  that being said it should with some amazing brainpowers be able to code a engine that in theroy only gets limited by the resolution I think... For at the end of the day there is only so many pixels you can draw on a screen at a final stage...

[Lynx]

Just thought I would throw in this useful tip...

It turns out Pyglet does an awful lot of OpenGL error checking.  This gets turned off if you compile in 'optimized' mode, but you can also configure it as follows:

Code:

import pyglet
# Disable error checking for increased performance
pyglet.options['debug_gl'] = False
from pyglet.gl import *

That line needs to be in before you import symbols from pyglet.gl.

Performance improved, um, dramatically.  And while trying to figure this out, I also brought in Lepton, a particle engine library for Python, and am pleased with how much better the explosions and smoke look.  So pushing at those limits has its uses.