Dropzone type of game in the works. A demo

[TotO]

It does make me wonder that if someone had done Pinball Dreams or something like what I am doing back in the 80s... would games like that have sold memory expansion packs and 128KB became the norm? Imagine if you were in the RAM expansion business and you bundled the Amstrad Pinball Dreams version with a RAM expansion pack. I think you would of shifted a lot of units

This occured when R-Type was released as many 464 users asked for a RAM expansion.
I sold a million and no more need to work since... (ok into a dream) In fact, peoples w/o expansion continue to think that 64K is a norm. Others play.

[ASiC]

And all it needed was a killer game, some knowledge of the CTRC tricks from the word go, and the Spectrum would of fallen by the wayside. Alas, it was never meant to be.

Although I agree that the lazy speccy ports was the single largest reason of why the cpc got bad rep, don't forget about the 4 (cpc+ included) different CRTC types.

Devs would have three choices:

- Support all CRTCs, somehow;
- Do not use specific CRTC type tricks;
- Game not compatible with all CRTCs.

We immediately discard the 3rd option.

While the first would be the best, I don't think software publishers would be too happy investing additional time and money for this.
I guess the most favourable would be the second option.
But again, why spent more time and money since they can code a shitty speccy port and call it a day     

[AHack]

Although I agree that the lazy speccy ports was the single largest reason of why the cpc got bad rep, don't forget about the 4 (cpc+ included) different CRTC types.

Devs would have three choices:

- Support all CRTCs, somehow;
- Do not use specific CRTC type tricks;
- Game not compatible with all CRTCs.

We immediately discard the 3rd option.

While the first would be the best, I don't think software publishers would be too happy investing additional time and money for this.
I guess the most favourable would be the second option.
But again, why spent more time and money since they can code a shitty speccy port and call it a day 

I agree, I think it would of been a mind field for devs back then getting the CRTC tricks working for all. Mind you, if the CRTC tricks were known in 1984 how many different CRTC types were used between 1984 and 1988 which was the CPCs commercial hayday? I guess people would of worked out things pretty quickly after a few commercial mishaps... the simple rupture tricks more or less work for all - the only pitfall there I can see is CRTC type 1 where the scroll address can change before the other types.


All I know is with the project I'm working on, the CRTC makes the Amstrad a power house... also the Z80 CPU is more flexable than a 6502 CPU and with extreme stack abuse code you can get 16bit memory transfers and speed things up dramatically as well. The combination of CRTC and Z80, in my mind, makes the CPC the best 8 bit computer that was never fully used. If all goes well with this project, I think I will get to the Amstrads full potential.


Anyway, still a long way to go But getting there!

[keith56]

Devs would have three choices:

- Support all CRTCs, somehow;
- Do not use specific CRTC type tricks;
- Game not compatible with all CRTCs.

I think you also have to bear in mind that Devs would have to play it safe, because they wouldn't know what was coming next...
If you're company was developing a game that pushed the CPC 464/6128 to the limit CRTC wise, and then the CPC+ came out and your game doesn't work, well now you've got a cancelled game, or a product recall...
Somehow got your amazing game working on all 4 CRTC types?... well in the 90's at any point Amstrad could have issued a new CRTC type... and now you're stuffed again because you didn't follow the official programming guidelines.

That's part of the reason retro games are so good now... the hardware is never going to change again - people can push things to the limit, and not worry about a failed or buggy product bankrupting their company.

[AHack]

I think you also have to bear in mind that Devs would have to play it safe, because they wouldn't know what was coming next...
If you're company was developing a game that pushed the CPC 464/6128 to the limit CRTC wise, and then the CPC+ came out and your game doesn't work, well now you've got a cancelled game, or a product recall...
Somehow got your amazing game working on all 4 CRTC types?... well in the 90's at any point Amstrad could have issued a new CRTC type... and now you're stuffed again because you didn't follow the official programming guidelines.

That's part of the reason retro games are so good now... the hardware is never going to change again - people can push things to the limit, and not worry about a failed or buggy product bankrupting their company.

I don't think I would group the CPC+ CRTC types into this discussion... those came out long after the CPC's commercial life was over and by that time people had moved onto the 16bit computers. Users would of just blamed the new hardware on why the game did not run correctly and not the devs.


I can think of two games that got it right and wrong by using CRTC tricks:


Right:
Mission Genocide - this had hardware vertical scrolling and rupture. That game could of been released in 1984 because as far as I can tell that works on all CRTC types. I think Mission Genocide was a crucial game in the CPCs life cycle. Even though I never did like the game at the time I was well impressed with it's technical achievements to the point of hacking the code to find out how it worked. If that had been released in 1984/1985 it would have been a game changer.


Wrong:
Ghost an' Goblins - it used the R3 registor trick to get half a char offset. The game had loads of issues between CRTC types and TV modulators.


But you are right, modern retro devs know the hardware is set in stone! That will never change now, plus they can access decades worth of CRTC knowledge at their finger tips. So as you say, modern games have a big advantage.

[AHack]

This shows the main player sprite animations. The up and down acceleration needs tweaking a lot. Getting the controls to feel right is next on my list.



https://www.youtube.com/watch?v=sfiM3O1_Q7g

[andycadley]

Yes, the CPC architecture means you can get great benefits from moving to 128K, unlike the Spectrum where the benefits are much more limited and it's really only practical as a kind of high speed storage medium for reducing multi-loads. You could probably argue that only putting 64K in the original machine was something of a mistake, though costs may the time probably made the margins a little too tight for more

[Hwikaa]

How smooth! Very impressive.

[AHack]

It's been years since I did any pixel art... Anyway here is a first pass of the new Hud Scanner with Smart Bombs and Life Counters. The width takes into account using overscan. There are certain colour combinations that really work well with the Amstrad palette.


My intention from the word go was not to convert Dropzone but to do a game as a cross between that game and Defender... this means graphics need to be done and it also means if I do a cartridge version I don't need permission from copyright holders.

[AHack]

Here's a little mock up of how the new Hud would look on an overscanned screen. I think with a good artist (I'm not the best) the graphics for this game can really shine. The scrolling planet can look so much better but that is probably beyond my skills as an artist to redo those graphics.


Hopefully people can see the potential of what this game can be.

[Gryzor]

I can honestly say this looks damn impressive. The scroll is just amazing and the mockup looks really pretty too!

[AHack]

I can honestly say this looks damn impressive. The scroll is just amazing and the mockup looks really pretty too!

I'm aiming to get a demo done for July sometime before I go on holiday for 3 weeks. I've asked a couple of artists from this forum if they would be interested in doing some artwork for this project but they have come back and said they are busy. But one did say at a later date that things maybe fine later on. I've still got loads of code that I need to do and I can basically use the ripped graphics from Dropzone to get by in the meantime.


But so far with what I have done with the code shows the Amstard can do this type of game at 50fps with lots of sprites and particle explosions... the code part will be good but eventually this project will need good art and music to make it shine as a show piece game for the CPC.


I'm making the demo to encourage an artist to come on board and do this justice as my art skills can get by but they will never shine to make this special. Anyway, take little baby steps and it will get there

[Gryzor]

I agree - although the technical feat is something great in itself it would really gain from the support of good assets!

[PuzCPC]

It all seems to be another project that will show how the CPC was underrated... I can not wait to see the demo.

[Maniac]

Just giving this a bump as it looked very promising. Love a good shoot em up! Has any more progress been made please?

[AHack]

Since I came back from my holidays last August, I've had no time to work on this for the time been. I intend to get back into it in June this year. I do intend to finish it but real life commitments get in the way of passion projects. I did promise a demo but I wanted to get complete overscan of the screen working with the new mockup graphics I posted, but as I say real life gets in the way.


I've decided to release a demo of what I have done so far... it's pretty unfinished (the Jetman has missing sprite data when it overlays over the planet) and the planet edge update happens where the raster is so you get flicker on update. That will be fixed by executing the update code at a different raster position. A joystick controls the Jetman, while the space bar or fire 2 on the joystick triggers a smart bomb flash.


Looking at it again with fresh eyes it's actually pretty impressive, especially when I know there is a crap load of raster time left for baddies and particle explosions and such. Let me know if any real hardware has issues with all the CRTC tricks I am using.


Enjoy my unfinished demo

[remax]

It's impressive how the animation is fluid.


However, i have quite a few graphic glitches...


On the border of the screen when scrolling, when the guy touch the earth (expected if i have well understood).


Also a strange persisting graphic glitch on the upper left side, and a lot of line on the very first screen.

[AHack]

It's impressive how the animation is fluid.


However, i have quite a few graphic glitches...


On the border of the screen when scrolling, when the guy touch the earth (expected if i have well understood).


Also a strange persisting graphic glitch on the upper left side, and a lot of line on the very first screen.

That's all expected. When the demo first starts the planet is not drawn so it's just showing random RAM patterns in a bank of memory. This will be fixed by drawing the whole planet in RAM before startup. The graphic glitch in the top left hand side is a test to see how many sprites can be drawn in 1 interrupt (52 scan lines). As I say the demo is not perfect but it does show that the CPC can do a game like this.

[remax]

Yeah, i was just reporting glitches in case there is something unusual

[Maniac]

Looks stunning and so smooth. A fantastic achievement. One issue I saw though on my 6128 Plus with the CM14 monitor is the screen rolls around and no amount of adjusting the horizontal hold will stop it completely. It gets close but something you're doing on the CRTC registers is causing a headache for the monitor!

[AHack]

Looks stunning and so smooth. A fantastic achievement. One issue I saw though on my 6128 Plus with the CM14 monitor is the screen rolls around and no amount of adjusting the horizontal hold will stop it completely. It gets close but something you're doing on the CRTC registers is causing a headache for the monitor!

Thanks for reporting. I'm not really doing anything special with the ruptures I use - very standard stuff really. For real testing I have a 128k Amstrad CPC with the original monitor and it works fine with that setup. It works fine in Winape with all CRTC types and CPC models as well.


Between the planet and the scanner (8 pixels deep) is not really pixels but a border, basically a blank line to save on memory. Also, after the last line of the scanner I turn off the display so nothing displays, which is to save memory again, then turn back the display on in VBlank. I wonder if that causes issues with your monitor? When I get back to this in June are you willing to do tests for me to get to the bottom of this?


It just goes to show what a minefield doing CRTC tricks is with all hardware configurations... if this was commercial back in the day this would have been a disaster Again, thanks for reporting but at least we know there is an issue and it can be fixed!

[Maniac]

Between the planet and the scanner (8 pixels deep) is not really pixels but a border, basically a blank line to save on memory. Also, after the last line of the scanner I turn off the display so nothing displays, which is to save memory again, then turn back the display on in VBlank. I wonder if that causes issues with your monitor? When I get back to this in June are you willing to do tests for me to get to the bottom of this?

No problem at all with doing tests for you to get to the bottom of it. Work and life sometimes get in the way of helping out, looking or posting on here but this looks so promising I'm happy to help.

[Axel]

What happened to this exciting project? Was it ever completed?