Amiga Games at 50 fps

[Photon]

Yep, animation framerate shouldn't be a factor in this - in some niche cases like rotating objects it might look slick for sure, but most animations simply convince the eye better @ 17 or even 12 FPS, than 25 or 50. The character or whatever just has no move to make in between the movements, e.g. a 50 FPS animated axe chop or turn would look slow and feel sticky or artifical.

And most 50 FPS games fully re-draw all sprites/bobs every frame because they have to anyway, so it's not a case of not being able to push performance, they just draw the same animation frame again.

[vulture]

per phx's suggestion, I've added Sqrxz1, Sqrxz3, Sqrxz4, Solid Gold, Trap Runner and Celtic Heart to the list

[ReadOnlyCat]

Originally Posted by Chrille

The animation of BOBs or sprites are usually not at 50 FPS. That would eat too much chip memory or disk space This is similar to most C64 games

Originally Posted by Photon

Yep, animation framerate shouldn't be a factor in this - in some niche cases like rotating objects it might look slick for sure, but most animations simply convince the eye better @ 17 or even 12 FPS, than 25 or 50.

I agree, animation should not count, only object movement.

And scrolling speed should not count either since you could have a 50Hz scrolling while all BOBs painfully move around at 4 Hz/FPS, would anyone dare to call that a 50Hz game? Certainly not.

Originally Posted by Chrille

Yes, Superfrog has only 25 FPS. Scrolling and sprites (Superfrog) are at 50 FPS, but all BOBs move at 25 FPS. E.g. the bees in the first world or the green ball (you can shoot with).
This is also similar in Zool and Zool2.

In passing, this is something I would avoid as a game designer, having different rates of update is not always detectable consciously but usually gives a weird impression that something is wrong with movement.

Originally Posted by Chrille

@Toni Wilen: One suggestion to improve framerate detection, you could look at $DFF0E0 - $DFf0FC (the bitplane pointers) and check how often they change.

The bitplane pointers constantly auto increment during display so I guess you meant "when they are changed via manual CPU/copper action".

But as I said, I think scrolling speed should not be relevant since even the slowest of games can update the display pointers at 50Hz even though their game actually updates its game loop at much slower rates.

What really matters in my humble kitten opinion is the rate at which the objects move, not the one at which the screen pointers update.

Originally Posted by Chrille

And on the other side AFAIR Z-Out has 50 FPS. The scrolling might be as slow as it is only updated every second frame, but the BOBs move at 50 FPS and the buffers change every frame.

Yup, which is why scrolling speed should be ignored unless the screen is the only thing that moves.

[roondar]

Originally Posted by ReadOnlyCat

What really matters in my humble kitten opinion is the rate at which the objects move, not the one at which the screen pointers update.

I'd go so far as saying what really matters is not the rate of object movement (which can be an artistic or gameplay choice) but rather the speed at which the game logic updates and graphics are drawn.

Meaning that I'd consider a game that has a slow, pondering monster approach the player at 1 pixel every 4 frames as being 50Hz if the player, monster & game logic internally update every 1/50th of a second.

But I guess this is more or less what you're getting at here

[Foebane]

Shadow of the Beast is NOT a 100% 50Hz game: when you turn on the spot, there is a noticeable drop in FPS. I've seen this discussed in detail somewhere else, but I can't be bothered to dig it up at the mo.

[vulture]

@Foebane

SotB is certainly a 50 fps game, when your character turns to the other side, the frame rate drops for a split second, that doesn't affect the bulk of the game which runs at full pace at all times. Besides, that was a programming deficiency that was corrected at SotB 3 afaik.

[Retro-Nerd]

Of cause SotB ist 50fps. Only nitpicking to mention this split-second drop when you turn the direction.

[Foebane]

Originally Posted by vulture

@Foebane

SotB is certainly a 50 fps game, when your character turns to the other side, the frame rate drops for a split second, that doesn't affect the bulk of the game which runs at full pace at all times. Besides, that was a programming deficiency that was corrected at SotB 3 afaik.

Originally Posted by Retro-Nerd

Of cause SotB ist 50fps. Only nitpicking to mention this split-second drop when you turn the direction.

That's why I mentioned the percentage: it's 50fps, but something like 99% of the time.

[dlfrsilver]

Originally Posted by Retro-Nerd

Of cause SotB ist 50fps. Only nitpicking to mention this split-second drop when you turn the direction.

Normal, since the sprite flip is done in software.

[Foebane]

Originally Posted by dlfrsilver

Normal, since the sprite flip is done in software.

Really? Why couldn't there be two sets of sprites and animations in both directions? Or was it absolutely paramount that the game run in half a megabyte?

Come to think of it, Beast 2 didn't need a memory expansion, neither.

Also, come to think of it, a simple flip of the current sprite graphic wouldn't have slowed the game down as I described... unless it was flipping ALL the player sprites in one go?

[Chrille]

Originally Posted by ReadOnlyCat

The bitplane pointers constantly auto increment during display so I guess you meant "when they are changed via manual CPU/copper action".

ahem, yes, that was what I meant I guess, it is too long that i've coded for Amiga ...

Originally Posted by ReadOnlyCat

But as I said, I think scrolling speed should not be relevant since even the slowest of games can update the display pointers at 50Hz even though their game actually updates its game loop at much slower rates.

True, but on the other side you have games like Gods, which are too bad to update the screen pointers every frame.

[ReadOnlyCat]

Originally Posted by roondar

I'd go so far as saying what really matters is not the rate of object movement (which can be an artistic or gameplay choice) but rather the speed at which the game logic updates and graphics are drawn.

Meaning that I'd consider a game that has a slow, pondering monster approach the player at 1 pixel every 4 frames as being 50Hz if the player, monster & game logic internally update every 1/50th of a second.

But I guess this is more or less what you're getting at here

Hum... you got me thinking.

I have worked on games where some parts of the game logic were updated at higher rates than the actual frame rate in order to produce a more realistic feel (the physics engine of driving games to be precise) but I would not say that they should be given higher frame rates because of that.

Although I do understand where you are coming from, I think that what matters is the update rate of action as far as the player is concerned. Even if a driving game updates its physics data at 100Hz, if the frame rate is 25Hz, the player is essentially seeing a 25Hz game.

The fact that the logic is updated at 100Hz has an influence on how the game reacts to player action but no influence at all on how frequently the game reacts to player input or updates its visual state to the player.

To use an analogy with spatial resolution, if a game uses one more bit of precision for its pixel movements for example, then movements will look more fluid and precise but that does not double the effective display resolution. It affects the trajectory of objects and makes it appear more precise but they still have the same resolution/size.

Originally Posted by dlfrsilver

Normal, since the sprite flip is done in software.

Well, it can be done in software and be fast.
The hiccup simply means that their sprite flipping routine is super slow.

With a 256 bytes table, one can flip all bits inside a byte with only three assembly instructions (not counting the loop logic) plus a Blitter pass.

move.b (a0),d1    <- get the byte to flip
move.b (a1,d1),d1 <- get the flipped byte from the table pointed to by a1
move.b d1,(a0)+   <- write the flipped byte

the only thing needed after that is to flip the position of the two bytes within each 16 bit word using one Blitter pass.

This is (definitely) not the most bandwidth efficient method but it is fast enough to flip the main sprite in much less than a frame.

[ReadOnlyCat]

Originally Posted by Chrille

True, but on the other side you have games like Gods, which are too bad to update the screen pointers every frame.

Are there mods of Gods which fix that? I would be curious to see the result.

[roondar]

Originally Posted by ReadOnlyCat

Hum... you got me thinking.

I have worked on games where some parts of the game logic were updated at higher rates than the actual frame rate in order to produce a more realistic feel (the physics engine of driving games to be precise) but I would not say that they should be given higher frame rates because of that.

Although I do understand where you are coming from, I think that what matters is the update rate of action as far as the player is concerned. Even if a driving game updates its physics data at 100Hz, if the frame rate is 25Hz, the player is essentially seeing a 25Hz game.

The fact that the logic is updated at 100Hz has an influence on how the game reacts to player action but no influence at all on how frequently the game reacts to player input or updates its visual state to the player.

To use an analogy with spatial resolution, if a game uses one more bit of precision for its pixel movements for example, then movements will look more fluid and precise but that does not double the effective display resolution. It affects the trajectory of objects and makes it appear more precise but they still have the same resolution/size.

Well, I did say I'd consider a game 50Hz if it updated the screen as well as logic at that rate, not just the logic
Then again, I'd call reacting to input a part of game logic and it seems you have a different (but equally valid) definition

What I'm trying to get at is that the discussion over 25Hz vs 50Hz has in some cases led to some IMHO rather strange positions being taken. For example, some people held the position that if a game doesn't scroll at 1 pixel/frame then it's not a 50Hz game, even when the game never scrolls at increments of more than one pixel. Others have said a game isn't 50Hz if there are any situations in which it might not run at 50Hz, even if only for a few frames (even if these have no impact on actual gameplay or are very rare).

So trying it a bit more clearly: I'd say a game is 50Hz if 'everything' (player, objects & screen movement) updates at 50Hz, even if some elements move at speeds of lower than one pixel per frame.

What I'm essentially am trying to do here is avoid the situation where an artistic/gameplay choice (let's have this object/the screen move slowly) is seen as a technical limitation (it moves slow, therefore the game engine can't move it any faster).

[gimbal]

Originally Posted by ReadOnlyCat

Are there mods of Gods which fix that? I would be curious to see the result.

Well, try the SNES version...

[mcgeezer]

Originally Posted by roondar

So trying it a bit more clearly: I'd say a game is 50Hz if 'everything' (player, objects & screen movement) updates at 50Hz, even if some elements move at speeds of lower than one pixel per frame.

What I'm essentially am trying to do here is avoid the situation where an artistic/gameplay choice (let's have this object/the screen move slowly) is seen as a technical limitation (it moves slow, therefore the game engine can't move it any faster).

If every object and the scrolling moved at least 1 pixel every frame then the game would be too fast. Rygar and Bomb Jack Beer Edition both run at 50 FPS but I interpolate the sprites at x16 resolution, so the sprites x and y positions internally need to move 16 pixels before they will move 1 pixel onscreen which would be the sprites slowest speed, it's still plotting the sprites every frame though.

Geezer

[roondar]

Originally Posted by mcgeezer

If every object and the scrolling moved at least 1 pixel every frame then the game would be too fast. Rygar and Bomb Jack Beer Edition both run at 50 FPS but I interpolate the sprites at x16 resolution, so the sprites x and y positions internally need to move 16 pixels before they will move 1 pixel onscreen which would be the sprites slowest speed, it's still plotting the sprites every frame though.

Geezer

Yeah, that is exactly my point.

My main reason for making this point is that, as I read it, some people in this thread were seemingly saying that objects/scrolling not moving at 1px/frame or more means a game is not 50Hz. Which doesn't make sense to me. Hence the post

[ReadOnlyCat]

Originally Posted by roondar

Yeah, that is exactly my point.

My main reason for making this point is that, as I read it, some people in this thread were seemingly saying that objects/scrolling not moving at 1px/frame or more means a game is not 50Hz. Which doesn't make sense to me. Hence the post

For the record, I completely agree.
Scrolling at half a pixel per second is a thing, it is just not perceptible on machines with an integer scroll step. Scrolling speed (number of pixels moved per second) and scrolling frame rate are two independent variables.
This is why I think scrolling should be ignored altogether anyway: it can be used to artificial inflate and deflate the perceived frame rate and is thus not a good reference point.

Game logic on the other hand, does not lie. If your character moves and reacts to input only every four frames you got your hands on a 12.5 FPS game even if the scrolling seems to be updated at 50Hz.

From a technical standpoint, the frequency of the main game loop is probably the best data point. Gentlemen and gentlewomen, warm up your disassemblers.

[alpine9000]

Originally Posted by ReadOnlyCat

For the record, I completely agree.
Scrolling at half a pixel per second is a thing, it is just not perceptible on machines with an integer scroll step. Scrolling speed (number of pixels moved per second) and scrolling frame rate are two independent variables.
This is why I think scrolling should be ignored altogether anyway: it can be used to artificial inflate and deflate the perceived frame rate and is thus not a good reference point.

Game logic on the other hand, does not lie. If your character moves and reacts to input only every four frames you got your hands on a 12.5 FPS game even if the scrolling seems to be updated at 50Hz.

From a technical standpoint, the frequency of the main game loop is probably the best data point. Gentlemen and gentlewomen, warm up your disassemblers.

I just run FS-UAE with uae_displaydata=1

It's pretty obvious what framerate a game is running at. Things change once per second -> 50fps

I guess it's possible to have a game with a 50 hz main loop yet every single screen object moves slower than 1 pixel per frame, but I think this would be extremely rare.

[Tsak]

@Vulture, Worthy runs at 50fps afaik.