OpenGL or pure SDL gfx?

SDL Development
1

Still working on my “game”.

I want it to be just a 2D game, but with a scrolling background. I’ve read a lot about SDL and GL and linux game programming in general now, and I’m still not able to get really smooth scrolling without resorting to openGL (I guess it has to do with GL supporting my hardware while SDL does not?). But I don’t really want any 3d effects or anything, so I think it’s perhaps a little “overkill” to use GL just to get smoother scrolling (also I’m puzzled by the fact that my 1,5ghz PC can’t produce smooth scrolling, when it was not much of a problem on one of those good ol 7,14mhz (iirc) computers).

What do you think? Is it normal to use GL for the gfx part, even when the game is not 3d? Sounds a little weird to me, but who knows. For now it seems to be the only way to get some hw supported scrolling.

Regards
Henning

2

I think you loose little in using OpenGL for your 2d game.

That is what I am using in my 2d project Kung Fu Kitsch, and I think
lots of linux 2d games do so too.

And you get some additional things free with the SDL/OpenGL
combination:

  • OpenGL is h/w more often than standard SDL-blitting
  • OpenGL may rotate any sprite for free
  • It’s good know-how in computer graphics in general
  • SDL has an active community and lots of games
    use it, and this mailing list is really great

Anyway, I can’t see why you’re not able to do smooth scrolling on you
machine using SDL-blitting… even if it is software it should be
smooth.

/Olof

Henning: “[SDL] OpenGL or pure SDL gfx?” (2003-09-14 23:55)

#Still working on my “game”.#
#I want it to be just a 2D game, but with a scrolling background. I’ve read a lot about SDL and GL and linux game programming in general now, and I’m still not able to get really smooth scrolling without resorting to openGL (I guess it has to do with GL supporting my hardware while SDL does not?). But I don’t really want any 3d effects or anything, so I think it’s perhaps a little “overkill” to use GL just to get smoother scrolling (also I’m puzzled by the fact that my 1,5ghz PC can’t produce smooth scrolling, when it was not much of a problem on one of those good ol 7,14mhz (iirc) computers).

#What do you think? Is it normal to use GL for the gfx part, even when the game is not 3d? Sounds a little weird to me, but who knows. For now it seems to be the only way to get some hw supported scrolling.

#Regards
#Henning

#_______________________________________________
#SDL mailing list
#SDL at libsdl.org
#http://www.libsdl.org/mailman/listinfo/sdl

3

Henning, just to know, are you using software or hardware surfaces?
I was able to get about 70fps on a Celeron 300 with an accelerated
video card (i think it was an ATI video card), all using only SDL
harware surfaces with RLE acceleration for colorkey based blits. With
software surfaces I could get about 60fps on a Athlon XP+ processor,
which is smooth for 2D scrolling. And m y game was running at 640x480
with 32bpp.

However, when I ported the game to MAC OS X I had some performance

problems with hardware surfaces, the blits are not that much
accelerated on that platafform due to the way Quartz handle video
operations (I got about 30fps when connected to the power adpter, ie,
processor at full speed).

At that point I changed to Open GL and after that, the game can

achieve about 300fps on my iBook 900 on energy saving mode when I turn
off my frame control (and I have an abusive number of objects on
screen). By these figures you can say that it’s worth to change to Open
GL, also you have some freebies:

- Fast zoom and roration
- Hardware alpha blits
- You can try some cool 3D effects to blend in your 2D game

The only con: if the target computer does not support Open GL by

harware, your game will suck big time. But as it’s quite difficult to
find a gamer that does not have accelerated video cards these days, you
can forget it.

I would say for you to go for it, it's worth, it may change some ways

you handle things in your game, but overall it will be much faster.

PauloEm Sunday, 14, September, 2003, ?s 05:55  PM, Henning escreveu:

Still working on my “game”.

I want it to be just a 2D game, but with a scrolling background. I’ve
read a lot about SDL and GL and linux game programming in general now,
and I’m still not able to get really smooth scrolling without
resorting to openGL (I guess it has to do with GL supporting my
hardware while SDL does not?). But I don’t really want any 3d effects
or anything, so I think it’s perhaps a little “overkill” to use GL
just to get smoother scrolling (also I’m puzzled by the fact that my
1,5ghz PC can’t produce smooth scrolling, when it was not much of a
problem on one of those good ol 7,14mhz (iirc) computers).

What do you think? Is it normal to use GL for the gfx part, even when
the game is not 3d? Sounds a little weird to me, but who knows. For
now it seems to be the only way to get some hw supported scrolling.

Regards
Henning

SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl

4

Still working on my “game”.

I want it to be just a 2D game, but with a scrolling background. I’ve read a lot about SDL and GL and linux game programming in general now, and I’m still not able to get really smooth scrolling without resorting to openGL (I guess it has to do with GL supporting my hardware while SDL does not?). But I don’t really want any 3d effects or anything, so I think it’s perhaps a little “overkill” to use GL just to get smoother scrolling (also I’m puzzled by the fact that my 1,5ghz PC can’t produce smooth scrolling, when it was not much of a problem on one of those good ol 7,14mhz (iirc) computers).

There is nothing weird, wrong, or “over kill” about using OpenGL to
write a 2D game. If it is the only way to get access to hardware
graphics then it is the only way. So, use it.

The bit about the difference in performance between an original 4Mhz PC
and a 1.5Ghz modern PC is a complete red herring. The volume of data you
have to move around on a modern PC huge compared to what we dealt with
on the original PC. Not to mention that we used lots of tricks, were the
only task running on the PC, and manipulated the hardware directly. Now
days you are never the only process running, can’t use any of the same
tricks, but we have astoundingly better hardware. So, if you use the
hardware you can get the effect of what you want. Though, true perfectly
timed smooth scrolling really isn’t possible anymore.

What do you think? Is it normal to use GL for the gfx part, even when the game is not 3d? Sounds a little weird to me, but who knows. For now it seems to be the only way to get some hw supported scrolling.

Use OpenGL. It works.

	Bob PendletonOn Sun, 2003-09-14 at 16:55, Henning wrote:

Regards
Henning

SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl
–
±----------------------------------+

5

Listen to bob!

Not sure if you know this but you can set “Orthographic” mode in OpenGL
where when you draw its 2d, so its not too wierd, plus if its faster, why
not?> ----- Original Message -----

From: bob@pendleton.com (Bob Pendleton)
To: “SDL Mailing List”
Sent: Sunday, September 14, 2003 3:34 PM
Subject: Re: [SDL] OpenGL or pure SDL gfx?

On Sun, 2003-09-14 at 16:55, Henning wrote:

Still working on my “game”.

I want it to be just a 2D game, but with a scrolling background. I’ve
read a lot about SDL and GL and linux game programming in general now, and
I’m still not able to get really smooth scrolling without resorting to
openGL (I guess it has to do with GL supporting my hardware while SDL does
not?). But I don’t really want any 3d effects or anything, so I think it’s
perhaps a little “overkill” to use GL just to get smoother scrolling (also
I’m puzzled by the fact that my 1,5ghz PC can’t produce smooth scrolling,
when it was not much of a problem on one of those good ol 7,14mhz (iirc)
computers).

There is nothing weird, wrong, or “over kill” about using OpenGL to
write a 2D game. If it is the only way to get access to hardware
graphics then it is the only way. So, use it.

The bit about the difference in performance between an original 4Mhz PC
and a 1.5Ghz modern PC is a complete red herring. The volume of data you
have to move around on a modern PC huge compared to what we dealt with
on the original PC. Not to mention that we used lots of tricks, were the
only task running on the PC, and manipulated the hardware directly. Now
days you are never the only process running, can’t use any of the same
tricks, but we have astoundingly better hardware. So, if you use the
hardware you can get the effect of what you want. Though, true perfectly
timed smooth scrolling really isn’t possible anymore.

What do you think? Is it normal to use GL for the gfx part, even when
the game is not 3d? Sounds a little weird to me, but who knows. For now it
seems to be the only way to get some hw supported scrolling.

Use OpenGL. It works.

Bob Pendleton

Regards
Henning

SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl
–
±----------------------------------+

SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl

6

StepMania is a good example of what can be done with OpenGL for a
primarily 2D game. Give the current alpha 4 a shot (pardon the plug):

http://sourceforge.net/project/showfiles.php?group_id=37892

You won’t be able to play the game without some music files, but
the rest of the interface shows off lots of very smooth scrolling,
even with a extra passes for sprite drop shadows and other effects.

OpenGL introduces its own fair set of compatibility issues, of course–but
you get that in any accelerated API.

(Note that only the Windows end is mature; the *nix and Mac ports are
fairly new. Apologies that there’s no source link for the snapshot; that
will be corrected in the next snapshot.)On Sun, Sep 14, 2003 at 11:55:26PM +0200, Henning wrote:

What do you think? Is it normal to use GL for the gfx part, even when the game is not 3d? Sounds a little weird to me, but who knows. For now it seems to be the only way to get some hw supported scrolling.

–
Glenn Maynard

7 
Henning, just to know, are you using software or hardware surfaces?

It makes no difference on the performance, so I’m pretty sure I only have a software surface, even when I try to get a hw surface.

get about 70fps on a Celeron 300 with an accelerated

It’s not really the framerate that’s bad, it seems okay and above 50, but the quality of the scrolling is not good. I have tried downloading other games that use SDL, and they display about the same bad scrolling.
It’s not a big problem, it’s just that I have seen scrolling with GL, and that looks great. So I wondered if I wanted to make the change to get that kind of scrolling.

video card (i think it was an ATI video card), all using only SDL
harware surfaces with RLE acceleration for colorkey based blits. With

I have tried with RLE acc. and hw-surfaces and double buffering. I used the DisplayFormat which helps a little, but still not enough.

Anyway, I think you’ve convinced me to go for GL. Which means I’ll have to go get some tutorial on that too. Oh, so much reading to do…

Regards
Henning

8

IMHO its overkill to use OpenGL for a simple 2D game.

As noted previously you would restrict your audience mainly
to people with hw-accelerated opengl-supported systems.

And I dont think that this kind of people will play your 2D game
very long, because they maybe have lot of other real cool 3D games.

IMHO the audience for simple 2D games are for example children
(and their parents who have to buy the game…).

So to buy and play a simple game for their kids, they wuold have to
provide a hw-accel opengl system…
In my eyes an unnecessary additional restriction…

Its possible to write a soft-scroller without opengl. Maybe there is something
completely wrong in your main game loop or your understanding of SDL
and/or programming.
Maybe you should solve this point instead of ignoring it and just switch
to opengl.

I would suggest to reduce your current game code to a minimal game loop
which still shows the worse scrolling and to post this demo code.
It should be possible to write this code in say 20 to 50 lines of code
(hopefully).

Or send it privately to me if you dont dare to post. But not just some code
fragments: a minimal simple small running demo loop which shows the
worse scrolling.

Thomas

9

IMHO its overkill to use OpenGL for a simple 2D game.

Probably - but then again, I considered purchasing a full version of
"Raptor: Call of the shadows", but never did, because there was no
way I could get a decent frame rate on any hardware or OS it would
run on. (It actually seems like the game has a logic frame rate limit
somewhere around 20 fps or so.) The blurring or jerking that frame
rates below ~60 Hz result in gives me a headache and makes it hard to
see what’s going on.

I’m not sure what you mean by “simple”, but this applies to any game
that scrolls a major area of the screen, unless it runs only in
320x240 mode.

As noted previously you would restrict your audience mainly
to people with hw-accelerated opengl-supported systems.

Or you could support both SDL 2D and OpenGL… glSDL is an easy way of
doing that, while actually coding only for the SDL 2D API.

And I dont think that this kind of people will play your 2D game
very long, because they maybe have lot of other real cool 3D games.

If they don’t, it’s because it’s a boring game. 3D doesn’t
automatically make games better or more addictive.

IMHO the audience for simple 2D games are for example children
(and their parents who have to buy the game…).

The vast majority of Kobo Deluxe players seem to be adults. :wink: And
the game is probably way too hard for kids that are too young for 3D
games…

Anyway, it’s a Free game, and I don’t know exactly how many active
players there are, so I can’t really talk about an “audience” in the
way you would about a commercial game.

So to buy and play a simple game for their kids, they wuold have to
provide a hw-accel opengl system…
In my eyes an unnecessary additional restriction…

If s/w rendering is sufficient for most players, and h/w rendering is
available for more demanding players (like myself), you get a
larger audience.

I think this is really worth considering for any game that does full
screen scrolling in 640x480 or higher resolutions, since those
usually never get close to full frame rate without h/w acceleration.

Its possible to write a soft-scroller without opengl.

Sure, but it’s not possible to get around the CPU<->VRAM bandwidth
limitations without using h/w acceleration.

That said…

Maybe there
is something completely wrong in your main game loop or your
understanding of SDL and/or programming.
Maybe you should solve this point instead of ignoring it and just
switch to opengl.

…yes, that’s a good point. Forget abour arcade/console quality
scrolling without OpenGL and sub-pixel accurate scrolling - but it
should be possible to get playable frame rates with sane resolutions
one any reasonably current hardware. Most players seem to be happy
with anything better than 20-40 fps (depends on the game), so it’s
definitely a good idea to try and support s/w rendering, if it’s
realistic. (It may not be if you’re using tons of blending effects,
transformations and stuff.)

[…]

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

.- Audiality -----------------------------------------------.
| Free/Open Source audio engine for games and multimedia. |
| MIDI, modular synthesis, real time effects, scripting,… |
`-----------------------------------> http://audiality.org -’
— http://olofson.net — http://www.reologica.se —On Monday 15 September 2003 13.59, Thomas Eder wrote:

10

Is this game you’re writing using threads? Just curious

~ Phil Thoren

11

accidentally mailed myself instead of the list…
ignore one line of indentation :)> > IMHO its overkill to use OpenGL for a simple 2D

game.

Agreed, however by the same logic it’s overkill to
use
a makefile or IDE for “Hello world”. That dosn’t
mean
you should try it anyways to learn, so you can
advance
to, say, an advance 2D game.

As noted previously you would restrict your
audience
mainly
to people with hw-accelerated opengl-supported
systems.

to the original poster:
what I would sugggest for this particular
problem
would be the workaround of two versions (either in
one
executable, selected at runtime, or two).

Version 1 would be what you have now… fixed at
500x300, using sdl blits.

Version 2 would target those with more advanced
systems… with the higher resolution monitors,
which
are more likely to be supported by AGP cards which
can
handle such resolutions, or at the very least
supported by a processor of equal capacity.

Thus you provide an overkill option for your
users.

And I dont think that this kind of people will
play
your 2D game
very long, because they maybe have lot of other
real
cool 3D games.

I’d play starcraft over 3d tic tac toe any day. The
point is the gameplay will dictate if players play
the
game, not if it’s 2d or 3d.

To the original poster:
If your game is indeed a “simple 2d game” I’d still
go
with my mentioned solution…it keeps your target
audience larger. However, IMHO learning to seperate
game from display is important…do so with your
next
game, so it can be run at 320x200 and 1600x1200 just
as well.

IMHO the audience for simple 2D games are for
example children
(and their parents who have to buy the game…).

agreed if by simple you mean “very simple” or “most
simple”.

So to buy and play a simple game for their kids,
they wuold have to
provide a hw-accel opengl system…
In my eyes an unnecessary additional
restriction…

Its possible to write a soft-scroller without
opengl.

Indeed… he allready has a game, he’s asking about
fixing a problem with having hardcoded everything to
500x300.

Maybe there is something
completely wrong in your main game loop or your
understanding of SDL
and/or programming.

He has learned… the thing he did wrong was to
hardcode the game to the display too much. It should
be able to handle multiple resolutions, and the game
mechanics itself should not depend on the screen at
all (hopefully they don’t!).

Maybe you should solve this point instead of
ignoring it and just switch
to opengl.

Huh? I thought you were just arguing to keep his
code
in SDL?

I would suggest to reduce your current game code
to
a minimal game loop
which still shows the worse scrolling and to post
this demo code.
It should be possible to write this code in say 20
to 50 lines of code
(hopefully).

Ok now I’m confused… I thought the scrolling
problems were in another thread?

final words to the original poster:
If you have a simple 2d game that you want to allow
many people to be able to use, I’d go with my
allready
mentioned quick 'n dirty solution.

If you have an advanced 2d game etc etc, the best
thing would be to go ahead and rework your code so
it
isn’t resolution dependant… it’ll save you sanity
trying to maintain the game later.

Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software

12

I think you’re mixing two posts together, I was not the one with the 500x300 display that needed a double pixel mode…?

with my mentioned solution…it keeps your target
audience larger. However, IMHO learning to seperate
game from display is important…do so with your

Yes, I have thought about that. I don’t really have a good sulution yet, but I will think about it. After all, I don’t see (right now) how a game will be the same in 640x480 and 1024x768 if it has a background image of 1280x800 that scrolls around.

If you have an advanced 2d game etc etc, the best
thing would be to go ahead and rework your code so
it
isn’t resolution dependant… it’ll save you sanity
trying to maintain the game later.

Seem like I have lots to learn. Not surprisingly.

Regards
Henning

13

I would suggest to reduce your current game code to a minimal game loop
which still shows the worse scrolling and to post this demo code.
It should be possible to write this code in say 20 to 50 lines of code
(hopefully).

Many thanks for your time then. Here it is, with what I thought was important to show my understanding (or lack thereof) of SDL.
I have a 1024x768 image called “image.bmp” that I scroll around in circles, if you want to run it you just need to provide some other image for the prog.
Everyone is welcome to comment, should they like of course.
And no, so far I don’t use threads anywhere in the original code either.

Regards
Henning

CODE

#include "SDL/SDL.h"
SDL_Surface *screen;
SDL_Surface *levelbg;
SDL_Surface *levelbg_bmp;

void updateScreen(int x, int y) {
SDL_Rect src;
src.w=640;
src.h=400;
src.x=x;
src.y=y;
SDL_BlitSurface(levelbg, &src, screen, NULL);
SDL_Flip(screen);
}
int main(int argc, char argv[]) {
SDL_Event event;
float x,y;
x=y=0;
SDL_Init(SDL_INIT_VIDEO);
atexit(SDL_Quit);
screen = SDL_SetVideoMode(640,480,32,SDL_FULLSCREEN|SDL_HWSURFACE|SDL_DOUBLEBUF);
if (0 == screen->flags & SDL_HWSURFACE)
printf(“Can’t get hardware surface\n”);
if (0 == screen->flags & SDL_DOUBLEBUF)
printf(“Can’t get doublebuf\n”);
levelbg_bmp = SDL_LoadBMP(“image.bmp”);
levelbg = SDL_DisplayFormat(levelbg_bmp);
SDL_SetColorKey(levelbg,
SDL_SRCCOLORKEY|SDL_RLEACCEL,
SDL_MapRGB(levelbg->format,255,0,255));
SDL_FreeSurface(levelbg_bmp);
while(1) {
SDL_PollEvent(&event);
if (event.key.keysym.sym == SDLK_ESCAPE)
break;
updateScreen(300cos(x+=0.004)+100,200*sin(y+=0.004)+100);
}
return 0;
}

14

Hello Henning ,

well aside from the bad microsoft’s style of
if( const == something )
which I find irritating when reading ,

the precedence/binding of ‘==’ is higher than ‘&’ and so
if (0 == screen->flags & SDL_HWSURFACE)

is interpreted as

if( (0 == screen->flags ) & SDL_HWSURFACE )

which is probably not what you wanted … me I bracket everything
so I dont have to remember what the precedence is (bitten once too
often :slight_smile:

so writing it correctly …
if( (screen->flags & SDL_HWSURFACE) == 0 )

:slight_smile:

Cheers,

Steve Houseman–

currently : | for strace, an annotator see -
@steve_houseman | http://www.houseman.demon.co.uk/

15

One tip: add a line

SDL_Delay(10);

… just after the updateScreen row. This will give your OS some “time
to breathe” and might actually make your own program run smoother
(since if you DON’T do this the OS will put your app to sleep as it
see fits, and that might not be as you want it done, and might be
the cause of non-smooth scrolling behaviour). Nowadays, we are
trapped in a multitasking-environment and must adapt – sad but true.

/Olof

Henning: “Re: [SDL] OpenGL or pure SDL gfx?” (2003-09-16 11:45)

#> I would suggest to reduce your current game code to a minimal game loop
#> which still shows the worse scrolling and to post this demo code.
#> It should be possible to write this code in say 20 to 50 lines of code
#> (hopefully).#
#Many thanks for your time then. Here it is, with what I thought was important to show my understanding (or lack thereof) of SDL.
#I have a 1024x768 image called “image.bmp” that I scroll around in circles, if you want to run it you just need to provide some other image for the prog.
#Everyone is welcome to comment, should they like of course.
#And no, so far I don’t use threads anywhere in the original code either.

#Regards
#Henning

#CODE

##include “SDL/SDL.h”
#SDL_Surface *screen;
#SDL_Surface *levelbg;
#SDL_Surface *levelbg_bmp;

#void updateScreen(int x, int y) {

SDL_Rect src;

src.w=640;

src.h=400;

src.x=x;

src.y=y;

SDL_BlitSurface(levelbg, &src, screen, NULL);

SDL_Flip(screen);

#}
#int main(int argc, char *argv[]) {

SDL_Event event;

float x,y;

x=y=0;

SDL_Init(SDL_INIT_VIDEO);

atexit(SDL_Quit);

screen = SDL_SetVideoMode(640,480,32,SDL_FULLSCREEN|SDL_HWSURFACE|SDL_DOUBLEBUF);

if (0 == screen->flags & SDL_HWSURFACE)

printf(“Can’t get hardware surface\n”);

if (0 == screen->flags & SDL_DOUBLEBUF)

printf(“Can’t get doublebuf\n”);

levelbg_bmp = SDL_LoadBMP(“image.bmp”);

levelbg = SDL_DisplayFormat(levelbg_bmp);

SDL_SetColorKey(levelbg,

SDL_SRCCOLORKEY|SDL_RLEACCEL,

SDL_MapRGB(levelbg->format,255,0,255));

SDL_FreeSurface(levelbg_bmp);

while(1) {

SDL_PollEvent(&event);

if (event.key.keysym.sym == SDLK_ESCAPE)

break;

updateScreen(300cos(x+=0.004)+100,200sin(y+=0.004)+100);

}

return 0;

#}

#_______________________________________________
#SDL mailing list
#SDL at libsdl.org
#http://www.libsdl.org/mailman/listinfo/sdl

16

Right. CPU hogs can lose the CPU for extended periods of time (ie tens
of ms) if any other process decides to do some work.

However, note that you should not do this if you have drivers with
proper (ie blocking rather than busy-waiting) retrace sync’ed
pageflipping, because then it might cause unsmooth animation where
you could have a steady full frame rate. It should probably be a user
option…

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

.- Audiality -----------------------------------------------.
| Free/Open Source audio engine for games and multimedia. |
| MIDI, modular synthesis, real time effects, scripting,… |
`-----------------------------------> http://audiality.org -’
— http://olofson.net — http://www.reologica.se —On Tuesday 16 September 2003 13.10, Olof Bjarnason wrote:

One tip: add a line

SDL_Delay(10);

… just after the updateScreen row. This will give your OS some
"time to breathe" and might actually make your own program run
smoother (since if you DON’T do this the OS will put your app to
sleep as it see fits, and that might not be as you want it done,
and might be the cause of non-smooth scrolling behaviour).
Nowadays, we are trapped in a multitasking-environment and must
adapt – sad but true.

17

David Olofson wrote:

IMHO the audience for simple 2D games are for example children
(and their parents who have to buy the game…).

The vast majority of Kobo Deluxe players seem to be adults. :wink: And
the game is probably way too hard for kids that are too young for 3D
games…

Anyway, it’s a Free game, and I don’t know exactly how many active
players there are, so I can’t really talk about an “audience” in the
way you would about a commercial game.

Well, here’s one addict :wink: . I’m still struggling to get past that darn
50th level…–
Milan Babuskov
http://njam.sourceforge.net

18

You might try being very defensive at first, getting rid of most of
the blue bombs, before you start working on the base.

BTW, did you read the hints page? (Doesn’t mention level 50
specifically, though.)

http://www.olofson.net/kobodl/hints.html

There are probably more hints that might be of use to people.
Sugestions are welcome!

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

.- Audiality -----------------------------------------------.
| Free/Open Source audio engine for games and multimedia. |
| MIDI, modular synthesis, real time effects, scripting,… |
`-----------------------------------> http://audiality.org -’
— http://olofson.net — http://www.reologica.se —On Tuesday 16 September 2003 15.28, Milan Babuskov wrote:

David Olofson wrote:

IMHO the audience for simple 2D games are for example children
(and their parents who have to buy the game…).

The vast majority of Kobo Deluxe players seem to be adults. :wink:
And the game is probably way too hard for kids that are too young
for 3D games…

Anyway, it’s a Free game, and I don’t know exactly how many
active players there are, so I can’t really talk about an
"audience" in the way you would about a commercial game.

Well, here’s one addict :wink: . I’m still struggling to get past that
darn 50th level…

19

David Olofson wrote:

Well, here’s one addict :wink: . I’m still struggling to get past that
darn 50th level…

You might try being very defensive at first, getting rid of most of
the blue bombs, before you start working on the base.

I thought their supply is infinite, so I can get rid of them until the
level is over ?!?!

BTW, did you read the hints page? (Doesn’t mention level 50
specifically, though.)

Yes. That “diagonal” tip really helped.

There are probably more hints that might be of use to people.
Sugestions are welcome!

Well, if I think of something really useful, I’ll let you know. ;)–
Milan Babuskov
http://njam.sourceforge.net

20

One tip: add a line

SDL_Delay(10);

… just after the updateScreen row. This will give your OS some
"time to breathe" and might actually make your own program run
smoother (since if you DON’T do this the OS will put your app to
sleep as it see fits, and that might not be as you want it done,
and might be the cause of non-smooth scrolling behaviour).
Nowadays, we are trapped in a multitasking-environment and must
adapt – sad but true.

Right. CPU hogs can lose the CPU for extended periods of time (ie tens
of ms) if any other process decides to do some work.

However, note that you should not do this if you have drivers with
proper (ie blocking rather than busy-waiting) retrace sync’ed
pageflipping, because then it might cause unsmooth animation where
you could have a steady full frame rate. It should probably be a user
option…

The problem is that you don’t know what the users drivers are doing and
the user most likely does not know what they are doing either. Then
there is the problem of drivers that synch by busy waiting so you don’t
get any value out the synching anyway…

So, run a tiny test loop during initialization and use the delay() call
if the frame rate is greater than 100 FPS or so. Not what you want to
do, but the best you can do in an uncertain world.

	Bob PendletonOn Tue, 2003-09-16 at 07:01, David Olofson wrote:

On Tuesday 16 September 2003 13.10, Olof Bjarnason wrote:

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

.- Audiality -----------------------------------------------.
| Free/Open Source audio engine for games and multimedia. |
| MIDI, modular synthesis, real time effects, scripting,… |
`-----------------------------------> http://audiality.org -’
— http://olofson.net — http://www.reologica.se —

SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl
–
±----------------------------------+