log in | register | forums
Show:
Go:
Forums
Username:

Password:

User accounts
Register new account
Forgot password
Forum stats
List of members
Search the forums

Advanced search
Recent discussions
- Archive 24:6 reviewed (News:)
- Adventures in Optimisation - Audio mixing (News:3)
- India (Prog:1)
- RISC OS interview with Gavin Smith (News:1)
- Rougol talk goes remote for Lockdown (News:3)
- NetSurf reaches version 3.10 (News:15)
- Archive 24:6 is 'in the post' and free to read online (News:1)
- June News round-up (News:)
- Baby steps... (PP:24)
- ROOL releases PI RC16 (News:)
Latest postings RSS Feeds
RSS 2.0 | 1.0 | 0.9
Atom 0.3
Misc RDF | CDF
Site Search
 
Article archives
The Icon Bar: Games: NBlood
 
  NBlood
  Phlamethrower (18: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 (10:41 15/4/2020)
              Phlamethrower (21:37 20/4/2020)
 
Jeffrey Lee Message #124501, posted by Phlamethrower at 18:19, 2/6/2019
PhlamethrowerHot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot stuff

Posts: 15094
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: 50
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
PhlamethrowerHot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot stuff

Posts: 15094
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
PhlamethrowerHot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot stuff

Posts: 15094
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
PhlamethrowerHot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot stuff

Posts: 15094
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: 50
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 10:41, 15/4/2020, in reply to message #124767
PhlamethrowerHot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot stuff

Posts: 15094
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 21:37, 20/4/2020, in reply to message #124800
PhlamethrowerHot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot stuff

Posts: 15094
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 ]
 

The Icon Bar: Games: NBlood