Hi there,
is it possibble to get the current scanline with SDL? Or is this driver
and system specific (I think DirectX has some functions to request the
current scanline)?
System: XFree 402, G400, SDL 1.1.7
Many thanks,
Sven
is it possibble to get the current scanline with SDL? Or is this driver
and system specific
This is driver and system specific.
See ya!
-Sam Lantinga, Lead Programmer, Loki Entertainment Software
Current scanline!? And here we are trying hard to just detect the vertical
retrace… 
Unfortunately, most modern hardware have very limited capabilites in this
area, but I think it should be possible to read the current VRAM address on
some RAMDACs. Forget about interrupts; you can’t even get that for the
retrace nowadays! One has to use RTLinux or similar and emulate it with a
timer IRQ + a few ?s of polling to stay in sync.
Another solution that might work, depending on what kind of accuracy you need
(well, you need an RTOS to do anything with scan line timing accuracy
anyway…) is to use the Pentium TSC or similar (something usable is
available on most platforms) and implement some sort of PLL that locks to the
retrace using polling. Then you can just read the timer/counter at any time
and then calculate the current raster position in “fractional frame” or some
similar unit.
I have a quick’n’dirty hack for the Utah-GLX OpenGL drivers (XFree86/Linux)
that does this using the Pentium TSC. It’s used for eliminating the tearing
in OpenGL programs, and therefore has to be called from the middle of the
glXSwapBuffers() function to be of much use. If you’re just going to use it
for coarse sub frame accurate timing, you should be able to do it in your
application - provided you can gain access to the I/O ports, or that you have
a target that supports retrace sync. (Most Linux targets don’t.)
It’s fairly generic (although not very portable) code, and should work with
virtually anything with a VGA compatible video card, but the PLL needs some
work. I’ll release the Utah-GLX patch and perhaps a stand-alone version when
I get it to work somewhat reliably.
//David
.- M A I A -------------------------------------------------.
| Multimedia Application Integration Architecture |
| A Free/Open Source Plugin API for Professional Multimedia |
----------------------> http://www.linuxaudiodev.com/maia -' .- David Olofson -------------------------------------------. | Audio Hacker - Open Source Advocate - Singer - Songwriter |--------------------------------------> david at linuxdj.com -'On Wednesday 07 February 2001 10:45, Sven Garbade wrote:
Hi there,
is it possibble to get the current scanline with SDL? Or is this driver
and system specific (I think DirectX has some functions to request the
current scanline)?
System: XFree 402, G400, SDL 1.1.7
It’s fairly generic (although not very portable) code, and should work with
virtually anything with a VGA compatible video card, but the PLL needs some
work. I’ll release the Utah-GLX patch and perhaps a stand-alone version when
I get it to work somewhat reliably.
Watch out for SMP systems. I submitted a framebuffer console patch to
wait for vertical retrace, and it was rejected because polling a VGA
register wasn’t safe on SMP systems.
See ya,
-Sam Lantinga, Lead Programmer, Loki Entertainment Software
Well, I’m not expecting to see it in an official release anyway, but what
exactly is the problem? ISA bus collisions between CPUs?
//David
.- M A I A -------------------------------------------------.
| Multimedia Application Integration Architecture |
| A Free/Open Source Plugin API for Professional Multimedia |
----------------------> http://www.linuxaudiodev.com/maia -' .- David Olofson -------------------------------------------. | Audio Hacker - Open Source Advocate - Singer - Songwriter |--------------------------------------> david at linuxdj.com -'On Wednesday 07 February 2001 20:39, Sam Lantinga wrote:
It’s fairly generic (although not very portable) code, and should work
with virtually anything with a VGA compatible video card, but the PLL
needs some work. I’ll release the Utah-GLX patch and perhaps a
stand-alone version when I get it to work somewhat reliably.Watch out for SMP systems. I submitted a framebuffer console patch to
wait for vertical retrace, and it was rejected because polling a VGA
register wasn’t safe on SMP systems.
Hi,
thanks for your helpful replies. It seems to be very hard to detect a
vertical retrace or even the scanline with modern graphic cards. I’m not
a very good programer, but this looks a little bit strange for me,
because today it’s relativ easy to design a complex 3D animation, which
is almost impossible in old DOS or Amiga systems, but it’s cruel to
detect “basics” like VR or the scanline, which doesn’t seem to be hard
on old systems. I’ve found 10 years old Amiga assembler code to do
exactly this job in a very accurate way.
We’re rewriting old DOS code to Linux, and it uses some functions to
detect the scanline to realise smooth animations and timing. This seems
to be a hard job im modern systems…
Hi,
thanks for your helpful replies. It seems to be very hard to detect a
vertical retrace or even the scanline with modern graphic cards. I’m not
a very good programer, but this looks a little bit strange for me,
because today it’s relativ easy to design a complex 3D animation, which
is almost impossible in old DOS or Amiga systems, but it’s cruel to
detect “basics” like VR or the scanline, which doesn’t seem to be hard
on old systems. I’ve found 10 years old Amiga assembler code to do
exactly this job in a very accurate way.
The most important reason for this going away is that it’s basically useless
without either an RTOS, or full control by overriding the OS.
For example, in my first hack to “fix” the tearing of Utah-GLX (OpenGL driver
for X) I simply polled the retrace bit. Due to the retrace bit giving only a
short pulse, thi driver frequently missed the retrace, being forced to wait
for the next retrace. Not fun.
The reason is that the X server isn’t a real time program, that operating
systems in general don’t support real time programs. (My patched Linux
kernels do, but that’s a feature that X can’t safely use.) Thus, it cannot
use a timer to emulate the missing retrace IRQs (by waking up just before the
retrace and the poll), because the timing accuracy of the timer interrupt is
insufficient.
Doing what I did in the first hack; just busy waiting, doesn’t work either.
It actually make the situation worse, as the time sharing system of the
scheduler will eventually get tired of X hogging the CPU, and practically
lowering it’s priority to allow other programs to run. There goes you chance
to hit the retrace…
Anymay, I think this can be improved a great deal even without OS real time
support, but even if we got a perfect retrace sync solution together, we’d
still be working on a cludge!
Why?
Well, retrace sync, even if implemented using retrace IRQs or RTLinux based
emulated retrace IRQs, this would cause system stress and still lower the
frame rates of your video applications more than necessary. A much better
solution is to do what has been done with audio for ages (even before the
Amiga did it, I think…); use sufficient buffering. Double buffering is not
sufficient, and with the poor real time performance of most current systems,
one may even need more than 3 buffers for smooth animation.
However, 3 buffers is quite enough for most practical applications, and 3 is
also the magical figure that actually allows the application some slack,
rather than forcing it to be in hard sync with the retrace. If there are 3
buffers, you can have anything between 0 and 1 buffers between you and the
display, which means that you don’t have to start rendering exactly after the
retrace to use all available power for rendering.
We’re rewriting old DOS code to Linux, and it uses some functions to
detect the scanline to realise smooth animations and timing. This seems
to be a hard job im modern systems…
I’m assuming you do this instead of using double buffering, or to do partial
back->front blits during the scan.
Don’t - such methods work on hard real time targets only.
Your best bet is to render one frame at a time into the back buffer of a
double buffered display, and then flip. The advantage is that you don’t have
to render the screen in top-down order to avoid flicker and tearing, as you
have to do on single buffered targets.
//David
.- M A I A -------------------------------------------------.
| Multimedia Application Integration Architecture |
| A Free/Open Source Plugin API for Professional Multimedia |
----------------------> http://www.linuxaudiodev.com/maia -' .- David Olofson -------------------------------------------. | Audio Hacker - Open Source Advocate - Singer - Songwriter |--------------------------------------> david at linuxdj.com -'On Thursday 08 February 2001 12:28, Sven Garbade wrote: