Announcing Sonic GX - a new episode of Sonic the Hedgehog for Amstrad GX-4000

[Anthony Flack]

Speak for yourself! Weather is lovely here in November.

I'd say I can't wait, but I'm ok with waiting. Between this and the new GnG, the Plus is finally getting some games that show its true ability, and we only had to wait 35 years.

[norecess464]

Between this and the new GnG, the Plus is finally getting some games that show its true ability, and we only had to wait 35 years.

My first real "wow" moment was the GnG remake originally programmed by @Xifos back in 2016, if I'm not mistaken.

IMO It set the standard and showed us the path to follow for all modern games on the GX-4000! Let's give him the credit he truly deserves! 

[dthrone]

Between this and the new GnG, the Plus is finally getting some games that show its true ability, and we only had to wait 35 years.

My first real "wow" moment was the GnG remake originally programmed by @Xifos back in 2016, if I'm not mistaken.

2018? 

[Egg Master]

My first real "wow" moment was the GnG remake originally programmed by @Xifos back in 2016, if I'm not mistaken.

2018? 

If it was released in 2018, it was probably programmed in 2016.

[kawickboy]

IMO It set the standard and showed us the path to follow for all modern games on the GX-4000! Let's give him the credit he truly deserves! 

Could you describe your devkit please (tools...) ?

[norecess464]

Could you describe your devkit please (tools...) ?

Sure.

I'm using Debian Linux using a Thinkpad X220.

I ask CeD (the 2D artist) new graphics. Here for example, the in-game sprite sheet.
I use GIMP to replace sprites in a more convenient order for me...


I also design all the levels myself with Tiled.


Then, I use Codelite, which is a nice small C++ IDE.
I created a simple command-line app that converts all the data (graphics, Tiled maps, etc) into a format suitable for the Amstrad GX-4000.
I'm also using that to generate sine curves, data tables, etc.


Then, I edit all my Z80 code using Geany.


I compile the game code (that references also the data) with SDCC C compiler / RASM Z80 assembler using a simple BASH script.
I also wrote separately my own SDCC Z80 converter to RASM Z80 (so the C code compiled by SDCC generates Z80 files suitable for RASM).
The source code will directly generate the final cartridge file.


To test the game, I use my own fork of CPCEC emulator (I extended it with a GTK UI).
The emulator will monitor for file changes on the cpr file, so each times a new build is completed I can immediately test it.

Here with the ASIC Inspector...


I test from times to times on the real hardware. I use a C4CPC cartridge inserted into my Amstrad Plus, with a cable connected from my laptop for quick CPR transfert.

I rely on git-cola for git management.
For every commit, I include the resulting compiled game.cpr file + memmap.txt file (the output provided by RASM, reporting all the memory taken so far). This proved to be a life-saver several times when chasing a bug that was introduced "many months ago".
To this day Sonic GX is made of 6021 commits over 2809 files and the repo age is 7 years!


I use korganizer to keep tracks of the bugs.


zim also for a local wiki (knowledge database, notes, etc).


I also maintain separately a folder containing references for the game, such as downloaded gameplay of Sonic the Hedgehog on other systems, unused graphics, prototypes, previews etc.


EDIT: I forgot to mention Arkos Tracker for the audio. I'm using an export of the SFX/songs directly into the game codebase.

I think that's a good overview...
Do not hesitate to ask if you have more questions!

[kawickboy]

We are far from a DAMS/Maxam + a CPC+ modded OCP indeed. That's nearly a professional devkit.

[Cwiiis]

Wow, that's an amazing amount of organisation! And 7 years is a very long time too, how active was it being developed over that time? I'm also quite interested that you're using SDCC, what parts of the game do you use C code with? I'd be interested in hearing about the high-level structure of the game and how C fits into that...

Out of interest, does your engine allow for a frame to run over budget? What happens in that case? What's your interrupt management like, and how do you deal with register and shadow register use?

Maybe that's too many questions, I'm just so interested seeing someone else's process

[norecess464]

7 years is a very long time too, how active was it being developed over that time?

For years, every Saturday morning, I've been sitting at my local coffee shop, programming for 2–3 focused hours.
My experience: the secret to long-term productivity isn't how much you get done in a single coding session -- it's how regular you are.

I'm also quite interested that you're using SDCC, what parts of the game do you use C code with? I'd be interested in hearing about the high-level structure of the game and how C fits into that..

I use C for the high-level game logic:

• compute new Sonic's position in the world
• what to do when Sonic is colliding
• camera management (that drives the 2D vertical/horizontal scrolling)

Those are parts with lots of logic "if condition then...", it makes implementation easier to maintain.
It takes approx. 10 raster-lines to process, I'm fine with that.

Out of interest, does your engine allow for a frame to run over budget? What happens in that case?

I'm using classic raster lines to estimate quickly how a budget fits in the current frame.
Whatever happens, I have an interruption at the end of the visible area that triggers a new frame. It resets everything (the stack, the shadow registers, DMA list, etc) so the game loop gets looped.
The sprite copy routines are executed at the end of the frame, so if the copy process can't be completed that's fine, it will be updated again a few frames after.

What's your interrupt management like, and how do you deal with register and shadow register use?

I rely on the DMA-INT instead of PRI. With those interrupts, I mostly manage the screen split, the background (the blue rasters), the multiplexed rings and the end of the frame.
I never use shadow registers in the game code itself. They are reserved for interrupt code, a bit like the Amstrad firmware actually does. (credit: this was suggested to me by Overflow when I started to create the game engine).

[eto]

wow... it would have taken me 7 years just to set up that tool chain.

[Anthony Flack]

My experience: the secret to long-term productivity isn't how much you get done in a single coding session -- it's how regular you are.

I applied a similar method using my Sunday afternoons. Forced myself to do at least one or two things every week. Eventually, sure enough the project is complete. 

[Anthony Flack]

Between this and the new GnG, the Plus is finally getting some games that show its true ability, and we only had to wait 35 years.

My first real "wow" moment was the GnG remake originally programmed by @Xifos back in 2016, if I'm not mistaken.

IMO It set the standard and showed us the path to follow for all modern games on the GX-4000! Let's give him the credit he truly deserves! 

True enough, and I did enjoy that version of GnG; it was cool to see a decent scrolling arcade platformer appear on the Plus, even though as a fan of course I realise it wasn't QUITE arcade-accurate. 

I mean, to be fair there are other good games; Pang was always a good example of the hardware used well, but I think it's fair to say that this and the new GnG are really "pushing the limits" as Sharopolis would say. 

[norecess464]

Pang was always a good example of the hardware used well

100% agreed, that's my preferred game from the launch titles. It really felt as a true console game!

[Slype]

Very interesting information on the development of this project, I'm taking notes... ;-)

[Cwiiis]

What's your interrupt management like, and how do you deal with register and shadow register use?

I rely on the DMA-INT instead of PRI. With those interrupts, I mostly manage the screen split, the background (the blue rasters), the multiplexed rings and the end of the frame.
I never use shadow registers in the game code itself. They are reserved for interrupt code, a bit like the Amstrad firmware actually does. (credit: this was suggested to me by Overflow when I started to create the game engine).

This is interesting, how are you using the DMA-INT and how does it differ in practice to using PRI?

It sounds like your system is quite similar to the one in my current project at a high level; I also made the same choice re shadow registers - Sprite upload/properties, scroll registers, sound/music and screen splits are all managed in interrupt handlers and the game logic is designed to be interruptable and waits if it runs ahead.

I hadn't really noticed before, but that's an impressive amount of overscan you're using too, how are you managing RAM allocation, especially with that much reserved for the screen? I'm guessing that using overscan like that also prevented you from having a static split HUD, though it's not like Sonic ever had one anyway, so perhaps you didn't even consider it

I'm also interested in how you're managing scrolling with such a large screen too - I only render the rows or columns on-demand and that works pretty well, but I've picked a screen res that aligns nicely and makes the maths easier/quicker. I would guess you're using look-up tables, but maybe there's something even smarter? It must be pretty tricky updating the screen when there's both overscan *and* scrolling... Really looking forward to playing this come November!

[norecess464]

This is interesting, how are you using the DMA-INT and how does it differ in practice to using PRI?

The difference: PRI can be set only on visible parts of the screen, while a DMA interrupt can be triggered at any time in the frame. Plus, you can get 3 DMAs int per line (vs. 1 PRI per line).
This article on the wiki has been very useful to me: https://www.cpcwiki.eu/index.php/Plus_Vectored_Interrupt_Bug
Especially this line: " Put your code between &2000-&3fff, &6000-&7fff, &a000-&bfff, &e000-&ffff ", which I use and saved me many headaches I was experiencing at the very beginning of the project.
It made the interrupts working as originally intended by Amstrad.

I hadn't really noticed before, but that's an impressive amount of overscan you're using too, how are you managing RAM allocation, especially with that much reserved for the screen?

I rely on 2 VRAM pages: &0000 and &C000.
I use &4000 with ASIC deactivated for map-specific data.
&8000-&A000 for temporary RAM (gameplay variables, global variables, temp buffers, etc).
&A000-&BFFF for shared code (ZX0 unpacker, music player, DMA callbacks, etc).
The very big secret: I make a heavy use of RMR2, allowing me to use any of the first 8 ROMs as Lower ROM. The tile code (a tile is a sequence of code in the engine) gets executed from both Lower ROM and Upper ROM during the same frame.
Keep in mind that with code executed (READ) from ROM, you can still WRITE pixels into the VRAM sections.
RAM+ROM+ASIC usage -> the GX4000 is a very blessed machine regarding the storage, it's much more than just "64KB of RAM".

I'm also interested in how you're managing scrolling with such a large screen too

Well, that would deserve a complete article ahah!.. (it's too big to explain in a forum post).

I look forward playing your game too! I'm sure it will be great!

[andycadley]

The very big secret: I make a heavy use of RMR2, allowing me to use any of the first 8 ROMs as Lower ROM. The tile code (a tile is a sequence of code in the engine) gets executed from both Lower ROM and Upper ROM during the same frame.
Keep in mind that with code executed (READ) from ROM, you can still WRITE pixels into the VRAM sections.
RAM+ROM+ASIC usage -> the GX4000 is a very blessed machine regarding the storage, it's much more than just "64KB of RAM".

Really interested to hear that. I've been saying for years that getting the most out of the GX really requires making the most of RMR2 and ROM write-through to give you basically 96K of address space. Glad to see that others have thought so too.

[norecess464]

btw, if I can provide an advice -- don't get too fooled by hardware tricks as I did

With Sonic GX, I totally underestimated how long gameplay features would take to implement. That's really where your energy should go. If the game is fun, things like fullscreen will become secondary.

[dthrone]

7 years is a very long time too, how active was it being developed over that time?
For years, every Saturday morning, I've been sitting at my local coffee shop, programming for 2–3 focused hours.
My experience: the secret to long-term productivity isn't how much you get done in a single coding session -- it's how regular you are.

I think your 500 bytes an hour of finished code/data is a pretty good rate