ADFFS 2.54

Discuss development specific to the Pi version of ADFFS
Vanfanel
Posts: 576
Joined: Mon Sep 16, 2013 12:01 am

Re: ADFFS 2.54

Post by Vanfanel »

I have updated the obey and scroll is still wrong in the Pi (JP2+).
JonAbbott
Posts: 2938
Joined: Thu Apr 11, 2013 12:13 pm
Location: Essex
Contact:

Re: ADFFS 2.54

Post by JonAbbott »

I've fixed the screen width issue and have yet to look into the scrolling problem.
JonAbbott
Posts: 2938
Joined: Thu Apr 11, 2013 12:13 pm
Location: Essex
Contact:

Re: ADFFS 2.54

Post by JonAbbott »

This is going to take a bit longer than I thought to get ready for release, as the StrongARM issues are proving problematic to track down. I've also not started on the games I'd like to release, the list of which is probably going to be:

F10039 Battle Tank (1990) (Minerva)
F10059 Bug Hunter & Moondash (1990) (Minerva)
F10060 Bug Hunter in Space (1990) (Minerva)
F10068 Casino (1989) (Minerva)
F10072 Caverns (1991) (Minerva)
F10132 Empire Soccer 94 (1995) (Empire Software)
F10167 Freddy's Folly (1988) (Minerva)
F10202 HoverBod (1988) (Minerva)
F10204 Ibix the Viking (1989) (Minerva)
F10251 Minotaur (1987) (Minerva)
F10253 Missile Control (1988) (Minerva)
F10267 Oh, No! More Lemmings (1992) (Krisalis Software)
F10596 Oh, No! More Lemmings [RPC version] (2001) (R-Comp Interactive)
F10597 Populous [RPC version] (2001) (R-Comp Interactive)
F10303 RedShift (1990) (Minerva)
F10362 Talisman (1989) (Minerva)
F10367 Thundermonk (1989) (Minerva)

And if I get time to sort out the artwork/manuals:

F10228 Lemmings 2: The Tribes (1994) (Krisalis Software)
F10242 Manchester United (1990) (Krisalis Software)
F10281 Pipe Mania (1989) (Krisalis Software)

Note that they all need retesting for compatibility on all platforms and OS's, which takes a few hours per game, so they'll probably have to be a gradual release as there's about 7 man days of work there alone. If I spot any issues, which require code changes or Boot script work, this pretty much doubles the time it takes as I have to go through a full test cycle again.

I spent a few hours on the JP2/JP2+/GBA scrolling issues, in the case of the former I've ruled out VIDC1/VIDC20 translation issues, so the issue is probably in the blitter. The issue is almost certainly related to the left border, as the game jumps when this border wraps.

GBA has a fundamental flaw in the way it was coded, essentially the game expands MODE 9 to 416 pixels but fails to set the screen borders, instead relying on the OS having defined them. The problem here is that the borders change depending on monitor type, ADFFS by default uses the type 0 monitor defaults from RO3.11, but this doesn't appear to be what the game is expecting. Because no borders are defined most emulators also go nuts when the border ends up being a huge figure. I may be able to fix GBA by figuring out the correct border value the game expects and modifying the Mode Extension module to define them.
JonAbbott
Posts: 2938
Joined: Thu Apr 11, 2013 12:13 pm
Location: Essex
Contact:

Re: ADFFS 2.54

Post by JonAbbott »

This video of GBA running on an A3010 shows the issue with the game, watch the right border, the screen is changing width as it scrolls.

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

Re: ADFFS 2.54

Post by JonAbbott »

Vanfanel wrote:I have updated the obey and scroll is still wrong in the Pi (JP2+).
I've tracked the jittery scrolling down to a bug in the game. It's not swapping the frame buffer at VSync, which is causing the VIDC parameters to become out of sync with the displayed frame by one frame. Normally a game would issue OS_Byte 19, followed by OS_Byte 113 to swap frames, JP2 however simply issues OS_Word 22 (set DAG) as soon as the frame is updated.

You should also see jittering on physical or under emulation, as this isn't the case however, RISCOS prior to GraphicsV may be delaying the DAG change until after the next VSync has occurred, or VIDC1/VIDC20 may ignore DAG changes until after VSync.

There's several ways to fix this:
  1. Add a wait for VSync into the game, after it does it's frame swap
  2. Figure out the time quirk its relying on to work on physical/under emulation
  3. Blit the frame when the DAG changes
(1) is the simplest, but will halve the frame rate of the game, so the frame rate will need fixing to 50fps
(2) I'll need to examine the RO3.71 source code and see if OS_Word 22 does anything special. If not, I'll need to experiment on VIDC1/VIDC20 to confirm the timings of parameter and DAG changes
(3) is the technique currently used when OS_Byte 113 is issued, so the code would need moving from OS_Byte 113 to GraphicsV 6 (set DAG). There could however be a knock on effect with other games that use OS_Word 22 to frame swap, if they swap the DAG before updating the frame buffer
Vanfanel
Posts: 576
Joined: Mon Sep 16, 2013 12:01 am

Re: ADFFS 2.54

Post by Vanfanel »

@Jon: I'd go with the simplest solution of patching the game to add the vsync wait, and fix it to 50fps. If it looks as smooth as on real hw, well, it's good enough and would save you time and possible frustration with other games getting broken on the way.
It's very interesing to real the other options, but I don't know enough about RISC OS inners to fully understand them.
JonAbbott
Posts: 2938
Joined: Thu Apr 11, 2013 12:13 pm
Location: Essex
Contact:

Re: ADFFS 2.54

Post by JonAbbott »

I've tried about half a dozen ways of implementing (1), but they all go out of sync occasionally.

Try today's build. The VIDC parameters may be fixed prior to VSync occurring, so any geometry changes don't take effect until the next VSync, if they're changed during the VSync interrupt - that's just a guess. To test this, I've moved the VSync to occur after the screen geometry has been calculated. This appears to fix JP2/JP2+ but we'll need to see if there's a knock on effect with all games that change the screen geometry during VSync. Caverns and James Pond appear to be okay, if you want to test some others.

EDIT: I've also now tested the following games @ 75 Hz, all appear okay except where noted:

BlowPipe
Boogie Buggy
Cataclysm
Caverns
Chuck Rock
Gribbly's Day Out (bad juddering @ 75Hz, does the same thing on previous builds)
James Pond
James Pond II
James Pond II+
Jet Fighter
Manchester United
Manchester United Europe
Nevryon (hanging past 2.54p due to a Page Zero read in RTSupport, update to RISCOS beta 06-04-16 or later to resolve)
JonAbbott
Posts: 2938
Joined: Thu Apr 11, 2013 12:13 pm
Location: Essex
Contact:

Re: ADFFS 2.54

Post by JonAbbott »

A few bug fixes in today's build that could affect games that touch Page Zero.
Vanfanel
Posts: 576
Joined: Mon Sep 16, 2013 12:01 am

Re: ADFFS 2.54

Post by Vanfanel »

@Jon: I was testing JP2 and JP2+ today on the Pi, in 50Hz mode, and they are indeed strange-scrolling versions of the original JP2 game: vertical scroll is smooth, it looks just like the Genesis version for example. Also, in moving platforms, when the platform is moving inside the screen, it moves smoothly, but as soon as JP reaches the screen point where scrolling starts, the scroll becomes less smooth.
When normally walking, JP moves smoothly inside static screen, but when horizontal scrolling starts it's not smooth. However, in some sloppy surfaces, it seems to be smooth sometimes...
Does the game work like that on real hardware? Amiga and Genesis versions are not like that at all. I suspect something is still not well with horizontal scroll in this game.
JonAbbott
Posts: 2938
Joined: Thu Apr 11, 2013 12:13 pm
Location: Essex
Contact:

Re: ADFFS 2.54

Post by JonAbbott »

Does the game work like that on real hardware?
I'm not about until Wed to test, there's a couple things you could try:

1. See what it does under ArcEm on the Pi
2. See if it behaves the same @ 60 or 75Hz

I was testing under 75Hz and it looked okay to me. I'm not 100% convinced the change I made to get it working, is how VIDC1/20 work, we may yet have to look at emulator source or perform testing on physical.
Post Reply