I thought I would tease a mockup shot of what a game like this would look like on the Amstrad. I used the C64 graphics and re-paletted to Amstrad colours. The screen size is 42x29 chars which makes it better than what a C64 or Atari could do.
Those of you that follow the programming section may of read some of my posts about things that I am working on. So far I've been implementing the technical code to get a game like this to work. The game will always run at 50fps with a multi-speed horizontal scroll that can scroll 1,2,3,4 screen mode 0 pixels or a max speed of 8 screen mode 1 pixels.
Graphically the Amstard can do much better than the C64 and eventually I will ask for art help from this community. In the mean time I will do a demo using the C64 art to flesh out a proof of concept - that should be easy as I've worked out all the technical issues. Also, I will need music in the future as well.
I don't want to strictly do Dropezone and want to lean it back to more Defender type of game play.
And last but not least I want to keep the game pure in the spirit of the 80s. This will work on 64K machines because publishers back then only wanted 64K games. I will also enhance the game for 128K machines, and also the plus range and use the extra features. It would be nice to evenyually do a cartridge for plus machines as well as that Amstrad console. Also a tape and disc release in a good collectors package would be nice... but that is a dream for the time been.
I'm actually quite shocked, when I re-started programming the Amstrad again (I've been making games for over 30 years now) as it was the machine I learnt to code Z80, that with all the new techniques that were discovered long after it's commercial use was over, the CPC is a real power horse and has the potential to be the best 8bit computer. The sad thing is a game like this could of been done in 1984 if people knew about all the CRTC tricks from the word go. Any way here is that tease mockup:
After watching the game reveal of Vespertino by the Batman Group, maybe I should change tack on memory requirements.
The original challenge for me was to do something impressive that runs at 50fps always within the 64KB restriction... the 64K limit is set by me because back in the day publishers only wanted 64KB games. What I'm doing is a trade off of memory and speed programming but what I have is certainly impressive for a humble 64K machine. Because the game will be based on Dropzone/Defender the wow factor along with the multi-speed scroll will be the particle explosions/effects as well as lots of moving sprites. I have lots of raster time to do that
If I used 128K of memory I could do full screen overscan (I am overscanning the display but it's not quite full screen), speed up the scroll edge update by dropping the map compression which will give more cpu time for more particles. And I could probably add a 3D paralax effect on each scan line of the planet.
A 128KB is sure temping but keeping the game pure and doing something impressive within the limits of 64K is a challenge in itself. I just feel after watching the Vespertino reveal that people will now expect more from future CPC releases. What are peoples thoughts on this?
I now have the exact same dilemma with the program I am working on, having seen Vespertino!
My program would benefit enormously from the extra RAM of the 6128, as I am decompressing compiled sprite code in real-time during screen updates.
The extra RAM would allow me to decompress all the frames of a sprite and leave it in RAM until that part of a level is passed, and of course that would result in a nice speed-up.
It's a tough decision!
Quote from: ervin on 06:49, 07 May 19
I now have the exact same dilemma with the program I am working on, having seen Vespertino!
My program would benefit enormously from the extra RAM of the 6128, as I am decompressing compiled sprite code in real-time during screen updates.
The extra RAM would allow me to decompress all the frames of a sprite and leave it in RAM until that part of a level is passed, and of course that would result in a nice speed-up.
It's a tough decision!
Yep, it's a tough decision. I think what I will do is get my proof of concept working and release a little demo... I need to do this anyway because I need people to check to see if it is compatiable with all the different CRTC types as I've only have the one CPC. And from there see what peoples reactions are to it.
@ervin (http://www.cpcwiki.eu/forum/index.php?action=profile;u=82), @AHack (http://www.cpcwiki.eu/forum/index.php?action=profile;u=3051),
honestly, if your game is better with 128k use 128k. The goal is to make the best game possible :D
And if you really want, after, make a 64k version.
A good reason to make a 64k game is to participate to the cpcretrodev (but i hope one day there will be a 128k category).
PS : Is new 64k extension currently sold (and affordable) for 464 (like gotek to replace disk drive) ?
Quote from: Arnaud on 18:04, 07 May 19
@ervin (http://www.cpcwiki.eu/forum/index.php?action=profile;u=82), @AHack (http://www.cpcwiki.eu/forum/index.php?action=profile;u=3051),
honestly, if your game is better with 128k use 128k. The goal is to make the best game possible :D
And if you really want, after, make a 64k version.
A good reason to make a 64k game is to participate to the cpcretrodev (but i hope one day there will be a 128k category).
PS : Is new 64k extension currently sold (and affordable) for 464 (like gotek to replace disk drive) ?
For me I need to get my little demo done and from the reaction I will guage things from there. From what I have now it's miles better than most 64KB games. I do have plans to enhance it with extra memory but, first, I want to see how far you can take a 64KB machine before I consider how to expand it.
A piss poor video showing what I have so far running on a CRT screen.
https://www.youtube.com/watch?v=umsoeA89K5s
Anyway it gives an idea :)
Good scrolling! Ah, if we have in 80's some great coders like now! Some old games look better. Good job! ;)
That looks fantastic!
Is it a hardware scroll?
Or is it stack-abuse based, with only the bottom portion being drawn to simulate a scroll?
Quote from: ervin on 13:48, 16 May 19
That looks fantastic!
Is it a hardware scroll?
Or is it stack-abuse based, with only the bottom portion being drawn to simulate a scroll?
It's using the harware scroll and rupture tricks the achieve the effect. I basically split the memory in 2 and gave 32KB to the code and storage and 32KB to the screen. The 32KB for the screens gets composited together by the ruptures. It can scroll at 1,2,3,4 mode 0 pixels and I don't use register 3 of the CRTC to shift the monitor h sync - I thought it was not best to use this trick because of the issues it carries and it actually complicates the scroll edge update.
Here's a new video of the demo so far working on the Retro Virtual Machine. It's much better, of course, on real hardware and CRTs. The next time I do a video I will do proper video capture from the computer instaed of my phone.
https://www.youtube.com/watch?v=3MmFlfzOE_o&feature=youtu.be
Just a video capture test from the emulator. LCD screens don't do it justice - you definitly need the real hardware to get the true feeling of it. The stars on the CRT leave a glowing trail behind them.
https://www.youtube.com/watch?v=r0LVq8jUUAk (https://www.youtube.com/watch?v=r0LVq8jUUAk)
I guess I'm not at the video production values of the Batman Group but hopfully these videos show what this old 8bit computer can do :D
If you keep the 50 FPS with all sprites it will be really spectacular!
Btw, in the video it seems that sometimes there are residual tiles in the scroll border, this could be easily fixed by drawing those tiles in the right moment of the frame.
Quote from: Rhino on 11:01, 18 May 19
If you keep the 50 FPS with all sprites it will be really spectacular!
Btw, in the video it seems that sometimes there are residual tiles in the scroll border, this could be easily fixed by drawing those tiles in the right moment of the frame.
I think the 50fps is possible - that blob in the top right of the screen is a 16 sprites test overlayed over each other. With that I still have three interrupts of time left. The hardest part of all this is because it's a 64KB game I have to do trade offs for speed and memory. So far it's working out and if I did an enhanced 128KB version that memory trade off for speed can be dropped and it will be quicker - which means the enhanced version will have more particle effects.
That scroll update glitch will be fixed... I just need to rearrange the code in my stack abuse kernal but have not been bothered yet.
So far I'm enjoying doing all this... It's reminding me why I started coding games all those years ago.
Today, TotO gives us the possibility to use 512kb ram with his xmem. More than 300 guys bought it !
So my question is, why don't we use this extra memory ? Why do we sell it ?
Doing some 64kb is a non sense nowadays... :o :o
It's my opinion.
At less 128K. Probably DK'Tronics sold more 464/664 64K RAM expansions in the 80s than peoples using a real CPC today.
We are late with cartridge games too, because the mentality was: "do not use the expansions port". Whe have missed amazing things you know.
Quote from: Ast on 17:22, 18 May 19
Today, TotO gives us the possibility to use 512kb ram with his xmem. More than 300 guys bought it !
So my question is, why don't we use this extra memory ? Why do we sell it ?
Doing some 64kb is a non sense nowadays... :o :o
It's my opinion.
It's more about the challenge for me. When I was a kid in the 80s I did talk to the publishers, trying to sell a game I did on the Amstrad (It was rubbish and was probably not worth publishing back then) and what they wanted was 64KB games that everyone could run. Yes you could enhance them to use extra memory but you were required to make it run on the base model. So I decided to take that requirement for this project for the challenge.
Yes, I will enhance it to use the extra memory to add more effects and such. Also, by doing a base version you can enter competitions and if the game becomes something a C64 or Atari 800 could not even hope to achieve you have grounds to claim it's the best 8bit version of that type of game - I've noticed a lot of C64 users dismiss anything on the Amstrad that uses the extra memory. An example is Pinball Dreams (no other 8bit could ever do that) and yet some C64 users will dismiss it because of the mentioned reasons.
Also, it would be nice to think something like this could of been done in 1984 if people had known about the CRTC tricks.
Bust rest assured once I get the base version done I will enhance it to see how far you can take it in the other direction :)
Quote from: AHack on 19:51, 18 May 19When I was a kid in the 80s I did talk to the publishers, trying to sell a game I did on the Amstrad and what they wanted was 64KB games that everyone could run.
Because it was for the business... Mainly doing fast Speccy ports for £££. On Amiga, greats developers like Team17 and DMA Design forced the players to buy a 512K expansion for the best. Sadly, no killer game on CPC to encourage peoples to buy a DK'Tronics 64K RAM in 1985... But 256K with Discology, sure! :-\
The only reason to expand the RAM (and 6128-ROM) came 1987 with Microprose Pirates.
What a great game!
Another attempt to capture what it is like on a CRT.
https://www.youtube.com/watch?v=_QbJCVnzENc
Looking fantastic, I really thought the CPC couldn't produce a horizontal scroll that smooth....
Quote from: Skunkfish on 20:00, 27 May 19
Looking fantastic, I really thought the CPC couldn't produce a horizontal scroll that smooth....
It can at 1, 2, 3, 4 mode 0 pixel increments at the cost of memory storage.
I've decided to make this a 128KB game because the benefits are too good to ignore. I've been told, in the modern CPC scene, that most people have memory expansion and with my own self imposed 64KB limit (for reasons that publishers in the 80s wanted that) will make the game on par with what an Atari 800 version could do. And with the extra memory it can go beyond that and will probably be on par with what was in the arcades at the time.
By using the extra memory I can get rid of map compreshion and gain lots of raster time back. In one interrupt (52 scan lines) I can update the scroll edge and update the mini-map for the scanner which leaves 5 interrupts of time for other uses. Also, this extra memory means full overscan is possible for the the screen now.
I've been working on the Sprite Managment system. It's a very interesting problem to solve in the respect of clipping compiled sprites, sprite removal for background restore, and racing the CRT electron gun for flicker free graphics. I seem to be getting there with that now.
Quote from: AHack on 04:53, 28 May 19
It can at 1, 2, 3, 4 mode 0 pixel increments at the cost of memory storage.
I've decided to make this a 128KB game because the benefits are too good to ignore. I've been told, in the modern CPC scene, that most people have memory expansion and with my own self imposed 64KB limit (for reasons that publishers in the 80s wanted that) will make the game on par with what an Atari 800 version could do. And with the extra memory it can go beyond that and will probably be on par with what was in the arcades at the time.
By using the extra memory I can get rid of map compreshion and gain lots of raster time back. In one interrupt (52 scan lines) I can update the scroll edge and update the mini-map for the scanner which leaves 5 interrupts of time for other uses. Also, this extra memory means full overscan is possible for the the screen now.
I've been working on the Sprite Managment system. It's a very interesting problem to solve in the respect of clipping compiled sprites, sprite removal for background restore, and racing the CRT electron gun for flicker free graphics. I seem to be getting there with that now.
128kb vs 64kb reminds me of the old Amiga debate (512kb vs 1MB), at first there weren't many games that required 1MB, but in the end any good title needed it and 1MB ended up being the standard.
Quote from: Rhino on 11:15, 28 May 19
128kb vs 64kb reminds me of the old Amiga debate (512kb vs 1MB), at first there weren't many games that required 1MB, but in the end any good title needed it and 1MB ended up being the standard.
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 :)
Thinking about all this, I think the Spectrum ports by publishers basically killed the CPC potential as a machine. 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.
Quote from: AHack on 07:05, 29 May 19It 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.
Quote from: AHack on 07:05, 29 May 19
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 :(
Quote from: ASiC on 12:40, 30 May 19
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!
Quote from: ASiC on 12:40, 30 May 19
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.
Quote from: keith56 on 00:16, 31 May 19
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.
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
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
How smooth! Very impressive.
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.
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.
I can honestly say this looks damn impressive. The scroll is just amazing and the mockup looks really pretty too!
Quote from: Gryzor on 10:38, 25 June 19
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 :)
I agree - although the technical feat is something great in itself it would really gain from the support of good assets!
It all seems to be another project that will show how the CPC was underrated... I can not wait to see the demo.
Just giving this a bump as it looked very promising. Love a good shoot em up! Has any more progress been made please?
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 :)
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.
Quote from: remax on 21:56, 03 January 20
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.
Yeah, i was just reporting glitches in case there is something unusual ;)
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!
Quote from: Maniac on 23:25, 05 January 20
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 :D Again, thanks for reporting but at least we know there is an issue and it can be fixed!
Quote from: AHack on 05:50, 06 January 20
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.
What happened to this exciting project? Was it ever completed?