Bomb Jack remake

[Anthony Flack]

Gotcha, so I could just save out that whole chunk of memory if I want to be extra safe. Or maybe just lowering it a bit would be reasonable. Either way it's good to know that can happen.

[andycadley]

If I'm understanding correctly, it's only if you care about the contents, right? Initializing AMSDOS (or other ROMs) will cause them to allocate some storage here and set it's contents with appropriate default values.

If you just have a big, trashable buffer there you shouldn't have to worry, right?

[Anthony Flack]

That whole 16k bank is a totally trashable buffer in-between stages, yes. If all I have to do is &BCCB to make all that memory good then yeah I can and will ignore it! 

[Jean-Marie]

I could free up 20k of RAM right now if I loaded the background images off the disk instead of having them squatting in memory all the time.

You can have the background images compressed in memory, using for example ZX0, then decompress them when needed. Unless they're already compressed?

[roudoudou]

Here is a loader from Ast
you must adapt drive backup in your programm, then it's easy to restore when you want to load later

Code Select Expand

   org #a000
;
; Loader with Rom 7 init (Amsdos)
; ----AsT/iMPact 2018
;
   ent $

   ld hl,(#be7d); get current drive in A
   ld a,(hl)
    push af
   ld c,7 ; init rom 7
   ld de,#40
   ld hl,#abff
   call #bcce
    pop af
   ld hl,(#be7d) ; put drive back
   ld (hl),a
;
   ld b,finname-name
   ld hl,name ; nom du fichier a charger
   ld de,#c000 ; buffer
    call #bc77
   ld hl,#c000 ; start
   call #bc83
   jp #bc7a

name db "sid.bin"
finname


[TotO]

@Anthony Flack Welcome to cpcwiki!

We have a little exchanged on youtube. Congratulation for your project.
I'm happy to have found your colour palette by doing a mockup using bright yellow and blue.

I'm sure you will find some help here form people like @abalore or @roudoudou for your technical issue.
EDIT: Oups, I have not seen the next page before posting.

[abalore]

Hello, I am the author of the Bomb Jack port/idiot in the video.

To answer the question about colours, in the main play area I am using 0 (black), 25 (light yellow), and depending on the level, either 11 or 14 (sky blue/violet), and 6 or 15 (red/orange).

Light yellow looks like light grey, almost white when it is put next to a sky blue pixel. 14 and 15 together make a nice medium grey. On a real CPC monitor, the pixels smear into the CRT dots and you can create many combinations of colours that don't even look like dithers. The classic Amstrad colours, the secondary colours like purple and orange, pink and lime create the best effects because they have a little bit of R, G and B so they light up all the phosphors. Also they are the colours that will dither beyond the CPC palette, whereas primary colours only dither into secondary colours. I really like some of the softer colours you can find in dithers; it takes the edge off the CPC's acid trip palette a little.

Here, I am limited by trying to recreate Bomb Jack, but that's the challenge. The overall effect still works on LCD I think, although you can obviously see more clearly how it is done. My main priority is looking good on the original CPC monitor.

Actually, my main priority is to try to get the gameplay accurate, but doing some nice Mode 1 graphics is a bonus. In general I have tried to use mostly dithered colour in the background (avoiding using pixels of the same colour next to each other), which helps the sprites to stand out. Also using 4-colour masked sprites rather than three colours plus transparent makes a big difference in Mode 1 I think.

I have also long thought that the Plus machine would be an excellent candidate for a faithful port of Bomb Jack. The sprite specs seem almost made for it, and of course the colours. But I don't have a Plus machine, so I did this instead. And it turns out the regular CPC ought to be, just about, fast enough to do a faithful port, hopefully. All the collisions are in now, and that wasn't much of a speed hit.

It makes a big difference IMO to hit 50hz and see the sprites appear to glide over the background like proper hardware sprites.

Hello! You are doing a great work!

My suggestion is that you make a cartridge game, compatible with all systems. You'll be able to have a lot more content, instant load and no disk management.

You can do it in a standard cartridge format to run in my Plus2CPC and Play2CPC expansions.

[BSC]

My suggestion is that you make a cartridge game, compatible with all systems.

How is that compatible with a CPC without the according add-on?

Regarding memory @Anthony Flack : If you target a 128k machine and will not be using all of its memory, you could use one of the additional memory banks (&4000 to $7fff) as buffer area and leave the firmware and Amsdos jump blocks etc just as they are. No restore needed, just use everything as-is. You could even use the screen memory as a buffer area. Hiding your buffers could be done by means of colours or the CRTC (e.g. setting screen height to zero chars). What I am trying to say: If you are loading things from disk anyways, you don't have to have all assets in memory at all times, potentially freeing enough RAM to leave "the system" intact.

[abalore]

My suggestion is that you make a cartridge game, compatible with all systems.

How is that compatible with a CPC without the according add-on?

A game for 128K is only compatible for one of the three CPC models. And one of the two plus models.

A cartridge game runs in a vanilla Plus, and in all CPCs with adapter, and also in the unmodified GX4000

[Prodatron]

Well, I don't think that there are more C4CPC adapters around than 6128 + 464 with memory expansions.

[abalore]

Well, I don't think that there are more C4CPC adapters around than 6128 + 464 with memory expansions.

You also have homebrew cartridges, many people here manufacture them. Also, the 464 and 664 users would need also the DDI expansion and Floppy Drive

[abalore]

By the way, the cartriges can be run also in a M4 board

[Anthony Flack]

I don't have any capacity to play cartridge games. I have a stock 6128. Converting to cartridge is perhaps a job for later. It seems like a waste to release a cartridge game without Plus features though. Perhaps a Plus version and a non-Plus version could both fit on the cart.


The reason the buffer area is not at &4000-&7fff is because that is the one ram bank that you can swap any of the extra ram banks into. I have swappable code and graphics in there and they need to be able to write to either &8000 or &c000, depending on which is currently the back buffer.

Given the limited ways that you can swap the extra RAM in and out, this seemed like the best way to ensure that everything fits together. I could probably put the firmware stuff into bank 5, and do a C2 bank switch to restore it, but I guess copying a few K of memory from somewhere else is only going to make the load slower by maybe one frame, anyway. 
 

[Anthony Flack]

I could free up 20k of RAM right now if I loaded the background images off the disk instead of having them squatting in memory all the time.

You can have the background images compressed in memory, using for example ZX0, then decompress them when needed. Unless they're already compressed?

They are cut into tiles, so 5 images currently occupies 20k.

I thought about adding extra compression, but figured it would only claw back a few extra K at best. Loading from disk would free it all, including potentially the code to draw it. Because the data could be loaded into a buffer, executed and then trashed.

Still, it is nice to have it all in memory at once with no disk access. I'm not in a rush to change everything over just yet. But it would be fun to add some extra pictures, and it seems like high score saving is a must, and I'll need disk access if I want that.

Incidentally, is there any nonvolatile RAM you can save high scores to on a cartridge? Or would you just keep a spare disk for all your cartridge save files?

[abalore]

Incidentally, is there any nonvolatile RAM you can save high scores to on a cartridge? Or would you just keep a spare disk for all your cartridge save files?

We use rewritable cartridges for Alcon2020, we save scores and settings. Or the whole cartridge can be updated to a new game version or to a different game.

But only when used along with the Play2CPC expansion. In normal Plus cartridge slots they are just read-only.

[GUNHED]

Buffering the system area has the advantage to be able to work with anything else than only drive A. Examples are B drives, B drives with bigger formats, hard-discs, RAM discs, modern mass media.

Regarding the Cartridge format... I understand that people want to push their projects. But most of the users imho own a CPC6128. So to target the stock CPC6128 first would make sense. After the stock CPC6128 it would be the same computer with ROM expansion (f.e. the M4 expansion sold over 1000 times!).

[Anthony Flack]

Yes I'm not against the idea and actually would like to try a cart/rom version that will work in 64k, and a Plus-enhanced version that might be able to run in 64k even from disk, but I'd have to buy some more hardware first, so I'm starting with the system I currently own myself. It was good enough for Orion Prime.

It's something to keep in mind when placing self-modifying code.

When you say buffering the system area, do you mean I should copy and restore the whole (estimated) rom area as well, rather than re-initialising the roms every disk access?

Sorry, I've never stick a rom in a CPC ever. Just trying to get a handle on how much of the system area needs to be copied and restored, and how much of it only needs to be made available. 

[abalore]

After the stock CPC6128 it would be the same computer with ROM expansion (f.e. the M4 expansion sold over 1000 times!).

FYI , the M4 can run cartridge images.

[TotO]

As I understand, Bombjack currently looks very promising but lack of memory. So, to push the project further it is instesting to think about ROM / Cartridge as that allow to play on all systems while the users own a device (or emulators) to read ROM or CPR files.

[Anthony Flack]

I am going to begin by writing a game that I myself can play on my own CPC, which is an ordinary 6128 with no cartridge slot. After that we will see. 

[Anthony Flack]

I should clarify: I'm not in danger of running out of operating memory. Not on the 6128 anyway. So there's no problem that will sink the project. 

I was just trying to decide whether to try to pack everything into one load. At first I was going to but now I think, hmm maybe nah.

It's not a matter of whether the game will work, but things like whether the title page logo gets to be animated. 

[norecess464]

@Anthony Flack I'm probably wrong with this answer, so please take the following with a grain of salt

I'm under the impression than your remake could fit in a regular Amstrad CPC 6128 with a single load and no extra use of ROM storage.

Few points of investigation:

- What is the result if you pack separately the complete background images / unpack them to screen when necessary ?
- Code section sometimes can take lots of memory, maybe you could try unpacking some parts of code/data "on demand", cf. menu code, game code, etc.
- If it's not done yet, maybe you can save some additional space by generating the sprite left/right at level startup?
- Sometimes, bitfields (for enemy statuses etc) can be better approach vs. an array of bytes
- If you don't plan using disc accesses, you can eventually remove the firmware code + redirect interrupts, and free the RAM between &A500+ to &C000 for your own usage. Even in that case, please take note it's still possible to read a file without the firmware (cf. FDC Tools from @Targhan : http://www.julien-nevo.com/arkos/fdc-tools/)
- Maybe what is blocking you, is the memory schema when using the extra 64Kb of the Amstrad CPC 6128 ? : I would strongly suggest to learn about &C1, &C2, &C3 banking modes if you are not aware of them
- Since your remake is 50hz-based, do you need page flipping (2 screen buffers) at all ? MAYBE you can sort the sprites vertically to restore background+redraw them at new position before they get displayed on the monitor ?
- Think about another approach ? Often with 8-Bit programming, there are multiple solutions for the same problem.

Good luck ! It's a very exciting project you get there. And please continue to share your progress !
ps. it's already pretty good in its current state

[TotO]

@Anthony Flack Thank you for the clarification. Sure, it is great if you can run it on a stock CPC 6128. I thought that you were worried because 20K left, while it is always a prototype of the game engine and the display performance for all the sprites.

[Anthony Flack]

Interesting... I haven't thought to try running the complete images through compression.

I think saving the high scores is desirable enough to want to re-enable disk access even without any loading. I'll have a look at that link too, is it easy to use?

For anything in the main loop, it's good to be able to optimise for speed, because I need it. This includes not trying to do anything clever with a single-buffered screen. Not just the sorting but the erasing, overlapping rectangles, sprites piling up in the same region of the screen... I figure the ability to do a nice clean hardware double buffer is one of the rare blessings granted to the CPC by the hardware gods and I will accept their blessing, this time anyway.

[Anthony Flack]

@Anthony Flack Thank you for the clarification. Sure, it is great if you can run it on a stock CPC 6128. I thought that you were worried because 20K left, while it is always a prototype of the game engine and the display performance for all the sprites.

The main game itself is mostly in, all the enemy sprites including some not yet shown, collisions are all done although bombs don't get removed yet, type and display panel is mostly done. You can cycle through all 63 stages. I love games of this era - nice compact amount of content. 

Memory isn't quite tight exactly, but I'm cautious as I plan out the remaining moves... something for the DOS, something for the music data, menus and transitions, title screen, win/lose animations, some more showoff screen effects, extra game modes, and the immediate question of whether I should draw this POW coin that has to appear in seven different colours in a more memory-efficient or speed-efficient way... all the graphics have been done, not quite all are encoded yet.