Frame pacing

Discuss ADFFS development versions and upcoming additions
JonAbbott
Posts: 1736
Joined: Thu Apr 11, 2013 12:13 pm
Location: Essex

Re: Frame pacing

Post by JonAbbott » Thu Jan 30, 2014 8:27 pm

JonAbbott wrote:
steve3000 wrote:3) What I didn't do, but had planned... Was to trap the keyboard scan OS_Byte(s).
That's a very good idea, I can add that to ADFFS quite easily. As with OS_Byte 113 - OS_Byte 121 (Keyboard scan), 122 (Keyboard scan from 16 decimal) and 129 (Scan a for a particular key) can all be made to check if OS_Byte 19 has been seen, if not force one.
The Manchester United title page will be a good test of it working.
I started to code this, then realised its not quite so straight forward. In brief, it needs to check if OS_Byte 19 and/or OS_Byte 113 are being called and only pause if not. I need to add code to reset the "OS_Byte 19 has been called" flag every n centiseconds otherwise it only pauses once.

That aside, I quickly checked the games that may benefit from this:

Alien Invasion (already fixed by ADFFS 2.34)
Champions: World Class Leader Board (doesn't use the keyboard, may need OS_Byte 128 as it checks the mouse buttons)
Ego: Repton 4 (already fixed by ADFFS 2.34)
F.R.E.D. (may benefit)
HoverBod (may benefit)
Ibix the Viking (may benefit, however the code has a bug where pressing a key speeds it up!)
Play It Again Sam 3: Letrouve (already fixed by ADFFS 2.34)
Manchester United (just the menu) (may benefit)
Populous (already fixed by ADFFS 2.34)

steve3000
Posts: 198
Joined: Thu May 02, 2013 9:25 pm

Re: Frame pacing

Post by steve3000 » Sun Feb 02, 2014 11:43 pm

JonAbbott wrote:
steve3000 wrote:I dabbled in this with LCDgamemodes (do you have the test version which reduces VSync?).
I've not seen that version - not that I recall anyhow. That last version you put on the dev site is 0.21b, from which I based 0.22d to botch VIDC20 support.
Ok, I've located this today.

It was v0.22, hidden away on my A540. *LCDgmFixVSync [On|Off] is the command. I suspect I didn't upload at the time because ADFFS already had it's own method of doing this - but if we're doing the same thing in different ways, then makes sense to learn what we can from the different methods...

I'll upload, with source, to the dev site tomorrow.

As a quick test, I loaded up PacMania (HDD version, not through ADFFS) on the A3020 connected to my LCD monitor. Speed is definitely controlled when *LCDgmFixVSync is on.

I'll have a go with PacMania through ADFFS next and report back.

JonAbbott
Posts: 1736
Joined: Thu Apr 11, 2013 12:13 pm
Location: Essex

Re: Frame pacing

Post by JonAbbott » Mon Feb 03, 2014 6:24 am

steve3000 wrote:I'll have a go with PacMania through ADFFS next and report back.
What you should hopefully find, is that with ADFForceVSync (use CTRL-SHIFT-Pg Up/Pg Down in game to adjust in realtime) set to:

O: It will pace itself at 50Hz, this is down to the "frame pacing" code
1: Will run at the monitor refresh rate or 100Hz, whichever is lower
2: Will run at 50Hz due to 2 forced 100Hz waits when it switches screen banks
4: Will run at 25Hz due to 4 forced 100Hz waits when it switches screen banks
...
20: Sloooowwwww!!!

There are still a lot of games to test, however the only ones that will current run too fast are those which don't use OS_Byte 19, OS_Byte 113 or Event 4 to pace themselves. In effect, the ones that purely rely on the CPU MIPS for the correct speed - these are the ones your keyboard idea will fix rather neatly.

JonAbbott
Posts: 1736
Joined: Thu Apr 11, 2013 12:13 pm
Location: Essex

Re: Frame pacing

Post by JonAbbott » Mon Feb 03, 2014 10:44 pm

Steve - In the next (Pi) beta, it will turn off the frame pacing code if the system is generating VSync at 50Hz.

It might be worth testing 56Hz on legacy machines to see if it is usable. I've yet to code the 50Hz check on IOC/IOMD but can widen the range if we decide to go 56Hz in LCDGameModes.

I also noticed while testing, that the frame pacing fixes the palette swap location on Lemmings, which is a bonus. It may fix others as well. We should probably keep a list of palette swapping games so we can check them as we look at changing the behaviour on legacy machines.

steve3000
Posts: 198
Joined: Thu May 02, 2013 9:25 pm

Re: Frame pacing

Post by steve3000 » Tue Feb 04, 2014 12:11 am

Jon - I've uploaded lcdgm with VSync fix to the dev area (LCDgmVS022.zip). Take a look at the source to see how I did it - was quit simple really.

Quick question - when you say "the next (Pi) beta" are the betas computer specific? I've downloaded v2.34b and transferred to the A4000 so I can have a play tomorrow - will this work?

Cheers,
Steve

JonAbbott
Posts: 1736
Joined: Thu Apr 11, 2013 12:13 pm
Location: Essex

Re: Frame pacing

Post by JonAbbott » Tue Feb 04, 2014 8:34 am

steve3000 wrote:I've uploaded lcdgm with VSync fix to the dev area (LCDgmVS022.zip). Take a look at the source to see how I did it - was quit simple really.
Will do, thanks.
steve3000 wrote:are the betas computer specific?
All of the changes going on at the moment are specific to StrongARM and 32bit compatibility, very few are applicable to IOC. It's all one code base however, with #if statements around version specific code.

Frame pacing was implemented across all three versions of ADFFS. Originally it was added to ensure the game and GPU updated the frame at a regular pace when abstracting the GPU on the Pi. I then realised it was also regulating game speed as a side effect, so back-ported it to IOC/IOMD.

The betas contain all three versions of the module, ADFFS for IOC, ADFFS400 for IOMD and ADFFS500 for anything else. Hopefully that answers your question.

steve3000
Posts: 198
Joined: Thu May 02, 2013 9:25 pm

Re: Frame pacing

Post by steve3000 » Tue Feb 04, 2014 10:25 pm

Perfect, just what I needed to know. Will get it running tonight on the A4000.

JonAbbott
Posts: 1736
Joined: Thu Apr 11, 2013 12:13 pm
Location: Essex

Re: Frame pacing

Post by JonAbbott » Wed Apr 02, 2014 7:46 pm

steve3000 wrote:3) What I didn't do, but had planned... Was to trap the keyboard scan OS_Byte(s).
I've had another go at getting this working today, however I've noticed its probably not actually going to fix many games.

The trigger for this was receiving the "Sporting Triangles" floppy image today, which runs at a crazy speed when it performs it's animations between the player giving input. The sequence of events are:
  1. Player is asked to press SPACE
  2. Animation plays
  3. Player is asked to select an option
At step 2, there are no requests for mouse or keyboard input and no VSync's, so it runs as fast as the CPU will go.

A few other possible solutions to the problem:
  1. Stall on SWI exit (although this does depend on the game calling SWI's whilst animation is going on)
  2. Slow down writes to screen memory (not a very accurate method)
  3. Slow the whole machine down whilst the CPU is executing appspace code
  4. Modify the game code to wait for VSync (not something I'd like to take on!)

JonAbbott
Posts: 1736
Joined: Thu Apr 11, 2013 12:13 pm
Location: Essex

Re: Frame pacing

Post by JonAbbott » Sun Feb 01, 2015 8:12 pm

Whilst fixing Manchester United Europe's CPU detection code, I looked into why the mouse cursor moves so quickly in the menu screen. On a hunch, I tested every OS_Byte and OS_Word it calls and found that OS_Word 21,0 delays until VSync before returning on RO3.11 and returns immediately on RO3.5+

I've now added the VSync delay back in, which has resolved the problem in this game. I'm not sure what other games this will affect, probably not many. I'll have to go through and test the ones I've flagged as too fast.

JonAbbott
Posts: 1736
Joined: Thu Apr 11, 2013 12:13 pm
Location: Essex

Re: Frame pacing

Post by JonAbbott » Wed Feb 25, 2015 11:50 am

JonAbbott wrote:
steve3000 wrote:3) What I didn't do, but had planned... Was to trap the keyboard scan OS_Byte(s).
I've had another go at getting this working today, however I've noticed its probably not actually going to fix many games.

The trigger for this was receiving the "Sporting Triangles" floppy image today, which runs at a crazy speed when it performs it's animations between the player giving input. The sequence of events are:
  1. Player is asked to press SPACE
  2. Animation plays
  3. Player is asked to select an option
At step 2, there are no requests for mouse or keyboard input and no VSync's, so it runs as fast as the CPU will go.

A few other possible solutions to the problem:
  1. Stall on SWI exit (although this does depend on the game calling SWI's whilst animation is going on)
  2. Slow down writes to screen memory (not a very accurate method)
  3. Slow the whole machine down whilst the CPU is executing appspace code
  4. Modify the game code to wait for VSync (not something I'd like to take on!)
Another option here is to implement pre-emptive multitasking and throttle the app by handing to another task for a period of time. This would also require a means of sharing T1 on RO3-4 and HAL_Timers on RO5. At some point, I'll create a thread for PMT and HAL_Timers as this will be relevant to adding WIMP support.

Post Reply