| |
NBlood |
| |
Phlamethrower (17:19 2/6/2019)
grannyg (18:38 18/3/2020)
Phlamethrower (09:28 19/3/2020)
Phlamethrower (22:42 22/3/2020)
Phlamethrower (23:30 26/3/2020)
grannyg (19:17 28/3/2020)
Phlamethrower (09:41 15/4/2020)
Phlamethrower (20:37 20/4/2020)
|
| |
|
Jeffrey Lee |
Message #124501, posted by Phlamethrower at 17:19, 2/6/2019 |
 Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot stuff
Posts: 15100
|
As teased in the Duke3D thread, I've been working on porting NBlood (i.e. 1997's Blood) to RISC OS.
No ready-to-go releases yet (more tidying and a few high-impact optimisations needed), but I have at least set up a github repo containing my changes: https://github.com/Phlamethrower/NBlood
If you've got the GCCSDK autobuilder set up it should be trivial to build your own binaries (see platform/RISCOS/README.md). Make sure your SDL build is up to date - I pushed some major fixes to GCCSDK SVN yesterday. Plus you'll need a copy of the game data files; I suspect the shareware files will do, but one of the downloads I looked at contained the installer exe, rather than the extracted game files - so you might need to jump through some hoops to get what's needed.
[Edited by Phlamethrower at 23:32, 26/3/2020] |
| |
 [ Log in to reply ] |
| |
|
Chris Gransden |
Message #124759, posted by grannyg at 18:38, 18/3/2020, in reply to message #124501 |
Member
Posts: 52
|
Finally got around to trying this out.
On a Pi 4 overclocked to 2.147GHz and everything running from a ram disk with Freepats. The frame rate more or less keeps to 60fps at 1440x900. I had to disable alignment exceptions when compiled with gcc4.
When compiled with gcc8 alignment exceptions can be left on. |
| |
[ Log in to reply ] |
| |
|
Jeffrey Lee |
Message #124760, posted by Phlamethrower at 09:28, 19/3/2020, in reply to message #124759 |
Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot stuff
Posts: 15100
|
I had to disable alignment exceptions when compiled with gcc4. Odd, I don't remember having to do that (I specifically remember fixing any unaligned access issues I ran into)
When I checked up on things a few months ago I spotted that some work was ongoing in the upstream eduke32 repository for optimising the audio code (which is the thing I was planning on doing at some point). I should probably check up again and see what state it's in now, because really the poor audio performance was the only thing holding me back from doing an initial release. |
| |
[ Log in to reply ] |
| |
|
Jeffrey Lee |
Message #124761, posted by Phlamethrower at 22:42, 22/3/2020, in reply to message #124760 |
Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot stuff
Posts: 15100
|
It took a few hours of fiddling, but today I was able to bring my port up to date. It looks like the audio mixing is now entirely integer based, which is nice.
I'll see if I can do some more testing and get it pushed to github sometime in the next week.
[Edited by Phlamethrower at 22:45, 22/3/2020] |
| |
[ Log in to reply ] |
| |
|
Jeffrey Lee |
Message #124765, posted by Phlamethrower at 23:30, 26/3/2020, in reply to message #124761 |
Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot stuff
Posts: 15100
|
New version pushed (to new riscos-2 branch; I reapplied my changes onto the upstream master).
Things I've spotted:
* sdl_mixer is no longer used for music - it looks like it was lost during an upgrade which allowed the game to perform the MIDI sequencing itself (using a selection of different backends). This means Freepats is no longer used/needed. I might try reimplementing it at some point.
* The default music driver is now an OPL emulation, which will work out-of-the-box (it turns out this was also in the old version, I just never spotted it).
* There's an alternate music driver which uses .sf2 format sound fonts, but I haven't found a sound font which it will load yet (admittedly I've only tried one so far). All the mixing uses FP math, so performance is likely to be worse than OPL.
* I think I've fixed the alignment exceptions issue you ran into - looks like it was specific to ARMv6 optimised builds, which I guess I'd never tried before
I'd say that a VFP-optimised build reaches a playable framerate on a Pi 1 at 640x480 if you have audio turned off - so Pi 1 will probably be the minimum spec I'll be aiming for when I finally implement some optimisations and prepare a packaged release. |
| |
[ Log in to reply ] |
| |
|
Chris Gransden |
Message #124767, posted by grannyg at 19:17, 28/3/2020, in reply to message #124765 |
Member
Posts: 52
|
The alignment exception error is fixed.
The new version gets 3 or 4 extra fps with gcc 8.
1920x1080 is playable on a Pi4. |
| |
[ Log in to reply ] |
| |
|
Jeffrey Lee |
Message #124800, posted by Phlamethrower at 09:41, 15/4/2020, in reply to message #124767 |
Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot stuff
Posts: 15100
|
I've been making good progress on optimising the low-level rendering code. There's still a number of routines to update, but I'll try and get my current set of changes published sometime in the next few days.
I still need to hook up Druck's TimerMod so we can get a more accurate frame rate counter, investigate why the OPL3 music is a CPU hog, and do a deep-dive into why up to 25% of CPU time is spent in memcpy! (hopefully that's just because of the way it renders to an off-screen buffer, and I'll be able to eliminate it by having it render directly to screen in 8bpp modes)
I've also remembered that there's an "r_upscalefactor" console variable which can be used for scaling the render resolution (e.g. 2 = 2-times upscaling), so if I expose that on the video options menu then it'll be an easy way for low-end machines like the Pi 1 or Iyonix to get extra performance. |
| |
[ Log in to reply ] |
| |
|
Jeffrey Lee |
Message #124806, posted by Phlamethrower at 20:37, 20/4/2020, in reply to message #124800 |
Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot stuff
Posts: 15100
|
New changes pushed; a couple of bugfixes, TimerMod support for more accurate timing, and a bunch of optimisations. At the slowest bit of E1M1 (looking through the cemetery gates), it now runs twice as fast as before on both Pi 1 (640x480x8bpp) and Titanium (1280x720x16bpp), which is nice.
investigate why the OPL3 music is a CPU hog Looks like it's just a complex thing to simulate (and was eating 50% of the CPU on a BB-xM!). I've put in an optimisation to halt processing of inactive channels, which has reduced it to around half, but that's still way too high, so I'm probably going to look into re-integrating sdl_mixer. |
| |
[ Log in to reply ] |
| |
|
