Sdl-newbie -> Blitz, UpdateRect vs DoubleBuff, etc

SDL Development
1

Hello gang!

 I just write a little "demo" (to help me to see how it work...)

using SDL and I’m having somes questions … ( I’m new to SDL,
SDL_image and SDL_mixer and much more… so you risk to see
me often here ;)). So there is my questions :=

o What’s the better := UpdateRect(screen,0,0,0,0) or DoubleBuffering ?
o Why using the KEY_DOWN I don’t get the event repeatly raised ?
(until the KEY_IS_DOWN…??? or it’s my role to remember it’s down
until I get a “KEY_UP” style event (note : I’m very-not-sure of the KEY_UP
name… but you know what I what to say … [;)] ) ?
o Blitzing!!! I blitz := It’s ok, but did I MUST clear the screen after
each
Updaterect(screen,0,0,0,0) ? If yes, with SDL_Fill…? (I’m at job, no doc
beside me;))
o Another points : THX GUYS!!! It’s fun and easy to work with SDL. I got
somes troubles to find the way to load a .xpm files (missing
-lSDL_image…
used SDL_RWops… but it’s working now [;)] ).

(Note : The last game I’ve programmed is in TurboPascal 7.0, so I’m lost
in all this new libs and functions (plus Makefiles… I got a LOT to
learn!) )

So Thx again for helping me [;)]

2

o What’s the better := UpdateRect(screen,0,0,0,0) or DoubleBuffering ?

This probably depends what you’re doing, and what the hardware you’re using
can support. Hardware accelerated double buffering is probably the best (if
you’re doing full-screen animation) but if you’re using double buffering and
it’s not supported by the hardware, SDL has to emulate it. If you’re changing
the vast majority of the screen each frame, using double buffering (even if
it’s done in software) is probably the best way to go about it. Drawing
directly to the screen and then updating it can cause flickering, especially
if you’re doing large updates, and this looks really ugly.

If you’re able to isolate areas on the screen and use SDL_UpdateRects(),
it’ll probably be faster on most platforms than double-buffering. A lot of
games make this pretty impractical though.

However, you might be able to “cheat” and draw the game in only a portion of
the screen, and use the rest for status things (health bars, ammo,
whatever) which don’t need to be updated all the time.

o Why using the KEY_DOWN I don’t get the event repeatly raised ?
(until the KEY_IS_DOWN…??? or it’s my role to remember it’s down
until I get a “KEY_UP” style event (note : I’m very-not-sure of the KEY_UP
name… but you know what I what to say … [;)] ) ?

There is a function you can use to tell SDL to repeatedly send key-down
events, and how often to send them (I don’t use it so I don’t know off-hand
what it is) For a typical game, yes, you want to keep track of this
yourself. I think a fairly common and simple way is to do something like:

#define KEY_NONE (0)
#define KEY_LEFT (1 << 0)
#define KEY_RIGHT (1 << 1)
#define KEY_FIRE (1 << 2)

…

int keydown = KEY_NONE;

while (SDL_PollEvent(&event) > 0)
{
switch (event.type)
{
case SDL_KEYDOWN:
switch (event.key.keysym.sym)
{
case SDLK_LEFT:
keydown |= KEY_LEFT;
break;
case SDLK_RIGHT:
keydown |= KEY_RIGHT;
break;
// and so on…
}
break;
case SDL_KEYUP:
switch (event.key.keysym.sym)
{
case SDLK_LEFT:
keydown ^= KEY_LEFT;
break;
// and so on…
}
break;
}
}

(above code typed without any reference, so the usual caveats apply)

Then when you’re doing your game updates:

if (keydown & KEY_LEFT)
myguy->x -= myguy->speed;
if (keydown & KEY_RIGHT)
myguy->x += myguy->speed;
… and so forth …

There’s very few times in a game when you actually want to get "normal"
keyboard input; mostly the keyboard is just a bunch of keys that are either
down or up, and using code like the above gives you this.

o Blitzing!!! I blitz := It’s ok, but did I MUST clear the screen after
each Updaterect(screen,0,0,0,0) ? If yes, with SDL_Fill…? (I’m at job,
no doc beside me;))

Blitzing? Blitting? :slight_smile:

Whether you need to clear the screen or not depends. If you’re using double
buffering, there’s no guarantee what’s going to be in the video surface
after you call SDL_Flip() - but if you’re using double buffering, you’re
probably redrawing the entire screen each frame anyway.

If you’re blitting directly to the video screen, and only making small
changes, redrawing the screen each time would be a bit counterproductive.

I use SDL_FillRect(screen, NULL, colour) to clear the screen. I don’t think
there’s a faster way of doing it…On Mon, 7 Jan 2002, Gerard wrote:

Mike.

3

You’re Da KinG! :slight_smile:

I’ll work on this night :wink:

I’ll be back with somes troubles soon

  • perhaps a little demo ??!?! hEh :wink:

So I just one things to say : THX THX THX THX!!!

Mike wrote:>On Mon, 7 Jan 2002, Gerard wrote:

o What’s the better := UpdateRect(screen,0,0,0,0) or DoubleBuffering ?

This probably depends what you’re doing, and what the hardware you’re using
can support. Hardware accelerated double buffering is probably the best (if
you’re doing full-screen animation) but if you’re using double buffering and
it’s not supported by the hardware, SDL has to emulate it. If you’re changing
the vast majority of the screen each frame, using double buffering (even if
it’s done in software) is probably the best way to go about it. Drawing
directly to the screen and then updating it can cause flickering, especially
if you’re doing large updates, and this looks really ugly.

If you’re able to isolate areas on the screen and use SDL_UpdateRects(),
it’ll probably be faster on most platforms than double-buffering. A lot of
games make this pretty impractical though.

However, you might be able to “cheat” and draw the game in only a portion of
the screen, and use the rest for status things (health bars, ammo,
whatever) which don’t need to be updated all the time.

o Why using the KEY_DOWN I don’t get the event repeatly raised ?
(until the KEY_IS_DOWN…??? or it’s my role to remember it’s down
until I get a “KEY_UP” style event (note : I’m very-not-sure of the KEY_UP
name… but you know what I what to say … [;)] ) ?

There is a function you can use to tell SDL to repeatedly send key-down
events, and how often to send them (I don’t use it so I don’t know off-hand
what it is) For a typical game, yes, you want to keep track of this
yourself. I think a fairly common and simple way is to do something like:

#define KEY_NONE (0)
#define KEY_LEFT (1 << 0)
#define KEY_RIGHT (1 << 1)
#define KEY_FIRE (1 << 2)

…

int keydown = KEY_NONE;

while (SDL_PollEvent(&event) > 0)
{
switch (event.type)
{
case SDL_KEYDOWN:
switch (event.key.keysym.sym)
{
case SDLK_LEFT:
keydown |= KEY_LEFT;
break;
case SDLK_RIGHT:
keydown |= KEY_RIGHT;
break;
// and so on…
}
break;
case SDL_KEYUP:
switch (event.key.keysym.sym)
{
case SDLK_LEFT:
keydown ^= KEY_LEFT;
break;
// and so on…
}
break;
}
}

(above code typed without any reference, so the usual caveats apply)

Then when you’re doing your game updates:

if (keydown & KEY_LEFT)
myguy->x -= myguy->speed;
if (keydown & KEY_RIGHT)
myguy->x += myguy->speed;
… and so forth …

There’s very few times in a game when you actually want to get "normal"
keyboard input; mostly the keyboard is just a bunch of keys that are either
down or up, and using code like the above gives you this.

o Blitzing!!! I blitz := It’s ok, but did I MUST clear the screen after
each Updaterect(screen,0,0,0,0) ? If yes, with SDL_Fill…? (I’m at job,
no doc beside me;))

Blitzing? Blitting? :slight_smile:

Whether you need to clear the screen or not depends. If you’re using double
buffering, there’s no guarantee what’s going to be in the video surface
after you call SDL_Flip() - but if you’re using double buffering, you’re
probably redrawing the entire screen each frame anyway.

If you’re blitting directly to the video screen, and only making small
changes, redrawing the screen each time would be a bit counterproductive.

I use SDL_FillRect(screen, NULL, colour) to clear the screen. I don’t think
there’s a faster way of doing it…

4

Just to speak of my own experience, using SDL_UpdateRects() is
defintely the way to go, if you are producing games/applications for
a broader range of PCs.

Even if you have to update a large portion of the screen, you don’t
have to do it at EVERY frame. Try to save unnecessary redraw/update
as much as you can at each frame, you’ll see the results. Even for
full screen scrolling (where you cannot avoid updating the whole
screen), changing from 1 pixel displacement per frame to 2 pixel
displacement per 2 frames will improve your FPS by almost two folds.
Heavy redraw/updates can be done, but not at every frame.

Most games that did badly at FPS were largely due to “lazy programming” :slight_smile:

Regards,
.paul.On Tue, Jan 08, 2002 at 12:14:00AM +0800, Mike wrote:

If you’re able to isolate areas on the screen and use SDL_UpdateRects(),
it’ll probably be faster on most platforms than double-buffering. A lot of
games make this pretty impractical though.

5

But in the case of a BomberMan clone and/or a
final fantasy game, I can’t keep a piece of
not-updated section of screen ! If all is moving
on the screen ? Or can I have a way to blit what
is already on the screen (Take all, move by 2 pixel left
and then just update the 2 missings pixel at the right ?)

For somes games like Gnibbles or like that I can
understand, but for a scrolling game… did I MUST
use doublebuff instead of updateRect ? Or it is possible
to use updaterect anyway !? ThX :wink:

Whooaaa guys! I’ll learn a lot here ;))

And… THX AGAIN :slight_smile:

paul at theV.net wrote:>On Tue, Jan 08, 2002 at 12:14:00AM +0800, Mike wrote:

If you’re able to isolate areas on the screen and use SDL_UpdateRects(),
it’ll probably be faster on most platforms than double-buffering. A lot of
games make this pretty impractical though.

Just to speak of my own experience, using SDL_UpdateRects() is
defintely the way to go, if you are producing games/applications for
a broader range of PCs.

Even if you have to update a large portion of the screen, you don’t
have to do it at EVERY frame. Try to save unnecessary redraw/update
as much as you can at each frame, you’ll see the results. Even for
full screen scrolling (where you cannot avoid updating the whole
screen), changing from 1 pixel displacement per frame to 2 pixel
displacement per 2 frames will improve your FPS by almost two folds.
Heavy redraw/updates can be done, but not at every frame.

Most games that did badly at FPS were largely due to “lazy programming” :slight_smile:

Regards,
.paul.

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

.

6

But in the case of a BomberMan clone and/or a
final fantasy game, I can’t keep a piece of
not-updated section of screen ! If all is moving
on the screen ? Or can I have a way to blit what
is already on the screen (Take all, move by 2 pixel left
and then just update the 2 missings pixel at the right ?)

Well, you can do that, and it’ll work very well on systems with h/w
accelerated screen->screen blitting - but it’ll be very, very slow when
SDL has to do it with the software blitters.

For somes games like Gnibbles or like that I can
understand, but for a scrolling game…

Consider a slow to medium speed parallax scrolling shooter, like
Project-X on the Amiga. (Can’t remember any others that I know for sure
do parallax! :slight_smile:

In most such games, the “action” parallax level (where the player is) is
scrolling at around 30 pixels/second, and it contains only some "edges"
and occasional obstacles that you’re supposed to avoid. The rest of the
screen area is occupied by parallax layers that are further away from the
viewer, and thus moving slower.

Now, unless you’re using sub-pixel accurate rendering, you’ll find that
it’s actually only some of the sprites that make use of the full frame
rate on a 60+ Hz display. Even the “action” level parallax layer moves to
a new pixel position only every other frame, and the further away layers
move even slower!

So, if you actively keep track of whether or not a parallax really moved
since the last frame, and the areas of the screen they occupy, you can
get away with refreshing only a fraction of the screen area every frame,
while still giving the illusion of full frame rate, full screen
scrolling. :slight_smile:

Obviously, you’ll have to offset the initial sub-pixel scroll offsets of
the layers to avoid having all of them move at once every N’th frame. For
example, if you have two layers; one moving one pixel every other frame,
and one moving one pixel every fourth frame, offset the second one so
that it will move in the frames between the frames where the first
layer moves. That is, during 4 frames, first layer 1 moves, then layer 2,
then layer 1 again and finally no layer at all. Repeat forever.

Hovever, you should also consider the rather serious problem that these
days, you can’t reliably select a suitable video refresh for your game.
You have to accept that you can’t always get 60 Hz or whatever, but you
have to make your game run at the right speed regardless of what you get.

This pretty much screws up the example I’m giving above - but then again,
since you can’t achieve absolutely smooth scrolling anyway, it’s no big
deal if you make things easier by just aiming for a reduced average per
frame update area.

That is, just look at the parallax layer coordinates, and whenever one
changes, add the visible areas covered by that layer to the “refresh
list”. (Of course, you need to “merge” overlapping refresh rectangles, as
it’s a total waste of time to update the same area more than once per
frame!)

did I MUST
use doublebuff instead of updateRect ? Or it is possible
to use updaterect anyway !? ThX :wink:

Uhm, well… SDL_UpdateRects() doesn’t make sense with double buffering,
as your graphics already is in VRAM after you’ve rendered it. Just
SDL_FlipSurface() (which is basically just a matter of swapping around
some pointers - no gfx copying), and it’ll be visible.

Indeed, you can use a partial updating scheme with double buffering
(Kobo Deluxe does in the SemiTriple buffering mode), but you have to be
careful! In theory, there’s no guarantee that the graphics will still be
there after two flips, but I have yet to see a system where this is not
the case. (Erasing the buffer would just mean extra overhead, so why
would anyone do it?) This applies to OpenGL as well.

//David Olofson — Programmer, Reologica Instruments AB

.- M A I A -------------------------------------------------.
| Multimedia Application Integration Architecture |
| A Free/Open Source Plugin API for Professional Multimedia |
----------------------------> http://www.linuxdj.com/maia -' .- David Olofson -------------------------------------------. | Audio Hacker - Open Source Advocate - Singer - Songwriter |-------------------------------------> http://olofson.net -'On Monday 07 January 2002 20:01, Gerard wrote:

7

But in the case of a BomberMan clone and/or a
final fantasy game, I can’t keep a piece of
not-updated section of screen ! If all is moving
on the screen ? Or can I have a way to blit what
is already on the screen (Take all, move by 2 pixel left
and then just update the 2 missings pixel at the right ?)

So you are refering to SDL_BlitSurface(screen, …, screen, …)?
I did a test on this scroll thing, my Linux does not support
SDL_HWSURFACE, so I am only using SDL_SWSURFACE, and the screen
create via SDL_SetVideoMode() is double buffered. You’ll find
the result surprising. In a 1024x768 size, blitting from/to the
same screen surface is actually slower than blitting from another
memory surface to the screen, 21 FPS v.s. 25 FPS.

I am not sure if some SDL_HWSURFACE plus hardware doublebuffer
will get you faster results on this screen to screen copy. But
as long as you use SDL_SWSURFACE screen, you’ll get the similar
result as I do. And 20+ FPS of just blitting in a while loop is
definitely no good for a decent game. That is why you dont often
encounter a scroller games of 1024x768, but instead of a much
smaller size, 640x480 or even smaller.

What the 25 FPS means here is, I can only make a full size
redraw and update for 25 times during one second. So if I
increase the displacement and only do it 15 times a second,
I may save up some time and use SDL_UpdateRects() to squeeze
in another 35 frame for other things, to improve the responsiveness
of my GUI widgets, etc. For example, my input caret can still
blink at 50 FPS even though I can only do full screen scrolling
15 times a second (but at the same speed as before).

For somes games like Gnibbles or like that I can
understand, but for a scrolling game… did I MUST
use doublebuff instead of updateRect ? Or it is possible
to use updaterect anyway !? ThX :wink:

SDL_UpdateRects() of only changed portions is definitely better
than SDL_Flip() on software double buffer. It is best your
program can support both depending on the user’s hardware, so
that it looks amazingly smooth on capable video cards, but still
decent over normal ones.

Also, I guess HWSURFACE is only available at full screen?
I could be wrong since I never had a good video card :PP
If you are like me and only use window mode, stick with
UpdateRects :slight_smile:

Regards,
.paul.On Mon, Jan 07, 2002 at 02:01:58PM -0500, Gerard wrote:

8

Thx David and Paul! :wink:

Last night, I convert my little project from C to C++
. Oriented Object Programming will be more fun
that C :wink: . I still got troubles with the fuc**n makefile
but I’ll got it :wink:

I’ll apply your comments this night and give you somes
comments tomorrow :wink: Thx again for the brunch of tricks
and tactics !! :wink:

Consider a slow to medium speed parallax scrolling shooter, like
Project-X on the Amiga. (Can’t remember any others that I know for sure
do parallax! :slight_smile:

  • parralax - The apparent displacement (or the difference in apparent
    direction) of an object, as seen from two different points*

is this you mean by parralax ? ;o)
(Don’t forget, I’m still a newbie! :slight_smile:

I’ve searched the Project-X just to see what it look like, but just
found somes reviews
of the games without any screenshot ;( (It got a 78% Eheh looks like
good :wink: )

Anyway, I’ll try the two! SDL_UpdateRect and SDL_Flip, HW & SW_Surfaces :wink:

I’m here to learn anyway ;))

So see you tomorrow ;)>

//David Olofson — Programmer, Reologica Instruments AB

.- M A I A -------------------------------------------------.
| Multimedia Application Integration Architecture |
| A Free/Open Source Plugin API for Professional Multimedia |
----------------------------> http://www.linuxdj.com/maia -' .- David Olofson -------------------------------------------. | Audio Hacker - Open Source Advocate - Singer - Songwriter |-------------------------------------> http://olofson.net -’

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

.

9

Thx David and Paul! :wink:

Last night, I convert my little project from C to C++
. Oriented Object Programming will be more fun
that C :wink: . I still got troubles with the fuc**n makefile
but I’ll got it :wink:

I’ll apply your comments this night and give you somes
comments tomorrow :wink: Thx again for the brunch of tricks
and tactics !! :wink:

Consider a slow to medium speed parallax scrolling shooter, like
Project-X on the Amiga. (Can’t remember any others that I know for
sure do parallax! :slight_smile:

  • parralax - The apparent displacement (or the difference in apparent
    direction) of an object, as seen from two different points*

is this you mean by parralax ? ;o)

Yep, that’s exactly it. :slight_smile:

Have a look at the parallax scrolling demos for a live demonstration -
including one with a recursive “zero overdraw” implementation.

http://olofson.net/mixed.html

I’ve searched the Project-X just to see what it look like, but just
found somes reviews of the games without any screenshot ;(

http://www.team17.com/softography.html?submit&topic=project_x

(The second shot demonstrates one of those typical obstacles in the
player’s parallax layer, on top of a background that scrolls very slowly.)

(It got a 78% Eheh looks like good :wink: )

Yes, it’s a great game, although very hard. Takes quite some practicing
and a good joystick to even get to the second level - and that’s where it
starts to get really hard! hehe

//David Olofson — Programmer, Reologica Instruments AB

.- M A I A -------------------------------------------------.
| Multimedia Application Integration Architecture |
| A Free/Open Source Plugin API for Professional Multimedia |
----------------------------> http://www.linuxdj.com/maia -' .- David Olofson -------------------------------------------. | Audio Hacker - Open Source Advocate - Singer - Songwriter |-------------------------------------> http://olofson.net -'On Tuesday 08 January 2002 16:12, Gerard wrote:

10

Have a look at the parallax scrolling demos for a live demonstration -
including one with a recursive “zero overdraw” implementation.

http://olofson.net/mixed.html

Superb Demo! It’s printed and ready to read tonight! :wink:
I’ll learn a lot on SDL with this kind of demo!! :wink:

I greatly appreciate :slight_smile:

Thx, and THX again! :wink:

11

Hiya,

DO> http://www.team17.com/softography.html?submit&topic=project_x

Aaargh! Aaargh! No escape! No escape!

Heheheh! I work for Team17. :wink:

Neil.

12

Neil Griffiths wrote:

Hiya,

DO> http://www.team17.com/softography.html?submit&topic=project_x

Aaargh! Aaargh! No escape! No escape!

Heheheh! I work for Team17. :wink:

GRRRRRRRRRRRRR IT’S MY DREAM!! Get paid to make games!!!>

Neil.

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

.

13

Neil Griffiths wrote:

Hiya,

DO>
http://www.team17.com/softography.html?submit&topic=project_x

Aaargh! Aaargh! No escape! No escape!

You think you could get away with releasing that and not be
remembered!? :wink:

Heheheh! I work for Team17. :wink:

Hey, were you around back then as well? :slight_smile:

GRRRRRRRRRRRRR IT’S MY DREAM!! Get paid to make games!!!

Well, if you hack a lot of nice stuff to show, and if you’re more
friendly ;-), you might get your foot in somewhere!

Anyway, many who have been there tell me that you should count on working
very hard for little money… heh

Meanwhile, I work… well, not that hard, and I get paid pretty well.
(At least since a while back.)

All right, i don’t code games, but real time programming and control
engineering isn’t that boring - and I get to hack whatever I like in my
spare time anyway. :slight_smile:

Speaking of which… remembers that it’s time for another Kobo Deluxe
pre-release

//David Olofson — Programmer, Reologica Instruments AB

.- M A I A -------------------------------------------------.
| Multimedia Application Integration Architecture |
| A Free/Open Source Plugin API for Professional Multimedia |
----------------------------> http://www.linuxdj.com/maia -' .- David Olofson -------------------------------------------. | Audio Hacker - Open Source Advocate - Singer - Songwriter |-------------------------------------> http://olofson.net -'On Wednesday 09 January 2002 21:13, Gerard wrote:

14

GRRRRRRRRRRRRR IT’S MY DREAM!! Get paid to make games!!!

Well, if you hack a lot of nice stuff to show, and if you’re more
friendly ;-),

I’m starting to :wink: I’m not friendly? ?? HEH :slight_smile:

you might get your foot in somewhere!

I WISH!!

Anyway, many who have been there tell me that you should count on working
very hard for little money… heh

Yep! (I’m already doing that for now, I’m working for a cheap company)

All right, i don’t code games, but real time programming and control
engineering isn’t that boring - and I get to hack whatever I like in my
spare time anyway. :slight_smile:

I’m in R&D, coding Kylix/Delphi/C(++)(Linux/W32)/C(ANSI for embedded
device(80c51))/HTML/DHTML/JavaScript/PHP . . .

The company where I work sell alarm systems for home/commercial.
We develop it :wink: Fun but … you know…

hehehEH :slight_smile:

I’ll do my best to be friendly :wink: HEhE

gerard

15

GRRRRRRRRRRRRR IT’S MY DREAM!! Get paid to make games!!!

When people say this to you, you should hand them a lollipop and pat them
on the head.

–ryan.

16

Ryan C. Gordon wrote:

GRRRRRRRRRRRRR IT’S MY DREAM!! Get paid to make games!!!

When people say this to you, you should hand them a lollipop and pat them
on the head.

Or buying him a Linux Game Developper Guide …

gerard

17

Hiya,

DO> You think you could get away with releasing that and not be
DO> remembered!? :wink:

True, it’s an amazing game. But… you don’t remember the Worms games?
:wink:

DO> Hey, were you around back then as well? :slight_smile:

Unfortunately not, no, I’ve not been there all that long. I’m enjoying
it though!

DO> Well, if you hack a lot of nice stuff to show, and if you’re more
DO> friendly ;-), you might get your foot in somewhere!

Yep, I found that having some nice demos and a sound knowledge of 3D
got me in. It wasn’t easy getting into the games industry straight out
of University, but I’ve managed it… so it IS possible. :slight_smile:

DO> Anyway, many who have been there tell me that you should count on working
DO> very hard for little money… heh

Well… I guess that’s relative really. Compared to other programming
jobs then yes, games programming is less money… But it’s still not
bad. :slight_smile:

DO> Meanwhile, I work… well, not that hard, and I get paid pretty well.
DO> (At least since a while back.)

Heheheh, we play Return to Castle Wolfenstein for about 2 hours each
day… :wink:

Mind you, now we’re starting another project based on - yep, you
guessed it - Worms, so that’ll go down the drain as we start to work
hard at it… The team I joined was the Worms Blast team… Which has
just finished now, just ironing out some bugs and trying to please
Sony too. :o

DO> All right, i don’t code games, but real time programming and control
DO> engineering isn’t that boring - and I get to hack whatever I like in my
DO> spare time anyway. :slight_smile:

Oh well, at the moment I’m just creating a network protocol based over
UDP which will be used for everything. The major problem is that it’s
got to be able to transfer any types of data and reform them correctly
at the other end (be that classes, files, level data, whatever)… But the
other end is quite possibly not using the same endianess. And I would
just like to say that the PS2 is a beast. :o

DO> Speaking of which… remembers that it’s time for another Kobo Deluxe
DO> pre-release

I’m really enjoying that game. =)

Mind you… I’m particularly enjoying glSDL too, so… get working on
that instead! :wink: Heh! :slight_smile:

Neil.

18

Hiya,

DO> You think you could get away with releasing that and not be
DO> remembered!? :wink:

True, it’s an amazing game. But… you don’t remember the Worms games?
:wink:

Actually, I haven’t played them all that much for some reason. Possibly
because they were released during a period when I wasn’t playing much at
all…

[…]

DO> Speaking of which… remembers that it’s time for another Kobo
Deluxe DO> pre-release

I’m really enjoying that game. =)

Mind you… I’m particularly enjoying glSDL too, so… get working on
that instead! :wink: Heh! :slight_smile:

Well, there are some things to fix before releasing Kobo Deluxe 0.4 - and
that includes some work on glSDL, to make all features used by Kobo
Deluxe work properly on any OpenGL card. (Currently, you need a card that
can do 1024x1024+ textures for correct rendering in higher resolutions.)

Anyway, I’m just about to upload 0.4-pre6, which contains some new stuff,
and some fixes. Most of the time was spent hacking a new audio engine,
but there are some “real” changes as well.

I’m going to release a Win32 binary package including an OpenGL enabled
version as well - but unfortunately, it seems like hardware pageflipping
isn’t detected properly, which results in some flickering…

//David Olofson — Programmer, Reologica Instruments AB

.- M A I A -------------------------------------------------.
| Multimedia Application Integration Architecture |
| A Free/Open Source Plugin API for Professional Multimedia |
----------------------------> http://www.linuxdj.com/maia -' .- David Olofson -------------------------------------------. | Audio Hacker - Open Source Advocate - Singer - Songwriter |-------------------------------------> http://olofson.net -'On Wednesday 09 January 2002 23:21, Neil Griffiths wrote: