Graphics Extension ROM based Game - experimenting

[flibble]

I started playing with this little test program at Markfield earlier in the year, I finally reached a 'milestone' of sorts, I ran out of memory on the BBC B

Good
- Tile based plotting
- Animation of character in 4 steps between adjacent tiles.
- Two sprite layers, background and characters plotted on top
- Written fully in BASIC
- keyboard input on z,x,*,/
- Just about fast enough performance
- Gfx look good, (even better in the Gameboy game I borrowed them from, ahem)

Bad
- flickery (plotting BG then character in each frame)
- no mask based plotting, when the white backgrounded character walks over a darker tile it looks a bit silly.

Ugly
- with only 12 sprites (8 character, 2 facing each direction, 4 background sprites), I have already run out of memory on the Beeb B

Running

- A machine with the graphics extension ROM fitted, or a Master with the 'Spriter' romimage from the welcome disc loaded into Sideways ram
- type *SSPACE 4
- hit break
- CH."GAME"

Future
I'm not sure it's worth me running any further with this. If I did I'd be tempted to say 'BBC Master only', as you always have the GXR to hand on the welcome disk and I could use shadow ram to free up 20k for more sprites and some actual gameplay.

[Lardo Boffin]

Have you considered running this over the Tube? The main program would live on the co-proc while the sprite data lives on the Beeb itself. That should help provide more space for sprites and interesting stuff!

[Lardo Boffin]

Also the Beeb can get on with just running sprite code for the ROM while the co proc handled the BASIC. Might help reduce flicker.

[flibble]

Interesting idea about the 2nd processor, running a few tests in beebem the second proc *does* give the most available memory, even more than shadow ram.

master 128 LOMEM HIMEM
MODE 1 3586 12288
MODE 129 3586 32768

bbc b
MODE 1 7170 12288
bbc b 6502 second proc
MODE 1 2050 32768

But I think I'll try the master next as I think more people have one ... including me

[Elminster]

Master with shadow and HiBASIC (ad copro) will give you 44k usable if you need more.But the thing about Basic is it is to blow that as well, then you will just have to start crunching.

[Lardo Boffin]

But I think I'll try the master next as I think more people have one ... including me

I guess I will have to join the master race at some point then! Although with raspberry Pi co-procs available for very little outlay hopefully most people have one by now.

[flibble]

then you will just have to start crunching.

With the initial 'B' version I had already started having to shorten variable names

I'm currently editing the program on the PC and pasting into to Beebem for testing, I think I could add an extra step in my build process that at least stripped out the comments.

[Elminster]

I write on Mac in bbedit, crunch it using the mdfs *crunch, makes it unreadable though which is a bit of a debugging pain. You can also hack the files up to crunch and then *lik as well if not enough memory to crunch them.

Was on my todo list to do some sort of Mac runableble basic cruncher and do it there rather than on Beeb, but never got around to it.

[flibble]

Well, 6 months on and an update.

I did experiment a bit more with this, but the big thing that got me to keep trying was cmorley helping me setup a working C compiler. As such I rewrote the program in C (with a coresponding decrease in size and increase in performance) and setup to use shadow RAM, giving me an extra 20KB to play with.

Things I've added recently.

• I created a 'spritesheet' on windows, used 'BBC Micro Image Converter' to create a 'screen', loaded this into screen memory and then wrote a short basic program that created GFX extension ROM sprites from the screen data. This is a lot easier than using the GFX ROMs SEDIT program.
• Added a 'Solid' flag to the map data to prevent players walking through buildings etc
• Added a 'door' flag to the map data which enables you to teleport between 'rooms'
• Added a 'special procedure' flag to the map data, which can be used to trigger events in the main code when a player touches or enters a location.
• Made the palette dynamic between different rooms.
• Added 'dialog' that can print up speeches between characters etc, triggered on 'special procedures'.

Big things that I still need to look at

• A combat system ... some game play would be good
• A map editor, programmatically typing in data, or just raw typing binary data into files isn't going to cut it.

I'm still not sure if I can fit all this in memory, but I have about 10KB more to play with I think. After that more drastic measures to reduce mem usage

Current sizes

• binary, 7.7KB
• Sprites, 4.5KB
• Workspace/variables, who knows?

[tricky]

That's great, could this be the first Retro software C release, or even the first beeb C game?

[cmorley]

+1 like. Good work.

Sideways RAM is trivial to use from C too (I did all my memory module test code in gcc). Assuming most people would have 2 banks, there is 32K more for tables, graphics etc. I think the linker file I gave you has an example of how to output overlaid memory segments... if not I can send you something.
Chris

edit: -Os optimise for size seems to help a bit... did you try that?

[flibble]

Well, progress is glacially slow, but there have been some updates.

A incredibly simple battle system is in, featuring an action menu (with only two actions) and the ability to target specific enemies.

I also realised that the main sticking point was ease of creating datafiles for the area maps, I started off reusing most of the game code and trying to write it on the master

However it became apparent that a mouse interface would be really useful and the sheer number of things I'd need to twiddle would make a beeb keyboard interface rather unwieldy. So over the last couple of days I've knocked something together on windows to create the maps. It has two editing modes, placing sprites on the map, and then adding special flags (solid, door, procedure call) to specific squares.

[tricky]

Well done flibble, keep it going.

[Elminster]

Yes definitely keep it up. I often prefer the more recent games that use 40 years of knowldege to stretch the Beeb, and/or use extra hardware, also the quality control is often better (labour of love ?) i.e. Any game by Tricky, but my real fave is Castle Defender. (Unless Sydney can knock it off the top with Happy Mrs Chicken)

[Lardo Boffin]

This looks impressive. What C setup are you using?

[lurkio]

Well, progress is glacially slow, but there have been some updates.

Glad you're persevering with this. It looks very interesting!

Are you keeping an eye on compatibility with JSBeeb (with GXR loaded into Sideways RAM)? (I'm sure there won't be any problems if your game already runs in BeebEm, but you never know...)

[flibble]

This looks impressive. What C setup are you using?

I'm using the gcc6 setup that cmorley helped me setup. I'm thinking that I really ought to document where to get it and how to set it up, because at the moment I'm not sure I've got it backed up anywhere!

Are you keeping an eye on compatibility with JSBeeb (with GXR loaded into Sideways RAM)? (I'm sure there won't be any problems if your game already runs in BeebEm, but you never know...)

Just tried it on JSBeeb, it runs fine

[lurkio]

I'm using the gcc6 setup that cmorley helped me setup. I'm thinking that I really ought to document where to get it and how to set it up

Yes, please do that!

[Lardo Boffin]

I'm using the gcc6 setup that cmorley helped me setup. I'm thinking that I really ought to document where to get it and how to set it up

Yes, please do that!

I second that please!

[cmorley]

Puppeh's instructions are fine. Just download it from GitHub and build it as per the readme.

The only change I made was to one of the startup assembler (.s) files so a C program would return to BASIC without corrupting the BASIC state at all.

Code: Select all

.\gcc-src\libgcc\config\6502\crt0.S:
32	.segment "STARTUP"
+#ifdef __C64__
33	lda #38
34	sta 1
+#endif

If you don't care about BASIC on exit (or never exit) then no mods are required.

viewtopic.php?f=2&t=13148&p=205590&hilit=gcc6#p205590

[flibble]

Things continue, I updated the editor to support including the 'random encounter' data in the level format.

When implementing the actual act of triggering a random encounter I needed a rng. This chap here seemed to have a simple rng that works well on 8 bit;

https://www.electro-tech-online.com/thr ... it.124249/

There's one extra feature that I wanted to add to the editor/engine in that changing between areas could alter which sprite set was used, for example you could use different sets for 'outdoors', 'indoors', 'town', 'cave' etc. As such I've spent the last few days going back to maps of the original game I'm 'borrowing' graphics from and hacking the individual sprites out.

[cmorley]

Great to see progress.

I use the prng built into BASIC for my C memory test software. It has the downside of only being compatible with a specific version of BASIC though. Fine for my memory test tools but not for you. Maybe JGH knows of a good method?

[tricky]

I have a 12 byte random number (256 entry series actually) generator, but you might just get away with the low byte of one of the timers or even 100hz/frame counter.

[flibble]

You've misunderstood, I'm using the prng in the link above, it works well and uses very little resources

Plus it's in C, so no hassle mixing it into the project

[flibble]

I'm still working on this, I'm trying to progress it to a 'mini game' that should hopefully have about 10 minutes of gameplay.

Here is a little video showing some things that have been worked on recently

https://www.youtube.com/watch?v=1yn4fuXYySE

• Two stage game loader to load sprite rom if it's not present, and load game if it is
• Splash screen
• detailed world map design (only of the first few rooms, as no spoilers, 23 rooms in total)

[Lardo Boffin]

Looks good!

[lurkio]

I'm still working on this, I'm trying to progress it to a 'mini game' that should hopefully have about 10 minutes of gameplay.

Here is a little video ...

This is all looking really great.

I don’t think I’ve seen this combo of look and game-type on the Beeb before. Good luck with the project. I really hope you finish it!

Btw, will the sprites have that sort of opaque “border” or “background” type thing around them in the final version of the game? (Not complaining, just asking!)

[jms2]

That's excellent, well done! Looks superb.

Just a thought - if all the plotting is being done via OS-legal methods, does this also work across the Tube?

[flibble]

Thanks for the the support folks

Btw, will the sprites have that sort of opaque “border” or “background” type thing around them in the final version of the game? (Not complaining, just asking!)

Yep, it's a limitation of the graphics extension ROM sprite plotting, there is no 'plot with a mask' function. I decided I could live with it during development then ask tricky for help once I'd solved the other issues All the character sprites use only 3 of 4 colours so there's scope for the 4th to be the mask.

Just a thought - if all the plotting is being done via OS-legal methods, does this also work across the Tube?

I've just had a quick check on emulator with 2nd proc and it didn't work, I couldn't tell you why.