Games that are Full Frame Rate or Slower - Limitations or Choice?

Originally Posted by Solo Kazuki

And my monitor was multisync. And what now? :P

Edit: Sorry guy, but it looks like your knowledge is based only on plain A500 with old PAL/NTSC. No better processor, no better monitor, nothing better...

Multisync or not you are still wrong.
You don't know the difference between frame computation rate ( step chosen by the programmer to update the 3d coordonates of the objects and build the 2d projection to display each fiftyth of a second ) and differentiated frame displayed per second.

With a fast Amiga a game coded to display a differentiated frame every 4 screen refresh period will display one every 2 at best thus giving you the impression it runs at more than 50 fps when in fact it is 25.

[Peckmore]

Originally Posted by Caligula

I know what 50 fps is and no doubt your answer was and stil is a joke.
Face the truth.
SOTB is not a 50 fps game, its refresh rate drops to 25 when the main character changes direction.

Isn't the definition of frame rate (or at least target frame rate) the rate at which the game/engine updates/draws frames? So in the case of SOTB, the game/engine is designed to operate at 50 FPS, meaning it has a 20ms window in which to draw to the screen (and, assuming the game logic updates at the same rate, also carry out any game logic).

So if a frame exceeds this time then you end up with a frame that exceeds it's allotted draw window which can result in either slowdown (if the next game logic update waits for the frame to complete), or just a drop in framerate (as the game logic continues to update at it's predefined rate, but sequential draw calls are skipped until the overrunning frame is drawn).

Which would mean that SOTB is definitely a 50 FPS game, but it exhibits either slowdown or a drop in framerate whenever the character switches direction (and it seems only for a single frame)?

[Solo Kazuki]

Originally Posted by Caligula

Multisync or not you are still wrong.
You don't know the difference between frame computation rate ( step chosen by the programmer to update the 3d coordonates of the objects and build the 2d projection to display each fiftyth of a second ) and differentiated frame displayed per second.

With a fast Amiga a game coded to display a differentiated frame every 4 screen refresh period will display one every 2 at best thus giving you the impression it runs at more than 50 fps when in fact it is 25.

Really? Also in Euro36/72 modes (72Hz refresh rate)? And NTSC (60Hz)?

[Foebane]

Originally Posted by Retro-Nerd

Of course SotB is a 50fps game. Who cares, if it runs 0,01% of the time in 25fps. Silly hairsplitting.

I agree.

Originally Posted by Caligula

I know what 50 fps is and no doubt your answer was and stil is a joke.
Face the truth.
SOTB is not a 50 fps game, its refresh rate drops to 25 when the main character changes direction.

Now you're being silly. I already explained that the MAXIMUM speed has to be 50/60fps, there are bound to be drops, especially for the player sprite flipping.

[Rotareneg]

To add to the SotB complexity: Some objects don't slow down when the player flips direction. In the following video the vertical spike continues to move at 50 Hz while the green balls and even the player sprites invincibility frame blinking slow to 25 Hz when turning:

[ Show youtube player ]

If you want to count frames during the first section that's not been slowed down, pause the video and use the , and . keys to single step frames.

[LeCaravage]

@Rotareneg : Well spotted. May be the spike is a hardware sprite ?

[mcgeezer]

shadow of the beast runs at 50 fps.

No doubt about it.

[Galahad/FLT]

Originally Posted by Caligula

I know what 50 fps is and no doubt your answer was and stil is a joke.
Face the truth.
SOTB is not a 50 fps game, its refresh rate drops to 25 when the main character changes direction.

Clearly you dont know what 50fps is, your beligerent conduct is a testament to that.

Im also highly amused you think Beast drops to 25 frames when the main character changes direction, seeing as the game stops scrolling completely until you move again in the opposite direction.

At this point someone should be checking your IP address to see if it matches any recently banned members

[mcgeezer]

Originally Posted by Galahad/FLT

At this point someone should be checking your IP address to see if it matches any recently banned members

Probably a bit of truth in this to be fair - only 8 posts all in this thread and coming across quite abrupt and antagonistic.

[frank_b]

Originally Posted by Rotareneg

To add to the SotB complexity: Some objects don't slow down when the player flips direction. In the following video the vertical spike continues to move at 50 Hz while the green balls and even the player sprites invincibility frame blinking slow to 25 Hz when turning:

[ Show youtube player ]

If you want to count frames during the first section that's not been slowed down, pause the video and use the , and . keys to single step frames.

Fixed point coordinates perhaps? It's possible to have a 50 hz game update on screen objects with fractional fixed point values. That way every object doesn't have to move at a linear 50 fps.

[alpine9000]

Originally Posted by frank_b

Fixed point coordinates perhaps? It's possible to have a 50 hz game update on screen objects with fractional fixed point values. That way every object doesn't have to move at a linear 50 fps.

I implemented this technique in Else We Get Mad originally, in that on slow machines when things got busy and it skipped frames everything would still move at the same speed. I ended up taking it out however and just locking the framerate on slow machines to 25fps as when it made the switch from butter smooth 50fps to 25fps it was quite disconcerting.

[vulture]

Qft!

Originally Posted by rotareneg

you're right, it's 60 fps. I don't know what's wrong with all you people's amiga's which run 10 fps slower than they're supposed to.

@Galahad

Yeah , he sounds a lot like a certain, rather delusional, archimedes-worshipper, doesn't he...?

[Seiya]

3D games are slow because Amiga architecture is "planar" and 3D poligonal games are in chunky, so Amiga has to do chunky-to-planar conversion in real time that require very fast processor.
Mostly 3D games like Simulator are conversions from PC that have chunky in hardware and so any conversion is slow on Amiga.
80 years DogFight on PC you have 256 colors, brushes on airplanes, much details and run smooth also on slow 286.
On Amiga it's not fluid also on 68030 because this c2p conversion require much cpu cycles to do.

Porting from Atari ST i think it's slow because Atari didn't have "blitter" so, Amiga conversion didn't use it and the speed it was not very great.

[roondar]

Originally Posted by Seiya

3D games are slow because Amiga architecture is "planar" and 3D poligonal games are in chunky, so Amiga has to do chunky-to-planar conversion in real time that require very fat processor.
Mostly 3D games like Simulator are conversions from PC that have chunky in hardware and so any conversion is slow on Amiga.
80 years DogFight on PC you have 256 colors, brushes on airplanes, much details and run smooth also on slow 286.
On Amiga it's not fluid also on 68030 because this c2p conversion require much cpu cycles to do.

Porting from Atari ST i think it's slow because Atari didn't have "blitter" so, Amiga conversion didn't use it and the speed it was not very great.

CPU and RAM speed does matter more than you think here - the slow 286 you refer to has better performance per clock than the Amiga's 68000 and was usually used at much higher frequencies for both CPU and RAM.

Even the 68030 for an Amiga can't fix the Amiga's slow chipmemory (OCS chipmemory limits the CPU to no more than 3.5MB/sec and even AGA only does ~7MB/sec), whereas a VGA card tends to use the ISA bus which allows up to 16MB/sec throughput.

So, the 68030 is much faster than the 286 but has to push pixels through a much slower interface (and yes, also needs to do C2P which does slow it down even further).

[Foebane]

Wow, moving from Amiga to PC (VGA) must've been like a dream: from having to POKE eight separate addresses in memory just for a single pixel in 256-colour mode (so to speak) to just ONE must've been liberating for graphics programmers!

I have an article from an obscure Amiga magazine that discussed in-depth how practical Doom would be to port to the Amiga, and the news at the end was bad, especially for a 68020-based machine. I could post it online if anyone wants to see it.

[Tigerskunk]

Originally Posted by vulture

Qft!
@Galahad
Yeah , he sounds a lot like a certain, rather delusional, archimedes-worshipper, doesn't he...?

Was my thought as well, that it's that dude...