Hi
Anyone nows a way to detect screen vertical retrace
in Java?
My games flicker a lot in windowed modes…
Start by looking into BufferStratergy, that will do what you want. Theres a million and one threads on it lying around here somewhere…
My previous post was not so clear…
There’s a way to synchronize the graphics refresh
of an APPLET or a windowed app with the screen
vertical retrace?
I’m using BufferyStrategy ONLY for fullscreen mode,
not for applets or windowed apps.
I cannot find other threads on the subject, so please
excuse my dumb question…
Are you using double-buffering in windowed mode, or are you rendering directly to the screen?
also, you can use BufferStrategy in windowed mode as well as in fullscreen mode, so you won’t have to change the code. Youmight want to be careful with resizing the window, though.
I’m using a double-buffered system, with a VolatileImage as back buffer.
I can use a BufferStrategy also for windowed mode, and this prevent (as you say?) graphics flicker.
My library is able to generate games for windowed mode, fullscreen mode and online mode (applets).
But I’m very interested in online games, so what can I do with APPLETS?
There isn’t a way to check Vertical retrace without using BufferStrategy?
And maybe without using native code?
Maybe I already know the answer: NO 
I used the term “flicker” to mean a strange visual effect that happens especially with graphic scrollings.
It is very difficult to notice it with a static screen game.
Applets can use BufferStrategy as well,
You just have to add a Canvas, then use that for your createBufferStrategy/getBufferStrategy calls.
Infact, it makes sense to use a Canvas in all cases, regardless of whether its an application or Applet.
As to catching the VBlank when in windowed mode, I’m pretty sure its not possible.
I think I heard somewhere that it wasn’t possible even with native code under windows? (any1 who can confirm/deny that rumor, pls correct me)
So as you say there’s NO WAY to reduce flickering
in APPLETS?
What I’ll gain using buffer strategy for applets?
I hope Sun will fix this problem (and maybe the timer)
in the next release!
Many thanks
well if you use BufferStrategy, you gain the potencial of it being vsynced.
It isn’t at the moment, but may be in the future/on other platforms.
That does raise 1 issue. What happens if you don’t want to wait for the vblank signal 
Most native games have an option to toggle vsync on or off. With the current BufferStrategy API, there is no facility to control whether you get vsync or not.
Are you getting “flickering” or just “tearing”??
Tearing being a horizontal “tear” in the image when the vertical scan crosses over during your image blit so that the top part of the screen is refreshed with the old image and the bottom part is drawn with the new image.)
Flickering being flashes of images in an intermediate state (like a cleared background colour).
You should only be getting tearing without syncing to the vertical retrace. If you are getting flickering it could be that your painting needs to be double buffered.
Yes…
I’m only getting a tear effect.
So for now, no way to eliminate it…
it sounds like your copies from the backbuffer to the screen are not accelerated for some reason.
Run your app with primitives tracing turned on and see if that’s the problem:
java -Dsun.java2d.trace=log YourClass
(you can search the forum for this flag to get more info)
Run
java -Dsun.java2d.trace=help YourClass
to get help.
[quote][…]
As to catching the VBlank when in windowed mode, I’m pretty sure its not possible.
I think I heard somewhere that it wasn’t possible even with native code under windows? (any1 who can confirm/deny that rumor, pls correct me)
[/quote]
I thought it’s impossible… but I’ve seen some emulators, wich are able to catch the vsync signal in windowed mode.
Well… I still don’t know how to do that … esp in java - but I guess it’s not possible there.
I was always under the impression that in windowed (Windows? hmmm) mode, the operating system has final control and authority over the vblank signal, as most of the redraw is “hidden” from the applicaton/game developer. I do not have a background using DirectX, so I don’t know if this rule is valid if you use DirectX in windowed mode (is this even possible?) Therefore, I’m inclined to say that unless part of the Java platform’s native DLLs change to intercept this signal in windowed mode, it’s not going to be available to us. Furthermore, I’m not even sure it can be intercepted in windowed mode. Can any DirectX experienced user add some illumination?
[quote]I was always under the impression that in windowed (Windows? hmmm) mode, the operating system has final control and authority over the vblank signal, as most of the redraw is “hidden” from the applicaton/game developer.
[/quote]
I don’t have DirectX experience, but I have plenty of video experience. The vertical retrace is not controled directly by the OS. Once you choose the display refresh rate (typically 60Hz and higher) that is the cycle the video card will be on. The video display hardware will lock to it and keep it steady. It doesn’t change.
The video drivers should provide access to a hardware interrupt that happens at the top of the rescan. I assume that this is accessible through DirectX so you can schedule things to happen at that point. It may be that you have to have full control of the display for that to happen - i.e. be in full screen mode. But that would be really stupid (so it is likely how Microsoft implemented it ) Actually i know that MS is aware that syncing blits to the vertical retrace is important… If you are watching video in a window for instance you don’t want a tear through the middle. I suspect there is a way, but I don’t know the minimum version of DirectX that allows it.
I’ve a lot of experience with DirectX <=7 and also with them was not possible to catch VSync in windowed mode.
Many years ago in DOS, using few simple assembly instructions you could sync with the refresh signal.
I’m not sure that now is possibbile to catch the signal in a simple and “legal” (I mean without strange OS accesses) way.