ADFFS 2.54
Re: ADFFS 2.54
I have updated the obey and scroll is still wrong in the Pi (JP2+).
Re: ADFFS 2.54
I've fixed the screen width issue and have yet to look into the scrolling problem.
Re: ADFFS 2.54
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.
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.
Re: ADFFS 2.54
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.
Re: ADFFS 2.54
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.Vanfanel wrote:I have updated the obey and scroll is still wrong in the Pi (JP2+).
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:
- Add a wait for VSync into the game, after it does it's frame swap
- Figure out the time quirk its relying on to work on physical/under emulation
- Blit the frame when the DAG changes
(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
Re: ADFFS 2.54
@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.
It's very interesing to real the other options, but I don't know enough about RISC OS inners to fully understand them.
Re: ADFFS 2.54
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)
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)
Re: ADFFS 2.54
A few bug fixes in today's build that could affect games that touch Page Zero.
Re: ADFFS 2.54
@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.
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.
Re: ADFFS 2.54
I'm not about until Wed to test, there's a couple things you could try:Does the game work like that on real hardware?
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.