CPCWiki forum

spectacular and very promising remake by Antony Flack:

Oh wow. Is he turning it into a complete game? 

Is that a very clever dithering of 4 colours or are there more than 4 colours (per line)?

Quote from: eto on 12:51, 10 January 23Is that a very clever dithering of 4 colours or are there more than 4 colours (per line)?

I think both. I love the UI design, it is part of the game.

Quote from: eto on 12:51, 10 January 23Is that a very clever dithering of 4 colours or are there more than 4 colours (per line)?

I was wondering about this as well. It seems, that there is black, white, light blue, red, but also yellow (the castle level).
But I think that's the monitor, and inside the game area there is no yellow, just white. Otherwise it would waste a terrible amount of rastertime.

looks lovely... great animations with many nice colors (in mode 1) & gfx.

I believe its 128kb only and for a good reason!

hm, another unknown guy comes up with a gem??

very good color usage, and fast sprites. I think the developer could think of making a cartridge version too to be able to play on 64kb CPCs too, and to optimize the sprite drawing even more.

Saw this yesterday.
Ok BJ was great on the CPC, but I wish we had superb games like this one back then.

Regarding the colours/mode 1:

It's really impressive how the CTM helps to accomplish the effect of having more than 4 colours, but I wonder how that looks in emulators, on an LCD or even on a GT65. 

Don't care how it looks on emulator or a CPC w/o using a CTM/CRT. It will be great when they will emulate the display too. :)

Hey! It's a totally impressive preview here

- the vertical-shaped resolution is obvious, perfectly fits the game design
- MODE 1 ? really ? you got me. Thanks to the dithering, I initially thought more inks were involved
- splendid pixel-based movement for the sprites (at 50hz?)

Now the flaws of the original game appears immediately obvious.

Please take your time to turn this into a great finalized game, it totally worth it :) 

This is one of the most awesome remake I've seen on this machine. And on OLD !
The 50hz sensation is thrilling, very arcade-ish.

Can't wait to play it !

Yes, there are more inks used. Listen to his videos.  :) :) :) Great to see that more coders use the power of MODE 1!  ;D ;D ;D

Never even liked playing Bombjack but I'm finding the development of this version pretty interesting from a technical viewpoint.

Quote from: GUNHED on 13:26, 12 January 23Yes, there are more inks used. Listen to his videos.

Sure, you can see ink change for the score and round.

This is fantastic, really nice work - especially impressive to see this on the stock CPC... I was kind of considering Bomb Jack for a Plus remake at some point in the future, but here's someone proving that the Plus is totally unnecessary to do a good job :)

Quote from: Cwiiis on 15:21, 12 January 23This is fantastic, really nice work - especially impressive to see this on the stock CPC... I was kind of considering Bomb Jack for a Plus remake at some point in the future, but here's someone proving that the Plus is totally unnecessary to do a good job :)

Right, the Plus is necessary to do a fantastic job.  :) So wait for the Plus version of the game.  ;)

Quote from: andycadley on 18:06, 13 January 23Although all this Plus chatter probably ought to be moved off this thread, the work here deserves the praise more than this discussion attached. @Gryzor ?

Yup will do

[EDIT] Just did, and cleaned offensive posts from all parties.

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.

And actually perhaps somebody here can help me.

I originally intended the whole game to fit into 128k, but as I continue to pack everything in I'm concerned I might not quite fit it all and don't want to sacrifice a nice animated title screen or cut back on any other fun effects like that for lack of memory, so I think I may have to acquaint myself with the disk drive. 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. And if I did that, I could add extra pictures as well. And then there's high score saving. There's definitely perks to getting the disk drive involved.

I'm a total noob at this though, and I've never tried to load a file from asm before. I'm going to need the firmware back no doubt but I nuked the firmware and dumped a screen buffer all over its jump block and the AMSDOS ram block and all its worky bits. 

That's fine, I don't need the screen buffer when I'm loading from disk, and I can restore all the firmware memory I pasted over if I stash it first. Surely somebody must have done this before though and can save me ploughing through loads of documentation. Can anybody tell me exactly what minimal memory locations I need to save/restore and what I need to call to get data on and off the disk? 

Quote from: Anthony Flack on 11:16, 16 January 23Surely somebody must have done this before though and can save me ploughing through loads of documentation. Can anybody tell me exactly what minimal memory locations I need to save/restore and what I need to call to get data on and off the disk?

This thread (https://www.cpcwiki.eu/forum/programming/game-overwrites-amsdos-can-i-re-enable-it/msg222667/#msg222667) contains Z80 assembler code to load files from disc when the firmware has been overwritten.

The areas of memory that you may, or will, need to preserve are:

• &0000-&003F - used by the firmware. If your code doesn't use this area, then you will only need to preserve the interrupt jump code from &0038-&003A.
• &ABFC-&B0FF - used by AMSDOS. The location of this area can change depending on what you specify for the highest usable byte of RAM (e.g. in BASIC, it's located from &A6FC-&ABFF). Also, if the user has installed any additional ROMs, these may reserve some RAM for themselves, so the value of &ABFC may need to be lowered.
• &B100-&BFFF - used by the firmware, AMSDOS and the stack.

You may also need to save the address of the stack pointer (SP) when you're using the firmware, and restore it once you're finished.

Brilliant. When you say the value of &ABFC may need to be lowered, is this something I need to check for in order for the game to work if you have things hanging out of the back of your CPC that I don't?

I haven't read the thread yet. I should go read the thread, maybe this is all covered. First CPC project, so learning as I go.

Hey, @Anthony Flack , welcome here, thanks for the awesome-looking remake and also thanks for the clarifications!

Quote from: Anthony Flack on 11:36, 16 January 23Brilliant. When you say the value of &ABFC may need to be lowered, is this something I need to check for in order for the game to work if you have things hanging out of the back of your CPC that I don't?

Actually, my code in the thread I linked to only initialises ROM 7, which is where AMSDOS or ParaDOS is installed. However it is possible to install other DOSes such as ROMDOS in other ROM slots, so I usually like to initialise all ROMs (using CALL &BCCB rather than CALL &BCCE).

Unfortunately I don't know of any way to check what value should be used instead of &ABFC. I tested a configuration in WinAPE that installs lots of ROMs (Protext, Prospell, Maxam, Utopia, ROMDOS) and it reserved memory from &A5FE-&B0FF, so that is an indication of how much memory you may need to copy temporarily.

I've found that if you're using the firmware functions, you also need to restore shadow registers (excluding `af) - in my game, I just avoid the firmware memory area and backup the shadow registers to allow use of firmware disk functions. (obviously only if you're using shadow registers - but I'm guessing you are :))

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.

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?

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! 

Quote from: Anthony Flack on 11:16, 16 January 23I 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 (https://github.com/einar-saukas/ZX0), then decompress them when needed. Unless they're already compressed?

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

   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


@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. ;D

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. :D

Quote from: Anthony Flack on 11:02, 16 January 23Hello, 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.

Quote from: abalore on 14:38, 16 January 23My 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.

Quote from: abalore on 21:25, 16 January 23

Quote from: BSC on 20:55, 16 January 23

Quote from: abalore on 14:38, 16 January 23My 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

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

Quote from: Prodatron on 21:50, 16 January 23Well, 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

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

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. 
 

Quote from: Jean-Marie on 13:08, 16 January 23

Quote from: Anthony Flack on 11:16, 16 January 23I 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 (https://github.com/einar-saukas/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?

Quote from: Anthony Flack on 01:16, 17 January 23Incidentally, 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.

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!).

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. 

Quote from: GUNHED on 13:50, 18 January 23After 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.

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.

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. 

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. 

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

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 ! 8)
ps. it's already pretty good in its current state

@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.

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.

Quote from: TotO on 09:46, 21 January 23@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.

Quote from: abalore on 08:27, 20 January 23

Quote from: GUNHED on 13:50, 18 January 23After 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.

Sure, and after every Cartridge-Run I do need to reinstall every ROM I use. Well, this is done quick with my ROManger - but still I do need to install FutureOS first. So honestly, the idea of running Carts is great for Gamers only, but not for Coders or who ever is using ROMs.

Targhan's code is impressive of course, but the AMSDOS file loader doesn't seem to have a corresponding save routine, and I think high score saving is the main reason I want to keep DOS open. I sure don't fancy doing a deep dive to figure it out myself, and I guess if it had more functions it would soon end up bigger than the firmware ram area anyway. 

So, firmware it is. 

Yes, I really recommend to save the firmware at #A500-#BFFF and don't use any proprietory solutions for accessing the FDC/disc drive. Today we have a lot of mass storage (SD card, USB, IDE) supporting DOS extensions like M4Board, SYMBiFACE III, UniDOS etc. It would be just great, if every new piece of software is compatible with these systems. For this you just save this area and that's it.

You also can do things a lot simpler by forgetting about managing files and write data into disc sectors directly. For instance, you can reserve last sector in disc to save high scores.

Quote from: Prodatron on 02:23, 22 January 23Yes, I really recommend to save the firmware at #A500-#BFFF and don't use any proprietory solutions for accessing the FDC/disc drive. Today we have a lot of mass storage (SD card, USB, IDE) supporting DOS extensions like M4Board, SYMBiFACE III, UniDOS etc. It would be just great, if every new piece of software is compatible with these systems. For this you just save this area and that's it.

Exactly!  :) :) :)

Looking at the firmware manual for the first time ever (I remember it was famously out of print for the longest time - it would have been nice to have in the 1980s), that part is as simple as can be. Which makes sense I guess if it's essentially BASIC without its trousers on.

If I understand correctly, if you run a binary file directly, it deactivates all the ROMs and everything has to be re-initialised before you can use the drive again. But if you load your code into memory and then call it from a small BASIC program, nothing is disturbed.

Is there any reason not to do this? 

Quote from: Anthony Flack on 23:28, 22 January 23If I understand correctly, if you run a binary file directly, it deactivates all the ROMs and everything has to be re-initialised before you can use the drive again. But if you load your code into memory and then call it from a small BASIC program, nothing is disturbed.

Is there any reason not to do this?

Using a BASIC loader means there is one more file stored on the disc. :D

Quote from: Anthony Flack on 23:28, 22 January 23But if you load your code into memory and then call it from a small BASIC program, nothing is disturbed.

You are right.
For later:
There is even the possibility to put a binary directly behind the basic code into the same file, so you only have to load the little basic program and have the binary included as well.

All right - as I prod at the CRTC like a klutz, I have another compatibility question for those that know better:

On the bonus screen between stages, I want to bring in the sides of the border on the centre part of the screen. So to have a 32 character wide screen at the top, a 20 character wide screen in the middle, and back to a 32 character wide screen at the bottom.

Without doing any kind of rupture, I was messing around with just changing the values of R1 and R2 while the screen is drawing. Changing R1 is no problem, and pulls in the right hand side border. But changing R2 to centre the image is messing with HSYNC timings and changing it midscreen causes an interesting effect... which I guess anybody who's ever messed with R2 is well aware of. 

(https://i.postimg.cc/3JN8YVsX/Border-Change.png)

Now, this should actually be completely fine for what I want, because there will only be black space on the lines where the screen skews diagonally. My CPC monitor seems to be fine with displaying this as well.

But am I doing a bad thing that will mess up on LCD screens, or make Baby Jesus cry? If so, I will have to rethink my idea.

I don't know about LCDs in general, but I did see this one video where the title screen on Sub Hunter (banging R2 for the wave effect) appeared to be messing up an OSSC.

Oh, you used the skewing behaviour as an effect? Nice.

I see what you mean with the OSSC there, but if that's the only problem that's surfaced after 11 years of Sub Hunter wiggling peoples' HSYNC, I guess it must be generally OK...

CRTC being tortured behind the scenes, before I hide it all under black ink. 

(https://i.ibb.co/F3vsqJ7/Bonus-Screen.png)

You must FIRST change R0 to 63+(32-20)/2=69.

Waiting ONE line 69 NOPs or litle more.

Set R2 to R2-6

Set  R0 to 63

org #b941
int equ $+1
jp custom_int

org &a400
.custom_int
di
push bc
push af
ld bc,&bc00
out (c),c
ld bc,&bd00+63+6
out (c),c
nop:nop:nop:nop:nop:nop:nop:nop
nop:nop:nop:nop:nop:nop:nop:nop
nop:nop:nop:nop:nop:nop:nop:nop

ld bc,&bc01
out (c),c
ld bc,&bd00+20
out (c),c

nop:nop:nop:nop:nop:nop:nop:nop
nop:nop:nop:nop:nop:nop:nop:nop
nop:nop:nop:nop:nop:nop:nop:nop

ld bc,&bc02
out (c),c
ld bc,&bd00+36
out (c),c
ld bc,&bc00
out (c),c
ld bc,&bd00+63
out (c),c

push hl
ld hl,custom_int2
ld (int),HL
pop hl

pop af
pop bc
.end_custom_int
di
EX AF,AF'
JP C,#B978
JP #B945

.custom_int2
di
push bc
push af
ld bc,&bc00
out (c),c
ld bc,&bd00+63-6
out (c),c

nop:nop:nop:nop:nop:nop:nop:nop
nop:nop:nop:nop:nop:nop:nop:nop
nop:nop:nop:nop:nop:nop:nop:nop

ld bc,&bc01
out (c),c
ld bc,&bd00+32
out (c),c

nop:nop:nop:nop:nop:nop:nop:nop
nop:nop:nop:nop:nop:nop:nop:nop

nop:nop

ld bc,&bc02
out (c),c
ld bc,&bd00+42
out (c),c
ld bc,&bc00
out (c),c
ld bc,&bd00+63
out (c),c

push hl
ld hl,custom_int
ld (int),HL
pop hl

pop af
pop bc
.end_custom_int2
di
EX AF,AF'
JP C,#B978
JP #B945

A How this work  :P

(about:invalid)

Quote from: McArti0 on 09:41, 18 March 23You must FIRST change R0 to 63+(32-20)/2=69.

Waiting ONE line 69 NOPs or litle more.

Set R2 to R2-6

Set  R0 to 63

I was wondering if there was a clean way. Those are blank lines anyway but I'll do it properly

Oh, I never got back to say, all done now: display is nice and tidy. Thanks for that McArti0

Update: 

I was so good at this when I was a little one, hope I've got some skills left when this comes out... 

This is sooo great! Super good and cool Mode 1 graphics and animations.
Seems that's the movements are very precise. 
Well done! Great to see a progress and looking forward to the sound implementation.

Just yesterday, since a long time, I checked to see if any update. ;D
This version looks really great. Fantastic work in progress. Congratulation!

Now, it is a shame when the levels colour require to use orange instead of red.
May be an idea will be to have alternative background to the Egypt one?
(that anyway do not render well in mode 1)

No way would I ever remove the Egypt background. It's Bomb Jack!

I was sure about the answer. ;D

For sure if you were doing something from scratch you could design the art specifically to look as good as possible on the CPC hardware. This is the opposite case, where the target is already decided and I just have to try to work with what is given. In some instances that has meant going to a fair bit of effort to imitate an effect that, on the original hardware, would have been really simple.

Fantastic! Great to see, that you nearly finished it!
Do you already have any idea how to implement the music and the sound fx?
Maybe using available tools like Arkos Tracker II or build it from scratch?

The arcade use the same soundchip and CPU. May be something like a register replay?
If the VGM RIP can help: https://vgmrips.net/packs/pack/bomb-jack-arcade

The same sound chip, only they used three of them... I don't think it will be too difficult to reproduce the music by ear; I played it on the guitar easily enough. What will be interesting is trying to see how much I can get away with cramming sound effects into the same channels. 

Great!

May be I'm wrong, but I think the music use one chip and the sfx the others.
You may allow to have music only, sfx only, and both together. (mixed or using sound expansion)

Arcade perfect ! Full marks.

Great work

Quote from: TotO on 16:11, 30 July 23Great!

May be I'm wrong, but I think the music use one chip and the sfx the others.
You may allow to have music only, sfx only, and both together. (mixed or using sound expansion)

I think so too. The music sounds like it can be reproduced in three channels, although they might be using extra channels in some places to make it sound more full. 

Indeed I was thinking the same thing with regards to giving people the option to have either or both. 

Quote from: Prodatron on 15:34, 30 July 23Fantastic! Great to see, that you nearly finished it!
Do you already have any idea how to implement the music and the sound fx?
Maybe using available tools like Arkos Tracker II or build it from scratch?

So far, I've not even made a single beep. But I look forward to figuring it out. I want to build something from scratch so I can understand it.

I love what you are doing  ;D

Good luck with the audio part -- doing this from scratch (cf. with no external tracker / existing audio player etc) won't be easy.

Maybe a playcity support could be considered. This hardware is perfect for such arcade port (Alcon2020...).

gameplay : https://files.fm/u/w3d6af9bf5#/view/xqgbzjaxv4

Oooh nice! :)

Looks fantastic!

That looks absolutely amazing, one of the best looking mode 1 gfx for an arcade conversions, love the use of the extra colours in the panels at the top/bottom

Nice graphics and crazy cool sound and effects.

Increbible !  Very nice ! 👍

Bravo, masterful conversion, what a wonderful use of mode 1 and rasters

Amazing work! Really great use of Mode 1 and associated screen tricks. Love it and can't wait to play!

The gameplay looks perfect, so do the graphics. And it seems to be at 50 Hz which is very rare on CPC and feels so arcade-ish.
A brilliant conversion I wish to play real soon !

WOW! You absolutely smashed it! Brilliant work and the pixel art is lovely.

Awesome really great. Are we there yet?

Unbelievable! It looks almost like the arcade version. How the did you manage to make it look so good? The music and sound effects are also top-notch. Really well done! 

Quote from: BSC on 22:52, 17 November 23How the did you manage to make it look so good?

That's a broad question, but there's quite a few interesting little touches in there I could talk about. Problems that I found fun ways to solve.

There are more than 4 colours per line in quite a few places (vertical colour splits). In several places I'm also using dithered colours but inverting the dither pattern at 50hz which disguises the dither. For example the rainbow colours at the top of the screen, and the entire background of the bonus screen. The flashing GAME OVER letters do this too.

The title page is quite complicated and ruptured in a couple of places; the top part of the screen is double-buffered, the bottom part of the screen is single buffered, and the title part itself is a six-buffered animation (animated in hardware). The colours on the title are interlaced, and the interlacing pattern also alternates at 50hz so you get the impression of more than 4 colours per line. I was quite curious as to how this was going to look and it turned out to be one of the more successful special effects I think.

For speed, I use two screen buffers and a third "clean" buffer to clear the sprites away. Many of the sprites are "compiled", ie hard-coded, and some like the P ball use self-modifying code on a hard-coded sprite to get all the different colours. Updates to the score panel are buffered and prioritised, so it doesn't try to update your score and increase your power meter on the same frame as you collect a bomb for instance, but does them one after another. It helps.

One effect which I was quite pleased with which is fairly subtle is the effect on the player when you are powered up; the arcade game cycles the player's colour palette and I can't do that so I wasn't sure what to do. In the end the player's sprite is ORed against an animated mask pattern and that did the trick nicely.

Excellent job. Thanks for describing it in details. Would sure help and encourage emerging authors/creators as well. A+++++

Pure magic! can't wait to play. Many thanks for the hard work and many hours you invested here!!

Quote from: Anthony Flack on 05:57, 18 November 23That's a broad question, but there's quite a few interesting little touches in there I could talk about. Problems that I
found fun ways to solve.

Thanks for the insights, now you made me even more curious ..

Sounds like all your tricks and solutions would convert nicely into a series of explanatory videos on YouTube :)

Quote from: Anthony Flack on 05:57, 18 November 23There are more than 4 colours per line in quite a few places (vertical colour splits). In several places I'm also using dithered colours but inverting the dither pattern at 50hz which disguises the dither. For example the rainbow colours at the top of the screen, and the entire background of the bonus screen. The flashing GAME OVER letters do this too.

Regarding dithering and colors, did you use inks 0, 2, 15 and 25 for the game area in level 1? At least it looks like it. I made a quick experiment, see screenshot. I think dithering in Mode 1 is quite useful.

edit: I changed my guess from ink 11 to 2 and replaced the screenshot.

You were right the first time, it's ink 11 in stage 1.

Great work ! WIP on good way :)

I wonder how this great project is proceeding.

Yes! I'm very sorry it isn't done yet. 

It has been nearly finished all year, but I have been busier with my work this year so progress is slower. I've been trying to do a few hours every Sunday to get it finished before year's end in time for the 40th anniversary of the CPC and Bomb Jack. I do enjoy it and would work on it all day if I could. 

I feel a bit guilty because the game is fully playable and I have meanwhile been playing it all year, it's great! Sorry for the wait, if you like Bomb Jack it will be worth it. I have slowly been adding the final bits of polish, front end menu, difficulty balancing, high score saving and various other details that I need to call it properly finished. It's getting close now. 

Don't worry about us man, it's just great it's still progressing no matter how slowly!

I'm really keen to share it. And give myself permission to start a new game :)

It's not always glamorous but sometimes you have to make a pause menu...

(https://i.imgur.com/X5lr6gn.jpeg)

Or a high score name entry screen

(https://i.imgur.com/ZqSSPNW.jpeg)

Hi Anthony! Great piece of work so far. Feel motivated to finish this super awesome game. It's one of the very very few to show the power of CPC MODE 1.  :) :) :) :) :) :) :) :) :)

Quote from: Anthony Flack on 11:34, 23 July 24I'm really keen to share it. And give myself permission to start a new game :)

Maybe a single screen game like Snow Bros or Rodland now that you have that killer engine?  ;D

I hope this venture would end up with a physical release ;)

Quote from: Anthony Flack on 10:08, 23 July 24Yes! I'm very sorry it isn't done yet. 

It's always a huge amount of work or just a big mess to finish the last 5% of a project.
For Bomb Jack you probably recognized, that your project will be really cool, so you just want to have it as perfect as possible. And this makes the last 5% even harder...

@Anthony Flack - You don't owe us an apology for delays.

We're waiting over five years for Vapourtino... personal life comes first.
At least you're cluing us in with relevant updates. :)

From what I'm seeing here, this Bomb Jack upgrade is gonna be worth it. :D

Quote from: Anthony Flack on 13:24, 23 July 24It's not always glamorous but sometimes you have to make a pause menu...

(https://i.imgur.com/X5lr6gn.jpeg)

Or a high score name entry screen

(https://i.imgur.com/ZqSSPNW.jpeg)

Impressive pause menu, that's a lot of work to get the additional pink/red colour for the Restart/Quit text, very nice

Quote from: Prodatron on 22:10, 23 July 24

Quote from: Anthony Flack on 10:08, 23 July 24Yes! I'm very sorry it isn't done yet. 

It's always a huge amount of work or just a big mess to finish the last 5% of a project.
For Bomb Jack you probably recognized, that your project will be really cool, so you just want to have it as perfect as possible. And this makes the last 5% even harder...

There's an old joke in game dev with more than a little bit of truth in it in my experience
The first 90% of the game takes 90% of the time.
The final 10% of the game takes the other 90% of the time.

You're exactly right, it's all starting to get a bit messier and hackier especially as I get close to the memory limit, but it's all going to fit (just). And the game itself has turned out great, so I want all the presentation to be as nice as can be.

Quote from: lmimmfn on 10:13, 24 July 24

Quote from: Anthony Flack on 13:24, 23 July 24It's not always glamorous but sometimes you have to make a pause menu...

Impressive pause menu, that's a lot of work to get the additional pink/red colour for the Restart/Quit text, very nice

If you like raster split colour effects, there's plenty more of that.

The nice thing about doing the menu like this it becomes trivial to have the text colour change as you make your selection. I don't have to redraw anything, just change the ink numbers, so it's easy. And the CPU has nothing better to do anyway, since the game is paused, so why not. I resisted the urge to put colour gradients or anything too ostentatious on the text because it's not in the style of the game, but it's nice to get a little bit of extra colour in there when I can.

Quote from: Anthony Flack on 22:41, 24 July 24

Quote from: lmimmfn on 10:13, 24 July 24

Quote from: Anthony Flack on 13:24, 23 July 24It's not always glamorous but sometimes you have to make a pause menu...

Impressive pause menu, that's a lot of work to get the additional pink/red colour for the Restart/Quit text, very nice

If you like raster split colour effects, there's plenty more of that.

The nice thing about doing the menu like this it becomes trivial to have the text colour change as you make your selection. I don't have to redraw anything, just change the ink numbers, so it's easy. And the CPU has nothing better to do anyway, since the game is paused, so why not. I resisted the urge to put colour gradients or anything too ostentatious on the text because it's not in the style of the game, but it's nice to get a little bit of extra colour in there when I can.

Ahh yeah, I can see the split masters at the top and bottom and I take it cpu is providing extra colours at the bottom one?

It's just very impressive to see the extra colour in the window of the pause screen, I don't think I've seen that in any game back then? and just seen it in demo's since. I realise it's not that difficult and counting cpu cycles but it's very impressive to see it in a game and you've made excellent use of mode 1 already with split rasters. 
It's those small touches/attention to detail that really add to the game experience, great work so far!!!

There's one screen which I won't spoil yet, where I push this technique as far as I can. I'm just curious to see how it will look so I have to try these things. 

There is only one 80s game that I can think of that used vertical colour splits, and that is the "Naughtyometer" in Jack The Nipper and it looks really nice. It's too bad coders weren't more adventurous with vertical splits back then, since there's no secret to it. It's true that it's easier to get the timing right with an emulator, but it's still nothing compared to what people were already doing with the Atari 2600.

I'm relieved that the title worked as well as it did, as that one was quite a puzzle to figure out. Again it is inspired by the Atari 2600, specifically the awesome homebrew port of Juno First. 

Quote from: Anthony Flack on 01:06, 25 July 24There is only one 80s game that I can think of that used vertical colour splits, and that is the "Naughtyometer" in Jack The Nipper and it looks really nice. It's too bad coders weren't more adventurous with vertical splits back then, since there's no secret to it. 

Are they raster splits? I'd honestly just assumed the screen was switched to Mode 0 for the bottom few lines, it would've seemed an easier way to pull off the same trick.

Looks very cool in your Bombjack though. And so subtle I didn't even notice it at first, which somehow makes it more impressive than if it were screaming out "look how clever my demo effects are"  :laugh:

Quote from: andycadley on 07:36, 25 July 24

Quote from: Anthony Flack on 01:06, 25 July 24There is only one 80s game that I can think of that used vertical colour splits, and that is the "Naughtyometer" in Jack The Nipper and it looks really nice. It's too bad coders weren't more adventurous with vertical splits back then, since there's no secret to it.

Are they raster splits? I'd honestly just assumed the screen was switched to Mode 0 for the bottom few lines, it would've seemed an easier way to pull off the same trick.

I had a look and I think it's actually impossible to tell either way just by looking. I assumed they were just banging the colour change because the bands look like about the right width for that, and it's only a few scanlines tall so it would be doable. But maybe.

A little update since I think I may have rashly said this would be done by Christmas and I think it probably won't. Because it is already upon us, and I just don't have much time at the moment. 

The game is essentially finished, except for a couple of minor timing glitches I have to straighten out, and one really annoying bug that crashes the game but not immediately, and is rare enough I don't know what set of circumstances triggers it. I don't want that ruining somebody's high score. After that I want to compress everything so it loads faster, and then I just need to write the readme file, set up the itch.io page and all that stuff which still will take a bit of time. 

I sorted out the problem I was having with the M4 which actually seems to be a WinAPE bug. The compiler was corrupting the last letter of the filenames and AMSDOS didn't seem to mind, but the M4 did. I don't know if this problem sounds familiar to anybody. Anyway having fixed the filenames, it runs great on the M4 now, loads super fast and saves high scores no problem. 

I have also included a little BASIC utility that lets you backup and restore all your high score tables. You can also use it to merge two save files together, if you want to combine your high scores with a friend's. Or, if you don't have a friend, between all your computers. I don't know if anybody will use it, but it's been good for testing anyway. 

about the 'last letter problem' it may be a wrong usage of directive

defb 'mytext' will output 'mytext'

whereas

str 'mytext' will add #80 to the last char, as expected ;D

I can be a secret beta tester. 8)

Quote from: Anthony Flack on 02:46, 13 December 24A little update since I think I may have rashly said this would be done by Christmas and I think it probably won't. Because it is already upon us, and I just don't have much time at the moment.

The game is essentially finished, except for a couple of minor timing glitches I have to straighten out, and one really annoying bug that crashes the game but not immediately, and is rare enough I don't know what set of circumstances triggers it. I don't want that ruining somebody's high score. After that I want to compress everything so it loads faster, and then I just need to write the readme file, set up the itch.io page and all that stuff which still will take a bit of time.

I sorted out the problem I was having with the M4 which actually seems to be a WinAPE bug. The compiler was corrupting the last letter of the filenames and AMSDOS didn't seem to mind, but the M4 did. I don't know if this problem sounds familiar to anybody. Anyway having fixed the filenames, it runs great on the M4 now, loads super fast and saves high scores no problem.

I have also included a little BASIC utility that lets you backup and restore all your high score tables. You can also use it to merge two save files together, if you want to combine your high scores with a friend's. Or, if you don't have a friend, between all your computers. I don't know if anybody will use it, but it's been good for testing anyway.

If you need help investigating the crash I'm ready. I also use WinAPE for development and I can sign a NDA if required

Quote from: roudoudou on 09:08, 13 December 24about the 'last letter problem' it may be a wrong usage of directive

defb 'mytext' will output 'mytext'

whereas

str 'mytext' will add #80 to the last char, as expected ;D

That would be it, which I guess means the example code I used was wrong too, but still works in AMSDOS and I only found it when trying to run on the M4. I assume the high byte is meant to be used as a string terminator then.

I meant the high bit, of course...

Quote from: Anthony Flack on 00:39, 14 December 24I meant the high bit, of course...

the bug description you provided is incomplete, because...

the high-bit has a meaning in AMSDOS (and has nothing related with terminator)

on the extension, it could mean "protected file" or "hidden file". So your bug may occur (or not) depending on the filename length :D

there is no terminator with Amsdos names because they must be always 8+3 byte long, not shorter, not longer

Quote from: Anthony Flack on 00:39, 14 December 24I meant the high bit, of course...

Are you using "cas in open" bc77 and the assembler directive that sets bit 7 for end of string and passing the correct length to cas in open and with amsdos it works but not on M4? If so it's not something that is documented so Im not surprised the M4 has a problem. 

Please also provide a link to the example. I hope it wasn't one of mine  :laugh:

I'm really not sure where I even dug the example up from now! Since it was a couple of years ago.

But yeah I am using cas in open and passing the correct length in b, I didn't know that the str assembler directive set bit 7 until I actually looked in memory (!) as I don't use the str directive anywhere else. Sorry I said bug when it was me not appreciating the difference between a str and a defb in the assembler; I am getting by on some basic knowledge of how a Z80 works and the general principle that programming is programming...

And yeah the thing that threw me was, it all seems to work fine in AMSDOS, so I never noticed the problem until I tried it on the M4. And it works fine on the M4 as a .dsk, just not as a directory. I had always assumed it was probably a problem with the way I was removing the firmware and then restoring it. But then when I actually wrote something to test the M4, the problem was obvious.

I guess the upshot is, I don't know the difference between a str and a defb, AMSDOS masks bit 7 so it makes no difference there, but the M4 file system doesn't. And if I had an M4 back when I started, I probably would have noticed right away.

Please go on with your great work!!! It will be one of the very few real jewels in CPC world!  :) :) :)

Don't give up. Your project is awesome.

I have had the pleasure of playing this... and it's GOOD! Preview coming soon to Retro Gamer...

Hey Anthony,

Just wanna say, don't quit on this. Your work looks awesome.
Take all the time you need.

People are still gushing over Vapourtino and that's nearly six years on the go.

You got this. :D

I do, not much longer now. Thanks for your patience. 

Quote from: Anthony Flack on 01:38, 12 February 25I do, not much longer now. Thanks for your patience.

Awesome!!! It will be one of the very best games ever!!!  :) :) :)

Hi @Anthony Flack , Game Will be released tonight ?

Quote from: XeNoMoRPH on 15:37, 07 March 25Hi @Anthony Flack , Game Will be released tonight ?

It's showing as being on tonight's Amstream, so fingers crossed!  :D

Yes, if all goes to plan the game will be out in a couple of hours.

Get it here:

https://anthonyflack.itch.io/bomb-jack-extra-sugar

I got it before your post here   ;D

Thank you!

Quote from: Anthony Flack on 22:50, 07 March 25Get it here:

https://anthonyflack.itch.io/bomb-jack-extra-sugar

Thank you so much for all your hard work, Anthony. This game is absolutely amazing, really pushes the limits of the CPC, and massively raises the bar! :D

@Anthony Flack , you need to correct this line for 464 users. Otherwise, it will crash.
org &4045
;;ld hl,&b941
ld hl,&B939
ld (&0039),hl
Congratz by the way!

Haha do I need to do an update already? I don't have an original 464 to test on. Let me sort that then. 

Rather than having to rebuild everything, I just added a line to the basic loader:

181 POKE &4046,PEEK(&39)

I think that should do the trick

I have updated the itch page with an updated version that patches in the above poke; let me know if that doesn't work for anyone. 

@Anthony Flack ,
I noticed the date I put the first post when I discovered the game, January 10, 2023, and the game was released yesterday March 7, 2025, more than 2 years of development, and when you showed it for the first time, you should have already been there for a long time.
The truth is that the wait has been worth it, congratulations... are you planning to do the same with any other title? ... are you going to continue programming for the CPC?

Of course I have ideas for more CPC games, but I have some commercial projects I need to focus 100% on for a while.

Finishing was slow mostly because I was busy with other things, but I'm sure I could work much faster on a future project and it would probably be an original game next time.

Purchased and after playing it I think it's the best 8 bit conversion from the arcade between C64, Spectrum and old CPC version.

Really an excellent version of Bomb Jack with extra features.

Just got to play it. Love it! looks so much better on a real crt. 
Guys, play on real hardware!

Wow. This is a love letter to Mode 1! Amazing job @Anthony Flack and thank you!!

Great!  Great!  Great!  Great!  Great!  Great!  Great!  Great!  Great! work!!!  :) :) :) :) :) :) :)

Just checked it out this evening.
It's really great. :)
With all respect to the arcade original and much love to the CPC showing all the details in the fantastic use of mode 1.

Graphics, sprites, sound, details and all the small extras are making an outstanding CPC game.
Thank you, Anthony.

The only thing I can say is fantastic... since yesterday I can't play anything else but this game, on emulator, on original hardware, everywhere I can't help but play "Bomb Jack Extra Sugar"... Thanks to Anthony for this fantastic pearl that will be talked about for a long time in this 2025 (and beyond).

My modest contribution was to make another video on the Remix Mode that I'm also sending you here. I used the invincibility cheat, I know I shouldn't have, but I was too curious to see the new levels! :P

Thanks again Anthony! 

Hello!

I played the game on real hardware, and it's a blast. I love the details -- it's very well done. Congratulations!

I can tell when a game is perfect: it's one that you know you'll launch and relaunch multiple times. And this new Bomb Jack is one of them! 8)

Also, thank you. It was a pleasure to follow the development of your game over the years. The result is truly impressive, especially considering it's your first real project on the Amstrad CPC. I'm really looking forward to see what your next project will be -- or not, which would be perfectly fine too! (Enjoy your well-deserved vacation now!)

Again, thanks!

my girl likes it!

(https://i.postimg.cc/bG0MwMgS/alice-Bomb-Jack.jpg) (https://postimg.cc/bG0MwMgS)

Absolutely fantastic game. It's so accurate I can only play it with an arcade controller.

Amazing work, technically, gameplay-wise, graphically. This is so close to the original arcade game. Bombjack is part of the very first arcade games I discovered back in the days and it's so heart warming to see and hear again about this game. All the feelings are back and for that a very big thank you !

I'm really impressed. The classic CPC version was one of my favorites, but this one is superior in every way. Thanks for the talent and effort put into making this game!!

Here they even praise old version,
https://lemmy.world/post/3866272
and in the meantime...
Great improvement. :)

@Anthony Flack I played Bombjack yesterday. Lots of content, options, game modes, very arcade looks and sounds. I have a really enjoyed to play and replay like children. Last but not least, some nice display tricks that are well highlighted. I think this is the best arcade conversion done on CPC to date. Congratulations, you are the best surprise of the last few years!

OMG what a f**ing cool implementation for the CPC! You really have to play it on real hardware, like I did it right now!
@Anthony Flack : This is such a great work, my biggest respect! (I was a CPC Bomb Jack maniac in the past)
With all the details around and the screen format the original arcarde feeling is just awesome!

so cool :)

I always thought that Mode 1 was treated unfairly because of all those crappy ZX ports. The CPC suffered somehow from the same problem that Amiga did with a lot of ST ports (even the ST games were not taking advantage of the 16bit h/w). Wec Le Mans was a proof that Mode 1 games can be good. Now this. Together with Amiga's Bombjack Beer Edition are the best version of the game, one for 16bit, one for 8bit. I cannot find anything wrong in this new CPC version. It's flawless. Perfect.

Properly made graphics in MODE 1 have 10 colors, not 4. Because there are so many unique combinations of two colors meeting in neighboring pixels that merge on CRT. Just look at Jill Lawson's work. And Anthony  use it perfect. :)

But a few years ago I read an interview with a programmer from Ocean (I don't remember his name, the one with long hair), who told what it was like to make a port from Arcade to ZX and CPC in '84-85. They would get a game machine in their room, and graphic designer and programmer had 2-3 months to make a port to ZX, first they had to play the game and take pictures by camera, sometimes they would film VHS. One would make pixels, other would write code. When they were done, the graphic designer would get another job, but coder had two weeks to made CPC port. There were much fewer CPC owners than ZX owners at that time, so it wasn't worth for company to spend more time on it. There was no one to improve graphics, and if someone didn't like it, they could buy another computer. If someone was rich, they bough some 16bit back then and to this day believe that all CPC games were uglier than Spectrum games. Meanwhile, 2/3 of CPC games have wide pixels like C64, or use MODE 1 with dithering or have different palettes in several areas of screen, and they don't look worse than on ZX. :)

Absolutely gorgeous. Plays beautifully, even if i'm not that good at it!

Definitely one I'm going to go back to, for sure.

Bought a copy and had a very brief go this morning. It's seriously impressive and absolutely shows what can be done in Mode 1 when you aren't just recolouring Speccy graphics. And it seems to play very well too, although I'd be the first to admit I've always been terrible at Bomb Jack.

Bought it, played it on a real CPC. What a treat! There are so much details everywhere, it's impressive! And the gameplay is also perfect! But it's waaaayyy harder than the original CPC version, probably due to the smaller screen (I managed to get to level 6 though while collecting almost all the sparking bombs on my first try, not so bad).

The graphics are quite spectacular, and sound is very good too! Thanks a lot for your effort!

The sound is all thanks to you my friend. I thought it would be a big job - and it probably would have been too, but then I downloaded Arkos Tracker 2 and it was all done in a day. So easy to use - we are spoiled.

I can tell you why it's harder - the original CPC version had only five enemies at most, but now it goes up as high as nine. 

Is it  invincibility cheat  is one of option?

Yes, invincibility or infinite lives, in options. 

Quote from: Anthony Flack on 02:57, 12 March 25I can tell you why it's harder - the original CPC version had only five enemies at most, but now it goes up as high as nine.

We had discussion at a mini-meeting about the difficulty, because we found the easy mode not that easy and... hard ^_^

Is the easy mode based on arcade code/mode ? Or easy mode based on your feelings (of a guy coding the game since many years and cannot realize what is hard or easy)  ;D

Each difficulty setting changes the enemy sequence you get, which follows the pattern of the arcade if you mess with the dip switches.

As well as that, for easy I slowed the rate that the enemies speed up, I delayed when the second bird arrives, I think I also removed one enemy entirely, and also made bonus lives come more often. I was concerned that people might find easy to still not be easy enough, but I didn't want to take away too much.

I think easy should be easier than the easiest setting of the arcade game, but that doesn't mean a mummy won't still land on your head. I don't think I've made it harder than the arcade, I think it's a little softer overall, but the arcade game was always quite tough. 

On CRT it looks and plays just like the arcade. So fun!

(https://i.ibb.co/Kg2myYq/bombcrt.jpg) (https://ibb.co/CybW0q7)

I love the title screen. The best on CPC. The Bomb Jack logo is just amazing! :o

Quote from: Anthony Flack on 02:57, 12 March 25The sound is all thanks to you my friend. I thought it would be a big job - and it probably would have been too, but then I downloaded Arkos Tracker 2 and it was all done in a day. So easy to use - we are spoiled.

Thank you :). Well, it's very satisfying to see production using my software, especially masterpieces like yours!

What a great mode 1 game. Such fluid movements and so many colours in mode 1 I've never seen in a game before.
Never thought that a CPC can do this. Looks and feels really like an arcade.

I only saw screenshots and videos yet and it looks fantastic! I want to buy and download it soon and try it on a real CPC since I was a hard core Bomb Jack fan back when it was only available on arcade. Anthony's version looks so much like it! <3

Am I the only one stuck on stage 5? I cannot reach the top bombs...

Push up to do a high jump. 

Superb achievement <3
Congratulations !

I rarely write anything here in the forum, although I often read along. But I just have to say how great this remake is. High praise, simply fantastic!

Last weekend I attended the Mittwinter Meeting 2025 and my Girlfriend played the new MODE 1 Bomb Jack there quite some time and enjoyed it very much. It was one of her first CPC games she played.  :) :) :)