News:

Printed Amstrad Addict magazine announced, check it out here!

Main Menu

Re: Bomb Jack remake [Plus offshoot discussion split]

Started by TotO, 18:44, 12 January 23

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

Cwiiis

Quote from: rexbeng on 10:59, 17 January 23Would EGX work (edit: in the case of using it in a game such as Bomb Jack) on Plus though?

That's a nice idea and feasible I think - given Anthony's current Bomb Jack runs all the game logic before the raster hits the playfield, presumably the time the CPC version spends shifting sprites around could be spent on an EGX playfield instead.

TotO

Quote from: andycadley on 10:44, 17 January 2316 colours in Mode 1 would have required a 32K display, which would have been a strain on a 4Mhz CPU
Not a problem if just to display a background and put sprites over it. (Pang, Puzzled, Panza, ...)
"You make one mistake in your life and the internet will never let you live it down" (Keith Goodyer)

TotO

@Cwiiis I have though about EGX, but is will kill all the CPU just to display the background.
"You make one mistake in your life and the internet will never let you live it down" (Keith Goodyer)

abalore

The MSX2 version is nice, but it's missing some stuff for no reason. It's missing the points when you pick a bomb and the special effects when picking a power up or killing an enemy.

Anthony Flack

The MSX version seems to have missed that the POW coin is meant to change colour. It can be worth up to 10,000 points if you pick it up at the right time. But not here I guess. The new Amiga version gets this right but then has the POW coin start on the wrong colour, so it starts with the second highest value rather than the lowest.

Little details, but no reason not to get it right. This stuff I think is more important than the graphics. 

Contrarily, I have thought it would have been great if the CPC had a nice double scanline mode. Square pixel mode 0. Super chunky yes, but twice as fast. You could do a full overscan screen in just 10k. You could also do Pico-8 resolution (128x128x16) really easily. 

Anthony Flack

I imagine a Plus version of Bomb Jack would still have to spend a fair amount of time spoon-feeding the ASIC with sprite data for the next frame, so it wouldn't quite be a free ride with the sprites. The logic is not complex and doesn't take much time. Although I still haven't seen anybody get the bird to behave like the arcade one does. 

TotO

With a "MODE 3" in 128x128 it would have been possible to display 16/256 colors in 8/16K (DOOM for GX/Plus). But considering the past of the CPC, it would have been preferable to have a "256x256" with color attributes for the Spectrum ports... And especially a linear addressing of the screen.
"You make one mistake in your life and the internet will never let you live it down" (Keith Goodyer)

abalore

I think in 128 x 256 with wide pixels and Plus palette you can do pretty decent backgrounds.

Yes, the pixel size will be different from foreground, but you can consider it as a "deep of field" effect, which makes the background slightly blurred. I think the result can be good.

abalore

Quote from: Anthony Flack on 12:41, 17 January 23I imagine a Plus version of Bomb Jack would still have to spend a fair amount of time spoon-feeding the ASIC with sprite data for the next frame.

Yes, but the cool thing is that you don't need to erase de sprites, which takes the same time than drawing them, and sometimes even more.

Cwiiis

Quote from: Anthony Flack on 12:41, 17 January 23I imagine a Plus version of Bomb Jack would still have to spend a fair amount of time spoon-feeding the ASIC with sprite data for the next frame, so it wouldn't quite be a free ride with the sprites. The logic is not complex and doesn't take much time. Although I still haven't seen anybody get the bird to behave like the arcade one does.
Not too much, as long as you don't mind your sprites switching on differing frames - If they're switching animation frames every 4 50Hz frames, for example (so 12.5fps, or twos if you're thinking traditional animation terms), and you have 12 animating sprites, then you only need to feed 3 sprites per frame, or 768 bytes (the upper nibble of each byte is ignored when loading Plus sprite data). I assume there's a lot more manipulation happening right now having to draw and erase each sprite every frame.

Sykobee (Briggsy)

Also with all the cart space, you can have per-frame programmed sprite updates, which are just pushing the changed pixels directly into the ASIC, rather than a single generic routine updating all 256 pixels in the sprite, by reading from main memory and uploading to the ASIC.

And the more animation frames you have and the smoother the animation, the fewer pixels are going to change between frames, so this scales well in the main. For example a sprite with wavy tentacles dangling down may not change most of the sprite, just the tentacles, so you only update these.

I bet there's a code generator for this out there too.

andycadley

I doubt anyone in 1990 would've been impressed by a ln upgraded CPC which had a lower screen resolution. Doom was still a few years off and the focus at the time was better 2D graphics,

A Speccy style mode might have worked, with a byte containing 8 pixels and then an attribute byte containing the on/off palette entry. That would have given Mode 1 resolution with 16 colours on screen, albeit with some restrictions on pixel colour. Might have upset the timing though as the GA would have needed to read both bytes before it could render the character as opposed to only needing the first byte before starting to render the left hand side of a CRTC column. Probably not insurmountable though 

H and V flipping for sprites would've been nice but if you're going to be reloading them for animation purposes it's not hard to do it in software with minimal extra cost. The one benefit of not packing the left and right pixels!

Having coded a lot of Plus stuff though, the one feature I'd have killed for is the ability to turn sprites on/off when doing a screen split. Often you want to do it to create a static score panel etc and being able to auto clip sprites would've been awesome. Well that or horizontal MODE splitting....

Sykobee (Briggsy)

The GA could read an entire row of attribute values during the 32-48 cycles where no data is being read (the C64 and Amiga does the same for sprite data). Sure, the GA would need to store that somewhere, but compared to 2KB of sprite RAM it's not massive.

All that was needed was a palette offset - 2-bits per cell - so in MODE 1 you could choose which 4 colours you wanted to use out of the 16 colour palette. Some would need to be duplicated of course (see NES games) but it would be a big step up in colour in MODE 1.
(you could also have had a bigger base palette, and more choices, even useful in MODE 0).

A bigger sprite RAM would have been best, with the ability to switch where the sprite data was in the RAM per sprite. But that would have been costly as it was embedded into the ASIC, to stop any contention with the main processor memory bus. H/V flips and clipping over splits would be nice too.

But it's all what-ifs. What if Amstrad had embedded a 16MHz Z80 into the ASIC (like they did with the PcW16), etc....

norecess464

Quote from: andycadley on 18:35, 17 January 23Having coded a lot of Plus stuff though, the one feature I'd have killed for is the ability to turn sprites on/off when doing a screen split. Often you want to do it to create a static score panel etc and being able to auto clip sprites would've been awesome. Well that or horizontal MODE splitting....
@andycadley 
Actually you can achieve this, cf. having a nice sprite clipping at the bottom, on top of your score panel.
It's unconventional, but it's doable through regular splitting (cf. playing with C4).
First screen: managed by the ASIC, you can do whatever in it, display all your sprites etc, even splits managed by the ASIC
Second screen: that one is managed through a CRTC splitscreen. Since C4 is going to be set once again to 0 at first scanline in that screen, the ASIC will consider that the sprites have been vertically offset-ed (cf. the sprite positions starts relatively at X/Y of the currently displayed screen). Please take note you will probably have to hide all the sprites at first scanline, otherwise some sprites may repeat.
Now I wonder: who or what are you going to kill ? ;)
My personal website: https://norecess.cpcscene.net
My current project is Sonic GX, a remake of Sonic the Hedgehog for the awesome Amstrad GX-4000 game console!

andycadley

Yeah, I was aware of that.  :P It messes up other things like PRIs though as well as requiring you to do all the kinds of display fiddling that it would be preferable to avoid.

If it had been possible to do automatically on a hardware split it would've been simpler. Plus potentially give you the ability to do it at multiple points on the frame if you wanted.... Alas it's one of those things you just have to live without.


Anthony Flack

Quote from: andycadley on 18:35, 17 January 23I doubt anyone in 1990 would've been impressed by a ln upgraded CPC which had a lower screen resolution.
I meant the original CPC, it seems like something that could have been possible. But right that people at the time wouldn't have been thinking like that. They wouldn't have seen the advantage of a lower resolution mode that was faster.

And yup even with the Plus' quirky way of handling sprite data it would still be faster for sure. Restoring the background is the biggest nuisance with software sprites. 

abalore

I'm thinking you can simulate a 128 x 128 mode, drawing only even lines and scrolling the screen 1 pixel up and down alternatively at each frame to get a 25 hz interlaced mode. Maybe not interesting for this project but might be interesting for demos or other stuff.

andycadley

Quote from: abalore on 21:17, 17 January 23I'm thinking you can simulate a 128 x 128 mode, drawing only even lines and scrolling the screen 1 pixel up and down alternatively at each frame to get a 25 hz interlaced mode. Maybe not interesting for this project but might be interesting for demos or other stuff.
Yeah, I believe there is some code and a CPR floating around that I did to try this before and it's certainly possible. Broke WinAPE though...

Anthony Flack

I was idly thinking along those lines when I was fooling around with Pico-8 earlier in the year. The chunky resolution is a lot of fun. It would be even more fun for the CPC if you could do it without the wasted video RAM though. Double-buffered full overscan in 20k. Much better for games than running in a tiny letterbox, which is what we tended to get instead.

Ah but what if, what if. We all know the CPC team did an unreasonably good job on the original design and given the circumstances it was created under, it should have been garbage.

abalore

Quote from: andycadley on 22:10, 17 January 23
Quote from: abalore on 21:17, 17 January 23I'm thinking you can simulate a 128 x 128 mode, drawing only even lines and scrolling the screen 1 pixel up and down alternatively at each frame to get a 25 hz interlaced mode. Maybe not interesting for this project but might be interesting for demos or other stuff.
Yeah, I believe there is some code and a CPR floating around that I did to try this before and it's certainly possible. Broke WinAPE though...
Yes, it's only valid for an actual CRT refreshing at 50hz

andycadley

Quote from: abalore on 23:26, 17 January 23
Quote from: andycadley on 22:10, 17 January 23
Quote from: abalore on 21:17, 17 January 23I'm thinking you can simulate a 128 x 128 mode, drawing only even lines and scrolling the screen 1 pixel up and down alternatively at each frame to get a 25 hz interlaced mode. Maybe not interesting for this project but might be interesting for demos or other stuff.
Yeah, I believe there is some code and a CPR floating around that I did to try this before and it's certainly possible. Broke WinAPE though...
Yes, it's only valid for an actual CRT refreshing at 50hz
Nah, it would've worked in an emulator it was just right on the edge of quirky CRTC and ASIC behaviour that just wasn't quite emulated properly by WinAPE. And there were less Plus emulators back then.


GUNHED

Using 32 KB VRAM (shown on screen) and have a 50 fps smooth scrolling is not problem with the regular CPC6128. It's not ever hard to code.  8)
So on the enhanced CPC - the 6128plus - it would be just more easy to handle. 

The new Bomb Jack version however does already like a Plus game. Its GFX is absolutely great, way better compared to the MSX2 video (some posts ago).  :) :) :)
http://futureos.de --> Get the revolutionary FutureOS (Update: 2023.11.30)
http://futureos.cpc-live.com/files/LambdaSpeak_RSX_by_TFM.zip --> Get the RSX-ROM for LambdaSpeak :-) (Updated: 2021.12.26)

Anthony Flack

#48
@Cwiiis "If they're switching animation frames every 4 50Hz frames, for example (so 12.5fps, or twos if you're thinking traditional animation terms), and you have 12 animating sprites, then you only need to feed 3 sprites per framey frame."

This is an excellent point, as 12.5fps is generally about right for sprite animation, and many of the enemy sprite animations in Bomb Jack would respond well to being stored as just the deltas, too. I've never thought about the creative possibilities that open up from only partly rewriting the sprite data. Might be time to start trawling ebay for a 6128 plus...

And of course if you had enough of the same enemy on screen you could just give each one a different frame and cycle their positions around... although I think that would be a wasted optimisation for Bomb Jack - even though some stages could take advantage of that, it would have to be able to run just as well in the other stages that don't.

With 16 sprites, you could do the player + 2 birds + 7 chasers + POW + bonus coin, plus the little bloop animation that happens when you pick up a bomb, which then turns into a floating score... you could have four of those at a time.

POWs and happy faces can become their own floating score after they are collected, since they won't be respawning for a little while.

Bombs drawn onto the background layer.

Anthony Flack

Or, use two sprites in the top panel to make the colour strobing panel more colourful. Then make the number of sprites available for floating bomb scores vary, depending on how many other sprites are on screen.

12 character sprites on screen is not uncommon, but tends to drop again quite quickly. It's when you get max enemies + POW coin + bonus coin all at once. 

Powered by SMFPacks Menu Editor Mod