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 :)