Welcome, Guest. Please Login or Register.  • Help
SMF Underground
+ SHMUP-DEV » SHMUP DEV FORUMS » Assistance
|-+ Time Based or Frame Based?

Pages: [1] 2  All   Go Down
0 Members and 1 Guest are viewing this topic. Topic Tools  
Read December 25, 2005, 04:34:47 AM #0
2dguy

Time Based or Frame Based?

I code using a custom designed time based movement engine, but for shooters that opens up some unique problems, nothing I havn't been able to solve, but I'm starting to wonder if the extra over head for dealing with time based movement is even worth it?

I was just curious how others are coding their shooters, in frame based or time based?
Offline  
Read December 25, 2005, 01:46:15 PM #1
joe

Re: Time Based or Frame Based?

Absolute Blue uses frame based animations and movements. This is possible if you choose a fixed refresh rate, for example if you choose a screen mode with 60Hz Hardsync.

Nowadays, I think I should have used time based movements because you can play it in any screenmode, and often the  precessing time is better used over the frames on time based movements.


Jochen Heizmann, Germany
Absolute Blue - Side-Scrolling Shoot'em'up-Game
www.intermediaware.com
Offline  
Read December 25, 2005, 02:11:07 PM #2
unknown

Re: Time Based or Frame Based?

Here's the approach I took for a tick based game, that took frame time into account.
The result is that it runs based on ticks, like an old style shooter. But theres almost never slowdown, and it will never run faster than you allow it too.

Code:
#define FRAMETIME (1/40.0) // Anyone can hit 40 fps, so Its going to run 40 fps for everyone :)
reset_time(); // all calls to get_time, will be mesured in seconds from this moment
t = t1 = 0;
while(1) {
loops = 0;
while(t-t1 > FRAMETIME && (loops < 3)) {
// If there's more than 3 movement updates for one grapics update then
// They no-ones going to know whats going on, so just draw what we have
// even though its running at slower than the desired fps
loops++;
t1 += FRAMETIME;
animate_one_frame();
}
t = get_time();
draw(); // Just draws the graphics to screen, updates nothing
}
Offline  
Read December 25, 2005, 04:15:49 PM #3
ToohrVyk

Re: Time Based or Frame Based?

Darklaga used a tick-based system, with 60 ticks per second. Frames occured at most 60 times per second as well, but were skipped if the rendering took too long (with 15 frames per second being a strict minimum).

My next project uses an event-based system: all movements are time-based (which allows some nice effects, such as slow motion or time rewind), and whenever a frame has been rendered I execute all events that were scheduled for that duration in the correct order. The advantage of this is that the representation of durations (weapon reloading, enemy wave timing etc) is much easier than with a tick-based or time-based system (I only need to schedule an event into the future at the right time), and the game performs less computations than with those systems (since it only executes scheduled events).
Offline  
Read December 27, 2005, 12:30:37 PM #4
Matt McFarland

Re: Time Based or Frame Based?

I am against just using a system that revolves on how many cycles you go through your game loop.  If you use that system and you have all these mechanics cbased on how many cycles you're going through then you can run into serious problems.

For one, things that occur on your system will not occur right on another system.  I can understand that if you want things to occur after each other, like "after the explosion do this" and that is a good way to use a cycle system.

But if you are having a master cycle system, every 5 cycles do this, every 10 cycles do that, then you could have things work totally out of sync with eachother.   I am against a frame-based system, and think that if you are serious about selling your game on multiple machine types then you will run into more compatibility problems with a frame-based system than a time-based system.

With a Timiing system my game is STILL fully functional at 30fps, and the frame skipping is so barely noticed even THEN that it wouldnt harm the gameplay.  However if it were running at 30fps on a frame system, my game would run horribly, forcing the minimum requirements to shoot up a bit..
« Last Edit: December 27, 2005, 12:44:09 PM by Matt McFarland »

<a href="http://www.mattmcfarland.com/flash/myFlashSig.swf" target="_blank">http://www.mattmcfarland.com/flash/myFlashSig.swf</a>
Offline  
Read December 27, 2005, 02:10:40 PM #5
unknown

Re: Time Based or Frame Based?

With my system, if you were running at 30 fps, It would do 2 game ticks, each frame then redraw the screen.
Which is in effect the same as what a time based system would do, except a time based system would do maybe 2.354 ticks per frame, whereas my systems will keep that inaccuracy and add it on another time, so there accumulitive error correction.

I chose to write my game this way because I wanted to get the feel of a classic, old school shooter.. But I definitly wont allow the game to run at anything but the best speed possible  Grin
Offline  
Read December 30, 2005, 08:43:45 PM #6
Olofson

Re: Time Based or Frame Based?

These days, I usually use a fixed logic frame rate and interpolation. This makes the game logic easy to get right, and allows the game to play exactly the same regardless of rendering frame rate - and, it still allows very smooth animation with serious hardware.

The bad news is that OpenGL or Direct3D rendering with sub-pixel accurate scrolling is needed if you want it really smooth at any refresh rate. (I'm talking N-pixels/frame-at-a-fixed-refresh-rate kind of smooth, like in the C64 and Amiga days.) However, it seems like most people are doing the rendering that way anyway these days, and you pretty much need to anyway, to get sufficient frame rates to even talk about smoothness.

Fixed Rate Pig in a not so simple example (sorta' playable game) using C and SDL. The logic frame rate is deliberately very low - 20 fps - to demonstrate the interpolation. (This causes a 100 ms input->response latency, which is why the controls may feel sluggish.)  Note that the rendering is not sub-pixel accurate.

(Sorry 'bout the lack of Win32 binaries! I'll have a go at it with the cross compiler in a moment...)

EDIT: Hey! I just realized there is a Win32 EXE in that package; it's just the SDL and SDL_image DLLs that aren't included. (Pig was intended as a programming example only...) Easiest way is probably to grab some other Win32 binary package, like Kobo Deluxe, and copy all the DLLs from there. Of course, you can also hunt them down on the SDL site if you prefer.
« Last Edit: December 30, 2005, 09:35:41 PM by Olofson »

//David
Offline  
Read December 30, 2005, 11:46:45 PM #7
Taiphoz

Re: Time Based or Frame Based?

I'm no huge fan of Delta Time at all, Although I will use it where needed, IN blitz I tend to use what they call rendertweaning. which is rather good.

in C++ or C'# im not sure exactly what the systems would be called, but, I think the most important thing for any system is that your game can be played by the biggest majority of random systems at the same speed to preserve gameplay.

Any system that reduces the number of systems the software can run on due to poor performance is a bad idea. there are still a lot of older systems out there that may not be able to stay true to a limited frame system.


Offline  
Read December 31, 2005, 12:15:56 AM #8
paladin

Re: Time Based or Frame Based?

here's you a tween-based blitz3d routine (thanks to mark silby of course)...
Code:

Const FPS=60 ;or 50... or whatever

;initialize timer stuff...
period=1000/FPS
time=MilliSecs()-period

; ------------------------------------------------------------------------
; MAIN LOOP
; ------------------------------------------------------------------------

While Not KeyHit(1)

Repeat
elapsed=MilliSecs()-time
Until elapsed

;how many 'frames' have elapsed
ticks=elapsed/period

;fractional remainder
tween#=Float(elapsed Mod period)/Float(period)

For k=1 To ticks
time=time+period
If k=ticks Then CaptureWorld

UpdateGame()
                     UpdateWorld
  Next

 ;Text Stuff Here

RenderWorld tween

Flip

Wend

End
« Last Edit: December 31, 2005, 12:17:28 AM by paladin »

needs more particles...
Offline  
Read December 31, 2005, 12:39:24 AM #9
Olofson

Re: Time Based or Frame Based?

here's you a tween-based blitz3d routine (thanks to mark silby of course)...

So, CaptureWorld grabs the current positions of all objects, and the 'tween' argument to RenderWorld is the "balance" factor for interpolating graphical coordinates from the last two sets of world coordinates? (I have no experience with the Blitz* products.)

If so, that's basically what I refer to as interpolation in Fixed Rate Pig. (And Kobo Deluxe, for that matter.)


//David
Offline  
Read December 31, 2005, 12:55:13 AM #10
oNyx

Re: Time Based or Frame Based?

[....] I am against a frame-based system, and think that if you are serious about selling your game on multiple machine types then you will run into more compatibility problems with a frame-based system than a time-based system.[...]

With time based systems way more things can go wrong. Tickbased is bullet proof. I also think that frame skipping really sucks in this genre. With slowdowns it remains playable at least, whereas frameskipping can warp you right into death. That isnt fun at all.

Shikigami 1+2, those games from zun etc are all using 60hz ticks. In shiki2 you can't save a replay if you only reached <55 fps for >5% of the time (or so) for preventing abuse of slow PCs. This way its competitive across a broad range of different machines.

So, 60hz ticks with swapinterval 1 (vsync 60hz) or 2 (vsync 120hz) for me.
Offline  
Read December 31, 2005, 01:12:16 AM #11
Olofson

Re: Time Based or Frame Based?

With time based systems way more things can go wrong. Tickbased is bullet proof. I also think that frame skipping really sucks in this genre. With slowdowns it remains playable at least, whereas frameskipping can warp you right into death. That isnt fun at all.

Shikigami 1+2, those games from zun etc are all using 60hz ticks. In shiki2 you can't save a replay if you only reached <55 fps for >5% of the time (or so) for preventing abuse of slow PCs. This way its competitive across a broad range of different machines.

So, 60hz ticks with swapinterval 1 (vsync 60hz) or 2 (vsync 120hz) for me.
What if you can't use 60 Hz (CRT becomes a stroboscope) or 120 Hz? (BTW, some drivers and operating systems do not allow applications to specify the refresh rate at all.)

What if there's no vsync? (Aaargh! The horror! Shocked But OpenGL drivers tend to disable it by default, and on some platforms, it's not available at all.)

And if you're using 120 Hz, how do you avoid the ghost effect on CRTs, caused by "double flashing" every frame?

A fixed frame rate + interpolation, apparently also known as tweening, deals with all that rather nicely - or at least, gets the job done even if the system or setup isn't optimal.

Now, your frameskipping argument is a very good one. Unless you're on an RTOS or well tuned system, you can count on the occasional "hickup", and this has to be dealt with. With interpolation/tweening, one has to do so explicitly, for example by clamping the delta times at some suitable value, effectively making the game pause if a delta time is too long.
« Last Edit: December 31, 2005, 01:26:58 AM by Olofson »

//David
Offline  
Read December 31, 2005, 01:18:28 AM #12
paladin

Re: Time Based or Frame Based?

@olofson: here's the info for renderworld()

Renders the current scene to the BackBuffer onto the rectangle defined by each cameras CameraViewport( ). Every camera not hidden by HideEntity( ) or with a CameraProjMode( ) of 0 is rendered. Rendering to other buffers is currently not supported by Blitz3D.

The optional tween parameter should only be specified when RenderWorld is used in conjunction with CaptureWorld. CaptureWorld is used to store the 'old' position, rotation and scale, alpha and colour of each entity in the game world, and a tween value of < 1 will interpolate between these 'old' values and the 'current' ones. A tween value of 0 will render all entities at their state when CaptureWorld was last called, and a tween value of 1 will render all entities at their current state.

The use of tweening allows you to render more than one frame per game logic update, while still keeping the display smooth. This allows you to cut down on the CPU time that would be required to update your game logic every render. Note, however, that the bottleneck in almost all 3D applications is the graphics card and the CPU time involved in updating game logic is often very little. A good alternative to render tweening is the use of a delta time, that is, moving your entities each frame depending on the time it took for the program to process and render that frame.

Render tweening is quite an advanced technique, and it is not necessary to use it, so don't worry if you don't quite understand it. See the castle demo included in the mak (nickname of Mark Sibly, author of Blitz3D) directory of the Blitz3D samples section for a demonstration of render tweening.


needs more particles...
Offline  
Read December 31, 2005, 01:36:02 AM #13
oNyx

Re: Time Based or Frame Based?

>What if you can't use 60 Hz (CRT becomes a stroboscope) or 120 Hz? (BTW, some drivers and operating systems do not
>allow applications to specify the refresh rate at all.)

You check the available modes, if there is 120 you can use it... if there isnt 120 or if its 0 (win9x for example behaves like that), you'll need to pick 60... which may be ignored anyways therefore you need some throttle code (which aims for example at 62.5 fps [16msec/frame]) as backup.

>What if there's no vsync? (Aaargh! The horror! Shocked But OpenGL drivers tend to disable it by default, and on some
>platforms, it's not available at all.)

You can only gently ask for vsync. Its the driver's decision if it gets actually en/disabled. (backup throttle... see above)

>And if you're using 120 Hz, how do you avoid the ghost effect on CRTs, caused by "double flashing" every frame?

Do you see "double flashing" in the cinema or with 100hz TVs? No? Well, every frame is shown twice there. It just looks steadier.

>A fixed frame rate + interpolation, apparently also known as tweening, deals with all that rather nicely - or at least,
>gets the job done even if the system or setup isn't optimal.

I aim for 6 year old hardware (or better) with some acceleration*. Getting 60+ fps even with hardware that bad is easy (even if the bullet count peaks at around 2500).

[* Like a K7/P3 500mhz + gf2mx]

edit: The b0rked formatting is the fault of that wider-than-your-post text area Tongue
« Last Edit: December 31, 2005, 01:38:07 AM by oNyx »

Offline  
Read December 31, 2005, 11:28:11 AM #14
Olofson

Re: Time Based or Frame Based?

>And if you're using 120 Hz, how do you avoid the ghost effect on CRTs, caused by "double flashing" every frame?

Do you see "double flashing" in the cinema or with 100hz TVs? No? Well, every frame is shown twice there. It just looks steadier.

Actually, I do, which is why I'm bringing the issue up.

However, TVs and cinema are bad examples of this effect, as the effect is partially masked by the motion blur - which is generally not implemented in games. I've played around with this in game engines without motion blur, and the effect is annoyingly visible to me, at least. Even at very high refresh rates, "double flashing" results in some level of blurring or ghosting, which disappears when animation is done at the full refresh rate.

Anyway, at 100+ Hz, the phenomenon starts to go away, unless things are moving around very fast, so unless you're as over sensitive as I am, you can probably get away with "double flashing" at 120+ Hz. Wink


//David
Offline  
Read December 31, 2005, 12:02:23 PM #15
Taiphoz

Re: Time Based or Frame Based?

Its worth taking note here that game timing from language to language can be a hell of a lot different, so what works for B3D turns out not to be so good for C# or java.

Its a matter of finding out what works for you, what runs on the most machines and what gives you the best control of speed and flow over your game.

Fit all those criteria and you have the best system for your project, this will not be the best system for all, but it will be the best for you and thats all that really matters.


Offline  
Read December 31, 2005, 04:44:41 PM #16
oNyx

Re: Time Based or Frame Based?

>And if you're using 120 Hz, how do you avoid the ghost effect on CRTs, caused by "double flashing" every frame?

Do you see "double flashing" in the cinema or with 100hz TVs? No? Well, every frame is shown twice there. It just looks steadier.

Actually, I do, which is why I'm bringing the issue up.

However, TVs and cinema are bad examples of this effect, as the effect is partially masked by the motion blur - which is generally not implemented in games. I've played around with this in game engines without motion blur, and the effect is annoyingly visible to me, at least. Even at very high refresh rates, "double flashing" results in some level of blurring or ghosting, which disappears when animation is done at the full refresh rate.

Anyway, at 100+ Hz, the phenomenon starts to go away, unless things are moving around very fast, so unless you're as over sensitive as I am, you can probably get away with "double flashing" at 120+ Hz. Wink


Seriously. There is no such thing as double flashing. Say a game runs with 50fps at 120hz. Then you see some frames 2 and others 3 times. There is no ghosting or whatever.

If you show each frame twice at 120hz its the same as showing each frame once at 60hz. The only difference is that it flickers less, because the brightness changes within one frame for a given pixel are smaller.



Upper: 60hz swapinterval 1
Lower: 120hz swapinterval 2
x axis: frames
y axis: brightnes

With the latter the brightnes difference peaks (from the desired value) is halved and refreshing also happens twice as often. Its really way nicer to the eye. The individual refreshes simply cannot be seen by a human (with 120hz you also dont see individual refreshes of this text, do you?).

I would say you have seen some weird effect in the past and now you're thinking its due to this stuff, but it isnt. You could for example see some kind of weird ghosting if you rely on having 2 buffers, but infact there are 3. Thats something completely different and with swapinterval 2 this kind of things just wont happen, because the same buffer is shown twice.

If you have Quake3 you can take a look at the stuff I'm talking about. Ensure that it runs at 120hz, ensure that opengl vsync is set to say "on by default"... then drop the console and enter:

r_swapinterval 2
vid_restart
Offline  
Read December 31, 2005, 05:39:59 PM #17
Olofson

Re: Time Based or Frame Based?

Seriously. There is no such thing as double flashing. Say a game runs with 50fps at 120hz. Then you see some frames 2 and others 3 times. There is no ghosting or whatever.

You may call it what you want, but the fact remains that showing the same frame twice at 120 Hz is different from showing unique frames at 120 Hz. Maybe most people can't see the difference for some reason, but I can, unfortunately.


Quote
If you show each frame twice at 120hz its the same as showing each frame once at 60hz. The only difference is that it flickers less, because the brightness changes within one frame for a given pixel are smaller.

Disregarding the flicker issue, which is another matter entirely, it's not the same, since the extra identical intermediate frames ruin the illusion of smooth movement by actually revealing that objects don't move between the 60 Hz frames. I don't know why, but that's how the human eye works. (Or mine do at least - but I could be an alien or something. Wink )


Quote
With the latter the brightnes difference peaks (from the desired value) is halved and refreshing also happens twice as often. Its really way nicer to the eye.

I would definitely agree that 120 Hz is nicer than 60 Hz (unless possibly if you're using a slow phosphor monitor specifically built for low refresh rates), but that's not really what I'm talking about. I maintain that there is a visible (to some people) difference between 60 fps at 120 Hz and 120 fps (ie tweening/interpolation, delta timing or similar, to produce unique frames) at 120 Hz.


Quote
The individual refreshes simply cannot be seen by a human (with 120hz you also dont see individual refreshes of this text, do you?).

No, I can't see individual refreshes or even flickering above 80-85 Hz or so, but this issue is not as simple as that.


Quote
I would say you have seen some weird effect in the past and now you're thinking its due to this stuff, but it isnt. You could for example see some kind of weird ghosting if you rely on having 2 buffers, but infact there are 3. Thats something completely different and with swapinterval 2 this kind of things just wont happen, because the same buffer is shown twice.

I noticed this some years ago when I was playing around with DirectDraw, and wanted to minimize the CPU load (that is, frame rate) while avoiding the hysterical 60 Hz flickinging. I decided to try higher refresh rates with a swap interval to produce the desired frame rate without the flickering - but I discovered that, while the flickering was eliminated, I got visible ghosting on fast moving objects instead.

(Actually, this is always present to some extent on any normal type of display, but displaying the same frame multiple times on a CRT seems to emphasize it.)

I could see the same kind of ghosting in Amiga games and demos running 25 fps at 50 Hz (PAL), and I just hated it. I thought that this effect would not be visible at all with 100+ Hz, but after actually trying it, I had to conclude that I was wrong.


Quote
If you have Quake3 you can take a look at the stuff I'm talking about. Ensure that it runs at 120hz, ensure that opengl vsync is set to say "on by default"... then drop the console and enter:

r_swapinterval 2
vid_restart

I'll try that. (Just need to switch OS and display.)


//David
Offline  
Read December 31, 2005, 06:09:42 PM #18
oNyx

Re: Time Based or Frame Based?

>You may call it what you want, but the fact remains that showing the same frame twice
>at 120 Hz is different from showing unique frames at 120 Hz.

That goes without saying. But its about swapinterval 2 @ 120hz vs swapinterval 1 @ 60hz.

>since the extra identical intermediate frames ruin the illusion of smooth movement

No.

>I don't know why, but that's how the human eye works.

No. Individual "eye pixels" are asynchronously polled at about 7-9hz. Its like spraying the new image over the old one. Thats the reason for reallife-motion-blur.

>unless possibly if you're using a slow phosphor monitor specifically built for low refresh rates

Slow decaying phosphor is used in older monitors, which are unable to go as high as 120hz.

120hz and swapinterval 2 is way nicer than 60hz and swapinterval 1 and there are only advantages and no drawbacks. And it looks perfectly smooth. Its basically like a very fast tft. Eg timebased, vsync on and a fluctuating framerate of 60-100 at 120hz looks less smooth, because the motion is less consistent.

With 120hz and swapinterval 2 there is no ghosting. Seriously, there isnt. Its impossible. You also dont see ghosting in animated gifs or avis do you?

And amiga... well, thats slow hardware and they used a lot of silly tricks there. Eventually you were seeing some side effects.
Offline  
Read December 31, 2005, 07:32:41 PM #19
Olofson

Re: Time Based or Frame Based?

Well, I tried RTCW (didn't have Q3A installed for some reason) with four different setups:
  • 60 Hz, frameskip 2 (30 fps)
  • 60 Hz, frameskip 1 (60 fps)
  • 120 Hz, frameskip 2 (60 fps)
  • 120 Hz, frameskip 1 (120 fps)

Needless to say, higher fps makes everything smoother. One would think that more than 60 fps shouldn't make much of a difference, but at 120 fps, everything is crystal clear when I'm moving around, and I find it easier to navigate, compared to 60 fps or lower. (I've tried this with Q3A before, and my limit is somewhere around 85 Hz. Higher than that is just a waste of GPU power, but lower makes the game harder to play.)

As to the ghosting phenomenon I'm talking about, I see it very clearly in both cases with frameskip 2.

Try 60 Hz and frameskip 2 (30 fps). Face some wall with well defined edges and details, and strafe, looking at the details as they scroll by.

I'd be surprized if you can't see at least two copies of every detail. (Or general blurring, which happens for the same reason.) I frankly don't know if your average person will still see this effect at 120 Hz with frameskip 2, bit I do, very clearly.


>You may call it what you want, but the fact remains that showing the same frame twice
>at 120 Hz is different from showing unique frames at 120 Hz.

That goes without saying. But its about swapinterval 2 @ 120hz vs swapinterval 1 @ 60hz.

Well, 2 @ 120 Hz is nicer to look at (no flickering), but I find the ghosting/blurring annoying. The feeling of reduced responsiveness is about the same as with 1 @ 60 Hz, though.


Quote
>since the extra identical intermediate frames ruin the illusion of smooth movement

No.

Well, I just tried it and came to the same conclusion as the last time I looked into it. What can I say...?


Quote
>I don't know why, but that's how the human eye works.

No. Individual "eye pixels" are asynchronously polled at about 7-9hz. Its like spraying the new image over the old one. Thats the reason for reallife-motion-blur.

Yeah, I know. The eye essentially works as a time domain low pass filter. That might actually explain what's going on here...!

When upsampling audio by an integer factor, the easiest way to get clean output is to just insert zeroes in between the samples, and then apply a relatively simple (as in, not extremely steep) low pass filter, to remove frequencies above the old Nyqvist frequency. The reason why you can get away with a simple filter and still get good results is that the transients added when you insert zeroes land in a frequency range far above the filter cutoff frequency.

Now, if you would use the same filter, but repeat every input sample N times instead of inserting zeroes, you would get horrible results. The filter cannot eliminate the stair-stepping, because it generates noise way too close to f0.

I figure what I'm seeing is basically the same effect. A high refresh rate with frameskip is approximating stair-stepped upsampling, whereas a low refresh rate with frameskip 1 corresponds to inserting zeroes.


Quote
>unless possibly if you're using a slow phosphor monitor specifically built for low refresh rates

Slow decaying phosphor is used in older monitors, which are unable to go as high as 120hz.

...and they're also unable to produce the annoying flicker that makes 60 Hz unusable on modern CRTs. I'm not sure whether they'd be slow enough to generate the kind of blur I'm seeing with CRTs with frameskip, and TFTs for that matter.


Quote
120hz and swapinterval 2 is way nicer than 60hz and swapinterval 1 and there are only advantages and no drawbacks. And it looks perfectly smooth.

Well, I have to disagree. All in all, it looks a tiny bit better than the 60 Hz flickering to me, but perfectly smooth? Not even close. It's acceptable if objects move very slowly, and/or there is proper motion blur.

Quote
Its basically like a very fast tft.
Well, I haven't tried this on any sufficiently fast TFT, but sampling theory (see above) tells me it would have the same problem as a CRT with frameskip > 1.


Quote
Eg timebased, vsync on and a fluctuating framerate of 60-100 at 120hz looks less smooth, because the motion is less consistent.

Of course, but that's a different matter altogether. A fluctuating frame rate definitely eliminates any chances of having smooth animation.


Quote
With 120hz and swapinterval 2 there is no ghosting. Seriously, there isnt. Its impossible.

So, why am I still seeing two copies of everything as soon as I set swapinterval to 2...? Smiley


Quote
You also dont see ghosting in animated gifs or avis do you?

No (not normally), because they're either making it with motion blur, or the frame rates are too low, so what I see is basically a fast series of still images.


Quote
And amiga... well, thats slow hardware and they used a lot of silly tricks there. Eventually you were seeing some side effects.

Well, it was fast enough that some games did rock solid full frame rate (50 Hz) scrolling, and that looked a lot smoother than the usual frameskip 2 to me. (And yes, I did my own experiments on the Amiga too, in 68k asm directly to the metal, so I'm not just assuming things here.)


//David
Offline  
Read December 31, 2005, 08:40:15 PM #20
Olofson

Re: Time Based or Frame Based?

I cracked it! Smiley

(And BTW, I have just compared 1 @ 60 Hz to 2 @ 120 Hz again, and I have to revert to my old position; 1 @ 60 Hz actually looks much better. This old CRT does flicker slightly at that refresh rate, but it's barely visible in your average RTCW scene. However, I can see no ghosting whatsoever, and animation looks and feels more fluent than with 2 @ 120 Hz. Anyway...)

With 120hz and swapinterval 2 there is no ghosting. Seriously, there isnt. Its impossible.

There is - and now I know why. Read on...

In these tests, I've been observing what happens when you try to track objects moving over the screen. When doing this, the eyes will be locked onto one object at a time, which means they're moving across the screen surface. This - the fact that the eyes are moving - is what causes the ghosting, and it also explains another thing I just observed; why there are  exactly N ghosts, where N is the frameskip/swapinterval value.

When the eyes have locked onto a moving object, they're moving constantly and smoothly, following the object. Now, that's fine as long as the object "flashes" every now and then, at the expected position. If the refresh rate isn't extremely low, you won't really see any flashing, and unless the monitor is very slow, you won't see that each "flash" is actually an image of a non-moving object without motion blur.

However, as we introduce frameskip, this breaks down! Now, every other frame will show the object in the wrong position - more specifically, the last position. The eye will not track this high frequency variation in speed, but instead it will keep moving smoothly. The resul is double exposure! The "real" frame hits the moving eye, and then the "extra" frame hits the eye in a different position.

With true 120 fps, any moving object tracked by the eye will hit the eye in the exact same place every time. With 60 Hz and no frameskip, every other frame is basically missing - which means nothing happens, and all is well. (Apart from the flickering, of course, but that's a different issue.)


This, however, doesn't quite explain why the whole scene looks blurred when running around with 2 @ 120 Hz. Maybe the blurring actually is a separate phenomenon? Or is it actually the brain and not the eyes that do the tracking, at least in this case? I mean, when running forward, the blurring is there, and looks  like a slight tunnel effect - but unless my eyes are equipped with zoom lenses, I can't very well be tracking the whole scene movement physically, can I...?


//David
Offline  
Read January 01, 2006, 03:56:38 PM #21
oNyx

Re: Time Based or Frame Based?

That explanation doesnt make much sense imo Smiley

Eventually its your driver which does something different than the spec says. ATI's drivers for example ignore it completely... they only know 0 and everything else is like 1. So, it seems to be not very practical in reality Undecided
Offline  
Read January 01, 2006, 05:06:10 PM #22
Olofson

Re: Time Based or Frame Based?

That explanation doesnt make much sense imo Smiley

The explanation might not be very clear, but the phenomenon isn't all that strange.

Have you noticed what it looks like if you move a LED display (like an old alarm clock or something; anything that drives LED segments by driving one figure at a time, as it's usually done) quickly in front of you? You'll see evenly spaced copies of the display, rather than plain motion blur.

This ghosting thing is basically the same thing; multiple exposure of a moving, flashing object. Only in the CRT case, it's the eye tracking an object moving over the CRT, rather than the CRT moving around.


Quote
Eventually its your driver which does something different than the spec says. ATI's drivers for example ignore it completely... they only know 0 and everything else is like 1. So, it seems to be not very practical in reality Undecided

Well, I can't think of any driver weirdness, that a CRT can reproduce, that would give this result. It's not a page flipping error or anything like that. Everything is rock solid and behaves just as expected. With swapinterval set to 0, I get a few hundred fps (no vsync) and with other values, I get the refresh rate divided by that value.

BTW, I used an nVidia 6800 based card with a recent nVidia driver on Win2k and RTCW for this. Either way, as I've already explained, I've seen this before on various, very different types of hardware, with games as well as my own test programs, written to the metal, and various APIs. Always the same result.


//David
Offline  
Read January 02, 2006, 08:37:29 AM #23
TheColonial

Re: Time Based or Frame Based?

Wow... that went a bit Off Topic there.. but it was fun to read! Smiley

One thing I'd like to throw in On Topic - lots of people make the mistake of only updating their game state once every frame. If you're locking yourself to a particlar frame rate that's fine - but make sure you update your game state as much as you can.  This allows for a much high precision in calculations that are related to time offsets.

For those of you out there who still update positions/locations/state/etc at the same time you draw them - STOP IT! Smiley lol.  Your game update should be happening independent of your framerate - regardless of whether your game is frame or time based. If it's frame based, then update once per frame, if it's not, do it whenever you can! But keep them independant.

Cheers!
TC.


In order to understand recursion, one must first understand recursion.
Offline  
Read January 02, 2006, 09:45:14 AM #24
2dguy

Re: Time Based or Frame Based?

"You check the available modes, if there is 120 you can use it... if there isnt 120 or if its 0 (win9x for example behaves like that), you'll need to pick 60... which may be ignored anyways therefore you need some throttle code (which aims for example at 62.5 fps [16msec/frame]) as backup."

If anyone here is actually changing the end user's monitor refresh rates (without getting permission from the end user at least!!) you should be forever not allowed not to release a video game on the pc. This is just insane. Sure you can change the screen resolution, but not the refresh rate.

"I could see the same kind of ghosting in Amiga games and demos running 25 fps at 50 Hz (PAL), and I just hated it. I thought that this effect would not be visible at all with 100+ Hz, but after actually trying it, I had to conclude that I was wrong."

It's easy to see, simply move 1 object on screen every vsync, move another at 2 vsyncs, the one moving at 2 will have the "ghosting effect" as you call it. It actually gets worse when you "focus" on the object. In a scrolling game where the "world" is scrolling and the main sprite is center screen, this "ghosting effect" is minimized greatly.

Bigger sprites also tend to mask the ghosting effect. But smaller bullet sprites jumping a few pixels every frame really enhance the ghosting effect if you miss a vsync or 2 once in a while. And it's not just monitor refresh rate that effects this "ghosting" it's also individual object duration on screen in between movements.

"Your game update should be happening independent of your framerate - regardless of whether your game is frame or time based."

Another popular misconcemption.

Your code should reflect exactly what is happening on screen.

ESPECIALLY in a shoot-em-up game.
Offline  
Read January 02, 2006, 07:02:05 PM #25
oNyx

Re: Time Based or Frame Based?

[...]
For those of you out there who still update positions/locations/state/etc at the same time you draw them - STOP IT! Smiley lol.  Your game update should be happening independent of your framerate - regardless of whether your game is frame or time based. If it's frame based, then update once per frame, if it's not, do it whenever you can! But keep them independant.[...]

Arcade/console games also do it and most pc shoot em ups, too. Everyone should play the same game... otherwise its impossible to compare scores.

[....]
If anyone here is actually changing the end user's monitor refresh rates (without getting permission from the end user at least!!) you should be forever not allowed not to release a video game on the pc. This is just insane. Sure you can change the screen resolution, but not the refresh rate.
[...]

No one changes the mode blindly. You can get the available modes and you can also get the current one. With some simple math you can determine if its save to switch.

Eg available refresh rates for 640x480x32 are 60, 72, 75, 80, 100, 120, 144, 160... well, thats what the OS tells you.

Say the current mode is 1024x768x32 @ 100hz.

768*100=76800

And you want 640x480x32 @ 120hz.

480*120=57600

So its save to switch. Even 160hz (480*160=76800) would be alright. If the OS fails to report the refresh rates (0 for everything) the only thing you can do is guessing... so you use 60hz, because its the only save value.
Offline  
Read January 03, 2006, 01:39:38 AM #26
2dguy

Re: Time Based or Frame Based?

"....No one changes the mode blindly. You can get the available modes and you can also get the current one. With some simple math you can determine if its save to switch...."

You're missing the point. You're asking the "hardware" if it's ok, not the end user. I NEVER want my monitor's refresh rate changed. There's also stories of some monitors being blown because of changing refresh rates. This again is something that should not be "standard" practice. I guess if you're coding the next Doom or Quake then you can probably get away putting up a menu with all the modes available and asking the user to select one. But for simple shoot-em-ups you really just want the user to click on run and go.
Offline  
Read January 03, 2006, 03:06:51 AM #27
oNyx

Re: Time Based or Frame Based?

>You're missing the point. You're asking the "hardware" if it's ok, not the end user. I NEVER want
>my monitor's refresh rate changed.

It looks better with vsync. Or generally... if everything is 100% synced.

>There's also stories of some monitors being blown because of changing refresh rates.

Cant happen with those simple sanity checks.

>I guess if you're coding the next Doom or Quake then you can probably
>get away putting up a menu with all the modes available and asking
>the user to select one.

Decide. Its either asking the user or not.

The other options are using always 60hz or the OS default settings for that mode (there is no guarantee that those modes are valid). Asking the hardware and checking if that stuff makes sense is the best option you have.
Offline  
Read January 03, 2006, 03:20:08 PM #28
2dguy

Re: Time Based or Frame Based?

You guys DO allow for Windowed mode right?
Offline  
Read January 03, 2006, 05:30:06 PM #29
Olofson

Re: Time Based or Frame Based?

You guys DO allow for Windowed mode right?

Naah. It's too cold outside this time of year. Grin

I try to make my stuff usable on pretty much anything (within reasonable limits), and then I try to add support for "tricks" that can make it run faster and/or smoother on better hardware. So, yes, windowed mode, fullscreen, software rendering, OpenGL, disabling/minimizing expensive blending effects, scaling to various resolutions etc...

However, I've been dealing mostly with Free/Open Source projects that run on 10+ different platforms with countless combinations of hardware and driver architectures. For a simple game like Kobo Deluxe, SDL pretty much covers everything, and there is an OpenGL layer (glSDL) to make use of OpenGL where available. The graphics can be scaled (load time) to various resolutions from 320x240 through 2048x1536, so you can have low resolution and high frame rate, or vice versa, or "everything", if you have accelerated OpenGL.

Scalability is a nice thing - but unfortunately, it gets a lot harder to do as soon as you start relying on scaling, rotation, blending and other stuff. At some point, it's just not worth the effort, as it'll be unplayable on low end machines no matter what. Then again, some Kobo Deluxe players prefer using 640x480 or higher even when it results in frame rates in the 20-40 fps range... I'd rather play in 320x240 if I have to - but hey, if they're happy, I'm happy.


//David
Offline  
Read January 03, 2006, 10:03:28 PM #30
oddbob

Re: Time Based or Frame Based?

If anyone here is actually changing the end user's monitor refresh rates (without getting permission from the end user at least!!) you should be forever not allowed not to release a video game on the pc. This is just insane. Sure you can change the screen resolution, but not the refresh rate.

To be honest, I'd rather games didn't do either without asking me first.

Regardless of whatever "sanity" checks someone puts into place, Its my machine that you're toying with and it should be my choice on wether a game changes things, not the authors.


Well, I've wrestled with reality for 35 years, Doctor, and I'm happy to state I finally won out over it.
Offline  
Read January 20, 2006, 11:34:57 PM #31
pvwr

Re: Time Based or Frame Based?

Just my 2c, I'm all out for a time based logic, running at 20 fps or so, and a renderer interpolating stuff on the hardware dependent vertical retrace. Computers are wild animals unlike their console counter parts, and we are not guaranteed to have a desirable/compatible frame rate. Not to mention that interpolating can make a nice use of subpixel rendering on 2D, which looks really nice. BTW, I have to thanks Olofson once again, his example on 2D subpixel scroll was really great. Had a lot of headaches to make a tilemap converter for subpixel scrolling, but in the end it was worth it Smiley.

I'd go with frame based logic IF (and only if) I knew all targeted hardware/OS  would support it, which is simply not true  Wink.
Offline  
Read January 21, 2006, 12:31:45 AM #32
2dguy

Re: Time Based or Frame Based?

"Just my 2c, I'm all out for a time based logic, running at 20 fps or so, and a renderer interpolating stuff on the hardware dependent vertical retrace.."

Any 2D game or demo download so I can see the above in action??? I've read about this and I'm not getting the advantage over regular time based coding. ? ? ?
Offline  
Read January 21, 2006, 07:22:12 AM #33
MarkR

Re: Time Based or Frame Based?

I created several games which used time-based movement with a variable timestep based on the framerate; these simply rendered as fast as possible.

I found that this wasn't ideal, as it caused significant gameplay differences no matter how hard I tried. Also my calibration method (which sampled the framerate every 1 second) causes some noticeable speeding up and slowing down.

These were some software-rendered Allegro games.

Now I'm very much in favour of a fixed timestep. This makes game logic a bit easier - timers etc can now simply be decremented in the logic routine. But more importantly, it makes it much more consistent.

I think that the ultimate way to work would be using interpolation (or maybe extrapolation) for movement. This would result in an extremely smooth appearance.

You'd still use a fixed timestep, but the renderer would not render objects in their current position, but either interpolated between their current and previous position, or extrapolated from their current position.

Mark
Offline  
Read January 21, 2006, 10:23:02 AM #34
pvwr

Re: Time Based or Frame Based?

"Just my 2c, I'm all out for a time based logic, running at 20 fps or so, and a renderer interpolating stuff on the hardware dependent vertical retrace.."

Any 2D game or demo download so I can see the above in action??? I've read about this and I'm not getting the advantage over regular time based coding. ? ? ?

If a simple tech demo can do the trick  (when I say simple it is REALLY simple), then you can check it out at http://www.chienloco.com/alpha/alpha3.zip. Both the scenery and player ship have their animation interpolated with subpixel precision, while the logic runs at  20fps (fixed). Don't expect much, as this is where I started testing this strategy, my current development is not as advanced as to have a complete demo. Also don't bother the graphics, I'm a programmer,not an artist  Cool.

As far as the game logic goes, I don't see an advantage on doing that as well. However, for the renderer it is the best approach, as in most OSs you can't change the vertical retrace to fit the game logic. If the vertical retrace is faster than the game logic, then interpolation will make animation look much better. Now put in there subpixel animation and you have something looking great.

I don't know about others, but on my experiments, having the logic running at 20 fps is very accurate for a shmup (heck, Samidare runs at 15fps and plays great). Is it easy to do? Not exactly, but in my opinion the visual aspect is superior than using the game logic and renderer running at the same speed.
« Last Edit: January 21, 2006, 10:24:50 AM by pvwr »
Offline  
Read January 21, 2006, 10:44:37 AM #35
pvwr

Re: Time Based or Frame Based?

I think that the ultimate way to work would be using interpolation (or maybe extrapolation) for movement. This would result in an extremely smooth appearance.

You'd still use a fixed timestep, but the renderer would not render objects in their current position, but either interpolated between their current and previous position, or extrapolated from their current position.

Mark

Thanks Mark, you explained in some simple lines what I'm doing  Cheesy.
Offline  
Read January 21, 2006, 01:04:21 PM #36
d000hg

Re: Time Based or Frame Based?

I created several games which used time-based movement with a variable timestep based on the framerate; these simply rendered as fast as possible.

I found that this wasn't ideal, as it caused significant gameplay differences no matter how hard I tried. Also my calibration method (which sampled the framerate every 1 second) causes some noticeable speeding up and slowing down.
Well if you'renot going to do delta time-based stuff correctly - I take it the rest of you arguing for fixed timestep frames do know the right way?
Offline  
Read January 21, 2006, 03:42:22 PM #37
MarkR

Re: Time Based or Frame Based?

Well if you'renot going to do delta time-based stuff correctly - I take it the rest of you arguing for fixed timestep frames do know the right way?

I had reasons for doing it that way.

I was averaging the frame time over 1 second and using that to calibrate the time step (of the next second).

That works well for some types of game, worse for others if the frame time varies dramatically. Of course it would be possible to do the calibration more often, or even measure the time every frame, but that creates some probems if a single frame is unexpectedly slow, for example due to a small piece of OS activity such as swapping.

I also wanted to ensure that the frame rate didn't vary excessively.

However if I was going to do that again, I'd try to make sure that it vsync'd if possible, which would help a lot.

Although you can't necessarily force a given refresh speed on PCs, you can reliably find out what it is after it's been set.

Mark
Offline  
Read January 23, 2006, 11:17:49 AM #38
d000hg

Re: Time Based or Frame Based?

<waits for 2dguy to comment on "forcing a refresh rate change">
Offline  
Read January 23, 2006, 03:22:40 PM #39
DXGame

Re: Time Based or Frame Based?

Interesting thread.

"Both the scenery and player ship have their animation interpolated with subpixel precision, while the logic runs at  20fps (fixed)."

Our development engine is time based where the "logic and the render" are processed once per loop. The fixed logic approach and " interpolated with subpixel precision" is kinda neat sounding but in the end it's the render speed that ultimately dictates everything.

With time based code, the faster the render, the smoother the logic calculates. The slower the render, the more coarse the logic is. Granted fixed logic is indeed easier to code, but the render process adds overhead. So in my opinion it's 6 one way, half a dozen the other. Wink
« Last Edit: January 23, 2006, 03:25:24 PM by DXGame »
Offline  
Pages: [1] 2  All   Go Up
Jump to:  

Page created in 0.196 seconds with 18 queries.