Untitled Dungeon Game - BBC B Version

developing/porting a new game or gaming framework? post in here!
User avatar
ChrisB
Posts: 143
Joined: Wed Oct 05, 2011 10:37 pm
Location: Surrey
Contact:

Re: Untitled Dungeon Game

Post by ChrisB »

Red - no - palette restrictions. But I can put blue dots in the rooms with enemies. End of the corridors is more logic - and it would only really apply to the corridors as it's obvious when the rooms are unattached so I'm unconvinced. (I was going to do this earlier - but the way I used to address the data structures this would have slowed things down too much - I updated that but never revisited this).
filledmaze.png
filledmaze.png (9.61 KiB) Viewed 1065 times
User avatar
tricky
Posts: 5591
Joined: Tue Jun 21, 2011 9:25 am
Contact:

Re: Untitled Dungeon Game

Post by tricky »

Cool, it is probably my poor memory, probably most people can remember where they haven't been yet!
User avatar
cardboardguru
Posts: 221
Joined: Fri Mar 09, 2018 10:26 pm
Contact:

Re: Untitled Dungeon Game

Post by cardboardguru »

Well we know where we're going. But we don't know where we've been.
User avatar
ChrisB
Posts: 143
Joined: Wed Oct 05, 2011 10:37 pm
Location: Surrey
Contact:

Re: Untitled Dungeon Game

Post by ChrisB »

I have been looking at creating a version to run on a BBC B. This is necessarily going to require some compromises. The challenges are as follows:
  • The main game logic code is a BASIC program that when crunched is about 18K.
  • There are 4 banks of sideways RAM in use (totalling around 62K) and 4K of other “glue” code and data.
  • The game saves to disk to maintain progress so the DFS workspace needs to be preserved (but only up to &1100)
  • The game runs in an unmodified mode 1 screen taking 20K
So I need to fit around 100K into 32K…
Moving to mode 4 (apart from having to redo all the graphics and graphics routines) would only gain 10K meaning the BASIC would have to be a multiload of some description. I’ve therefore gone for the targeting a BBC B with 16KB of sideways RAM and a DFS disk drive. This seems a reasonable compromise. It will probably be able to make it work on an Electron with similar requirements. Also I've done the following:
  • Remove some of the maze graphics so there is no longer variation between them (I might these back at a later stage but I’m wary of increasing load times too much)
  • Removed the tune & inventory screens.
  • Split the basic into functional modules (town, map, maze, fight etc.) and make the game load the relevant SWRAM image and BASIC module as you progress.
As such here’s a demo of progress so far. Note that this is a very rough in terms of transitions between modules but you can see that the game is functional (although several of the menu options aren’t). I’ve left the disk drive noises in so you an see when the disk access is being made.

Challenges.
The way the sideways code was structured for the Master version is various rom images with routines and associated data. There is stub code that selects the right rom bank and calls the code. So for example – the text plot routine references a table in SWRAM with all possible text routines so I can say “plot string 3” at any point in the code.

This has presented some challenges moving to only only one SWRAM module available at one time. I’ve had to make sure that all the routines associated with a particular task are in the same ROM. This means that you can’t – for example – draw any cards when you’re navigating the maze. Which means the inventory screen isn’t possible without more loading. Also common routines (like the box plot) either need to be duplicated or moved to main memory.

This was a particular challenge for the text routines as there’s a significant amount of text (around 3K) that I don’t want in main memory. As such I’ve implemented some “static” points that are the same across all the images as entries for the text plotting. It’s a similar story for the screen images.

Next is the battle routines. Even with the other data taken out this still sits at around 14K of compressed BASIC which is too big. I’ve therefore implemented some overlays that decompress BASIC from the SWRAM image as required allowing the fight to both fit and have reasonable performance. (Disk based overlays would make it painfully slow).

Lastly there’s the whole multiload piece. At the moment I have a common “join” program that changes to mode 7 and performs the SWRAM load as necessary. This obviously introduces a considerable delay when moving from one screen to another. This is acceptable when – for example – you’re going back to town because this only happens rarely. However moving from the Dungeon to the Battle screens and back again is something that happens many times so minimising the time here would be good.

So to reduce the time I’m compressing the SWRAM images and decompressing them on load which should reduce the load time on the principle that disk access is the slowest part here. The maze rom is only 4K on disk but decompresses to around 14K. The battle rom doesn’t do so well as it contains lots of already compressed data (11K to 15K). I might also look at removing the join program and duplicating this into the programs.
User avatar
tricky
Posts: 5591
Joined: Tue Jun 21, 2011 9:25 am
Contact:

Re: Untitled Dungeon Game

Post by tricky »

Wow Chris, that is great work!
Sounds like a good candidate for BooBip OS RAM module, to give you an extra 15K for BASIC, but I don't know how many people have them.
With the MMC type devices, the load is about 10X faster (from memory) so that should help in some (most?) cases.
Are you planing on supporting multiple SWRAM banks? I guess it is a little more code and more than a little extra effort.
Great to see the B being supported on what looked like it could only be a Master (and B+?) game.
Richard
User avatar
ChrisB
Posts: 143
Joined: Wed Oct 05, 2011 10:37 pm
Location: Surrey
Contact:

Re: Untitled Dungeon Game

Post by ChrisB »

Ahh - knew there was something I forgot to mention.

I'm looking at 16K SWRAM as the minimum platform and I'll get it working on that first. However I'm also thinking that if 32K is available then loading the maze/fight SWRAMs into these two banks would mostly eliminate the back and forth (there will still be some load time for the BASIC but much reduced). And yes - an MMC or similar will make thing much more usable.
User avatar
tricky
Posts: 5591
Joined: Tue Jun 21, 2011 9:25 am
Contact:

Re: Untitled Dungeon Game

Post by tricky »

I was thinking of remembering the last two etc, but fixing one might be easier ;)
PS All my show beebs have 32K, but my main one is Solidisk.
User avatar
ChrisB
Posts: 143
Joined: Wed Oct 05, 2011 10:37 pm
Location: Surrey
Contact:

Re: Untitled Dungeon Game

Post by ChrisB »

OK - attached is an initial beta for the BBC B version to get feedback on how people feel it works.
UDG_BBCB_Beta1.ssd
(84.25 KiB) Downloaded 13 times
Requirements.
A BBC B with DFS and 16 or 32K of sideways RAM that is witeable via ROMSEL (This will change at some point). It will use the lowest two banks it finds. If there is 32K then there will be less loading between the maze and fight screens. It will work on a B+ - but probably not a Master.

Known issues:
Instructions don't work.
Save file error handling might not work well.
There is screen corruption when loading. This is intended to be hidden by palette switching at some point.
The sound is not right.
Escape still works.
The SWRAM configuration it is using is displayed at startup - this will be removed.

Let me know how you get on.
User avatar
lurkio
Posts: 3616
Joined: Wed Apr 10, 2013 12:30 am
Location: Doomawangara
Contact:

Re: Untitled Dungeon Game

Post by lurkio »

ChrisB wrote:
Fri Apr 30, 2021 7:17 pm
OK - attached is an initial beta for the BBC B version to get feedback on how people feel it works ... UDG_BBCB_Beta1.ssd ... Requirements ... A BBC B with DFS and 16 or 32K of sideways RAM that is witeable via ROMSEL (This will change at some point). It will use the lowest two banks it finds. If there is 32K then there will be less loading between the maze and fight screens.
Just tried this in my Model B with a ctorwy/IFEL/Picton ROM/RAM board, with various ROM-images installed, including two ROM-images in SWRAM slots 0 and 1, but with those slots *KILLed using ARM ROM Manager (because they were unnecessary and one of them was a filesystem ROM that would have raised PAGE). When I booted UDG, it overwrote the ROM-images in those two slots! Which isn't ideal.

This is pretty much the same problem that ocurred at one point during the development of Ozmoo:

viewtopic.php?f=2&t=19975&p=283990&hilit=arm#p283990

:idea:

EDIT: Ah, I see that the SWRAM slots are overwritten even if I haven't *KILLED them! Fair enough. (But it might be nice to check before overwriting any ROM-images, whether *KILLed or not..?)
User avatar
ChrisB
Posts: 143
Joined: Wed Oct 05, 2011 10:37 pm
Location: Surrey
Contact:

Re: Untitled Dungeon Game BBC B Version

Post by ChrisB »

This is very much a beta version and the Sideways detection code is the minimum to get the game running. This needs to be expanded to include more varieties of SWRAM etc. One of the plans is to allow you to specify which banks you would like to use rather than letting the game detect them to get round the kind of issues you are having.
User avatar
ChrisB
Posts: 143
Joined: Wed Oct 05, 2011 10:37 pm
Location: Surrey
Contact:

Re: Untitled Dungeon Game BBC B Version

Post by ChrisB »

Attached is an updated version.
UDG_BBCB_Beta2.ssd
(85 KiB) Downloaded 10 times
Note that the SW Ram behaviour is the same as previous - i.e. the bottom two slots will be overwritten. Also only ROMSEL based SWRAM is currently supported.

Changes in this version.
Sound should now work correctly.
Added pallet switching routine to hide data during loading.
Save file handling should now be robust and error appropriately.
Made space for SW Routines.
Couple of minor display bug fixes.
User avatar
ChrisB
Posts: 143
Joined: Wed Oct 05, 2011 10:37 pm
Location: Surrey
Contact:

Re: Untitled Dungeon Game BBC B Version

Post by ChrisB »

Time for another update. Attached is Beta 3.
UDG_BBCB_Beta3.ssd
(85.75 KiB) Downloaded 9 times
This release adds in the instructions and credits menu and reduces the sound volume. As such the game is now feature complete (probably ;) )

I now need to focus on the Sideways Ram detection and selection code for the various types that exist.
User avatar
ChrisB
Posts: 143
Joined: Wed Oct 05, 2011 10:37 pm
Location: Surrey
Contact:

Re: Untitled Dungeon Game - BBC B Version

Post by ChrisB »

Hot on the heels of Beta 3 is Beta 4.
UDG_BBCB_Beta4.ssd
(85.5 KiB) Downloaded 12 times
This release adds support for 2 more sideways RAM types - Ramsel based and Watford types. The game says which it is using at startup. Unfortunately I have no way to test these so if anyone can run them up on appropriate hardware that would be appreciated.

I don't have any idea what the actual composition of types out there is - or how much interest there is in adding more support. Any comments are appreciated.
User avatar
lurkio
Posts: 3616
Joined: Wed Apr 10, 2013 12:30 am
Location: Doomawangara
Contact:

Re: Untitled Dungeon Game - BBC B Version

Post by lurkio »

In his Acorn Ozmoo project, SteveF seems to have detected most types of SWRAM boards, including a troublesome Solidisk one, and it can detect when slots are empty too. I wonder if you'd be able to use his code..? It's on Github, I believe.

:?:
SteveF
Posts: 999
Joined: Fri Aug 28, 2015 9:34 pm
Contact:

Re: Untitled Dungeon Game - BBC B Version

Post by SteveF »

Ozmoo uses a lightly tweaked version of Wouter Scholten's swrtype-0.7 to detect sideways RAM. I originally tried writing my own code, but doing this reliably on real hardware is a lot harder than it seems at first. (Well, it was for me anyway!)

My tweaks are:
  • Add Electron support.
  • Detect only free sideways RAM instead of all sideways RAM.
You can see the Ozmoo version of the code here. This builds a FINDSWR executable which is executed by the loader (code here).

There's another tweak courtesy of hoglet to un-break some MMC filing systems after the FINDSWR code probes for Solidisk style sideways RAM. We re-select the current filing system inside the FINDSWR code after doing all the tests, and in the loader we do:

Code: Select all

*/FINDSWR
ON ERROR GOTO 500
*INFO XYZZY1
500ON ERROR PROCerror
to force a reset of MMC-based filing systems which have possibly been upset by FINDSWR messing around with the user port. (XYZZY1 is a non-existent file.)

(Edit: I should give lurkio credit here for reporting this problem and doing lots of work to test various unsuccessful fix attempts.)

The result is a sideways RAM type byte (Acorn, Solidisk, etc) populated at swr_type, a count of RAM banks at ram_bank_count and a list of bank numbers at ram_bank_list. (In another Ozmoo-related quirk, the code only detects a maximum of nine banks, but that can easily be changed.)

Ozmoo detects non-Acorn style sideways RAM but won't use it at the moment - no one has expressed an interest in having support for other forms of sideways RAM added yet. Ozmoo is probably of more niche interest than Untitled Dungeon Game, so you probably can't read too much into that, but I offer the observation for what it's worth.

You're welcome to take my changes, it might be worth dropping Wouter a line if you want to use this code.

If you have any questions I'm happy to try to help!
User avatar
ChrisB
Posts: 143
Joined: Wed Oct 05, 2011 10:37 pm
Location: Surrey
Contact:

Re: Untitled Dungeon Game - BBC B Version

Post by ChrisB »

Thanks both. Wouter's code was my starting point for the types but the logic is mine (and simpler). I deliberately avoided messing with the user port to avoid upsetting any MMC storage options there. There is some nice stuff to step round potential ROMS in your code Steve but I would think that this is probably the minority case. As I said before I'm intending to add a utility to allow you to set the RAM locations if your setup demands it.
User avatar
lurkio
Posts: 3616
Joined: Wed Apr 10, 2013 12:30 am
Location: Doomawangara
Contact:

Re: Untitled Dungeon Game - BBC B Version

Post by lurkio »

ChrisB wrote:
Tue May 11, 2021 10:42 pm
There is some nice stuff to step round potential ROMS in your code Steve but I would think that this is probably the minority case.
Ooh, I'm not so sure about that! I'd have thought that people with enough SWRAM would have loaded (some of) it up with useful ROMs (multiple filesystems, ROM management utils, etc.).

ChrisB wrote:
Tue May 11, 2021 10:42 pm
I'm intending to add a utility to allow you to set the RAM locations if your setup demands it.
Why not detect the slots that look empty and give the user the choice either to accept them (for loading game data into) or to reject them and specify their own slots?

(Just some suggestions. Please feel free to ignore them if they don't work for you!)

:idea:
User avatar
tricky
Posts: 5591
Joined: Tue Jun 21, 2011 9:25 am
Contact:

Re: Untitled Dungeon Game - BBC B Version

Post by tricky »

I posted mine when I was doing AstroBlaster six or so years ago and couldn't find a better way around messing up MMC devices when checking/using STL SWRAM than:

Code: Select all

100 CALL findswr
110 ON ERROR GOTO 130
120 GOTO 140
130 ON ERROR OFF
140 *LOAD rom
or if you don't mind it locking up on a genuine error:

Code: Select all

100 CALL findswr
110 ON ERROR GOTO 120
120 *LOAD rom
At the time the only safe way I could find of resetting an MMC FS was just to try the op and let it fail, then try again.
You could do a dummy operation, but on floppy/GOTEK, that isn't "free".
You only need the on error on the next IO after accessing the user port.

I have recently added looking for the (C) and reading the ROM type byte, but don't use it yet.
My plan was to use non-(C) banks first and then just pick the lowest (C) banks if I need more!

PS my current code is just under 200 bytes and uses &7x to store SWRAM slots and &8x rom bytes and findswr, gettypes and copy are stand-a-lone (remove &FE0x lines to remove STL checks).
In Astro Blaster I also check for the RAM on a WE12 ROM RAM board. The ROM can only be written to by code running on the board, so if the DFS is on board, you can just *LOAD and if BASIC is on the board, you can load to RAM and then copy with a for loop. You read it in the normal way, but it is always in slot 14.
User avatar
ChrisB
Posts: 143
Joined: Wed Oct 05, 2011 10:37 pm
Location: Surrey
Contact:

Re: Untitled Dungeon Game - BBC B Version

Post by ChrisB »

Thanks all for you inputs. I didn't want extra prompts during loading hence my idea of a separate configuration for those who need it. The B+/Master has exactly the same approach to sideways ram banks and this doesn't seem to have caused issues there. Which brings me to release beta 5.
UDG_BBCB_Beta5.ssd
(87.5 KiB) Downloaded 6 times
Changes as follows:
  • Inclusion of a program to set the swideways banks the game uses. CHAIN"SWSet" to use it. This creates a configuration file that the main game will read. If the file exists the game will attempt to detect SWRAM in the configured slot(s) only and will not look for any other banks.
  • Tidied up some transition screens to prevent the display of loaded data.
Lastly - I see a few downloads of the previous beta. Has anyone tried this out - and if so - what did you think?
User avatar
tricky
Posts: 5591
Joined: Tue Jun 21, 2011 9:25 am
Contact:

Re: Untitled Dungeon Game - BBC B Version

Post by tricky »

I given beta 5 a quick blast, seems great, I don't have any more time at the moment, but will get back to it as soon as I do.
User avatar
ChrisB
Posts: 143
Joined: Wed Oct 05, 2011 10:37 pm
Location: Surrey
Contact:

Re: Untitled Dungeon Game - BBC B Version

Post by ChrisB »

One of the things that I "cut" initially was the graphic for the boss battle as I didn't want to have a large amount of loading before this happened. I've never been happy with this but just didn't have space. Then in a "why on earth didn't I do that before" moment I restructured one of my lookup tables and now have the space for the Boss graphic & enlargement code. Also space to put back all the original shield graphics.

Attached is therefore beta 6 with these changes. Also included is a bug fix for the end game message and a fix to stop saving being automatically enabled.
UDG_BBCB_Beta6.ssd
(87.5 KiB) Downloaded 7 times
This version has the dangerous potential to be promoted to release 1.
User avatar
lurkio
Posts: 3616
Joined: Wed Apr 10, 2013 12:30 am
Location: Doomawangara
Contact:

Re: Untitled Dungeon Game - BBC B Version

Post by lurkio »

ChrisB wrote:
Sun Jun 06, 2021 7:41 am
Attached is therefore beta 6 with these changes. Also included is a bug fix for the end game message
Didn’t get anywhere near the endgame (or even past the first dungeon!), but I gave the beta a quick test on my Model B last night, and it seemed to work well.

I still think it would be slicker if it autodetected empty SWRAM slots, à la Ozmoo, but, failing that, the SWset program does the job, albeit that it has to be run manually.

Great update!

=D> =D> =D>
Post Reply

Return to “new projects in development: games”