CSDL with quad-buffering and a seperate flip-thread

Martijn_Melenhorst · March 9, 2002, 9:38am

I just wanted to let you know all my nagging on this list about triple-buffering was not for nothing: A new CSDL version is uploaded to my website,
csdl.sourceforge.net. This version now works with quad buffers and a flip-thread. The whole idea is, that the user blits into alternating software
’backbuffers’ (2), governed by CSDL, after which the flipthread takes care of blitting the current softwarebuffer to the hardware backbuffer, and
flipping that one to the frontsurface… The gain here is, that while the flip thread is busy doing it’s thing, the user is already able to draw the next
frame on the other software surface!

I have used the ‘fixed timestep’ method to overcome refreshrate-differences, like I discussed before on this list. All you need to do is specify a
’gamelogics’ routine, and how many times per second you want it to run, and a ‘gamedraw’ routine, which is called, if all is running well, at the
framerate of the monitor. Oh well, an example in the future will probably help a little bit better

For now, I will focus on the promised sprite engine. This sprite engine will be able to do linear interpolations of movements so that sprites which are
only updated, say, 10 times per second by the gamelogics routine, will move smoothly for every frame drawn.

David_Olofson · March 11, 2002, 12:58pm

I just wanted to let you know all my nagging on this list about
triple-buffering was not for nothing: A new CSDL version is uploaded to
my website, csdl.sourceforge.net. This version now works with quad
buffers and a flip-thread. The whole idea is, that the user blits into
alternating software ‘backbuffers’ (2), governed by CSDL, after which
the flipthread takes care of blitting the current softwarebuffer to the
hardware backbuffer, and flipping that one to the frontsurface… The
gain here is, that while the flip thread is busy doing it’s thing, the
user is already able to draw the next frame on the other software
surface!

Sounds nice!

All we need now for Linux is retrace sync’ed flips. :-/

For any target with h/w pageflipping, it’s doable even w/o a retrace IRQ

but only for refresh rates below the kernel HZ, which is normally 100
on Intel… One could use the RTC, though, as that’s present in some form
on virtually any Linux machine, regardless of CPU type.

So, the solution I’m going to try is basically this:

* Set up a "virtual" PLL, with the idle period set to the
  nominal refresh rate of the current video mode.

* "Replace" the kernel's idle thread with something that
  polls the retrace register, informing the PLL whenever
  it sees a retrace.

* Set up a "page flipper" thread or IRQ handler on the RTC,
  which is set to a rate somewhere above the current
  refresh rate. This will wake up sleepers on the video
  driver whenever a flip occurs.

* Set up a FIFO queue between the video driver and the
  "page flipper" thread, onto which the driver can push
  pages that are ready for display.

* Have the video driver sleep when it's asked to flip,
  and there are no unused buffers left.

Now I just have to find a driver that supports h/w pageflipping -
preferably with more than two pages. heh

Any suggestions for a G400 card? (I have a GeForce 2 GTS as well, if that
would be better for some mysterious reason, and some 32 MB ATI Rage Pro
card here at work…)

I have used the ‘fixed timestep’ method to overcome
refreshrate-differences, like I discussed before on this list. All you
need to do is specify a ‘gamelogics’ routine, and how many times per
second you want it to run, and a ‘gamedraw’ routine, which is called,
if all is running well, at the framerate of the monitor. Oh well, an
example in the future will probably help a little bit better

Cool. Just like the Spitfire Engine.

For now, I will focus on the promised sprite engine. This sprite engine
will be able to do linear interpolations of movements so that sprites
which are only updated, say, 10 times per second by the gamelogics
routine, will move smoothly for every frame drawn.

Is that assuming that the logic frame rate is also 10 Hz? Well, it
doesn’t have to be, but anything else will complicate the API a bit, as
any interpolator will need at least two sets of coordinates. Either the
application will have to tell the engine where a sprite is going as well
as when it’s supposed to be there - or the interpolator will just have
to wait and buffer at least two “move commands” before even starting to
move the sprite.

In the Spitfire Engine (Kobo Deluxe), I chose the easy way and simply
assumed that the game’s control system would deliver a constant rate
stream of coordinates for all objects, one set for every control system
frame. That way, I can use a simple interpolation algorithm,
mathematically equivalent to the linear interpolation your average
wavetable soft synth is doing.

The best part is that the control system callback of the game doesn’t
even have to be aware of the fact that there is interpolation. It just
assumes that the objects are like h/w sprites, and that the screen
refresh rate equals the control system frame rate.

//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 Saturday 09 March 2002 18:37, Martijn Melenhorst wrote:

Martijn_Melenhorst · March 11, 2002, 4:43pm

All we need now for Linux is retrace sync’ed flips. :-/

So, from what I gather, linux sucks for game development I mean, if it can’t even give you the moment a synced flip can happen?
Isn’t SDL in some way solving this already for us, or is it really that unpredictable with linux installations?

Now I just have to find a driver that supports h/w pageflipping -
preferably with more than two pages. heh

Any suggestions for a G400 card? (I have a GeForce 2 GTS as well, if that
would be better for some mysterious reason, and some 32 MB ATI Rage Pro
card here at work…)

I really do not know much about Linux driver issues. I mean, any card should be able to do h/w pageflipping these days, right? Or at least
emulate it in the drivers? Because then my solution would work also…

I have used the ‘fixed timestep’ method to overcome
refreshrate-differences, like I discussed before on this list. All you
need to do is specify a ‘gamelogics’ routine, and how many times per
second you want it to run, and a ‘gamedraw’ routine, which is called,
if all is running well, at the framerate of the monitor. Oh well, an
example in the future will probably help a little bit better

Cool. Just like the Spitfire Engine.

And just like Metal Gear Solid 1 for the PC, I got the tip from one of the developers on a message board…

For now, I will focus on the promised sprite engine. This sprite engine
will be able to do linear interpolations of movements so that sprites
which are only updated, say, 10 times per second by the gamelogics
routine, will move smoothly for every frame drawn.

Is that assuming that the logic frame rate is also 10 Hz? Well, it
doesn’t have to be, but anything else will complicate the API a bit, as
any interpolator will need at least two sets of coordinates. Either the
application will have to tell the engine where a sprite is going as well
as when it’s supposed to be there - or the interpolator will just have
to wait and buffer at least two “move commands” before even starting to
move the sprite.

The 10 Hz above was just an example I used to illustrate my point. It could be anything, ofcourse. And the linear interpolation is really simple:
Every sprite knows it’s former position and it’s position where it should be in the next frame… So you got 2 (x,y) positions. All I do is interpolate
those two coordinates, nothing more, nothing less, actually.

In the Spitfire Engine (Kobo Deluxe), I chose the easy way and simply
assumed that the game’s control system would deliver a constant rate
stream of coordinates for all objects, one set for every control system
frame. That way, I can use a simple interpolation algorithm,
mathematically equivalent to the linear interpolation your average
wavetable soft synth is doing.

What’s that with you and the softsynths Linear interpolation: Say for 0.5 logics frame: (X + deltaX * 0.5), or: (X1+(X2-X1)*factor), same for y. I
hope that’s what you meant? If so, then yes, it is the simple way.

The best part is that the control system callback of the game doesn’t
even have to be aware of the fact that there is interpolation. It just
assumes that the objects are like h/w sprites, and that the screen
refresh rate equals the control system frame rate.

I am calling the control system more often than the game logics themselves. Works really nice, because it gives the user better feedback when
moving a mousepointer with the mouse etc. And it’s not that processor-intensive anyway. This is also a tip I read from, I guess it was a, Team
17 developer.

David_Olofson · March 11, 2002, 5:40pm

All we need now for Linux is retrace sync’ed flips. :-/

So, from what I gather, linux sucks for game development

Well, we still have fast OpenGL drivers, and some even seem to
implement retrace sync. Still, I have to agree to some extent, as I’m
coming from the PAL/NTSC hard-sync’ed, ultra smooth world of the Amiga,
C64 and co…

I mean, if
it can’t even give you the moment a synced flip can happen? Isn’t SDL
in some way solving this already for us, or is it really that
unpredictable with linux installations?

SDL can’t solve it, and probably shouldn’t even try. It’s a driver issue.

Sure, it’s possible to poll the retrace bit from within an application on
Linux (“just” be root and ask for permission to touch those ports
directly - which is a trick you can’t pull on Windows, AFAIK), but that’s
not exactly portable, reliable or nice.

Now I just have to find a driver that supports h/w pageflipping -
preferably with more than two pages. heh

Any suggestions for a G400 card? (I have a GeForce 2 GTS as well, if
that would be better for some mysterious reason, and some 32 MB ATI
Rage Pro card here at work…)

I really do not know much about Linux driver issues. I mean, any card
should be able to do h/w pageflipping these days, right? Or at least
emulate it in the drivers? Because then my solution would work also…

The problem is that remarkably few cards have retrace IRQs these days. It
seems like they rely on certain accelerator commands + some way of
blocking when on the command buffer. As the cards can only do real h/w
pageflipping this way, most Linux drivers are ruled out, as they don’t
support h/w pageflipping at all. heh

Even so, drivers that do support h/w pageflipping don’t implement retrace
sync for some reason. Either it’s some kind of general hostility towards
smooth animation among Linux driver hackers, or virtually all cards have
severely broken designs.

[…]

Is that assuming that the logic frame rate is also 10 Hz? Well, it
doesn’t have to be, but anything else will complicate the API a bit,
as any interpolator will need at least two sets of coordinates.
Either the application will have to tell the engine where a sprite is
going as well as when it’s supposed to be there - or the
interpolator will just have to wait and buffer at least two “move
commands” before even starting to move the sprite.

The 10 Hz above was just an example I used to illustrate my point. It
could be anything, ofcourse. And the linear interpolation is really
simple: Every sprite knows it’s former position and it’s position where
it should be in the next frame… So you got 2 (x,y) positions. All I
do is interpolate those two coordinates, nothing more, nothing less,
actually.

Exactly.

In the Spitfire Engine (Kobo Deluxe), I chose the easy way and simply
assumed that the game’s control system would deliver a constant rate
stream of coordinates for all objects, one set for every control
system frame. That way, I can use a simple interpolation algorithm,
mathematically equivalent to the linear interpolation your average
wavetable soft synth is doing.

What’s that with you and the softsynths

Dunno. Just can’t stay away from that kind of stuff!

Linear interpolation: Say
for 0.5 logics frame: (X + deltaX * 0.5), or: (X1+(X2-X1)*factor), same
for y. I hope that’s what you meant? If so, then yes, it is the simple
way.

Yeah.

The best part is that the control system callback of the game doesn’t
even have to be aware of the fact that there is interpolation. It just
assumes that the objects are like h/w sprites, and that the screen
refresh rate equals the control system frame rate.

I am calling the control system more often than the game logics
themselves. Works really nice, because it gives the user better
feedback when moving a mousepointer with the mouse etc. And it’s not
that processor-intensive anyway. This is also a tip I read from, I
guess it was a, Team 17 developer.

Ah! “Control System” in the above was meant as the whole fixed rate part
of the game, rather than user input.

Either way, I have a problem with the ridiculously low mouse update rates
usually seen on Windows, so I’m running the mouse crosshair in Kobo
Deluxe through the interpolation as well. It’s smooth, but I can’t play
with the mouse anyway, so I can’t really tell if it’s responsive
enough… (I prefer the keyboard, or a digital arcade joystick.

//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 12 March 2002 01:41, Martijn Melenhorst wrote:

Stefan_Hubner · March 11, 2002, 6:12pm

At 02:39 12.03.2002 +0100, you wrote:

Well, we still have fast OpenGL drivers, and some even seem to
implement retrace sync. Still, I have to agree to some extent, as I’m
coming from the PAL/NTSC hard-sync’ed, ultra smooth world of the Amiga,
C64 and co…
Yes, it’s really sad that the days of generating a VIC-IRQ on rasterline
$0fb to know when you can start rendering are over …
St0fF.

Martijn_Melenhorst · March 11, 2002, 11:30pm

And it’s equally sad you could, while waiting for $fb, change the whole palette, resolution and sprite-allocation at every pixel you wanted also?

Don’t go bashing the Amiga’s graphics system, man, it was great! It only took two lines of assembly-code to wait for a vertical blank, and now
people are still discussing how to do it properly on both Windows and Linux while trying to write a smooth-running game!

12-3-2002 3:15:29, St0fF 64 wrote:>At 02:39 12.03.2002 +0100, you wrote:

Well, we still have fast OpenGL drivers, and some even seem to
implement retrace sync. Still, I have to agree to some extent, as I’m
coming from the PAL/NTSC hard-sync’ed, ultra smooth world of the Amiga,
C64 and co…
Yes, it’s really sad that the days of generating a VIC-IRQ on rasterline
$0fb to know when you can start rendering are over …
St0fF.

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

David_Olofson · March 12, 2002, 8:06am

Yeah - but what’s worse is that the days of smooth animation seem to be
over as well (at least if you’re running Linux); not just the days of
brutal hard real time retrace sync.

//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 12 March 2002 03:15, St0fF 64 wrote:

At 02:39 12.03.2002 +0100, you wrote:

Well, we still have fast OpenGL drivers, and some even seem to
implement retrace sync. Still, I have to agree to some extent, as I’m
coming from the PAL/NTSC hard-sync’ed, ultra smooth world of the
Amiga, C64 and co…

Yes, it’s really sad that the days of generating a VIC-IRQ on
rasterline $0fb to know when you can start rendering are over …
St0fF.

Stefan_Hubner · March 12, 2002, 8:51am

At 17:05 12.03.2002 +0100, you wrote:>On Tuesday 12 March 2002 03:15, St0fF 64 wrote:

At 02:39 12.03.2002 +0100, you wrote:

Well, we still have fast OpenGL drivers, and some even seem to
implement retrace sync. Still, I have to agree to some extent, as I’m
coming from the PAL/NTSC hard-sync’ed, ultra smooth world of the
Amiga, C64 and co…

Yes, it’s really sad that the days of generating a VIC-IRQ on
rasterline $0fb to know when you can start rendering are over …
St0fF.

Yeah - but what’s worse is that the days of smooth animation seem to be
over as well (at least if you’re running Linux); not just the days of
brutal hard real time retrace sync.
Sounds like another reason for me not to switch to linux … how do
demo-coders implement timing under linux, then?
I just ask SDL to GetTicks and have my effects beeing f(t), the synced
retrace is done by the OpenGL-driver … hopefully evryone using nvidia
under windoof has this option enabled … or this there a way of querying
the retrace_sync_status and manually enabling it?
Would be helpful for my demo …
St0fF.

David_Olofson · March 12, 2002, 8:52am

[…]

Don’t go bashing the Amiga’s graphics system, man, it was great!

Yeah. I’m really missing that copper… Although it had only 3
instructions, it was the perfect tool for everything to do with video
synchronization.

Having it manually reload sprite DMA buffers several times per raster
line was especially cool! (More than 8 h/w sprites per line.

It
only took two lines of assembly-code to wait for a vertical blank, and
now people are still discussing how to do it properly on both Windows
and Linux while trying to write a smooth-running game!

As you probably know, the fundamental difference is that AmigaDOS was a
more or less hard real time capable microkernel based OS, while these
days, we have to live with an average scheduling latency jitter that’s
much worse than the worst case latency on the Amiga…

In short, trying to sync an application directly with the retrace is
futile on a “modern” OS.

//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 12 March 2002 08:29, Martijn Melenhorst wrote:

David_Olofson · March 12, 2002, 10:25am

At 17:05 12.03.2002 +0100, you wrote:

At 02:39 12.03.2002 +0100, you wrote:

Well, we still have fast OpenGL drivers, and some even seem to
implement retrace sync. Still, I have to agree to some extent, as
I’m coming from the PAL/NTSC hard-sync’ed, ultra smooth world of
the Amiga, C64 and co…

Yes, it’s really sad that the days of generating a VIC-IRQ on
rasterline $0fb to know when you can start rendering are over …
St0fF.

Yeah - but what’s worse is that the days of smooth animation seem to
be over as well (at least if you’re running Linux); not just the days
of brutal hard real time retrace sync.

Sounds like another reason for me not to switch to linux … how do
demo-coders implement timing under linux, then?

Timing is not a problem with Linux - especially not if you happen to
run on a preemptive or (older) lowlatency kernel - but of course, there
will be tearing and unsmoothness with most drivers. (Some do support
retrace sync and/or double buffering, but those are usually closed source
drivers that effectively do this by “bypassing” XFree86.)

I just ask SDL to GetTicks and have my effects beeing f(t),

No problem that far…

the synced retrace is done by the OpenGL-driver …

…but here, you’ll just have to live with the fact that the "flip"
operation will usually start as soon as you call SDL_FlipSurface().

hopefully evryone using nvidia
under windoof has this option enabled … or this there a way of
querying the retrace_sync_status and manually enabling it?

At least no portable way, AFAIK.

//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 12 March 2002 17:48, St0fF 64 wrote:

On Tuesday 12 March 2002 03:15, St0fF 64 wrote:

Stefan_Hubner · March 12, 2002, 4:05pm

At 19:24 12.03.2002 +0100, you wrote:

At 17:05 12.03.2002 +0100, you wrote:

At 02:39 12.03.2002 +0100, you wrote:

Well, we still have fast OpenGL drivers, and some even seem to
implement retrace sync. Still, I have to agree to some extent, as
I’m coming from the PAL/NTSC hard-sync’ed, ultra smooth world of
the Amiga, C64 and co…

Yes, it’s really sad that the days of generating a VIC-IRQ on
rasterline $0fb to know when you can start rendering are over …
St0fF.

Yeah - but what’s worse is that the days of smooth animation seem to
be over as well (at least if you’re running Linux); not just the days
of brutal hard real time retrace sync.

Sounds like another reason for me not to switch to linux … how do
demo-coders implement timing under linux, then?

Timing is not a problem with Linux - especially not if you happen to
run on a preemptive or (older) lowlatency kernel - but of course, there
will be tearing and unsmoothness with most drivers. (Some do support
retrace sync and/or double buffering, but those are usually closed source
drivers that effectively do this by “bypassing” XFree86.)

I just ask SDL to GetTicks and have my effects beeing f(t),

No problem that far…

the synced retrace is done by the OpenGL-driver …

…but here, you’ll just have to live with the fact that the "flip"
operation will usually start as soon as you call SDL_FlipSurface().

Ok, I don’t use this … I use SDL_GL_SwapBuffers();

hopefully evryone using nvidia
under windoof has this option enabled … or this there a way of
querying the retrace_sync_status and manually enabling it?

At least no portable way, AFAIK.

This was just a testing result … the portability got lost when I started
using bass for mp3-playback, because I don’t think using smpeg with
dll-size of 500something kB would be intelligent, as right now it is only
supposed to run under windows, on a very fast computer, with a very new
graphicscard (release date: Symposium&Mekka 2002, PC Demo Competition …
hopefully!) … then bass with 94kB somehow is the better solution …

Cheers,
St0fF.>On Tuesday 12 March 2002 17:48, St0fF 64 wrote:

On Tuesday 12 March 2002 03:15, St0fF 64 wrote:

Bob_Pendleton · March 13, 2002, 9:34am

St0fF 64 wrote:

At 17:05 12.03.2002 +0100, you wrote:

At 02:39 12.03.2002 +0100, you wrote:

Well, we still have fast OpenGL drivers, and some even seem to
implement retrace sync. Still, I have to agree to some extent, as I’m
coming from the PAL/NTSC hard-sync’ed, ultra smooth world of the
Amiga, C64 and co…

Yes, it’s really sad that the days of generating a VIC-IRQ on
rasterline $0fb to know when you can start rendering are over …
St0fF.

Yeah - but what’s worse is that the days of smooth animation seem to be
over as well (at least if you’re running Linux); not just the days of
brutal hard real time retrace sync.

Sounds like another reason for me not to switch to linux … how do
demo-coders implement timing under linux, then?

Exactly the same way you do it under Windows.

Most of the discussion, has imho, been pretty pointless since the
solutions depend on the behavior of specific, hardware, drivers, and
OSes… There hasn’t been a portable way to synch to vertical retrace
since the first svga cards came out.

Some where around here I have a nice modex triple buffer renderer that I
wrote back in '93 or '94. It was obsolete by the end of '95 and so was
this whole line of argument…>> On Tuesday 12 March 2002 03:15, St0fF 64 wrote:

I just ask SDL to GetTicks and have my effects beeing f(t), the synced
retrace is done by the OpenGL-driver … hopefully evryone using nvidia
under windoof has this option enabled … or this there a way of
querying the retrace_sync_status and manually enabling it?
Would be helpful for my demo …
St0fF.

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

–
±-----------------------------------+

Bob Pendleton is seeking contract +
and consulting work. Find out more +
at http://www.jump.net/~bobp +
±-----------------------------------+

Bob_Pendleton · March 13, 2002, 9:37am

David Olofson wrote:

[…]

Don’t go bashing the Amiga’s graphics system, man, it was great!

Yeah. I’m really missing that copper… Although it had only 3
instructions, it was the perfect tool for everything to do with video
synchronization.

Having it manually reload sprite DMA buffers several times per raster
line was especially cool! (More than 8 h/w sprites per line.

It
only took two lines of assembly-code to wait for a vertical blank, and
now people are still discussing how to do it properly on both Windows
and Linux while trying to write a smooth-running game!

As you probably know, the fundamental difference is that AmigaDOS was a
more or less hard real time capable microkernel based OS, while these
days, we have to live with an average scheduling latency jitter that’s
much worse than the worst case latency on the Amiga…

In short, trying to sync an application directly with the retrace is
futile on a “modern” OS.

If you really want to you can go get Amiga OS 4.0 and use it. I recently
signed their developer NDA got their SDK. Very nice, very much alive.> On Tuesday 12 March 2002 08:29, Martijn Melenhorst wrote:

//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

–
±-----------------------------------+

Bob Pendleton is seeking contract +
and consulting work. Find out more +
at http://www.jump.net/~bobp +
±-----------------------------------+

Stefan_Hubner · March 13, 2002, 9:49am

At 11:32 13.03.2002 -0600, you wrote:

Most of the discussion, has imho, been pretty pointless since the
solutions depend on the behavior of specific, hardware, drivers, and
OSes… There hasn’t been a portable way to synch to vertical retrace
since the first svga cards came out.

I guess this is the sad thing about evolution in the case of graphix
adaptors …

Some where around here I have a nice modex triple buffer renderer that I
wrote back in '93 or '94. It was obsolete by the end of '95 and so was
this whole line of argument…

At that time I didn’t even have a computer. My first one I got in '95, it
was a CBM VIC20, just little time later I got my C128DCR … and then I got
a 486 at new years 2000 … well, tell me that I’m a poor boy …
St0fF.

Gabriele_Greco · March 13, 2002, 10:03am

At 11:35 AM 3/13/02 -0600, you wrote:

As you probably know, the fundamental difference is that AmigaDOS was a
more or less hard real time capable microkernel based OS, while these
days, we have to live with an average scheduling latency jitter that’s
much worse than the worst case latency on the Amiga…
In short, trying to sync an application directly with the retrace is
futile on a “modern” OS.
If you really want to you can go get Amiga OS 4.0 and use it. I recently
signed their developer NDA got their SDK. Very nice, very much alive.

BTW on actual Amigas (that those days are all provided with SVGA like
boards) the problem of sync are exact the same you have with
linux

Anyway some gfxcards provide hw synched page flipping, but you cannot rely
on that. Anyway the SDL amiga port has a full hw accel support so if the
gfxcard driver support HW page flipping you can use it (I’m the
maintainer of the port)

Bye,
Gabry (gabrielegreco at tin.it)

Martijn_Melenhorst · March 13, 2002, 10:59am

Problem is, I need to earn money doing what I do, actually, since it’s the only thing I can do well No offense, ofcourse, but Amiga OS 4.0 is really
way off the path of the original Amiga, and to my opinion, they shouldn’t be allowed to use that name anymore at all. But, apart from that, it is a
very nice system itself, I’m just curious how long it takes for .NET to take over :(>If you really want to you can go get Amiga OS 4.0 and use it. I recently

signed their developer NDA got their SDK. Very nice, very much alive.

Martijn_Melenhorst · March 13, 2002, 11:06am

Most of the discussion, has imho, been pretty pointless since the
solutions depend on the behavior of specific, hardware, drivers, and
OSes… There hasn’t been a portable way to synch to vertical retrace
since the first svga cards came out.

Some where around here I have a nice modex triple buffer renderer that I
wrote back in '93 or '94. It was obsolete by the end of '95 and so was
this whole line of argument…

I do not see this discussion as being obsolete: The people who joined this discussion were looking for a way to get a smooth-running system on
every OS out there, on every hardware. I think that discussion applies especially in these days. Getting the moment of a vsync, by interrupt or
whatever, is therefore a crucial topic. It was already obvious from the contents of the posts that there still is a lot of confusion about these subjects,
and that especially people using Linux OS-es get varying results and possibilities all the time.

As for your triple buffer solution: As we dicussed earlier, a triple buffer solution is only possible if you can do a driver/hardware-managed “flip-on-
vsync” of those surfaces without holding the program to wait for a VSync. This is not a possibilty with the standard SDL functions, and that started
the whole argument. Ofcourse maybe you couldn’t care less, and just want the user to see a tearing-effect on this screen, but I do care about this.

The solution I made actually works, by the way, and it will on every graphics card, as long a it is running Windows, I guess, since those drivers do
have a vsync functionality…

David_Olofson · March 13, 2002, 11:15am

[…]

the synced retrace is done by the OpenGL-driver …

…but here, you’ll just have to live with the fact that the "flip"
operation will usually start as soon as you call SDL_FlipSurface().

Ok, I don’t use this … I use SDL_GL_SwapBuffers();

Of course - I was thinking about “flip” in general, but typed something
else…

hopefully evryone using nvidia
under windoof has this option enabled … or this there a way of
querying the retrace_sync_status and manually enabling it?

At least no portable way, AFAIK.

This was just a testing result … the portability got lost when I
started using bass for mp3-playback, because I don’t think using smpeg
with dll-size of 500something kB would be intelligent, as right now it
is only supposed to run under windows, on a very fast computer, with a
very new graphicscard (release date: Symposium&Mekka 2002, PC Demo
Competition … hopefully!) … then bass with 94kB somehow is the
better solution …

Ok. It was quite some time ago I used DirectX directly, so I don’t
remeber if you can ask/set that in a standard way. (It has to be
possible, as the driver options dialog does it, but…)

//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 13 March 2002 00:54, St0fF 64 wrote:

David_Olofson · March 13, 2002, 11:41am

[…]

If you really want to you can go get Amiga OS 4.0 and use it. I
recently signed their developer NDA got their SDK. Very nice, very much
alive.

“developer NDA”? Oh, well…

Still, good to hear that it’s alive.

//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 13 March 2002 18:35, Bob Pendleton wrote:

David_Olofson · March 13, 2002, 11:47am

[…]

Most of the discussion, has imho, been pretty pointless since the
solutions depend on the behavior of specific, hardware, drivers, and
OSes… There hasn’t been a portable way to synch to vertical retrace
since the first svga cards came out.

Some where around here I have a nice modex triple buffer renderer that
I wrote back in '93 or '94. It was obsolete by the end of '95 and so
was this whole line of argument…

So, tearing and “jittering” is state-of-the-art these days?

//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 13 March 2002 18:32, Bob Pendleton wrote: