Speedier sprites

[Brian_Raiter]

I have a 2-D tile-based game. Some of the tiles have transparent
areas. (When the program renders the game display 20 times/sec, it
has to do about 100 bits of tiles. The tile size is user-configurable,
but the most common size is 48x48 pixels.)

Currently, this is how the rendering works. The program requests a
32-bit SDL_Surface for the video screen, regardless of the native
setup. (24-bit color, no alpha channel.) The tiles are read from a BMP
file. Tiles with transparencies are specified by two tiles in the BMP
file, an image tile and a mask tile. The program stores the tiles are
stored in memory, 32 bits per pixel, with a special pixel value used
to indicate a transparent pixel. The transparent pixel value is
usually 0xFF000000. (It’s figured out using something like “~0UL ^
rmask ^ gmask ^ bmask”.) The tiles are stored in malloc()ed memory –
no SDL surfaces involved. I then have a few (relatively) simple
functions to “manually” blit tiles to the screen, minus the
transparent pixels.

Unfortunately, the above solution bypasses much of SDL. (The code
never once calls SDL_BlitSurface, for example) But, it was the fastest
of several approaches that I tested on my hardware, so it was what I
used.

However, I’ve gotten complaints from a few users that my program runs
too slowly on their machine. I believe that the bottleneck for them is
SDL’s translation of the screen from 32bpp to the native format. There
are enough people complaining to motivate me to try to create an
alternate display engine. Presumably this second engine should use a
native-format screen surface. The question is, how to deal with the
sprites?

Here are the ideas I’ve come up with. I’m hoping that someone here
with more SDL experience than myself can offer some guidance as to
which is more likely to bear fruit before I slog out a bunch of code.

1. Use SDL_SetColorKey() on my tile surfaces to get transparent
   pixels. This is the usual approach, but it requires my program to
   find a color to use for the key on the fly. And if the native
   format is only 8bpp, it is highly likely that there wouldn’t be any
   unused colors available. Increasing the pixel depth in order to
   make a 257th color available would only lose the advantage of
   keeping to the native format.

2. Keep the tiles in my non-SDL memory, with 32 bits per pixel, but
   using native pixel values. (0xFF000000 will still mark transparent
   pixels.) Write three more sets of tile-copying functions to handle
   8-, 16-, and 24-bit destination surfaces. This is the approach that
   I’m leaning toward at the moment, though it probably involves the
   most new code.

3. Add alpha values to the tile pixels, using only 0 and 255. Use
   SDL_DisplayFormatAlpha() to create the tile surfaces, and use
   SDL_BlitSurface() to copy these to the screen surface. My initial
   tests suggest that this approach would be SLOW.

4. Something else entirely that I haven’t thought of.

b

[David_Olofson]

[…]

1. Use SDL_SetColorKey() on my tile surfaces to get transparent
   pixels. This is the usual approach, but it requires my program
   to find a color to use for the key on the fly.

Not really. If you’re using the same key for all tiles and sprites,
it’s just a fixed value.

Either way, I don’t see how this differs from your current approach.
You still need to use a particular value for the key, right? Just
hand it to SDL_SetColorKey() instead.

And if the native
format is only 8bpp, it is highly likely that there wouldn’t be any
unused colors available.

That’s one reason why I never use SDL_SetColorKey() - although I’m not
sure it’s a valid reason.

Theoretically, you could RLE encode colorkeyed surfaces without
allocating an actual value for the key. One might assume that this is
what you get if you take a 32 bit surface, SDL_SetColorKey() is,
enabling RLE encoding, and then convert the surface. However, I think
you just lose the colorkeying and RLE properties in the conversion as
it is.

[…]

2. Keep the tiles in my non-SDL memory, with 32 bits per pixel, but
   using native pixel values. (0xFF000000 will still mark
   transparent pixels.) Write three more sets of tile-copying
   functions to handle 8-, 16-, and 24-bit destination surfaces. This
   is the approach that I’m leaning toward at the moment, though it
   probably involves the most new code.

The advantage is that you still have full control. However, I think
it’s pretty hard to beat the SDL blitters for generic blitting, if
you make use of SDL’s RLE. Even if you want custom effects, you don’t
have to reimplement all blitters.

3. Add alpha values to the tile pixels, using only 0 and 255. Use
   SDL_DisplayFormatAlpha() to create the tile surfaces, and use
   SDL_BlitSurface() to copy these to the screen surface. My
   initial tests suggest that this approach would be SLOW.

This is exactly the same speed as colorkeying if you do it right. Use
RLE acceleration. Only pixels that are actually alpha blended will
cost extra. (I use this for AA all over the place in Kobo Deluxe.)

4. Something else entirely that I haven’t thought of.

Well, there’s always OpenGL…

You shouldn’t need this for plain 2D without alpha blending with most
drivers on Win32, but many other platforms lack efficient ways of
supperting software rendering, leaving you no other alternative than
OpenGL if you want decent frame rates in resolutions higher than
320x240.

If you don’t want to mess with OpenGL directly, just implement it with
SDL blitters and then try compiling with glSDL.

//David Olofson - Programmer, Composer, Open Source Advocate

.- The Return of Audiality! --------------------------------.
| Free/Open Source Audio Engine for use in Games or Studio. |
| RT and off-line synth. Scripting. Sample accurate timing. |
`-----------------------------------> http://audiality.org -’
— http://olofson.net — http://www.reologica.se —On Tuesday 11 March 2003 03.03, Brian Raiter wrote:

[rsteinke_at_w-link.n]

4. Something else entirely that I haven’t thought of.

Well, there’s always OpenGL…

You shouldn’t need this for plain 2D without alpha blending with most
drivers on Win32, but many other platforms lack efficient ways of
supperting software rendering, leaving you no other alternative than
OpenGL if you want decent frame rates in resolutions higher than
320x240.

If you don’t want to mess with OpenGL directly, just implement it with
SDL blitters and then try compiling with glSDL.

If you want something completely different, I once did
something like this with extremely aggressive caching.
Basically, for every possible combination of tile layers
render the image once (as you need it), and cache it
for later reuse. That way, alpha rendering isn’t time
critical. If you want to look at my example, it’s up
at http://hexmap.sourceforge.net.

Ron Steinke

“The sound of gunfire, off in the distance. I’m getting used to it now.”
– Talking Heads> From: David Olofson

On Tuesday 11 March 2003 03.03, Brian Raiter wrote:

[Anatoly_R]

Hello Brian,

Tuesday, March 11, 2003, 4:03:40 AM, you wrote:

BR> 2. Keep the tiles in my non-SDL memory, with 32 bits per pixel, but
BR> using native pixel values. (0xFF000000 will still mark transparent
BR> pixels.) Write three more sets of tile-copying functions to handle
BR> 8-, 16-, and 24-bit destination surfaces. This is the approach that
BR> I’m leaning toward at the moment, though it probably involves the
BR> most new code.

You might check my sources (http://bgs.sf.net) for DrawPixel or
something like that routine. I’ve found it somewhere else… Very
compact and works almost perfectly.–
Lynx,
http://dotNet.lv mailto:@Anatoly_R

[Glenn_Maynard]

Currently, this is how the rendering works. The program requests a
32-bit SDL_Surface for the video screen, regardless of the native
setup. (24-bit color, no alpha channel.) The tiles are read from a BMP
file. Tiles with transparencies are specified by two tiles in the BMP
file, an image tile and a mask tile.

Yuck, that’s silly. Use PNGs with an alpha channel. Much easier to
edit and much smaller. (If you don’t want to use full alpha, just force
the values to on and off.)

Unfortunately, the above solution bypasses much of SDL. (The code
never once calls SDL_BlitSurface, for example) But, it was the fastest
of several approaches that I tested on my hardware, so it was what I
used.

You might want to investigate to find out which underlying SDL blit
you’re using, and find out why your own code is faster. It’s likely
that some setting is causing SDL to use a slower blit that’s doing extra
work which you don’t really need, which your own blit code doesn’t do,
in which case you can probably get SDL to use a more appropriate blit.
(Compile SDL in debug, and trace through the blit selection code. I’m
not sure if there’s an easier way to do this.)

Note that several of the more important SDL blits are assembly-optimized,
and almost all of the C versions are loop-unrolled. They’re reasonably
well-optimized.

And, as David pointed out, make sure you’re using RLE if you can.

1. Use SDL_SetColorKey() on my tile surfaces to get transparent
   pixels. This is the usual approach, but it requires my program to
   find a color to use for the key on the fly. And if the native
   format is only 8bpp, it is highly likely that there wouldn’t be any
   unused colors available. Increasing the pixel depth in order to
   make a 257th color available would only lose the advantage of
   keeping to the native format.

First off, obligatory noise: Color keying sucks. (But, I usually use
OpenGL, so I never need it.)

I doubt anybody is actually using paletted (8-bit) display surfaces. It’s
much easier to say “RGB screens only” and disallow that case completely.
(Handling paletted display surfaces is a whole bunch of new cases; it’s
a pain, especially if you have non-paletted image data.)

Note that the (non-RLE) color key blits in SDL are less optimized. (There
are a lot of different optimized blits for various important conversions, but
only a couple generic ones for color keying.)

2. Keep the tiles in my non-SDL memory, with 32 bits per pixel, but
   using native pixel values. (0xFF000000 will still mark transparent
   pixels.) Write three more sets of tile-copying functions to handle
   8-, 16-, and 24-bit destination surfaces. This is the approach that
   I’m leaning toward at the moment, though it probably involves the
   most new code.

Er. I’m assuming by “native pixel values” you mean that the pixel data
format matches that of the screen. (That’s the point; that way, if you
have 16-bit data, you can simply pull two bytes–a pixel–out of the
input, drop it in the output and be done; to copy 16 pixels, you just
copy over 32 bytes.) How can you use 0xFF000000 to mark transparency if
you’re doing that? That implies 1: a 32-bit hardware surface and 2:
those eight bits are never going to be used by the hardware surface.

If you’re thinking about storing 16-bit data by spreading it into 32
bits and ignoring half of it, realize that this will slow down blits
enormously–it’s doubling your memory access for nothing (and most of
these blits are bottlenecked by memory access alone).On Mon, Mar 10, 2003 at 06:03:40PM -0800, Brian Raiter wrote:

–
Glenn Maynard

[Brian_Raiter]

[combining replies to several people in one email]

David Olofson:

3. Add alpha values to the tile pixels, using only 0 and 255. Use
   SDL_DisplayFormatAlpha() to create the tile surfaces, and use
   SDL_BlitSurface() to copy these to the screen surface. My
   initial tests suggest that this approach would be SLOW.

This is exactly the same speed as colorkeying if you do it right.
Use RLE acceleration. Only pixels that are actually alpha blended
will cost extra. (I use this for AA all over the place in Kobo
Deluxe.)

I guess I wasn’t doing it right in my tests, then. I will revisit the
alpha approach and see what I can get.

Ron Steinke:

If you want something completely different, I once did something
like this with extremely aggressive caching. Basically, for every
possible combination of tile layers render the image once (as you
need it), and cache it for later reuse. That way, alpha rendering
isn’t time critical.

I thought of this originally. Unfortunately, many (maybe most) of my
combined tiles are not drawn one directly on top of the other, but are
drawn off-center by various amounts. The number of potential
combinations is pretty high.

Glenn Maynard:

Yuck, that’s silly. Use PNGs with an alpha channel. Much easier
to edit and much smaller. (If you don’t want to use full alpha,
just force the values to on and off.)

The tiles are meant to be user-editable. A significant number of my
user base wouldn’t be able to view a PNG, much less edit one.

First off, obligatory noise: Color keying sucks.

Well, that’s the second person to disaparage color-keying. Given the
inherent difficulty of using color-keying reliably in this particular
situation, I’ll follow your advice most willingly.

I doubt anybody is actually using paletted (8-bit) display surfaces.

Actually, a number of my users are using 8-bit displays.

How can you use 0xFF000000 to mark transparency if you’re doing
that? That implies 1: a 32-bit hardware surface and 2: those eight
bits are never going to be used by the hardware surface.

The point is that the pixel data isn’t in an SDL_Surface at all. It’s
just my own malloced memory.

Anyway, I won’t go into further details with regard to your comments
on this idea. It sounds like what I need to do is forget this approach
and give alpha channels another try.

Thanks to everyone who responded. I really appreciate the helping
hands.

b

[Eddy_L_O_Jansson]

2003-03-11 23:54:00, Brian Raiter wrote:

The tiles are meant to be user-editable. A significant number of my
user base wouldn’t be able to view a PNG, much less edit one.

If they have a graphical web browser released within the last five years or so, then yes they can view
it.

Here’s a hint; Internet Explorer v1.5 is ©Microsoft in 1996. In 1997 IE got caught up and got png-
support. If you go that far back, then you’ll gotta assume that most users can’t handle long filenames
too!

The “png isn’t widely supported”-meme needs to be put to rest. It’s uneducated, IMHO.

As for editing, unless you provide a complete toolchain – in which case your objection would be moot
anyway – I believe you can expect who are people deep enough into gaming to edit tiles, to actually
know about and use png.

[Glenn_Maynard]

The tiles are meant to be user-editable. A significant number of my
user base wouldn’t be able to view a PNG, much less edit one.

Actually, a number of my users are using 8-bit displays.

Gross. Are you targetting the SNES? I havn’t used a system that needed
paletted output in a decade (unless you count the VGA text console with
aalib), and PNG is ubiquitous.

Good luck, then; you’ll need it.

How can you use 0xFF000000 to mark transparency if you’re doing
that? That implies 1: a 32-bit hardware surface and 2: those eight
bits are never going to be used by the hardware surface.

The point is that the pixel data isn’t in an SDL_Surface at all. It’s
just my own malloced memory.

The point of this was just that if your pixel data matched the hardware type,
the only way you could use 0xFF000000 to mark transparency is if those bits
were unused.On Tue, Mar 11, 2003 at 02:54:00PM -0800, Brian Raiter wrote:

–
Glenn Maynard

[David_Olofson]

[…]

The “png isn’t widely supported”-meme needs to be put to rest.
It’s uneducated, IMHO.

Well, there’s only one problem: Many browsers still don’t handle the
alpha channel correctly. I don’t know of any graphical browser that
does not support PNG at all, though.

As for editing, unless you provide a complete toolchain – in
which case your objection would be moot anyway – I believe you can
expect who are people deep enough into gaming to edit tiles, to
actually know about and use png.

I don’t know of any reasonably useful graphics applications without
PNG support. Maybe there are some; dunno… (No, nothing that came
with Windows counts - unless they started bundling something serious
lately.)

Besides, GIMP is Free and runs on Un*x and Win32. AFAIK, there’s also
a Mac OS version, but I don’t know anything about it’s state.

PaintShop Pro is very low cost (like a game, IIRC) and appears to be
pretty competent, at least for it’s price. (I don’t know it very
well. I came from PhotoShop and then switched to GIMP when I started
using Linux.)

Anyway, what if you want real alpha? (For AA, effects and stuff.) Then
your only alternative to PNG would be TGA - and you don’t want to use
that unless you store your files in compressed archives… heh

//David Olofson - Programmer, Composer, Open Source Advocate

.- The Return of Audiality! --------------------------------.
| Free/Open Source Audio Engine for use in Games or Studio. |
| RT and off-line synth. Scripting. Sample accurate timing. |
`-----------------------------------> http://audiality.org -’
— http://olofson.net — http://www.reologica.se —On Wednesday 12 March 2003 00.23, Eddy L O Jansson wrote:

[David_Olofson]

The tiles are meant to be user-editable. A significant number of
my user base wouldn’t be able to view a PNG, much less edit one.

Actually, a number of my users are using 8-bit displays.

Gross. Are you targetting the SNES? I havn’t used a system that
needed paletted output in a decade (unless you count the VGA text
console with aalib), and PNG is ubiquitous.

Well, they could be using it for speed. As many of us know too well,
fullscreen s/w rendering gets dog slow in any "acceptable"
resolutions on some platforms. (That’s the main reason for glSDL; it
was simply the only option.)

Good luck, then; you’ll need it.

Well, the SDL blitters should work fine, as long as you’re not
actually alpha blending. The conversion code would have to be
relatively sophisticated for nice results (creating a palette based
on total color statistics, and then dithering using that palette),
but at least, it’s not time critical. You do it at load time, and
they you just blit surfaces as usual.

//David Olofson - Programmer, Composer, Open Source Advocate

.- The Return of Audiality! --------------------------------.
| Free/Open Source Audio Engine for use in Games or Studio. |
| RT and off-line synth. Scripting. Sample accurate timing. |
`-----------------------------------> http://audiality.org -’
— http://olofson.net — http://www.reologica.se —On Wednesday 12 March 2003 00.25, Glenn Maynard wrote:

On Tue, Mar 11, 2003 at 02:54:00PM -0800, Brian Raiter wrote:

[Glenn_Maynard]

I guess. Seems like trading down, to me.On Wed, Mar 12, 2003 at 02:13:20AM +0100, David Olofson wrote:

Well, they could be using it for speed. As many of us know too well,
fullscreen s/w rendering gets dog slow in any "acceptable"
resolutions on some platforms. (That’s the main reason for glSDL; it
was simply the only option.)

–
Glenn Maynard

[David_Olofson]

Well, to me, an action game is totally unplayable if the frame rate is
significantly below 30 fps. I’d rather play with poor graphics than
get infuriated by a series of nice looking still images.

Of course, with OpenGL and any recent $70+ 3D card, pretty much any 2D
game could do >60 fps in 1024x768x32, so why trade at all?

//David Olofson - Programmer, Composer, Open Source Advocate

.- The Return of Audiality! --------------------------------.
| Free/Open Source Audio Engine for use in Games or Studio. |
| RT and off-line synth. Scripting. Sample accurate timing. |
`-----------------------------------> http://audiality.org -’
— http://olofson.net — http://www.reologica.se —On Wednesday 12 March 2003 02.38, Glenn Maynard wrote:

On Wed, Mar 12, 2003 at 02:13:20AM +0100, David Olofson wrote:

Well, they could be using it for speed. As many of us know too
well, fullscreen s/w rendering gets dog slow in any "acceptable"
resolutions on some platforms. (That’s the main reason for glSDL;
it was simply the only option.)

I guess. Seems like trading down, to me.

[Anatoly_R]

Hello Glenn,

Wednesday, March 12, 2003, 3:38:16 AM, you wrote:

GM> On Wed, Mar 12, 2003 at 02:13:20AM +0100, David Olofson wrote:

Well, they could be using it for speed. As many of us know too well,
fullscreen s/w rendering gets dog slow in any "acceptable"
resolutions on some platforms. (That’s the main reason for glSDL; it
was simply the only option.)

GM> I guess. Seems like trading down, to me.

Doh, that mumbling about slow sprites sounds like pure stupidism to
me. I’m using P166MMX for tests with old Matrox Millenium 4mb and I
still find that MANY NEW 2D games (including those, which use SDL) are
running full speed! And they even have MORE details than those, who
are running slow.

I wasn’t working on anything SDL related in couple of monthes, but as
far as I remember apps which were using PNGs, MP3 sound etc were
running absolutely fine on that box. And I DON’T CALL IT LOWEND (some
of you probably call P2-P3 “lowend”).

My opinion about using obsolete formats is:

Those, who still try to use BMPs and force users to use them instead
of PNGs in GAMING !ENGINES! are slowing down industry progress. They
start spreading rumours that PNGs aren’t spreaded widely, alpha eats
all your resources on P4/3ghz with 1gig of RAM etc etc etc.

That reminds me browser wars (I still here “Mozilla sucks since it
renders my 100% correct page incorrectly”).

Stop finding excuses, get lowend box and find best SDL videoflags and
make couple of different benchmarks with different blitting methods.

It would take you MUCH LESS TIME and bring you MUCH MORE EXPERIENCE
than your mumbling in mailing lists.

.

8 bit colors in 2003… OMG.

SDL isn’t ported to systems which are limited to 256 colors.
There is no SDL on GBA, SNES (LOL), GP32.–
Lynx,
http://dotNet.lv mailto:@Anatoly_R

[J_Grant1]

Well, to me, an action game is totally unplayable if the frame rate is
significantly below 30 fps. I’d rather play with poor graphics than
get infuriated by a series of nice looking still images.

Of course, with OpenGL and any recent $70+ 3D card, pretty much any 2D
game could do >60 fps in 1024x768x32, so why trade at all?

Well, providing the screen refresh is at least 50hz any thing as low as
24fps would be fine, afterall this is what films use (each frame is
displayed twice per frame I believe). I developed "Hover Boarding 3D"
for playstation, this game was fine at 25fps, and it was a fast paced
action game.

Generally the animations in a scene are less than the scene fps. If the
fps was less than the number of animation fps then that would be a problem.

JG

[Stephen_Anthony]

I don’t think this is always true. Films may be only 24 fps, but they
take advantage of motion blur. That is, any two consecutive frames
consist of parts of the image from each one, blurred over the time they
are shown. That optical illusion fools the eye into thinking that there
are more frames.

In a game, the frame you have will usually be distinct from the previous
one (unless you do motion blur on your own). As a result, you need
more fps than the typical fim to achieve the same result.

The fact that people can tell the difference between 30, 60, and 100 fps
in a game indicates that 24 fps is not always fine.

SteveOn March 12, 2003 11:32 am, J. Grant wrote:

Well, to me, an action game is totally unplayable if the frame rate
is significantly below 30 fps. I’d rather play with poor graphics
than get infuriated by a series of nice looking still images.

Of course, with OpenGL and any recent $70+ 3D card, pretty much any
2D game could do >60 fps in 1024x768x32, so why trade at all?

Well, providing the screen refresh is at least 50hz any thing as low as
24fps would be fine, afterall this is what films use (each frame is
displayed twice per frame I believe). I developed "Hover Boarding 3D"
for playstation, this game was fine at 25fps, and it was a fast paced
action game.

[David_Olofson]

Well, to me, an action game is totally unplayable if the frame
rate is significantly below 30 fps. I’d rather play with poor
graphics than get infuriated by a series of nice looking still
images.

Of course, with OpenGL and any recent $70+ 3D card, pretty much
any 2D game could do >60 fps in 1024x768x32, so why trade at all?

Well, providing the screen refresh is at least 50hz any thing as
low as 24fps would be fine,

No, not to my eyes. It looks blurred, and my head starts to hurt after
playing for too long.

afterall this is what films use (each
frame is displayed twice per frame I believe).

Films have motion blur, and they’re generally 3D, which means you
don’t see much fast pure 2D motions.

I developed “Hover
Boarding 3D” for playstation, this game was fine at 25fps, and it
was a fast paced action game.

It was also 3D. In my experience, 3D action games in general are still
playable at about half the fram rate of the lowest requirement for a
2D action game.

Generally the animations in a scene are less than the scene fps.

Animations, yes - if you have them at all. Scrolling and movement is
what matters though, and those are often faster than 50
pixels/second.

If the fps was less than the number of animation fps then that
would be a problem.

Not really. You wouldn’t notice much, unless the animations were huge
and/or very fast.

//David Olofson - Programmer, Composer, Open Source Advocate

.- The Return of Audiality! --------------------------------.
| Free/Open Source Audio Engine for use in Games or Studio. |
| RT and off-line synth. Scripting. Sample accurate timing. |
`-----------------------------------> http://audiality.org -’
— http://olofson.net — http://www.reologica.se —On Wednesday 12 March 2003 16.02, J. Grant wrote:

[Stanley_Brown]

The fact that people can tell the difference between 30, 60, and 100 fps
in a game indicates that 24 fps is not always fine.

Agreed. But 24 FPS isnt horrible though for some games. If you refresh
at 100 fps and you only have 5 unique frames displayed in that time it
will look exactly the same at 20 fps. The more unique frames you need
displayed the higher your refresh rate needs to be.

[David_Olofson]

Yeah, but that’s not the big issue here. The real problems are with
scrolling and sprite movement; not animation.

//David Olofson - Programmer, Composer, Open Source Advocate

.- The Return of Audiality! --------------------------------.
| Free/Open Source Audio Engine for use in Games or Studio. |
| RT and off-line synth. Scripting. Sample accurate timing. |
`-----------------------------------> http://audiality.org -’
— http://olofson.net — http://www.reologica.se —On Wednesday 12 March 2003 17.00, Stanley Brown wrote:

The fact that people can tell the difference between 30, 60, and
100 fps in a game indicates that 24 fps is not always fine.

Agreed. But 24 FPS isnt horrible though for some games. If you
refresh at 100 fps and you only have 5 unique frames displayed in
that time it will look exactly the same at 20 fps. The more unique
frames you need displayed the higher your refresh rate needs to be.

[Stanley_Brown]

David Olofson wrote:>On Wednesday 12 March 2003 17.00, Stanley Brown wrote:

The fact that people can tell the difference between 30, 60, and
100 fps in a game indicates that 24 fps is not always fine.

Agreed. But 24 FPS isnt horrible though for some games. If you
refresh at 100 fps and you only have 5 unique frames displayed in
that time it will look exactly the same at 20 fps. The more unique
frames you need displayed the higher your refresh rate needs to be.

Yeah, but that’s not the big issue here. The real problems are with
scrolling and sprite movement; not animation.

Scrolling and sprite movement, which are both forms of animation,
produce unique frames.

[David_Olofson]

David Olofson wrote:

The fact that people can tell the difference between 30, 60,
and 100 fps in a game indicates that 24 fps is not always fine.

Agreed. But 24 FPS isnt horrible though for some games. If you
refresh at 100 fps and you only have 5 unique frames displayed in
that time it will look exactly the same at 20 fps. The more
unique frames you need displayed the higher your refresh rate
needs to be.

Yeah, but that’s not the big issue here. The real problems are
with scrolling and sprite movement; not animation.

Scrolling and sprite movement, which are both forms of animation,
produce unique frames.

Well, yes, but if we’re talking about “5 unique frames”, it sounds a
lot more like “sprite image animation” than movement to me - and I
have a hard time seeing how it could happen for more than brief
moments in a scrolling game.

At least, very few enemies in Kobo Deluxe ever move that slow, and
scrolling is constantly at 100 pixels/s. (320x240; multiply with
scale factor.) Situations where you can’t tell 33 fps from 80 fps are
virtually nonexistent in that game.

//David Olofson - Programmer, Composer, Open Source Advocate

.- The Return of Audiality! --------------------------------.
| Free/Open Source Audio Engine for use in Games or Studio. |
| RT and off-line synth. Scripting. Sample accurate timing. |
`-----------------------------------> http://audiality.org -’
— http://olofson.net — http://www.reologica.se —On Wednesday 12 March 2003 18.23, Stanley Brown wrote:

On Wednesday 12 March 2003 17.00, Stanley Brown wrote: