@GUNHED Everything can be better on GX/Plus, it is not the same system.
It require to think the game for it, so it is no more CPC related.
Quote from: GUNHED on 18:03, 12 January 23Quote 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. ;)
What a silly comment. Pinball Dreams already disproved that.
Not everyone is quite up to Pinball Dreams standards of coding though.
Bombjack is one of the games I've had on my list of "arcade games that would lend themselves to the Plus hardware". Along with Green Beret and, for different reasons, Space Invaders. I think these are the sorts of games someone who wanted to learn game programming could try on the GX without hitting too many hardware limits or having to learn the kind of hardcore coding tricks necessary to do on an old school CPC.
That doesn't diminish from how great this is, but I'd like to see someone have a go at a GX native version of Bombjack too.
Quote from: Shaun M. Neary on 10:57, 13 January 23Quote from: GUNHED on 18:03, 12 January 23Right, the Plus is necessary to do a fantastic job. :) So wait for the Plus version of the game. ;)
What a silly comment. Pinball Dreams already disproved that.
You should see the Plus version. It's soooo much better! :P ;D 8)
Quote from: andycadley on 11:57, 13 January 23Not everyone is quite up to Pinball Dreams standards of coding though.
Yes, and it's even worse with 'Plus standards' sadly. At least the demo coders show the right way in this case.
If I wouldn't be super busy with coding of applications and OS stuff the I would love to do such kind of games. However, since a couple of years there seems to be a never ending flood of new games. Great thing btw.
Quote from: GUNHED on 12:55, 13 January 23If I wouldn't be super busy with coding of applications and OS stuff the I would love to do such kind of games.
Incidentally, you got some news of your sisters ? :D
Quote from: GUNHED on 18:03, 12 January 23Right, the Plus is necessary to do a fantastic job. :) So wait for the Plus version of the game. ;)
So I understand Alcon2020 is not a fantastic job :(
Quotebut here's someone proving that the Plus is totally unnecessary to do a good job (https://www.cpcwiki.eu/forum/Smileys/SoLoSMiLeYS1/smiley.gif)
I think the word "totally" is inadequate here in the context.
See Ghosts'N Goblins from
@Golem13 :
https://www.youtube.com/watch?v=tZ_9zTFwrJY
It's already proving how good the "pluses" of the Plus can dramatically improve the game experience.
I love the regular Amstrad CPC as much as I love the Amstrad Plus, and as
@TotO said, it's 2 distinct platforms, even if it shares its lot of similarities.
While this preview of the remake of Bomb Jack for Amstrad CPC is already fantastic, a Plus version would probably benefit a lot from separate palette for sprites vs. background, instant loading, etc.
Quote from: Jean-Marie on 14:33, 13 January 23Quote from: GUNHED on 12:55, 13 January 23If I wouldn't be super busy with coding of applications and OS stuff the I would love to do such kind of games.
Incidentally, you got some news of your sisters ? :D
Well, I do not have sibling (alive). Maybe I didn't get the joke. Lost in languages. :)
A lot of the Plus advantage is having access to 512KB of ROM for each game which allows a lot of graphical variety that no 64KB game could ever offer. The enhanced palette and hardware sprites+scrolling are just (lovely) sugar on top.
(the same goes for the 512KB C64 cart games coming out these days like EOTB, except the palette is greys and muds still)
Quote from: Sykobee (Briggsy) on 17:33, 13 January 23A lot of the Plus advantage is having access to 512KB of ROM for each game which allows a lot of graphical variety that no 64KB game could ever offer.
This isn't Plus specific. You can create a hardware "catridge", which is plugged to the CPC old-gen expansion bus, autostarts a game and provides tons of ROMs as well.
Quote from: GUNHED on 17:31, 13 January 23QuoteIncidentally, you got some news of your sisters ? :D
Well, I do not have sibling (alive). Maybe I didn't get the joke. Lost in languages. :)
;D ;D He is referring to an unfinished fullscreen game.
PS: Yes, this is very offtopic
Ah, thanks I got it now... :) :) :)
Well, it is what it is. As you know time is such a scarce good. ;) :)
Honestly if I had to rank Plus features by usefulness, the ability to do a Rupture style split essentially for free would rank first, then pixel scrolling, then sprites. Access to large amounts of ROM would be quite the way down the list.
Although all this Plus chatter probably ought to be moved off this thread, the work here deserves the praise more than this discussion attached.
@Gryzor ?
While the fact to access a ROM cartridge is more useful than all the other features.
It always depends what you want to do. :)
Also there are two philosophies...
1. Decede to create a project, then see how it can be achieved
2. Look at what a particular hardware is strong, then create a project around it
Raster int are more useful for demo, ROM for games and tools.
Plus sprites would be hugely beneficial. I've never tried programming a Plus but 80% of the CPU time here is dedicated to the sprites. I know the Plus sprites are kinda stupid in that you can't just point them at the graphics you want them to display, but I'm sure it would still be much faster and easier and look better.
What feature is most useful depends on what the project is. Here it would be the sprites and the colours. And the rupture would be a convenience.
But I don't have a Plus, I've never even seen a real Plus. And if I didn't think this would be possible or worthwhile to achieve on a regular CPC, I would have chosen something different. Something that fits more easily into 64k next time, perhaps.
Quote from: Anthony Flack on 23:26, 16 January 23And if I didn't think this would be possible or worthwhile to achieve on a regular CPC, I would have chosen something different. Something that fits more easily into 64k next time, perhaps.
If it would be on a Plus, I would still like it and think it's great, but I would be less impressed.
At least part of why it is SO impressing is because it is a stock CPC 6128. No Plus, no cartridge, just a plain CPC with 128K in Mode 1.
Yes I think part of the fun is choosing something that you think the system is only just barely capable of. For the Plus, a game like Ghosts n Goblins is a good challenge. I don't think a stock CPC can really do that game proper justice. There's a ton of mid-80s Capcom games that would be great for Plus machines.
For the stock CPC, there's still a lot of great arcade games from around 1981-84 that would port really well. Donkey Kong on the CPC is an excellent example of a game that's well-matched to the system's capabilities.
By the way, having now spend a bit of time scrutinising the arcade game in detail, it was apparent to me that beyond the ripped graphics, Bomb Jack: Beer Edition on the Amiga is not particularly accurate. Certainly an improvement on the old Amiga version but from a casual look there are differences I noticed which I guess they didn't notice. The way Bomb Jack jumps isn't quite right. The way the bird moves isn't right (neither is mine yet). I was interested to see if they had got the bird behaviour figured out, but it's not even close. And the animation when you collect the bomb plays backwards! That's not important but it's a bit sloppy.
A good port is about more than just the hardware and graphics.
Considering CPC+/GX4000 enhancement could should bring us something similar to the wonderful unofficial MSX2 release:
It is a shame Amstrad as not offered to display 16 colours for "mode 1" on Plus/GX to match with sprites.
16 colours in Mode 1 would have required a 32K display, which would have been a strain on a 4Mhz CPU (the SAM Coupé struggles to manipulate a 24K screen with a 6Mhz Z80)
Furthermore the gate array would've needed to read twice as much data from RAM, which would probably have required significant redesigns. At that point the timing changes would probably have been better used increasing the number of sprites and letting them read image data from RAM.
Would EGX work (edit: in the case of using it in a game such as Bomb Jack) on Plus though?
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 (the SAM Coupé struggles to manipulate a 24K screen with a 6Mhz Z80)
Furthermore the gate array would've needed to read twice as much data from RAM, which would probably have required significant redesigns. At that point the timing changes would probably have been better used increasing the number of sprites and letting them read image data from RAM.
People are already regularly using 32k displays for overscan screens - I don't think the CPU would've been an issue (well yes, sure, it would play into things, but there are many games (like Bomb Jack) where the screen is mostly static). Given the capabilities of the ASIC in the Plus, I don't think 16 colour mode 1 would've been much of a stretch. Definitely a missed opportunity, alongside the somewhat limited sprites...
More feasibly, the real shame is that the hardware sprites don't decouple sprite from sprite memory and don't provide v/h flip - both of those capabilities would've gone a long way in making things both easier and more flexible. Less feasibly, background priority would've been nice too, though I suppose would've had a considerable memory cost.
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.
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, ...)
@Cwiiis I have though about EGX, but is will kill all the CPU just to display the background.
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.
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.
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.
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.
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.
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.
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.
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.
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....
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....
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 ? ;)
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.
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.
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.
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...
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.
Quote from: andycadley on 22:10, 17 January 23Quote 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
Quote from: abalore on 23:26, 17 January 23Quote from: andycadley on 22:10, 17 January 23Quote 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.
Found it:
https://www.cpcwiki.eu/forum/programming/gx4000-scan-line-doubling/msg98244/#msg98244
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). :) :) :)
@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.
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.
You can also "NES" it up a bit if necessary and just not display one or two sprites on alternative frames. It's a bit flickery, but mostly acceptable in many cases (especially if you don't do it to the main player sprite) as long as the sprites are mostly visible.
There are certainly lots of creative ways of working around the slightly cumbersome sprite system when needed.
That's what I'm going to have to do with the OG version as well, since I will need up to 12 sprites and I only got to 11. So, if you have max enemies + pow + bonus coin on screen at the same time, the pow and the bonus coin will have to share a sprite until you collect one of them.
That is another thing on the to-do list, write the code to handle an overloaded sprite list. Removing the bomb from the screen might cause a brief sprite list overload too, which might cause an enemy to flicker briefly if there's a lot going on. If you see it, it's not a bug it's a feature to preserve 50hz