Logging SDL Events for playback

Hi All,
I am working on an Input class for the Pascal bindings for SDL and
would like to add the ability to log the SDL input events ( Mouse,
Keyboard and Joystick ) to a file for later playback ( such as demo
replays, game tutorials etc ).

Has anyone already implemented something like this, or have any
suggestions for implementing such a feature. I am not sure whether time
based logging would be better than frame based logging.

Any input would be greatly appreciated.

Thanks,

Dominique
http://www.DelphiGamer.com := go on, write a game instead;

This is a pretty easy way of implementing demo playback, but keep in
mind that it only works for games where the logic is 100% independent
of frame rate, real time and things like that. I did it in Project
Spitfire (old DOS project) and I’m planning on using the same
technique in Kobo Deluxe. It’s slightly more complicated in the
latter, since lots of things are “random” - but since it’s using an
internal pseudo-random RNG, everything can be reproduced if I store
the RNG seed in demo files.

It won’t work with games that do one (variable length) logic time
slice per rendered frame, unless possibly if you also log the times
at which the game collects input events. Even if you did (and figured
out a way to force the data back in at the correct logic times),
you’d have to ensure that the game logic is exact - approximations
wouldn’t do. For games with this kind of logic systems, I think it’s
easier and more reliable to implement the demo recording/playback on
the logic system level, storing all critical game events, to ensure
that demos play back correctly even if timing and positions are
slightly off at times.

Time vs frames depends on what kind of logic engine the game is using.
What’s important is that the logger and the game logic has the exact
same idea of time, so input events can be replayed at the exact right
points in logic time.

//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.nethttp://www.reologica.se —On Sunday 28 September 2003 11.31, Dominique Louis wrote:

Hi All,
I am working on an Input class for the Pascal bindings for SDL
and would like to add the ability to log the SDL input events (
Mouse, Keyboard and Joystick ) to a file for later playback ( such
as demo replays, game tutorials etc ).

Has anyone already implemented something like this, or have any
suggestions for implementing such a feature. I am not sure whether
time based logging would be better than frame based logging.

Any input would be greatly appreciated.

This is an OpenGL specific question, so apologies if it is not
considered applicable for the list, and I’ll quietly attempt to ask it
elsewhere …

I’m using OpenGL in purely orthographic projection mode for 2D graphics, and have
my display set up in the standard 2D mode of x going from left to
right (0-…), and y going from top to bottom (0-…).

What would people suggest as the best method for copying a section of
a texture to a section of another texture?

pbuffers? If so, how? And if I use them, does it mean I can’t use
them under Linux, when I port my applications?

Drawing to the screen for a short time, and copying that to a texture?

A problem I’ve found so far is that because my y coordinates are
essentially inverted as far as OpenGL is concerned, I have to draw the
image flipped before being able to copy it correctly. This is fine,
but a bit of a pain to have to do.

Thanks guys,

Rob

What would people suggest as the best method for copying a section of
a texture to a section of another texture?

glTexSubImage*() -> memory to texture

glGetTexImage() -> texture to memory

pbuffers? If so, how? And if I use them, does it mean I can’t use
them under Linux, when I port my applications?

Its platform specific

A problem I’ve found so far is that because my y coordinates are
essentially inverted as far as OpenGL is concerned, I have to draw the
image flipped before being able to copy it correctly. This is fine,
but a bit of a pain to have to do.

No.
If your picture is a texture is to easy to draw it correct.
Else use glDrawPixels() with correct glPixelZoom() parameters to invert image

I thought w/ the latest release of SDL there was PBuffer support?> ----- Original Message -----

From: cham_gss@hotmail.com (Chameleon)
To:
Sent: Monday, September 29, 2003 6:08 AM
Subject: Re: [SDL] OpenGL, drawing from a texture to another texture

What would people suggest as the best method for copying a section of
a texture to a section of another texture?

glTexSubImage*() -> memory to texture

glGetTexImage() -> texture to memory

pbuffers? If so, how? And if I use them, does it mean I can’t use
them under Linux, when I port my applications?

Its platform specific

A problem I’ve found so far is that because my y coordinates are
essentially inverted as far as OpenGL is concerned, I have to draw the
image flipped before being able to copy it correctly. This is fine,
but a bit of a pain to have to do.

No.
If your picture is a texture is to easy to draw it correct.
Else use glDrawPixels() with correct glPixelZoom() parameters to invert
image


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

I thought w/ the latest release of SDL there was PBuffer support?> ----- Original Message -----

From: cham_gss@hotmail.com (Chameleon)
To:
Sent: Monday, September 29, 2003 6:08 AM
Subject: Re: [SDL] OpenGL, drawing from a texture to another texture

What would people suggest as the best method for copying a section of
a texture to a section of another texture?

glTexSubImage*() -> memory to texture

glGetTexImage() -> texture to memory

pbuffers? If so, how? And if I use them, does it mean I can’t use
them under Linux, when I port my applications?

Its platform specific

A problem I’ve found so far is that because my y coordinates are
essentially inverted as far as OpenGL is concerned, I have to draw the
image flipped before being able to copy it correctly. This is fine,
but a bit of a pain to have to do.

No.
If your picture is a texture is to easy to draw it correct.
Else use glDrawPixels() with correct glPixelZoom() parameters to invert
image


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

I thought w/ the latest release of SDL there was PBuffer support?> ----- Original Message -----

From: cham_gss@hotmail.com (Chameleon)
To:
Sent: Monday, September 29, 2003 6:08 AM
Subject: Re: [SDL] OpenGL, drawing from a texture to another texture

What would people suggest as the best method for copying a section of
a texture to a section of another texture?

glTexSubImage*() -> memory to texture

glGetTexImage() -> texture to memory

pbuffers? If so, how? And if I use them, does it mean I can’t use
them under Linux, when I port my applications?

Its platform specific

A problem I’ve found so far is that because my y coordinates are
essentially inverted as far as OpenGL is concerned, I have to draw the
image flipped before being able to copy it correctly. This is fine,
but a bit of a pain to have to do.

No.
If your picture is a texture is to easy to draw it correct.
Else use glDrawPixels() with correct glPixelZoom() parameters to invert
image


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

I thought w/ the latest release of SDL there was PBuffer support?> ----- Original Message -----

From: cham_gss@hotmail.com (Chameleon)
To:
Sent: Monday, September 29, 2003 6:08 AM
Subject: Re: [SDL] OpenGL, drawing from a texture to another texture

What would people suggest as the best method for copying a section of
a texture to a section of another texture?

glTexSubImage*() -> memory to texture

glGetTexImage() -> texture to memory

pbuffers? If so, how? And if I use them, does it mean I can’t use
them under Linux, when I port my applications?

Its platform specific

A problem I’ve found so far is that because my y coordinates are
essentially inverted as far as OpenGL is concerned, I have to draw the
image flipped before being able to copy it correctly. This is fine,
but a bit of a pain to have to do.

No.
If your picture is a texture is to easy to draw it correct.
Else use glDrawPixels() with correct glPixelZoom() parameters to invert
image


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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1On Monday 29 September 2003 15:08, - Chameleon - wrote:

What would people suggest as the best method for copying a section of
a texture to a section of another texture?

glTexSubImage*() -> memory to texture

glGetTexImage() -> texture to memory

primitive rendering -> texture to buffer

glCopyTexImage*() -> buffer to texture

Should be faster than down+uploading through AGP, but it has the obvious
drawback of messing with the color buffer.
Of course, it’s still just a workaround for lack of pbuffer.

cu,
Nicolai
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQE/eG5isxPozBga0lwRAhtaAJ48i7pX0eoehcFswsJZwaye1+cv6ACcDks6
kRAJdjEMfZpDJzYOY3cvfVY=
=sk8c
-----END PGP SIGNATURE-----

Hi David,
From your reply I could not work out which technique you did end up
using in the SpitFire.

Dominique
http://www.DelphiGamer.com := go on, write a game instead;

It’s really rather simple. The game runs at a fixed logic frame rate
of 60 Hz (which is rather easy as it’s using a VGA Mode-X mode at 60
Hz), and the logger/demo player is inserted right between the input
code and the “player control” interface of the game logic. The
logger/demo player has three modes:

Normal:
	Forward input to the game logic.

Record:
	Forward input to the game logic, and record
	the input state for each frame.

Playback:
	Disable input and instead pass the state for
	one frame at a time to the game logic.

This still works in a game like Kobo Deluxe, where there is a fixed
logic frame rate, but it does not work for games with variable
logic frame rates, as you cannot get accurate playback without
enforcing the exact logic frame durations as well as the input. (And
then you’ll need interpolation to make demos look good, and then you
may as well use a fixed logic frame rate + motion interpolation, as I
do in Kobo Deluxe. :slight_smile:

IIRC, since input in Project Spitfire is nothing but 4 directions
(digital) and two fire buttons, I just store one byte of data per
frame, ie 60 bytes/s. Not very much, as that’s all that’s needed to
fully reproduce a game. (Enemies have no AI, and there are no random
events or interactive game logic; it’s just plain retro style
preprogrammed attack waves.)

//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.nethttp://www.reologica.se —On Monday 29 September 2003 23.16, Dominique Louis wrote:

Hi David,
From your reply I could not work out which technique you did end
up using in the SpitFire.