R-Type

[jbaudrand]

Impressive work, and.. i'm still block at the same point than origin version, so I haven't make any improvment in my skill for 25 years!!!

[TFM]

Had a longer playing phase now. It all works very well and smooth enough. Wonderful job again!!! I had no crash or problems at all. And thanks' a lot for the casual mode - it's well appreciated!!!

[Gryzor]

No crashes for me either. I wonder why.
What an excellent game... (bis)

[fano]

I am happy to read major part of players didn't get this awfull bug.Sadly , it exists (shame on me  ) and is related to a particular way to play (that's surely why i missed it).It is very difficult to track and fix but we are working on it to get a perfect 3" release 

PS. Can we look forward to the sequel R-Type II which was newer released for the CPC?

I am too a fan of R-Type II (more than R-Type I).This point has been discussed and finaly we choose to do not.That would be a big challenge and some things (i think especially to level 4 with its moving parts) would be very difficult to port.
But (yes there is always a BUT) , if some CPC & R-Type II lovers want to try this challenge , we can provide the source of this R-Type engine (a bit documented and fully commented) , tools (windows only) and technical support to help to port.

[EgoTrip]

While this game definitely IS better than the original CPC version, I would not go as far as saying that its the benchmark of future CPC games. Yes it looks great, yes it sounds great, but I found the controls to be latent and sluggish. Also, the lack of a redefine keys option with the not so great control keys lost points for me. I'd give it a 7.5/10 overall.


Cybernoid 2 is still the best CPC shooter IMO, this maybe a different style but it doesn't come close to beating it.


I definitely do look forward to the next Easter Egg project though, hopefully it'll be a totally different genre, like a side-scrolling platformer.

[TotO]

tomas1977 picture (cpcrulez forum)

the lack of a redefine keys option with the not so great control keys lost points for me

Look on the left of your computer, you got an unused joystick port for playing since 25 years. (and a stereo jack too)
About the keyboard mapping, there are two:

CPC 6128 (or PC, like MAME emulator. Best mapping ever) :
MOVE: Arrows keys
BEAM: CONTROL
FORCE: COPY (ALT on PC)

CPC 464/644 (because we know that some peoples got 64K ext.)
MOVE: Functions keys (like arrows)
BEAM: Z
FIRE: X

After that, you make the choice to not keep "old useless features" in the options menu.

[trocoloco]

I gotta disagree with totO and Egotrip. First, I dont understand why u find the controls slugish  , i played the game (always on real hardware) with keyboard and 3 different joysticks and control have been always quick and accurate, but I still suck with joysticks tho 

As for totO, I like the mapping and it's surely the best for a 6128 as standard set, but  I gotta say that I do miss a redefine keys option in the game cos I miss a combination of opqa (or similar) which imo is the best way to control your ship. Anything than that, This R-type is one of the best shooters for CPC for sure and i like it more than Cybernoid 2 which is good but not so detailed as this one tho.

[TotO]

I gotta say that I do miss a redefine keys option in the game cos i miss a combination of opqa (or similar) which imo is the best way to control your ship.  Anything than that, This R-type is one of the best shooters for CPC for sure and i like it more than Cybernoid 2 which is good but not so detailed as this one tho.

Thank you for your feedback.
You need two fingers for fires, not one. Moving ship is not easy with. Fast fire too. (need fingers already busy with moves)
Ergonomics tests have been done to improve the gameplay.
We haven't  made random choices.

[Puresox]

Redefine keys is the best option , every one can be suited then , Left handers,right handers etc.. Cursors are just awkward for this type of game.

[MacDeath]

to redefine keys enable to swap fire 1 and fire2... this can be usefull for some joypads or sticks.

[TotO]

Cursors are just awkward for this type of game.

Keyboard is just awkward for this type of game.

redefine keys enable to swap fire 1 and fire2... this can be usefull for some joypads or sticks.

All joystick/joypad get left controler. You can't chose to move it.
Fire buttons are on right, and it's common to get first the main fire and after the second fire.
It's the case of the GX4000 pad.
It's the case of a SMS pad with a good adapter.
It's the case on a real arcade stick pluged on a CPC.

If you have a custom arcade stick or a Genesis/Megadrive hacked pad, please use this :

A : FIRE 1
B : FIRE 2
C : FIRE 1
START : FIRE 3

Cheers.

[trocoloco]

Thank you for your feedback.
You need two fingers for fires, not one. Moving ship is not easy with. Fast fire too. (need fingers already busy with moves)
Ergonomics tests have been done to improve the gameplay.
We haven't  made random choices.

You most are welcome !

The thing about the fires I see it this way. By playing with a opqa sort of mapping we could, for example, redefine fires 1 and 2 as n and m, normally we have the finger ready on fire 1 and eventually we use fire 2, so to my point of view its not really necessary  to have a finger ready on fire 2 as using the arrows tho.

I dont mean to be picky, its just the way I play better the games with, but hey, arrows, copy and control as i said before its a good way to play it.

[Capper]

    When I handed off the original Spectrum R-Type source code to Activision back in 1988 I was asked if I wanted to do the Amstrad conversion next. I declined and the job was tasked to Keith Goodyer who - as everybody now knows - did an incredible job of taking my non-labelled mess of code and turning it into a finished product in only 21 days. Of course a ridiculous three week schedule meant that Keith didn't have time to work his magic and produce the conversion the Amstrad truly deserved so the result was seen as a disappointment then and ever since. It has taken close to 24 years for the Amstrad gaming community to finally get the game they should have had all that time ago but at last the promise has been kept thanks to a generous act by the Easter Egg team who put all their time and effort into producing a brand new version for a brand new gaming generation.

    I still feel close to the original game and I'm proud to see that an aspect of something Mark Jones, Rob Hylands, Karl Jeffrey, Dave Jolliff, Keith Goodyer and myself helped create all those years ago has been picked up and taken further than anyone could imagine with such detail and affection by Easter Egg. I would like to offer my congratulations to everyone at Easter Egg for not only producing such a fantastic, polished conversion but for the wonderful job they have done of publicising the project. It's one thing to write a game but it's another to get people talking about it and playing it - which through the use of the website, word of mouth, interviews, advance videos etc. they have managed to achieve in a very professional manner indeed.

    Finally I would like to thank Easter Egg for mentioning me in the game credits, which implies I had something to do with the game but in reality all I did was tell a few stories and pass along some very confusing old routines. If you read that this new version contains X or Y percent of my old code then please ignore it - this is a 100% Easter Egg Amstrad game and they richly deserve all the credit and accolades that come with such an achievement.

Bob Pape

[SyX]

Everything was possible, because we were "standing on the soulders of giants" 

My generation has a debt with you, Joffa, Ritman, ... and all the amazing people that filled our childhood with dreams and that is something that i can never forget. Thanks Bob!

[Gryzor]

Thanks to Capper for a really nice post; it's always great to hear the old-timers lament about the good ol' days while chewing tobacco at sundown... erm, sorry, got carried away there a bit.
Concerning the keys, control is definitely very well defined. I only miss redefinition for nostalgia reasons - QAOP FTW!

[MacDeath]

If you read that this new version contains X or Y percent of my old code then please ignore it - this is a 100% Easter Egg Amstrad game and they richly deserve all the credit and accolades that come with such an achievement.

Well, had your original game been with different software solutions to handles the sprites and tiles, this may have not been possible to get it like it is.

Having a character based engine enables to get it fast enough, if not that smooth.
And it was a proper solution to get rid of those awfull colour clashes, this so awesome speccy "feature"

I looked at the MSX version (done by japanese I think).
Basically they also use the character based animation, but with the only difference that the R9 sprites (and modules/Forces) and a few projectiles are done in HardSprites...

Basically, the R9 move smoothly, so many actually believe it is a smooth version, which it is not.

Most enemie waves are also full-character moved...
The R9 shoots are characters too, which lead to a lot of "unmasked" clashes with the background... especially on levels like this one :

Irem's R-TYPE on the MSX - Stage 6


And most of all, with the speccy version you could handle a proper smooth scrolling effect, one aspect the MSX failed abyssmally..


Of course, the 8x1 attributs from the MSX enable some better graphics than the Speccy... more coloured.



And most of all, this speccy version was the closer to the arcade in so many way...
Waves patterns, type of enemies...

The fancy C64 version is in not way as close.


The main point was also to prouve to the Retro-computer fans that the Amstrad CPC is not a humble and inferior speccy clone as many actually tend to believe (due to the lot of unpolished speccy ports the industry impsoed to us).


The only condition being to use a proper 6128 configuration instead of a 464.



To be fair, such kind of remastering on CPC from a speccy port couldn't have been performed with games like BlackTiger per example.
As the speccy version is not that good to begin with.

R-Type is generaly seen as the best speccy arcade port ever.

QAOP FTW

I don't think F, T and W would be a proper setting for fire1, fire2 and pause...

[fano]

To be honnest , we look at MSX version when we had a to choice to make about scrolling.One possible option was to have char hardware scroll (like MSX) but we finally found that was not suited for a shooter like R-Type  (and it is awfull  )

[andycadley]

But (yes there is always a BUT) , if some CPC & R-Type II lovers want to try this challenge , we can provide the source of this R-Type engine (a bit documented and fully commented) , tools (windows only) and technical support to help to port.

Is there any chance the source will be available anyway? Not quite R-Type II, but I can think of another platform not far from the hearts of many here that really could have done a quality version of R-Type and I'd be curious to see how difficult it might be to adapt the code to take advantage.

[MacDeath]

Not quite R-Type II, but I can think of another platform not far from the hearts of many here that really could have done a quality version of R-Type and I'd be curious to see how difficult it might be to adapt the code to take advantage.

Which one are you talking about ?

Perhaps the Enterprise128 ?

I mean, I can't see a lot of other system who may utilise the Speccy/CPC source code...

MSX already have a proper version, MSX2/2+/turboR guys just have to re-use the existing MSX one or restart from scratch (I mean, those MSX2 and later can really have powerfull video modes, and sweet scrollings on 2+... also shitons of sprites...)

C64 and others are not Z80 based computers.

Speccy allready has the best R-Type possible on this standard.


Perhaps SamCoupé ?
It would just need the speccy version to get proper sounds and recoded graphics I guess...


BTW, it would be cool to see our "cousins" from the Enterprise128 scene to port this.
Perhaps they could use the extra palette choice.

Or were you thinking about the AmstradPLUS ?


Concerning an R-Type II... I guess a new set of tiles and sprites and new levels patterns would be enough.
Yet some effects like the water may be a little tricky to implement...



R-Type II part 1 of 2

R-Type II part 2 of 2

ouch...

The various moving backgrounds/sceneries may not be good enough in a character based engine.


R-TypeII is so much more complcated, with a big load of extra content, lots of sprites and so on...
Much more heavy to get on an 8bit machine done properly (= arcade faithfull...)

you have to accept when the Arcade system are too much for the humble CPC.


let's check the Atari ST version :

R-TYPE II - ATARI ST PLAYTEST

[andycadley]

Which one are you talking about ?

Well I was thinking specifically of the GX4000. Although a SAM Coupe version would also be an interesting challenge, it's probably one of the few 8-bit machines even less well suited to scrolling games than the CPC (it has a 32K screen and just a 6MHz Z80!)

[MacDeath]

Well I was thinking specifically of the GX4000. Although a SAM Coupe version would also be an interesting challenge, it's probably one of the few 8-bit machines even less well suited to scrolling games than the CPC (it has a 32K screen and just a 6MHz Z80!)

You know, the Video is still in 50Hz I guess...
If it is done as on CPC, it doesn't put that much more Wait states in theory (I don't know actually) but yeah, the CPU must still deal with twice more video Datas to process.

The VRAM is not that much a problem if you have enough RAM to begin with...
while having to handle twice bigger datas, the Z80 still has a lot more cycles... but not really twice more.

The basic Sam coupé has 256K minimum...
It is regarded as a Speccy successor.

The 256×192, linear framebuffer, 4 bits per pixel (16 colours) = 24 KB

But ok, it goes for actually 32K of RAM... sort of...

Concerning GX4000... a brand new code must be done.

I mean ok let's say you have Hard scrolls and sprites... and 512K ROM cartridges... and DMA sounds...
Still the pure RAM is 64K only and the CPU is the same as on CPC, yet it must handle more stuff.

Let's just say it could be possible to get the R9 sprite and its modules in smooth Hardsprites... And extra palette too.
But to mod in order to manage the new RAM/ROM ratio is still a lot of work... and may also fail with existing engine.

And Fano surely want to do something else.


anyway...

@Capper (the Pape of Speccy...)

I wanted to ask you a question concerning the speccy and professionnal games from the era.

How did you handled the 2 main Speccy configs... the 48K/+ and the 128/+2/+2B/+3...

On Amstrad, some games actually supported the 128K config but just to get a single loading of the game and perhaps some extra sounds...
But very few games were "128k only" games...

I suppose it was the same with the Speccy128 versions most of time ?
Did it only added soem Sounds and less multiloading in tape version ?
Or did some game actually get more stuff in gameplay and "graphic content" ?

This new R-Type version is a good way to see how a proper "6128" version should be... (6-128 = (relatively fast and solid) disk + 2x64K RAM).
As we always feel our CPC was downgraded by having so many users with tapes and 64k only models.

Was the strategy in game company the same on speccy ?

[andycadley]

You know, the Video is still in 50Hz I guess...
If it is done as on CPC, it doesn't put that much more Wait states in theory (I don't know actually) but yeah, the CPU must still deal with twice more video Datas to process.

The VRAM is not that much a problem if you have enough RAM to begin with...
while having to handle twice bigger datas, the Z80 still has a lot more cycles... but not really twice more.

The basic Sam coupé has 256K minimum...
It is regarded as a Speccy successor.

Even with 512K, which is typically considered "the norm" for a SAM, it's a lot of data to move around at a reasonable speed and having heaps more memory available doesn't go a long way to helping. Scrolling shooters are pretty much non-existant on the platform.

Concerning GX4000... a brand new code must be done.

I mean ok let's say you have Hard scrolls and sprites... and 512K ROM cartridges... and DMA sounds...
Still the pure RAM is 64K only and the CPU is the same as on CPC, yet it must handle more stuff.

Let's just say it could be possible to get the R9 sprite and its modules in smooth Hardsprites... And extra palette too.
But to mod in order to manage the new RAM/ROM ratio is still a lot of work... and may also fail with existing engine.

And Fano surely want to do something else.

There would certainly be lots of bits that would need to be done differently, however there may be lots of code that can be reused. At the absolutle minimum having documentation on how all the levels, sprites and movement patterns are stored would be incredibly useful. I'm sure Fano would prefer to be working on something new, but there are other people out there who might be interested in making some use of the code.

On Amstrad, some games actually supported the 128K config but just to get a single loading of the game and perhaps some extra sounds...
But very few games were "128k only" games...

I suppose it was the same with the Speccy128 versions most of time ?
Did it only added soem Sounds and less multiloading in tape version ?

Most 128K Speccy games were just the 48K version with AY music added and the multiload replaced with a single load. Even towards the latter end of the Speccy's life, there were only a very small number of truly 128K only titles released (and chances are one or two of those could potentially have been 48K multiloads if there had been the demand).

[MacDeath]

SAM Coupé wikipage :

Internal RAM was shared between the video circuitry and the CPU, with CPU accesses incurring a speed penalty (the memory contention delay) as it waited for ASIC accesses to finish. As a result, the SAM Coupé's CPU ran only around 14% faster than the ZX Spectrum CPU, yet was required to do much more work in SAM's appealing high-resolution modes to produce a similar movement on the display. A Mode 3 or Mode 4 screen uses four times as much RAM as a ZX Spectrum, so four times the work had to be done in the same time.

Ok.
Basically the SAM has the exact same problem as the CPC, but even more severe as the bpp is souble compaired to good old CPC...

but on the other hand, the SAM coupé could pehaps run the spectrum version of R-Type but in Mode2 (with 8x1 attribute as on the MSX1 or Thomson MO5/TO7...)

This would be the Speccy version looking a bit more like the MSX version, minus the Hardsprite smooth R9+Force.


but to be honest I am a bit      disappointed bit the SAM coupé, it is always regarded as the best 8bit computer by some collectionners...
But actually it is not really that much more powerfull.
It just sports fancier videomodes, but those are then too big for the system.

The sound system must be a bit heavier too I guess (6 channels...)

The Z80 may have needed 8mhz or even more perhaps.

[Capper]

I wanted to ask you a question concerning the speccy and professionnal games from the era.
How did you handled the 2 main Speccy configs... the 48K/+ and the 128/+2/+2B/+3...

I can't speak for every company and coder involved in the production of 128K games for the Spectrum at the time so I'll try and cover what I can from my personal experience. What I find ironic(?) is that you could probably get a better explanation of this from one of the many Spectrum retro-fans around who has studied this in detail - but as the old saying goes....."If you can remember Woodstock then you weren't there." :-)

The general attitude was that 128K was a minority market compared to 48K so anything involving 128K either had to be priced high to cover the extra development costs or broken down so that it could multiload off tape for a 48K. There were a few prestige 128K only titles like Carrier Command but the usual route was to produce a game you knew would work on 48K and then ramp it up to the 128K since that way you definitely had two versions you could sell. The advantages of 128K to gamers were (hardware changes aside) basically extra memory, better sound quality that cut down on processor time and paging of the screen display. While the last two options definitely gave 128K versions an advantage over 48K ones you couldn't use them to optimize a 128K game then downgrade it to a 48K and expect the same results, replacing a tightly coded hardware screen flipping routine with a slower block move software-based one wouldn't get you the same thing.

As late as 1989 Activision didn't have a policy of supporting 128K versions. They would accept a 128K version if offered by the programmer but they wouldn't specifically or contractually ask for one and they certainly wouldn't have paid substantially more for it since the market was predominantly 48K cassette-based even at that late a date. By the time 128K models were being bought in large numbers (because you couldn't buy 48K any more) Spectrum software had advanced from the simple Horace-type games to complicated graphically heavy arcade conversions which meant that the major software companies were looking for  product that would better their competitors and I think some of those saw 128K as a means to do just that. Some companies took advantage of the extra memory to produce better quality graphics with more animation frames, sprites and larger game-play areas and to produce music and audio FX that didn't sound like it came from a strangled gerbil. But the reason for doing so was just to make money, pure and simple. With an A-Class cassette title selling for £9.99 all you had to do was pay a musician 2K for some AY music and a few days from the programmer and you'd end up with something you could sell at a premium price of £14.99 on a +3 disk or a deluxe packaged cassette.

I would also guess - and it's only a guess - that a lot of companies wanted to get out of the cassette market and saw the +3 as a means of doing so, in which case there was no way they could get away with chucking a single-load cassette version on a disk unless it was 'enhanced' somehow. They may have used the excuse that gamers were now used to better quality games so would be prepared to pay more for them them but when a gaming system is starting to die out the belief that users will pay more for games, not less, is a sure-fire way to go broke (cf Danny Devito's "buggy whip" speech in the film Other People's Money.)

The idea that extra memory cuts down on multiload is also open to argument since it all depends on the nature of the game. What it does is cut down on RELOAD time when you need to start again. You have to fill up that 128K either through an initial one-off load or streaming during the game and if you thought cassette loading on a 48K Spectrum was long then imagine having to wait for an entire 128K to load in off cassette before you could play the game! The same goes for in-game loading, the only advantage it gave you was that you only had to load something once off tape rather than over and over again, but you still had to load it in the first place. The +3 gave you a floppy disk which loaded a lot faster than tape but then you didn't need the extra memory to store data off since you could reload previous data so quickly anyway.

I worked on two 128K projects, the first was a 128K only program supplied with a hardware keyboard for the High Street market. The extra memory is used to hold keypress codes so that AY music can be recorded and played back, to a minimum length specified by the distributor. Since I was still learning Z80 at the time the method I used was wildly inefficient and the extra memory is used purely as a dump area and nothing else. The second 128K was Tusker for System 3. Basically the 128K version is the same as the 48K version apart from AY sound and faster loading of levels from the disk, the tape levels aren't preloaded neither are they paged out for later reloading. The disk version was a bit of an afterthought from System 3, as was AY sound support, which is why paging wasn't implemented right from the start and everything has (looking at my source code 20+ years later) a tacked on feeling.

It's not that hard to write a 128K game compared to a 48K one since there's very little that's actually different between the two. Using the AY chip does free up processor time that would otherwise be spent in BEEPing and so does the hardware flipping of the screen display but back "in the days" it was too little too late. If it's used more nowadays by retro-coders I think it's because you don't have to spend time compressing and optimizing code and graphics - a delicate art. If you're running out of memory you can just page in another bank of RAM. put them in there and tell the player to select the 128K option on their emulator.

[viddi]

Okay, here is another bug report for the 6128 Plus:

I transferred the original DSK file via CPCDiskXP (3,5", B-Drive).
Once again it worked for the first time. I could even quit and restart the game.

But after a reset and a reload all I can see is the score panel (music and fx are audible, though).
Then after some seconds a "FATAL ERROR" screen appears:

xxx FATA ERROR xxx

FS_LOADFILE
CHECKSUM ERROR

xxx FDC/FS REPORT xxx

ST0 01000001   .   ST1 10000000
ST2 00000000   .   ST3 01101001

TR.03    HD.0         SC.C8       SZ.2

LAST FILE                 CASUAL   BIN



PRESS ANY KEY TO RESTART SYSTEM!