| |
Wanderer
Account closed
Registered: Apr 2003
Posts: 478 |
Sprite problem (rasters)
Hi.
Here's my problem... I have 8 sprites on the screen. When they are motionless, they are fine. When I attempt to move them left (scrolling) they shake. The same goes for a sprite scroll routine in another demo I'm working on.
It looks like its the raster because it moves from the top of the sprites to the bottom (they are arranged on top of one another in a stack).
I've tried moving the routine that moves the sprites when the raster is below them or above them and even while it's updating the sprites.
It still shakes... it only does so maybe once every 4 seconds so it isn't every cycle. I don't know why this is happening..
Help?! :)
(This is on CCS64 with auto refresh rate, maybe it's the emulator??) |
|
| |
Wanderer
Account closed
Registered: Apr 2003
Posts: 478 |
Quote: Hi.
Here's my problem... I have 8 sprites on the screen. When they are motionless, they are fine. When I attempt to move them left (scrolling) they shake. The same goes for a sprite scroll routine in another demo I'm working on.
It looks like its the raster because it moves from the top of the sprites to the bottom (they are arranged on top of one another in a stack).
I've tried moving the routine that moves the sprites when the raster is below them or above them and even while it's updating the sprites.
It still shakes... it only does so maybe once every 4 seconds so it isn't every cycle. I don't know why this is happening..
Help?! :)
(This is on CCS64 with auto refresh rate, maybe it's the emulator??)
Hrm.. it works under my Win2000 machine but on another machine it flickers something bad. I don't think this is a 'code' problem so much as it is the PC it's being coded on.
/me walks away feeling silly |
| |
anix
Account closed
Registered: Feb 2004
Posts: 35 |
if it's NTSC (right?) then one machine is 60hz and looks correct, and your other machine must be 70,72,75... and will be ugly. |
| |
Krill
Registered: Apr 2002
Posts: 2980 |
code oldschool effects on the real thing and new school effects on the pc, that's how i do it ;) prevents from ugly "bugs" that are caused by mismatching refresh rates =) |
| |
Radiant
Registered: Sep 2004
Posts: 639 |
Actually, the problem with flickering graphics in emulators is unresolvable in most modern non-realtime OS's. It is due to the fact that it is impossible for a process/thread to be guaranteed to be running while the vertical retrace occurs, thus generating some jerkiness in the graphics even when syncing with the retrace.
So never judge the smoothness of your routines on an emulator - use the real machine for that, or an emulator in a realtime OS, or in an environment without context switches (such as DOS ;-) ). |
| |
Graham
Account closed
Registered: Dec 2002
Posts: 990 |
AmigaOS shows that it is possible to do in a multitasking environment. The problem with PCs is the total ignorance towards such things from the side of the OS authors (both, linux and windows).
There are two ways how such thing could be solved: Via vertical blank irqs or for a "wait for vertical blank" which doesn't use a busy loop and REALLY puts the task on sleep until a vertical blank is reached. Also a simple frame counter would solve a lot of jerkyness problems... |
| |
Radiant
Registered: Sep 2004
Posts: 639 |
Quote: AmigaOS shows that it is possible to do in a multitasking environment. The problem with PCs is the total ignorance towards such things from the side of the OS authors (both, linux and windows).
There are two ways how such thing could be solved: Via vertical blank irqs or for a "wait for vertical blank" which doesn't use a busy loop and REALLY puts the task on sleep until a vertical blank is reached. Also a simple frame counter would solve a lot of jerkyness problems...
Yes, that's why I wrote "most modern non-realtime OS's". ;-)
Indeed, a blocking call to wait for the next vertical blank would be awesome, and is the thing I most often mention when people ask me what I'm not satisfied with in Linux/Windows (yes, it happens all the time, really :-P). |
| |
cadaver
Registered: Feb 2002
Posts: 1160 |
From memory, when you use triplebuffering in directdraw, the program (displaydriver) blocks until it can flip the buffers for the next time. This way you can get stable animation on each screen refresh, and it's just as good as waiting for the vertical retrace. But the refresh rate most probably isn't right (50.12Hz) |
| |
Graham
Account closed
Registered: Dec 2002
Posts: 990 |
That is not the Problem. Ofcourse you have some functions which sync to the vertical blank (IDirectDraw4::WaitForVerticalBlank), but they do it with a busy loop eating up 100% cpu time. Also, if there is a task switch short before the vertical blank, the routine will not wait 1 but 2 frames... theoretically this could happen the 2nd frame also etc etc. |
| |
cadaver
Registered: Feb 2002
Posts: 1160 |
Mmm, I still think the problem is mostly with coding of emulators. Just tested CCS64 V3, you can use a custom screen refresh rate, but the problem is that it systematically hiccups every time the difference between C64 refresh and screen refresh generates an extra frame. The multitasking isn't causing the problem, but the fact that CCS doesn't have balls to "cheat" and clamp the execution rate to the screen.
EDIT: Aha, by setting sync to "unlimited" it actually clamps the update exactly to screen refresh, so you get gloriously smooth screen update. But now it's going far too fast :( Maybe 50 Hz custom refresh isn't really anywhere near 50 Hz (at least for me...)
|
| |
Tch
Account closed
Registered: Sep 2004
Posts: 512 |
Hmmm,strange..
I have made a routine involving many sprites and there is no flickering whatsoever.
It uses close to every x-position on the screen.
I made it completely using Winvice (V1.14) with the refresh-rate set to "auto".
According to this thread,it ought to bug.
Maybe it is because I use Windows XP?
Could be as Slay Radio bugs when I run Vice in Warp-mode,stealing all my "rastertime". :P
Or maybe it will bug on a real C64..
|
| |
Wanderer
Account closed
Registered: Apr 2003
Posts: 478 |
Maybe it is the programmer :) (me). It works fine on my home machine, default refresh rate. On my parents machine it flickers something awful. The sprites 'jerk' a little.
I can only hope the competition demos will be run on a true 64. Where the results will either be very good or something awful that the emulator could not emulate.
|
| |
Cybernator
Registered: Jun 2002
Posts: 154 |
Generally speaking, why would anyone use tripplebuffering? Ok, say that the first frame is being displayed, and the second is ready in the second buffer, if I want to prepare the third frame immediately I'll have to go for a third buffer (coz the first one's being displayed, and the second is yet to be displayed). BUT, if the rendering happens that fast, I could just wait until the buffers flip, and continue rendering in the first buffer. By the time I reach the VBI, the rendering will be finished. So why go any further than doublebuffering?
Graham wrote:
> Also, if there is a task switch short before the
> vertical blank, the routine will not wait 1 but 2
> frames... theoretically this could happen the 2nd
> frame also etc etc.
Is an ISR routine considered a separate task? I mean, can the ISR be triggered if the task in which it belongs is idle? If it can, I don't see why M$ doesn't implement page flipping with an IRQ. On the other hand, if the ISR cannot be triggered immediately, this could be implemented in the gfx card. Say, the CPU requests a pageflip when the buffer is ready and continues its job. The gfx cards sees this and as soon as the display has finished, it can flip the buffer on its own. Of course, the CPU would need to be notified of this, but that's not timing critical.
|
| |
Optimus
Registered: Jan 2002
Posts: 122 |
>Generally speaking, why would anyone use tripplebuffering?
I had the same question as you :)
I am new in windows programm, till now I vsynced my effects in DOS, sometimes needing one buffer, sometimes rendering directly to the screen right after Vblank.
In windows, I still don't know how can I make my programms flickerless, there are some times interruptions from the system while my code renders stuff. There is buffer flipping and stuff, but still I think I encounter some problems. I don't know if a 3rd buffer could solve the problem and how do I use it. I have hardly seen smooth scrolling and most people don't care anyways..
I have heard of some demos using interesting techniques with a large ammount of software screen buffers, like some Amiga demos with 3d scenes (The Castle by Loonies), where if for example some frames runs preety fast and some incoming ones slower, the next ones are rendered in memory for future output, while the 1st ones are still outputted to the screen. This way, the demo runs overall in a more steady average frame rate (and not the first frames in 30-50fps and the other heavier ones in 10-20fps eg). But that's with scenes with varying frame rates. Interesting..
Other than that, I don't know what tripple buffering is usefull for. I would like to hear about, hopefully it would save me from those screen clashes at Windows..
Optimus
|
| |
Wanderer
Account closed
Registered: Apr 2003
Posts: 478 |
I finished coding a demo page only to wake up this morning and find the top raster effect was shaking. Frustrated, cursing, I tried changing the JSR to different parts of the screen. It still shook.
Finally I shrunk the window with the emulator and it looked fine. So I gave up, removed the newest version of the CCGS emulator and went back to the old version. The demo page works (no shaking) but it still gives the odd 'jitter'.
The only real test would be on a real 64.
*sigh*
|
| |
Tch
Account closed
Registered: Sep 2004
Posts: 512 |
@Wanderer..
If you want,could you have a look at this for me..
Intrology
Especially the menu.
One of the logos is made with sprites,does it jitter?
Also the scroll runs smooth when I watch it with Vice.
As do most demos I have watched.
Maybe it matters how much of your CPU´s power is set to the actual running program,instead of background activities?
Anyway,I hope your coding won´t be frustrated too much with this renditioning of it on emulators.
Good luck!
|
| |
MagerValp
Registered: Dec 2001
Posts: 1078 |
Triple buffering helps with effects that don't take an integral number of frames to render, as it eliminates the vblank wait. I.e. if you have an effect that takes 25000 cycles to render, with double buffering it has to run at 25 fps, but with triple buffering it'll run at 40 fps. With double buffering the rendering pipeline stalls as the 1st frame is being displayed, and the 2nd frame is waiting for vblank. With a 3rd buffer you can keep rendering.
|
| |
Graham
Account closed
Registered: Dec 2002
Posts: 990 |
You can immediately continue rendering with double buffering if you disable the vsync, but then you will see "upper half old frame, lower half new frame". |
