The Icon Bar: General: Starfighter 3000 on Raspberry Pi: flickering HUD
| |
Starfighter 3000 on Raspberry Pi: flickering HUD |
| |
gaula92 (15:39 7/11/2012)
sirbod (18:53 7/11/2012)
gaula92 (19:44 7/11/2012)
sirbod (00:05 8/11/2012)
gaula92 (12:36 9/11/2012)
sirbod (06:34 15/11/2012)
Jaffa (08:34 15/11/2012)
gaula92 (09:07 15/11/2012)
Phlamethrower (14:14 15/11/2012)
sirbod (19:45 15/11/2012)
Phlamethrower (12:34 16/11/2012)
Raeddie (17:44 16/11/2012)
sirbod (18:52 16/11/2012)
gaula92 (19:07 16/11/2012)
sirbod (19:31 16/11/2012)
Raeddie (19:23 16/11/2012)
sirbod (19:46 16/11/2012)
Raeddie (20:14 16/11/2012)
|
| |
|
Señor Nueces |
Message #121419, posted by gaula92 at 15:39, 7/11/2012 |
Member
Posts: 43
|
Hello there
I tried StarFighter 3000 on my Raspberry Pi (32 bit downloadable version, working great on the Pandaboard).
The game runs, but when I switch it to fullscreen mode (320x256@50Hz), the HUD on top of the screen flickers a lot. Some buildings and mountains flicker, too. Tittle screen logo with interlaced Starfighter 3000 letters flickers also.
However, background is stable: no flickering at all.
I'm posting it here since I know SF3000 developers (or co-developers) read this forum.
Is there a solution or does the game need a special Rpi patch?
thanks |
| |
 [ Log in to reply ] |
| |
|
Jon Abbott |
Message #121420, posted by sirbod at 18:53, 7/11/2012, in reply to message #121419 |
Member
Posts: 563
|
Didn't we conclude there's no VSync in another thread, or am I getting confused?
You could try running ADFFS in the background and turn on forced vsyncs (*ADFForceVsync 1). I've not tried it on a Pi, so have no idea if it will work - I'd be interested to know though.
[Edited by sirbod at 18:53, 7/11/2012] |
| |
[ Log in to reply ] |
| |
|
Señor Nueces |
Message #121423, posted by gaula92 at 19:44, 7/11/2012, in reply to message #121420 |
Member
Posts: 43
|
There's vsync, I was wrong, but the Rpi Risc OS version is somewhat special: the physical video mode won't change after it has booted. That physical video mode is read from config.txt and there's no way to change it.
HOWEVER, what the Pi does is to scale any Risc OS video mode to that physical mode.
So it's perfectly possible to have smooth scroll in the likes of Twinworld if you use hmi_group = 1 and hdmi_mode = 17 in config.txt, and then you define the 320x256@50Hz mode in Risc OS to be used by the game.
This same 320x256@50Hz mode is also working for Starfighter 3000, since it's the mode the game needs to run fullscreen.
I believe the flickering issue isn't related to vsync, as other elements in the game, most notably background, doesn't flicker at all.
About ADFFS, wasn't it supposed to be incompatible with new systems since it's missing a ROM module or something like that? |
| |
[ Log in to reply ] |
| |
|
Jon Abbott |
Message #121424, posted by sirbod at 00:05, 8/11/2012, in reply to message #121423 |
Member
Posts: 563
|
About ADFFS, wasn't it supposed to be incompatible with new systems since it's missing a ROM module or something like that? A stub ADFS module was added for the Pi a few releases ago. |
| |
[ Log in to reply ] |
| |
|
Señor Nueces |
Message #121429, posted by gaula92 at 12:36, 9/11/2012, in reply to message #121424 |
Member
Posts: 43
|
@Jon Abbot: Ok, tried your ADFForceVsync 1 sugestion. No changes, same flickering. It's not an vsync problem anyway. |
| |
[ Log in to reply ] |
| |
|
Jon Abbott |
Message #121474, posted by sirbod at 06:34, 15/11/2012, in reply to message #121429 |
Member
Posts: 563
|
I borrowed a Pi to have a play yesterday and was initially impressed, however I've come across various issues which need someone more knowledgable on the hardware and more specifically the RISC OS distro to answer.
The first issue was the screen address: OS_ReadDynamicArea returns 2DA00000, OS_ReadVduVariables returns F4E00000. The later seems to the correct one, but memory does exist at the former. Is there any documentation on this? Is the memory at 2DA00000 some form of video back buffer?
Secondly, RISC OS doesn't seem to support screen banks on the Pi. OS_Byte 112 / 113 either aren't implemented, the GPU driver doesn't support the functionality or something is configured incorrectly on my install. Again is there any documentation on this?
The end result of all this is that although (for example) I can get Zarch to run natively under ADFFS on the Pi, you only see VDU output that's done through the OS and nothing that's written to the VDU memory, and everything appears on the one screen bank.
Before I go off and start fixing these issues in software, I want to be sure of why the VDU is implemented the way it is on the Pi distro, and what the capabilities of the GPU are.
Finally, are the differences in the Pi distro and memory map documented anywhere? |
| |
[ Log in to reply ] |
| |
|
Andrew Flegg |
Message #121475, posted by Jaffa at 08:34, 15/11/2012, in reply to message #121474 |
Member
Posts: 53
|
I'd guess the forums on riscosopen.org would be a better question to discuss the intricacies of the Pi memory map. |
| |
[ Log in to reply ] |
| |
|
Señor Nueces |
Message #121476, posted by gaula92 at 09:07, 15/11/2012, in reply to message #121474 |
Member
Posts: 43
|
Jon Abbot: As you were pointed out, ask these question on the Open Risc OS forums.
What you're doing, trying to get those games to run on the Pi, is great!
May I donate a Pi so you can easily work on it without havint to borrow it? |
| |
[ Log in to reply ] |
| |
|
Jeffrey Lee |
Message #121478, posted by Phlamethrower at 14:14, 15/11/2012, in reply to message #121474 |
 Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot stuff
Posts: 15100
|
The first issue was the screen address: OS_ReadDynamicArea returns 2DA00000, OS_ReadVduVariables returns F4E00000. The later seems to the correct one, but memory does exist at the former. Is there any documentation on this? Is the memory at 2DA00000 some form of video back buffer? On the Pi and Iyonix (and anything else RISC OS 5 that doesn't rely on the OS for screen memory management), the screen DA is just a dummy DA not used for anything. It exists, and memory can be allocated to it, but its size and address don't in any way correlate to the memory used by the video driver. I'm not quite sure why Castle chose to do it this way - probably just because it was the path of least resistance.
Secondly, RISC OS doesn't seem to support screen banks on the Pi. Correct. This will be the cause of the flicking HUD in Starfighter (and similar issues in a few other games, e.g. Zarch).
I've been thinking about this recently, and I think it's possible to support multiple screen banks on the Pi, it just won't be as straightforward as on other platforms. The GPU allows us to allocate a large framebuffer but only display a smaller sub rectangle. So we need to allocate a framebuffer which is N times taller than the desired screen mode, then display a rectangle within that area at the correct Y offset to simulate the presence of multiple screen banks.
The only tricky bit is working out the value of "N", since there's currently no way for a program to indicate how many screen banks it wants to use when it's performing a mode switch (apart from the BBC style MODE x+128 ). The easiest solution might be to calculate N so that we don't go above some sensible limit on the framebuffer size (e.g. 8MB ). Note that simply taking as much memory as the GPU will give us isn't necessarily a good idea, as it can cause problems with audio, and in future would cause problems with 3D, video decoding, etc.
Finally, are the differences in the Pi distro and memory map documented anywhere? Not really!
[Edited by Phlamethrower at 14:14, 15/11/2012] |
| |
[ Log in to reply ] |
| |
|
Jon Abbott |
Message #121479, posted by sirbod at 19:45, 15/11/2012, in reply to message #121478 |
Member
Posts: 563
|
I've been thinking about this recently, and I think it's possible to support multiple screen banks on the Pi, it just won't be as straightforward as on other platforms. The GPU allows us to allocate a large framebuffer but only display a smaller sub rectangle. So we need to allocate a framebuffer which is N times taller than the desired screen mode, then display a rectangle within that area at the correct Y offset to simulate the presence of multiple screen banks. Isn't that how VIDC worked?
The only tricky bit is working out the value of "N" Isn't N a simple calculation from the size of DynamicArea 2 and the screen size (the one the app expects, not the one the GPU is necessarily using)
From a forward thinking perspective (I'm obviously talking about legacy support here), I agree that setting a sensible limit of 8MB is a very sensible approach.
If the differences between the Pi distro and RO5 aren't documented, who's keeping track of what needs to be looked at later...such as screen buffering?
In the Pi distro, is it possible to redirect VDU output to a different memory location? To the DA for example? If I can get everything writing to the DA, I can implement screen buffers and blit translate to the actually screen memory on a buffer change...all very simple to implement, assuming it can be done quick enough.
EDIT: I'll move this discussion over to ROOL
[Edited by sirbod at 19:48, 15/11/2012] |
| |
[ Log in to reply ] |
| |
|
Jeffrey Lee |
Message #121485, posted by Phlamethrower at 12:34, 16/11/2012, in reply to message #121479 |
Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot stuff
Posts: 15100
|
I've been thinking about this recently, and I think it's possible to support multiple screen banks on the Pi, it just won't be as straightforward as on other platforms. The GPU allows us to allocate a large framebuffer but only display a smaller sub rectangle. So we need to allocate a framebuffer which is N times taller than the desired screen mode, then display a rectangle within that area at the correct Y offset to simulate the presence of multiple screen banks. Isn't that how VIDC worked?
Not really. With VIDC you're able to do a horizontal scroll (as long as you're happy with the pixels lost from one edge of the screen appearing on the other), with the Pi you won't. AFAIK this won't matter to RISC OS, but may affect some games.
The only tricky bit is working out the value of "N" Isn't N a simple calculation from the size of DynamicArea 2 and the screen size (the one the app expects, not the one the GPU is necessarily using)
That's assuming the app (a) uses the screen DA, and (b) sets the DA to the right size before it performs the mode change. (We wouldn't want to resize the framebuffer after the mode change, as I'm fairly certain the GPU doesn't attempt to preserve its contents when we resize it)
If the differences between the Pi distro and RO5 aren't documented, who's keeping track of what needs to be looked at later...such as screen buffering? Good question! There's this wiki page which covers some bits, but for the rest I guess it's just down to the developers who worked on the relevant areas to remember what's left to do. |
| |
[ Log in to reply ] |
| |
|
Holger Palmroth |
Message #121487, posted by Raeddie at 17:44, 16/11/2012, in reply to message #121474 |
Member
Posts: 58
|
The end result of all this is that although (for example) I can get Zarch to run natively under ADFFS on the Pi Really? I can't get my legally purchased copy of Zarch working, even on my RISC OS 3.7 StrongARM Risc PC, with or without ADFFS. On my Beagleboard it chokes at the SFS module being 26bit.
Are there different versions of Zarch floating around? |
| |
[ Log in to reply ] |
| |
|
Jon Abbott |
Message #121488, posted by sirbod at 18:52, 16/11/2012, in reply to message #121487 |
Member
Posts: 563
|
For Zarch, see the details here (scroll down to the game fixes).
For a StrongARM, you also have to disable the cache, either via "*CACHE OFF" or "*ADFCacheOff 2000" (turns the cache off for 20 seconds whilst it loads)
SFS - there may well be different versions of Zarch. Is your copy the Play it Again Sam version or the original floppy?
Getting back on topic, it would seem that RISC OS on the Pi isn't best suited to gaming at the moment, because of the lack of video buffering. Hopefully things will improve as the video driver is developed.
[Edited by sirbod at 18:53, 16/11/2012] |
| |
[ Log in to reply ] |
| |
|
Señor Nueces |
Message #121490, posted by gaula92 at 19:07, 16/11/2012, in reply to message #121488 |
Member
Posts: 43
|
I don't get it, Jon. Those fixes you point to clearly indicate that the Zarch fix is for Risc OS 3.5 > 3.7 only- Does it work on the Raspberry Pi, using 32bits Risc OS 5.19?
What other games have you tested with ADFFS on the Pi? |
| |
[ Log in to reply ] |
| |
|
Holger Palmroth |
Message #121492, posted by Raeddie at 19:23, 16/11/2012, in reply to message #121488 |
Member
Posts: 58
|
SFS - there may well be different versions of Zarch. Is your copy the Play it Again Sam version or the original floppy? Looking into the application for the first time since I bought it like 10 years ago, I seem to have the PIAS version on the original floppy.
It's the stand alone box with the original floppy, but on the floppy is a "!Superior" application with a menu for different games disabled. (The menu never comes up, it starts Zarch directly.) It seems someone copied the PIAS version on a original floppy.
Will try fiddling with the cache, thank you. |
| |
[ Log in to reply ] |
| |
|
Jon Abbott |
Message #121494, posted by sirbod at 19:31, 16/11/2012, in reply to message #121490 |
Member
Posts: 563
|
Correct, those fixes are for RO3.7
I'm testing the Pi at the moment, but it will require changes to the video driver before I can get older games working. For the time being, you can use ADFFS under ArcEm - but it's obviously very slow. Zarch for example runs at between 25-100% of its speed on an ARM3, depending on how much is being drawn on screen each frame.
But to answer your question, yes I have Zarch running natively on the Pi, but you can't play it as nothing appears on screen - except for the score. If I can figure out how to redirect VDU output to the DA, it should work.
However, for other games to work, there are a lot more issues to overcome such as 32bit module support, sound, VIDC emulation etc.
I'm looking at different options of how to overcome this, as the Pi is clearly the future for the JASPP project due to it being cheap as chips. |
| |
[ Log in to reply ] |
| |
|
Jon Abbott |
Message #121496, posted by sirbod at 19:46, 16/11/2012, in reply to message #121492 |
Member
Posts: 563
|
It's the stand alone box with the original floppy, but on the floppy is a "!Superior" application. You have the reissued version which used the PIAS version with the protection removed. This version was issued long after the original, possibly after they ran out of original floppies.
Due to the disc protection employed, the original floppy requires a dedicated disc imager to duplicate. |
| |
[ Log in to reply ] |
| |
|
Holger Palmroth |
Message #121497, posted by Raeddie at 20:14, 16/11/2012, in reply to message #121496 |
Member
Posts: 58
|
Due to the disc protection employed, the original floppy requires a dedicated disc imager to duplicate. The image produced by ADFimager works just fine following your instructions, apart from (of course) step 7 is "!Superior" instead of "!Boot".
[Edited by Raeddie at 20:18, 16/11/2012] |
| |
[ Log in to reply ] |
| |
|
The Icon Bar: General: Starfighter 3000 on Raspberry Pi: flickering HUD |
