CPCWiki forum

Hi,

anyone out there know of a good collection of Amstrad screenshots for PoP?

have seen the Mobygames set but i am really looking for the Amstrad Palace levels.

Alternatively would any kind person(s) care to "cap" me some with a "pure" graphics format like GIF or PNG (no compression).

only looking for the "unusual" architecture of the palace. like tapestries, arch windows, columns etc

Cheers

Steve

tracked down some amstrad level maps at full res so mission accomplished.

thanks for reading.

Steve

Links please !


Also :
http://www.cpc-power.com/index.php?page=detail&num=1684

Hey! Can I inquire as to why you're asking? Remodeling your house maybe? :)

I never understood why the hero in this game is blonde...
Persia? Aren't they black haired?  ???

Quote from: Devilmarkus on 09:32, 03 May 11
I never understood why the hero in this game is blonde...
Persia? Aren't they black haired?  ???

I blame Hollywood ;)

There is a tribe of Indians to the North who have blond hair and blue eyes... Kalash (?) I think they're called, but the story doesn't reveal much.

Quote from: MacDeath on 06:07, 03 May 11
Links please !


Also :
http://www.cpc-power.com/index.php?page=detail&num=1684 (http://www.cpc-power.com/index.php?page=detail&num=1684)

thanks for that link. sorry i can't post links to what i found because it was sent to me as a zip.

i am perfectly willing however to forward the maps to anyone here who can archive them for future use.

I was after them because i am evaluating the possibility of converting it to probably the one mainstream machine it never was done for in the first place. cramming it into 64k tho may not even be possible. certainly not in Bitmapped mode like the amstrad version. which i assume is 128k only?

the prince's hair varies wildly in colour from version to version IIRC from white on the apple thru brownish blonde on the pc to hollywood blonde with a quiff on the amstrad :)

Steve

(http://i1105.photobucket.com/albums/h355/ste86/title.gif)

I'm guessing it's the Atari 8bit?
But I could be wrong.

It would be interesting to see it on this platform - I know nothing of it other than it's 6502 based.

EDIT: It seems you are talking about the c64 version?
EDIT2: I think the CPC version does run in 64k.

I ws thinking that it was the C64 version too where it would work brilliantly.

it may not work at all on a c64 particularly in 64k.

no chance at all in bitmapped mode i think. it would have to be character mode in order to keep the cpu and memory usage down. which itself causes a whole new set of problems, especially with the huge amount of frames for the protagonist which all have to me in RAM constantly and will almost certainly have to have some run length compression on them.

FYI the Atari 8 bit is sadly a victim of over hyping by its user fanbase. It is realistically a 4 colour machine with inadequate HW sprite capability. any version of PoP for it would actually, i think only be possible in a mono spectrum style.

I can see why the spectrum & amstrad versions were done but no c64, simply because these machines have the required CPU to graphics welly to do this game as a direct conversion under software from the original apple version.

Steve

I agree concerning Atari8bit...
its fanboyz are annoying !
"the best 8 bit ever"... but IMO the graphic modes are so strange and delicate to handle to be considered a decent machine...
it took perhaps 20years to discover how to really do colours on it...

And the majority of games are something like a 4 coloured mode0 with some bits of rasters.... erk...

This big colour palette would have been betterly used on an amstrad.

Quoteit may not work at all on a c64 particularly in 64k.

You simply wouldn't get something as "good" as on Amstrad...
But if you use multiloadings the 64k may not be that problematic.

And a heavy use of Hardwired sprites may be helpfull too...

http://noname.c64.org/csdb/release/?id=4527
http://www.lemon64.com/forum/viewtopic.php?t=32129&sid=f278c5e7a463264798c70f27489e13d0
http://www.uvlist.net/game-158883-Prince+of+Persia

I don't know about the colour palette, the greys would be nice (always a pain in the arse for graphic designing on an amstrad "back in the day" :) )

but the only real "red" is even worse than the c64 one.

can anyone say definitively whether Amstrad PoP is 128 only or does it run in 64k?

Steve

>Amstrad PoP is 128 only or does it run in 64k?
I have a copy of a French edition of Prince of Persia.  On the box it states "CPC / CPC+"  - it doesn't state anywhere 'which' CPC is the minimum.
I've take a photo of the instruction page inside the manual - that is no clearer as you can see.

If I were to "ass-u-me", I would say it was 128k, purely because it is supplied on disc and it references the CPC+, if I get a chance later I'll see if I can connect a Drive to a 464 and see if it runs...

There is a tape version of the game. It seems it will run on 464, so seems to indicate it will run in 64k.
http://www.cpc-power.com/index.php?page=detail&num=1684 (http://www.cpc-power.com/index.php?page=detail&num=1684)

There are some english instructions and it doesn't say anything about 128k here.

EDIT: Markus made a snapshot of the tape version. Intro and game loaded as 2 parts.
Game is definitely 64k, no "bank switching" i/o is done in the code.

Although I do agree that Atari 8-Bit Fanboyz tend to get carried away with how good their machine is/was (as do C64, Speccy and many other 8-Bit Fanboyz) and the colours were quite complicated to manipulate, the Hardware however was really well thought through and had some really good features not seen on other 8-Bits: Built in HF, Composite and S-Video (a small hardware tweak was needed on some models for S-Video), really flexible Cartridge port and of course the joystick port which had a 5V supply and two analogue inputs.
Every machine has it's good and bad points, judging or comparing two machines using just one feature is rather lame, and starts ridiculous arguments that nobody wins.

Bryce.

Quoteas do C64, Speccy and many other 8-Bit Fanboyz

What is this I don't even...
Such behaviour is quite unseen on Amstrad Fandom. ;)


The µPokey soundchip wasn't quite bad from what I've heard...
4channels...which may be good.
It was also used in some Atari Arcade (Toobin' perhaps ?)

Anyway being easy to use is quite a great quality for a computer system...
And graphically wise, Atari 8 bit was sort of... missed opportunity.

But... its design was quite old after all.

The funny part is that by a strange hasard Amstrad CPC is the actual Atari ST's 8bit equivalent, while Atari 8 bit is not...(sort of)

As the old saying goes, if you 'assume' you make an 'ass out of you and me'.... and alas I did.


I can confirm that the Prince of Persia works perfectly okay on a CPC 464 with 64K of RAM.  As shown in the attached photos.  In fact it runs very well, shame I'm no good at playing the game!  I think I might get some practice in now though  ;)

Quote from: STE86 on 12:36, 04 May 11
it may not work at all on a c64 particularly in 64k.

no chance at all in bitmapped mode i think. it would have to be character mode in order to keep the cpu and memory usage down. which itself causes a whole new set of problems, especially with the huge amount of frames for the protagonist which all have to me in RAM constantly and will almost certainly have to have some run length compression on them.

Well the characters would presumably use the hardware sprites. The background should be easily doable using the non bitmap mode of the display.

I can add the 64kb tape version of the game doesn't work in 472 english keys (rom BASIC 1.1). I had this great game. The game loads the intro and then the game as arnoldemu said but when you finish the first level, the game hangs when the player pulls the cornice to open the door to 2nd level. This 472 gave me troubles with a bunch of games !!

Quote from: andycadley on 16:27, 04 May 11

Well the characters would presumably use the hardware sprites. The background should be easily doable using the non bitmap mode of the display.

This is what I was thinking. The main sprite didn't seem to have that many colours so using 2 sprites on the C64 for the hair, skin colour, clothing and the extra, for toning would work very nicely. Or maybe even creating the sprite in a higher resolution.

Quote from: MiguelSky on 18:10, 04 May 11
This 472 gave me troubles with a bunch of games !!

Does it behave different compared to a 464?

Quote from: TFM/FS on 21:51, 04 May 11

Does it behave different compared to a 464?

I looked at the code for Prince of Persia.
It seems to call the rom routines direct for loading off cassette, so perhaps this is the problem?


I also noticed:

1. it doesn't seem to use double buffering (it doesn't double buffer the entire screen anyway).
2. it seems to have code for mirroring tiles and perhaps the sprites too.
3. it reads the font from the rom.

It draws to a buffer, first the background tiles it seems, then it masks the man sprite over this, it then copies this to the main screen for display.
(using an LDI loop).


No idea if it sorts the sprites or anything, seems like it just draws it.

Quote from: MiguelSky on 18:10, 04 May 11
I can add the 64kb tape version of the game doesn't work in 472 english keys (rom BASIC 1.1). I had this great game. The game loads the intro and then the game as arnoldemu said but when you finish the first level, the game hangs when the player pulls the cornice to open the door to 2nd level. This 472 gave me troubles with a bunch of games !!

Funnily enough I'm getting exactly the same problem via emulation for both UK/Spain releases (I want to use either as they're both in English)

Prince of Persia (UK) (1990) (UK retail version) [Original].dsk (http://www.cpc-power.com/pages/download_part.php?fiche=1684&dsk=6&part=Prince%20of%20Persia%20%28UK%29%20%281990%29%20%28UK%20retail%20version%29%20%5BOriginal%5D.dsk)
Prince Of Persia (UK) (1990) (Spain retail version) [Original].dsk (http://www.cpc-power.com/pages/download_part.php?fiche=1684&dsk=5&part=Prince%20Of%20Persia%20%28UK%29%20%281990%29%20%28Spain%20retail%20version%29%20%5BOriginal%5D.dsk)

Both disks from the CPC-Power site.

It does list for the French version above the two a poke -

"Ne pas avoir besoin de saisir le mot de passe a la fin du niveau 01"
ie "Do not need to enter the password at the end of level 01"

The pokes are -

poke &001B, le &00 en &C3
poke &001C, le &B1 en &00


Does that mean for the first poke change the value at &001B *FROM* &00 *TO* &C3??

The default value at &001B is indeed 00
But the default value at &001C isn't B1, but is in fact B9 ??? ?

So what do I do?

Thanks!

Quote from: Gryzor on 07:51, 04 May 11
There is a tribe of Indians to the North who have blond hair and blue eyes... Kalash (?) I think they're called, but the story doesn't reveal much.

Did you know that kalash are in many ways greeks?


Actually i never new that prince of persia's story was about them

@Sigh,

the sprites on a c64 version will have to be limited to multicolour non overlayed ones so it will never look as well shaded as the amstrad version. there are simply not enough sprites on the c64 to cope with the enemies with swords and the main character in close proximity, bearing in mind that the main character can initiate any move he wants at any time.

the sprites numbers would have to be dynamic, on roving rasters to enable the sprite to go from 1 sprite wide and 3 high when standing or jumping straight up to being 3 across and 2 high whilst in the widest frame of his running jump.

while fighting the characters would be 2x2 sprites each with another 1 each for the sword blade.

@arnoldemu
thanks for that info, it is an interesting insight into how the amstrad one works. anything else u come across please post.
I can tell you that PoP uses the "painters algorithm" to draw its tiles from bottom left to top right of the screen. that way the titles naturally mask over each other in the direction of the isometric as it draws.

Steve

(http://img203.imageshack.us/img203/5510/standingjump20240.gif)

Quote from: STE86 on 10:49, 05 May 11
@Sigh,

the sprites on a c64 version will have to be limited to multicolour non overlayed ones so it will never look as well shaded as the amstrad version. there are simply not enough sprites on the c64 to cope with the enemies with swords and the main character in close proximity, bearing in mind that the main character can initiate any move he wants at any time.

the sprites numbers would have to be dynamic, on roving rasters to enable the sprite to go from 1 sprite wide and 3 high when standing or jumping straight up to being 3 across and 2 high whilst in the widest frame of his running jump.

while fighting the characters would be 2x2 sprites each with another 1 each for the sword blade.

(http://img203.imageshack.us/img203/5510/standingjump20240.gif)

I see. You could always use a software sprite for the enemies, as they have a very limited moves set. There is only 1 enemy on screen at a time though out the whole game if I remember.

sadly not. to software sprite on the c64 would require any sw sprite to be the same 4 colour set as the background graphics. which would totally defeat the objective.

sw sprites on the c64 are only effective as bullets in 8x8 blocks or on the rare occasion that they are used in complex graphics like one of the players in IK+ they all occur over background colour thereby negating any attribute clash problems.

Steve

But you could have just the sword as a software sprite? This would save on a few hardware sprites enough for animating both the enemy and player or is that still not possible?

Here's a link to "Games That Never Were C64" with info on Prince of Persia for C64(just scroll down):

http://www.gtw64.co.uk/archive.php?page=%204&letter=P (http://www.gtw64.co.uk/archive.php?page=%204&letter=P)

yes i suppose the sword could be a sw sprite but it just adds to the already complex animation and offset sprite placement sequence just to get 1 more colour "sometimes" in the main sprite. I say sometimes because there will, on some frames still not be enough sprites to completely cover and add colour to all areas of the main sprite.

additionally, this game is already far from assured of fitting in 64k without adding more sprite data :)

transient multiloads have to be kept to a minimum on the c64 because of its agonisingly slow disk.

I am aware of that PoP version. it is however simply a set of homebrew screens with no sprites ever done afaik and as such is pretty useless.

There is currently another c64 PoP (running) conversion in the works, also using my sprite data but will defeinitely not fit into 64k and is based around a cartridge format.

I would like to do one in 64k as a disk based system because to me as an oldschool game developer, if it doesnt run on stock hardware then you may as well run it on a PC.

Steve

Fair enough.

Quote from: STE86 on 16:20, 05 May 11
There is currently another c64 PoP (running) conversion in the works, also using my sprite data but will defeinitely not fit into 64k and is based around a cartridge format.

How are they getting around the sprite problem? I'm quite surprised with the conversion problems for the C64 unless you make the sprite fit into the 24x21 dimensions, where it would be rather tiny!

Quote from: TFM/FS on 16:23, 05 May 11

Yes, all greeks I know have blond hairs and blue eyes ;D ;D ;D

Well, maybe you're a tad ignorant about history, who knows...

there is no "sprite problem" assuming that u use none-overlayed sprites which basically limits them to 3 colours and transparent so they are less colourful than the amstrad ones but still work as most of the hero character is white and pink anyway.

the sprite data would be drawn into matrices of hardware sprites so the matrix for some frames would be:

1
2
3

if he was standing

12
34

in a fight stance (plus sword)

or

12
345

if he was in a flying leap to the right. etc.

Steve

Ste, have you tried any mock-ups yet?

I didnt even know this existed for the CPC until this thread was posted. It looks incredible. I watched the long play video, wow. I'm going to be giving this a go for sure.

Quote from: STE86 on 19:02, 05 May 11
there is no "sprite problem" assuming that u use none-overlayed sprites which basically limits them to 3 colours and transparent so they are less colourful than the amstrad ones but still work as most of the hero character is white and pink anyway.

the sprite data would be drawn into matrices of hardware sprites so the matrix for some frames would be:

1
2
3

if he was standing

12
34

in a fight stance (plus sword)

or

12
345

if he was in a flying leap to the right. etc.

Steve

Ahhh okay I think I understand now when you mentioned the 2x2 sprite (24x21) so it would be a 48x42 sprite? (Man..I'm rubbish at this!!! I'll understand more when I see the mock up ;D ).

I really hope you get this working on the C64/128/Cartridge as it should of never have missed out in the first place.

Quote from: EgoTrip on 21:10, 05 May 11I didnt even know this existed for the CPC until this thread was posted. It looks incredible. I watched the long play video, wow. I'm going to be giving this a go for sure.

That is because you are not tried the CPCGamesCD, there you can browse "all" the games of CPC, sort them in categories, seek with filter and of course, play them :D

You can download from the link in my sign.

Quote from: MiguelSky on 07:29, 06 May 11
That is because you are not tried the CPCGamesCD, there you can browse "all" the games of CPC, sort them in categories, seek with filter and of course, play them :D

You can download from the link in my sign.

Blatant self-promotion :D But well worth it!

Yeah, it's a hell of a conversion to be sure... really great!

QuoteHow are they getting around the sprite problem?

As they always do : sprite multiplexing.

http://codebase64.org/doku.php?id=base:sprite_multiplexing

Getting them in large pixel enable 4 colours (3+transparent)
So you may use the same design as CPC version (with perhaps less colours...)

The main problem... sprite are greatly well animated (captain obvious) so they may need quite a good lot of animation frames.
Yet there are not a lot of simultaneous heroes/baddies "sprites" in this game

the sprites are all done and have been for 18 months :)

they are converted from the PC version of the game into 2:1 pixel ratio. except that the hero now looks down as he takes a careful step forward which the apple one does and the pc one doesnt. (and yes they are less colourful than the amstrad version).

and yes there are 200 odd sprite frames :)

Steve

Any chance of a preview?  ;)
Will it be cart or 128?

this at the moment is simply all talk, evaluation and graphics. :-\

i have quite a few sprite animation sequences as animated test gifs and alot of currently disjointed and separate background graphic elements. but to go further requires some "real" game coding. not demo writing, but old fashioned high stamina games slog.

And having done this crap professionally 20 years ago, i am only too aware of how few real coders there are now doing homebrew stuff. :(

but we live in hope :)

Steve

QuoteYou could always use a software sprite

Sftware sprites ? on a C64 ?

Remember that the C64 is actually not really better than a ZX spectrum concerning Softsprites...
Colour clashes all the way !

yet less severe a on speccy Thx to the 4 colour per attributes mode (160x200)...
Also got to remember that concerning Softsprites, C64 is perhaps even inferior to CPC... it remains a 64K machine with 1mhz CPU...

You can use software sprites as already stated and done by coder TMR:
http://cpcwiki.eu/forum/index.php/topic,1882.msg18985.html#msg18985 (http://cpcwiki.eu/forum/index.php/topic,1882.msg18985.html#msg18985)

You can also use hardware sprites to step in for colour clashes.

MacDeath is essentially correct in this matter.

tho sw sprites are used often on the c64 they are used mainly as bullets in charset mode where cpu usage can be held to a minimum and they can be "blocked" on rather than fully sw sprited on.

as i have said the only major game i can think of offhand to use it for a main character and still keep speed is IK+ where 2 players are sprites and 1 is made from sw. tho to do this any background has to be blank in order for no attribute clash to occur and/or allow the player to be blocked on rather than full sw sprite mask and removal to be required.

International Karate for the A8 also uses this method where it creates both players from sw using its 5 colour mode. examine the c64 and a8 versions on youtube you will see that the c64 sprites for IK cross into the "picture" area whereas the a8 ones are always over flat colour.

MacDeath is also correct that at 1mhz the c64 is not at all suited for sw spriting. examine the vids of Karateka from 1984 where EVERYTHING is sw on all computer versions and see how slow the c64 is compared to the a8 version.

Steve

C64 is saved from being a piece of dooky junk by its hardsprites, hardscrolls and SID.

When you want to do something in software... you simply cannot be as good as a CPC IMO.

Despite attributes, the "normal" 160x200x16 mode on CPC is far better than C64's.
No need to worry with clashes and a larger palette choice (not in greys and browns...though)

The same goes with the Mode1 320x200x4... easier to get good looking sprites effects in Soft... yet ok there are less colours on screen.But despites those less colours, you can get stuff more detailed because no limitation per character... = 3 colours for sprites (4th colour as mask) and 4 colours for 8x8 backgrounds tiles...


But ok, CPC is so much heavier on the graphical matter that it needs a 128K config to run "properly" IMO.


Anyway Prince of persia was quite decent on PC Dos in CGA display...
You should aim at this kind of graphics on C64 IMO...


Yet of course the possibility to get more colours on C64...
The part of background where the player can't go ("foreground" bricks/stones...) do not bother with attribute clashes.


Needless to say the sound is to be far better as PC's beeper...lol.

well not wishing to turn this into a vs thread but the hardware sprites, 320 pixel resolution hardware scroll and the best soundchip for over 10 years was what actually made the c64 the games machine of its time, so you can't really isolate them tbh they were a package.

the hardware made it unnecessary in most cases to have to resort to cpu intensive sw methods.

and yes the amstrad was easier to design graphics for, as it was like designing for a low res ST, but to say its better is to ignore the fact that it has no hardware to help out the cpu which also means for many games it simply isn't as good a mode as c64 charset at 2k per screen. even an ST with a 7.9mhz processor couldnt out do a c64 with sw, doing what it was best at, scrolling arcade games.

and i think i can do "bit" better than pc cga using colour ram to make fiery torches and to add extra colour to portcullises, chompers and the background brickwork

Steve

Hi,

I could be wrong but i thought the first version of prince of persia was done on apple 2.
Which uses a 6502 cpu at 1 mhz, and has not much RAM (48 or 64).
C64 has almost the same cpu, better graphics, better sound (than apple II) and enough hardware sprites for the main character and one guard/ennemy.
You can have a nice version of prince of persia on C64 !  :)

Maybe ported from apple 2 ?

according to the apple technical PDF for PoP written by Mechner in '89 then the apple II version is for the E type with 128k ram. of which he lists he uses 127.5k of it.

oh and the apple screens memory is apparently constructed in such a way that its faster to write to under cpu than the equivalent c64 modes. which i can well believe judging by the disparity in speed between the 2 versions of Karateka.

Steve

Steve,

If you really want to investigate if it's doable with character graphics, then the NES version is the best one to look at. That one has been redone using an 8x8 grid. Looks a bit odd though, and you'll need tons and tons of tiles. Not a problem on the NES.
And then it's a lot of code, even if you have to just reverse engineer and understand it. Maybe better wait until I publish my work (after I'm done). :)

i have already redone almost all of the graphics based on an 8x8 grid and aligned to character edges.

to do so would require a c64 version to use tiles based on a 64 pixel height instead of the pc/apple versions 63 pixels. i realise that it is set to 63 to enable the 3 pixels at the top to be used for the  tiles from the screen above. however at 64 pixels high 3 levels would make 192 out of 200 lines, the top 8 could then be used for the blocks from above. this however would mean there was no room for the "life" bars and timer, so the most obvious solution to this on the c64 would be to open the bottom border and sprite them in there.

locking the c64 to 64 pixel high tiles would have the effect of reducing the character count by 2/3 as the characters in the tiles for each of the 3 "levels" on a screen would then be repetitious.

the attached image generates somewhere in the region of 125 characters (i think) and another point is that the 256 character limit only applies per screen and not all tiles are used on each screen so maybe it is reasonable to "construct" your character set as you need it dynamically?

bearing in mind that there are many characters that are common to all screens. many of which are on that screen below and that generally speaking only the left edges of the floor tiles would change with any frequency and they only number 3 or 4.

Nice to see an example which also looks great. Do you have an image of the sprite and enemy? Would be nice to see the whole mock up.

You know that you'll also need to animate those screens, right? Gates moving down, jaws chopping, floors jiggling, torches with flickering flames, and constantly build a mask every frame for the player and enemy sprites. Also any of those tiles can be partially obscured by the block to the right (and they are in many levels).
And didn't you cheat there with the flame colors? Or are those supposed to be sprites?

well i figure that certain liberties would need to be taken on the animation. to make it work.

the gates for instance "could" animate on 8 pixels steps, you will also note that the grid on the gate for the most part is a single tessellating character and only the 4 or so at the bottom would need to change once to being on black background.

jiggling of the floors could be done by swapping character definitions. The left and right sides of the raised "pressure" tile can double as jiggly floor. swapping alternately. the falling of them would cause some aggro, but if they fell on 8 pixel steps this could be minimised.

torch flames tho not shown on this pic i have defined currently as hi res 1 char wide and 2 high 3 frame animation in characters. their graphics are never crossed so 2 bytes of colour ram could be used to colour them and flickered like mad thru white, yellow and red to provide a flame look i think.

you will also notice that the outline brickwork is currently depicted as dark blue colour ram currently conjectural.

chompers can again animate on 8 pixel boundaries and again will use minimal additional "edge" characters something like the pic below (the white stripe of color ram is also conjectural at this time).

pretty much all of the blocks to the right that intrude are solid characters like wall and you will note that i have repositioned the twin square columns slightly so their left edges are byte based (blocked on rather than sprited on)
masking against columns would therefore become an exercise in knocking uniform vertical stripes out of sprites. going behind and infront of chompers could still be a royal pain in the arse to do tho :)

Well the C64 can, IIRC, put sprites either in front of or behind the foreground. So assuming you can avoid situations that need both it's probably possible to let the hardware handle sprite masking for you.

Quote from: andycadley on 19:46, 14 May 11
Well the C64 can, IIRC, put sprites either in front of or behind the foreground. So assuming you can avoid situations that need both it's probably possible to let the hardware handle sprite masking for you.

When you do the sprites behind foreground using hardware they don't go behind ALL the colours :(  they still appear over background and one of the other colours (can never remember if its the character colour or one of the multicolours).   Masking the sprites in software isn't a problem though.

Quote from: PeteD on 10:51, 18 May 11
When you do the sprites behind foreground using hardware they don't go behind ALL the colours :(  they still appear over background and one of the other colours (can never remember if its the character colour or one of the multicolours).

If memory serves, it's the multicolour generated by %01 bit pairs in the graphics data.

There's a couple of games that use it such as Implosion, a quick flick of a priority register and the player's sprites appear to be moving between the two layers of background without any software masking needed.

Quote from: MacDeath on 11:28, 06 May 11
As they always do : sprite multiplexing.

http://codebase64.org/doku.php?id=base:sprite_multiplexing (http://codebase64.org/doku.php?id=base:sprite_multiplexing)

Getting them in large pixel enable 4 colours (3+transparent)

Sorry, I just noticed this. So a "normal" hardware sprite (24x21) holds 3 colours which are 2 PLUS transparency? (and not 3+transparency as I thought?)
Double Dragon 2 sprites has 4 colours+transparency making 5 colours. The game has 2 players and 2 enemies on screen at once.

Quote from: STE86 on 15:53, 07 May 11

International Karate for the A8 also uses this method where it creates both players from sw using its 5 colour mode. examine the c64 and a8 versions on youtube you will see that the c64 sprites for IK cross into the "picture" area whereas the a8 ones are always over flat colour.

So you could get an extra colour (light grey or blue) on the main sprite if need be?

on the c64, you can choose hi resolution for sprites, which gives you 1 colour + transparency, resolution is then 48x21.
or you can choose multicolour, which gives 3 colours + transparency, resolution is then 24x21.

You can give each sprite 1 unique colour. in multicolour, 2 other colours are then shared over all sprites.

Now you can re-program the sprite positions and graphics locations -> "multiplexing".
You can also overlay hi resolution sprites over multicolor (so you can do hi-res outlines, with multicolour to fill the internal areas).

Quote from: sigh on 12:47, 18 May 11
Sorry, I just noticed this. So a "normal" hardware sprite (24x21) holds 3 colours which are 2 PLUS transparency? (and not 3+transparency as I thought?)

In 12x21 pixel multicolour there are four colours in total with pixels being generated from bit pairs; one sprite colour each, two shared colours that are used by all sprites and transparency.

Quote from: sigh on 12:47, 18 May 11
Double Dragon 2 sprites has 4 colours+transparency making 5 colours. The game has 2 players and 2 enemies on screen at once.

In Double Dragon 2 each fighter is two hardware sprites, one for the top half of the body and i'm guessing that one is set to pink, whilst the other for the lower is set to whatever colour the trousers need to be; the shared colours are brown and, if i'm right about pink for the upper colour, brown.

Quote from: arnoldemu on 13:01, 18 May 11
on the c64, you can choose hi resolution for sprites, which gives you 1 colour + transparency, resolution is then 48x21.
or you can choose multicolour, which gives 3 colours + transparency, resolution is then 24x21.

24x21 for high res and 12x21 for multicolour.

Quote from: TMR on 13:07, 18 May 11
24x21 for high res and 12x21 for multicolour.

thank you for the correction :)

Ahhhh right. So you can have "8" 12x21 multicolour wide pixel sprites on screen at once without having to resort to multiplexing and dealing with raster lines etc. Hmmm - I'm beginning to understand a little better about STE86 approach to the POP and enemy sprites...

Quote24x21 for high res and 12x21 for multicolour.

yet using the same surface on screen... isn't it ??

Quote from: arnoldemu on 13:01, 18 May 11
You can also overlay hi resolution sprites over multicolor (so you can do hi-res outlines, with multicolour to fill the internal areas).

Would doing this use an extra sprite? (Just thinking of high res POP)

Edit: I suppose it would as using this method would be 2 + transparency instead of 1.

Quote from: sigh on 15:10, 18 May 11
Would doing this use an extra sprite? (Just thinking of high res POP)

Edit: I suppose it would as using this method would be 2 + transparency instead of 1.

Yes.

It would work like this:

1 sprite, which is multi colour. This uses 3 colours + transparency. it defines the colours for the areas.
The pixels have been setup carefully so that when the hi-resolution one is overlaid they do not "spill" out.

You then take 1 more sprite, which is high resolution. It has 1 colour and transparency. You can set it's colour.
Position the high resolution one over the top of the multi-colour one. Now you have colour with hi resolution outline.

So you would need x2 the amount of sprites to make the pop main character this way.

Quote from: MacDeath on 14:44, 18 May 11
yet using the same surface on screen... isn't it ??

Yup, the C64 essentially "thinks" at 320x200 pixels all the time (which is why it can mix modes between sprites or indeed on a cell by cell basis in some character-based screen modes) and just has bits pairing up when objects are set for multicolour mode.

Target Renegade

http://www.lemon64.com/games/details.php?ID=2603 (http://www.lemon64.com/games/details.php?ID=2603)

is one of the best examples of this method on the c64.

the sprites however are all designed to fit into exactly what the c64 display in order to do this.

unfortunate PoP was never designed to be c64 "friendly" :)

It also helped that Dave Collier was IMHO one of the most technically proficient coders the c64 ever had.
and probably one of the least publicised.

Steve

Would you consider making use of the C128 instead of the C64 if the squeeze got too much? I know that that the C128 is pretty much a completely different machine, but having the extra MHz and the extra 64k memory for animation frames and loading data, you may be able to use some software sprites if needed, seeing as the game doesn't scroll, and the background is black most of the time.

It'd be better to go to cartridge than a different machine.   They're emulated so no problem there and for people who want to use hardware, flashable ones are available relatively cheaply.    Personally I think it will fit in 64k (after various calculations, compression methods, using character screen instead of bitmap and checking memory usage with Ste's graphics) with cutscene stuff being read from disk when needed then the data that replaced being read back again.   It's a wait of X number of seconds that C64 users are all too used to anyway.

QuoteTarget Renegadeon C64

Graphics are good, but the limitation in displayed sprites is somewhat drastic.

Yet yes, this one manage to be better looking than CPC's Target Renegade, which was notoriously screwed concerning graphics (depends, some levels are OK btw....).


I aggree concerning cartridge game.
As told in GX4000carts topic, it is a way to freeed the RAM a lot and get a lot of extra stuff...

BTW C64 retains its Video limitations.
And C128 is perhaps not that better on Video. More RAM is OK... but the Extra hardwares and MHz are not that usable in games. Are they ?

Perhaps in Cartridge format, more SoftSprites may be used but As i told, C64 is not that well designed to be that good in SoftSprites.
But tthis is better than nothing.

Pete, would you mind letting me have a look at your calculations? To make sure you didn't miss something?
Btw, my version is close to alpha status now. Main missing features are the mirror/shadow man stuff and cutscenes/titles.

Quote from: mrsid on 12:31, 19 May 11
Pete, would you mind letting me have a look at your calculations? To make sure you didn't miss something?
Btw, my version is close to alpha status now. Main missing features are the mirror/shadow man stuff and cutscenes/titles.

Yeah, I'll tot it all up later.  There's nothing definitive yet, just stuff based on how I'd do it all starting from scratch and then calculations based on Ste's graphics (how many chars he needs etc), anim frame info and the sprite compression test I wrote last year.  I've not continued much on the code (only really thought about doing anything on it again when Ste started to convert the title sequence) because Ste told me you'd got quite far with your version since the last time we saw what you'd done on it so there probably is some stuff I've missed.   Even if I have missed things though I still think it'll fit, maybe have to drop a few sprite frames here and there but with the converted ones in 2:1 ratio there are some that are sooooooo close they're kind of redundant.

yes at least 5 if not 7 out of the amazing 15 frames it takes to animate drinking a potion would be the first candidates for a kickoff.

Quote from: MacDeath on 12:30, 19 May 11
Graphics are good, but the limitation in displayed sprites is somewhat drastic.

Yet yes, this one manage to be better looking than CPC's Target Renegade, which was notoriously screwed concerning graphics (depends, some levels are OK btw....).

I actually prefer the character designs on the CPC version, despite the C64 high res look. The animations on the CPC for that game are nicer too.

Quote from: MacDeath on 12:30, 19 May 11

And C128 is perhaps not that better on Video. More RAM is OK... but the Extra hardwares and MHz are not that usable in games. Are they ?

I really hope thats not true.....

Quote from: MacDeath on 12:30, 19 May 11
BTW C64 retains its Video limitations.

There aren't many machines without video limitations out there...

Quote from: MacDeath on 12:30, 19 May 11And C128 is perhaps not that better on Video. More RAM is OK... but the Extra hardwares and MHz are not that usable in games. Are they ?

They're used in a few but because the C64 was so dominant there are very few C128-specific games out there and they don't take full advantage of the hardware. 2MHz can be kicked up from C64 mode, it won't work during the visible screen but for the third of a frame where it's displaying borders the processor can be running double time - most of Andrew Braybrook's later games do that, upping the software sprite count and scroll speed in cases like Alleykat and Uridium Plus.

Quote from: MacDeath on 12:30, 19 May 11Perhaps in Cartridge format, more SoftSprites may be used

Having a metric f**kton of ROM for unrolled draw code or optimal sprite data can make a significant difference to software sprite engines; it even helps for hardware sprites, Ocean's Toki animates the player character by flipping between cartridge banks, the cracked versions of the game all had to drop the music to make room in memory for those animations.

Quote from: MacDeath on 12:30, 19 May 11but As i told, C64 is not that well designed to be that good in SoftSprites.

It depends on the software sprites, which mode they're being handled in, what's required of them and so forth; remember that C64 games lean towards running at fifty frames a second and that makes the job of getting a high software sprite count more difficult; if C64 gamers hadn't come to expect and indeed demand that high refresh speed, programmers could have got away with a lot more.

Quote from: TMR on 18:29, 19 May 11

It depends on the software sprites, which mode they're being handled in, what's required of them and so forth; remember that C64 games lean towards running at fifty frames a second and that makes the job of getting a high software sprite count more difficult; if C64 gamers hadn't come to expect and indeed demand that high refresh speed, programmers could have got away with a lot more.

Very true. I can understand the high frame rate for fast scrolling games, but other than that you could get away with a lot less.

Quote from: sigh on 22:14, 19 May 11
Very true. I can understand the high frame rate for fast scrolling games, but other than that you could get away with a lot less.

It's the same problem across the board for 2D, C64 gamers rapidly came to expect 50FPS from scrolling games so a static screen title dropping below that speed would have been ripped to shreds by the reviews and punters alike.

I have noticed the lack of enemies in several C64 games, one example is Renegade. Wouldn't the C64-reviewers notice that too and say 50 Hz or 25 Hz or even less, the updatespeed isn't the only thing that makes a game. Lets see some more sprites. But as TMR say, they probably didn't. Weird as the same reviewers in some magazinehouses worked for several 8-bit magazines, C64, Amstrad and Spectrum

Yup! Lack of enemies on beatem up games were a huge problem with the C64. Target Renegade, Golden Axe, Double Dragon 1 and 2 all shared the same fate and it makes me wonder that if they were to have dropped the rate to half, whether that problem could of been overcome using some software sprites for enemies. When I look at Sub Hunter on both the C64 and CPC, I see very little difference in speed and smoothness.

Something like POP needn't run at 50fps.

Prince of Persia runs at 15fps originally.

Quote from: sigh on 09:44, 20 May 11Yup! Lack of enemies on beatem up games were a huge problem with the C64. Target Renegade, Golden Axe, Double Dragon 1 and 2 all shared the same fate and it makes me wonder that if they were to have dropped the rate to half, whether that problem could of been overcome using some software sprites for enemies.

Not really no, software sprites have other impacts if you're using character-based screen modes (which all the games you listed are) and it reduces the number of colours in play, stops objects being able to swap unless sprite colours match backgrounds and so forth.

Converting a game is about concessions, and something usually has to give - take Gryzor on the Amstrad for example. Target Renegade and both versions of Double Dragon use overlaid sprites to get something closer to coin-op resolution and that ties up hardware sprites, Golden Axe's objects were designed for two sprites wide and again the limits per scanline come into play. Different design choices and perhaps a little creative coding could've got more enemies on screen in the same way that Double Dragon 3 does.

Quote from: sigh on 09:44, 20 May 11When I look at Sub Hunter on both the C64 and CPC, I see very little difference in speed and smoothness.

i do, at least it stands out quite a bit on real hardware - are you comparing both on real machines or just under emulation?

Quote from: sigh on 09:44, 20 May 11
Something like POP needn't run at 50fps.

These days there's an element of "macho programming" as well, coders thinking that if it can be done at 50FPS let's feckin' do it! =-)

I find it very unlikely that even Dave Collier could make PoP run inside a frame :). considering how much overlaying, masking and software character creation would have to take place even in character mode let alone on a 10k bitmap.

so "macho" or not i wouldnt get your hopes up.

more "classic" games run in 2 or even 3 frames than u may think. Exploding Fist and Paradroid spring to mind immediately.

Steve

Considering the CPC f.e. it's no problem to scroll with 50 fps in overscan (32 KB V-RAM) and to move a player sprite + two enemies f.e. (and maybe some shots or smaller stuff whatever).

The question is what exactly do you want to do in a single frame?

Quote from: TMR on 15:32, 20 May 11
Not really no, software sprites have other impacts if you're using character-based screen modes (which all the games you listed are) and it reduces the number of colours in play, stops objects being able to swap unless sprite colours match backgrounds and so forth.

Ahhh Okay. Well this makes me feel even more that the C128 needed more love! ;D

Quote from: TMR on 15:32, 20 May 11
Different design choices and perhaps a little creative coding could've got more enemies on screen in the same way that Double Dragon 3 does.

I had a look at this on youtube which showed 3 enemies and 1 player. I'm taking that you could still have the 3 enemies in a 2 player mode, but the animation and graphics seems to have been sacrificed quite a bit in order for this to happen?

I had a C64 until 2008 and played many games ,and as Sigh pointed out, in some games I realised about the lack of enemies  which I found strange, f.e. playing UN Squadron rarely you will see more than two sprites on screen (the game gets really boring). Playing Altered Beast happens about the same, as you go forward you only see falling one zombi from the sky when normally it's three of them, also facing the first level boss it only throws at you 2 stones while in CPC you can count 5 of them.

On games like Toki where you can find 4 enemies on screen or even 5 (If I remember well), but everything seems more sluggish than a normal C64 game.

Quote from: TMR on 15:32, 20 May 11
i do, at least it stands out quite a bit on real hardware - are you comparing both on real machines or just under emulation?

I did'nt have the chance to play Sub hunter on a real C64, what differences do you notice on them?

Quote from: sigh on 19:55, 20 May 11Ahhh Okay. Well this makes me feel even more that the C128 needed more love! ;D

You dont get any advantage from a C128 in that respect; character-based screens are still handled the same and having more CPU power to throw at jobs can't fix the lack of software sprite colours.

Quote from: sigh on 19:55, 20 May 11I had a look at this on youtube which showed 3 enemies and 1 player. I'm taking that you could still have the 3 enemies in a 2 player mode, but the animation and graphics seems to have been sacrificed quite a bit in order for this to happen?

In two player mode it handles at least six moving objects on a line, but it's only using eight hardware sprites in total and it turns on vertical expansion.

The problem is more about how the objects move really, producing six or more objects with two sprites each (as with Double Dragon 2) is theoretically possible, but if they need to move vertically it becomes difficult to time the sprite recycling to avoid glitches; the Melbourne House Double Dragon has that cheap-looking gap between the two halves of each person to make recycling easier, but it's putting enough hardware sprites up for eight characters were it not doing overlays.

Quote from: trocoloco on 10:00, 21 May 11
I did'nt have the chance to play Sub hunter on a real C64, what differences do you notice on them?

The difference between twenty five frames a second and fifty - some folks can't see the difference between every other and every frame but i can, painfully so in some cases.

Quote from: STE86 on 17:11, 20 May 11
I find it very unlikely that even Dave Collier could make PoP run inside a frame :) . considering how much overlaying, masking and software character creation would have to take place even in character mode let alone on a 10k bitmap.

And that's probably one of the reasons it took a while for anyone to even try it... that'd be the passion killer for me if i didn't dislike the game to start with. =-)

Quote from: TMR on 17:38, 21 May 11
And that's probably one of the reasons it took a while for anyone to even try it... that'd be the passion killer for me if i didn't dislike the game to start with. =-)

at max quality with no colourclash the range should be from 190Hz  through 250 Hz, oops sorry. That was Quake. I sometimes feel there is something religious behind the framerate importance. Feck enemies, just keep the framerate up

QuoteI have noticed the lack of enemies in several C64 games, one example is Renegade.

Yup... due to the actually limited number of HardSprite per scanline.


And also due to the fact C64 deeply suck in Softsprite, due to the severe attributed limitation.


Ok wide pixels "mode0" , the 160x200x4/character attribute based mode can actually do like some sort of Speccy with a bit less attribute clashes but wide pixels in very few colours actually sucks.


Beat'hemalls like Renegade are in cavalier perspective/isometric...
Square attributes clashes hate isometric and cavalier perspective.


And to be fair, for a C64, to manage software masked sprites must be even far worse than on CPC...


Concerning C128... I admit I like the fact the Extra RAM and the  almost Dualcore are kool features, sadly I've heard the extra Z80 is perhaps not easy to actually exploit alongside the MOS8502 and the Video Hardsprites+Scrolls...
Also the machine could have used a new palette (like the Atari ST's one at least) or extra video modes.
Also some extra sprites capabilities wouldn't hurt...

Quote from: ivarf on 20:25, 30 August 12

at max quality with no colourclash the range should be from 190Hz  through 250 Hz, oops sorry. That was Quake. I sometimes feel there is something religious behind the framerate importance. Feck enemies, just keep the framerate up

Blimey, talk about thread necro...

No, it's not something religious but, if you're used to just about everything running at 50FPS, it's a lot harder to fully enjoy a game dropping below that speed especially if that speed change appears to have an adverse effect on control response; that's the only real difference in gameplay terms between the Spectrum and CPC versions of R-Type but it's considered a significant difference by both camps.

Jason, it's a c64 thing you know?

It matters greatly to anyone who cut their teeth on a c64. anything trying to scroll outside of a frame was taboo to us.

Nobody else actually expected it, except c64 devs and gamers :) They are all quite happy with 25hz and less.

I remember how shocked I was in '87 that by and large, the Amiga couldn't manage anything significant in 1 frame and it took me some time to accept the 50hz "barrier" had gone.

once you break 1 frame you may as well hold it outside of 1 frame because there really is nothing worse to me than seeing games pop in and out of totally smooth.

Steve

Sure and the c64 people has special eyes that let them to see through walls :P Come on!!! Everybody can see & feel when a game goes at frame, even a Dragon user, in other case the oculist is a nice place to visit  ;D

But the important thing in a game is the PLAYABILITY, a game need to be fun, nothing else. And that c64 attitude of "a game should go to 50fps" has made more more harm than good to the system, transforming a big part of the c64 catalog in sad technical demos with a nice sid song. You can see in the Lemon64 TOP100 (http://www.lemon64.com/games/votes_list.php), how those 50fps games are not the most memorable between the c64 fans, and the 90% of that list are not going to be worst games for going at 25fps or 12.5fps.

Quote from: STE86 on 12:03, 01 September 12
Jason, it's a c64 thing you know?

It matters greatly to anyone who cut their teeth on a c64. anything trying to scroll outside of a frame was taboo to us.

Which is why (as i was quoted as saying) i wouldn't have done PoP on the C64, that and i didn't really feel it was playable until pretty recently.

Quote from: SyX on 13:05, 01 September 12Sure and the c64 people has special eyes that let them to see through walls :P Come on!!! Everybody can see & feel when a game goes at frame, even a Dragon user, in other case the oculist is a nice place to visit  ;D

Not everybody can see the difference between 25FPS and 50FPS and in some cases they struggle to spot a difference between those and 12.5FPS too, seeing games at those speeds as "smooth" when others are aware of a significant difference. That came as a surprise to me and was one of the reasons my about-to-be-released Atari 8-bit shoot 'em up is finally coming out; the 25FPS scrolling was something i've never been happy with but, since at least some players will never notice, i eventually decided to go for it.

Quote from: SyX on 13:05, 01 September 12But the important thing in a game is the PLAYABILITY, a game need to be fun, nothing else. And that c64 attitude of "a game should go to 50fps" has made more more harm than good to the system, transforming a big part of the c64 catalog in sad technical demos with a nice sid song.

Playability is incredibly subjective and what you personally feel to be a tech demo is someone else's playable game so there's very little point trying to discuss it in those terms. And every machine has games in it's back catalogue that some would consider to be tech demos, i believe a few people have said something similar about Fres Attack or Killer Cobra for example but i still enjoy them both as games.

C64 was great for Playability,great for sound and great for graphics, I do not know any of the technical details but The machine was fun and a lovable,smooth and a real pleasure. If the Amstrad had had proper backing and taken off at the same time, it would have been interesting to see the Amstrad pushed with enthusiasm with loads of bedroom programmers competing.I'm sure that there would be a higher hit ratio.But alas it wasn't to be.

Because the original color palette is limited and need yellow for tiles maps too ? Because black is for the background ? Because yellow hair is for heroes and super sayen ? :p

Quote from: TotO on 11:25, 02 September 12
Because yellow hair is for heroes and super sayen ? :p

Well, it's gone a bit mousey over the years but i'm taking that as a complement... =-)

Quote from: TMR on 01:50, 01 September 12
No, it's not something religious but, if you're used to just about everything running at 50FPS, it's a lot harder to fully enjoy a game dropping below that speed especially if that speed change appears to have an adverse effect on control response; that's the only real difference in gameplay terms between the Spectrum and CPC versions of R-Type but it's considered a significant difference by both camps.

I'm not sure that's entirely true. R-Type on the CPC was mostly slated for being a big pile of near monochrome, whose Speccy heritage was so prominent that it even features "attribute clash" on a machine that has per-pixel colours. To add insult to injury, the Speccy version that it was ported from is practically awash with colour making it look so much better than the typical Spectrum game.
The net result is that Speccy owners tended not to notice some of the little flaws here and there (the number of people who describe it as smooth-scrolling when it clearly jerks along a character at a time is astounding), whereas the CPC version has become more and more the poster child for everything that sucks about quick and dirty ports to the machine.
Of course 50FPS updating is nice if you can manage it and retain scrolling at a playable rate. For all it's lauded on the C64 for example, Uridium has always struck me as pretty much unplayable compared to the Spectrum/CPC versions. They don't scroll as fast, but slowing the game down does wonders for making it a bit more playable and less of a pointless memory test requiring you to react to things you've not even seen yet. If the C64 version ran at a similar pace, it would be a lot better for it IMO (and without those stupidly unfair homing things, might even be a good game).

Quote from: andycadley on 23:52, 03 September 12
I'm not sure that's entirely true. R-Type on the CPC was mostly slated for being a big pile of near monochrome, whose Speccy heritage was so prominent that it even features "attribute clash" on a machine that has per-pixel colours. To add insult to injury, the Speccy version that it was ported from is practically awash with colour making it look so much better than the typical Spectrum game.

But that attention to what is, essentially, cosmetic detail flies in the face of what SyX said, that "the important thing in a game is the PLAYABILITY, a game need to be fun, nothing else" (my emphasis). There's subjectivity involved of course, but R-Type on the Spectrum is considered by many to be playable so those colour counts or the "simulated" clash shouldn't make the slightest difference (and some players presumably made their decision about R-Type before having seen the Spectrum iteration), leaving only the lower refresh speed and the subsequent delay on the joystick response to explain why one version is considered playable and the other not.

Quote from: andycadley on 23:52, 03 September 12Of course 50FPS updating is nice if you can manage it and retain scrolling at a playable rate. For all it's lauded on the C64 for example, Uridium has always struck me as pretty much unplayable compared to the Spectrum/CPC versions. They don't scroll as fast, but slowing the game down does wonders for making it a bit more playable and less of a pointless memory test requiring you to react to things you've not even seen yet. If the C64 version ran at a similar pace, it would be a lot better for it IMO (and without those stupidly unfair homing things, might even be a good game).

As i noted previously, playability is subjective so i disagree with pretty much everything you said and prefer the C64 version by a fair distance. And it's years of playing Uridium that mean i'm a reasonable Killer Cobra or Fres Attack player because they're both scrolling at about the same speed as Uridium does at full tilt.

Quote from: TMR on 14:40, 04 September 12
But that attention to what is, essentially, cosmetic detail flies in the face of what SyX said, that "the important thing in a game is the PLAYABILITY, a game need to be fun, nothing else" (my emphasis). There's subjectivity involved of course, but R-Type on the Spectrum is considered by many to be playable so those colour counts or the "simulated" clash shouldn't make the slightest difference (and some players presumably made their decision about R-Type before having seen the Spectrum iteration), leaving only the lower refresh speed and the subsequent delay on the joystick response to explain why one version is considered playable and the other not.

From a purely academic point of view, of course the judgement of any game should be entirely down to the playability, it's all that should matter. Reality is entirely different though, the cosmetic details can and do make all the difference. And many of the magazine reviewers back in the day were floating between Amstrad/Spectrum magazines, so were undoubtedly mentally comparing versions. And things like the colour clash stand out a lot more when the game is downgraded to four colours as opposed to the veritable rainbow of colours littered all over the Speccy release.

Quote from: TMR on 14:40, 04 September 12
As i noted previously, playability is subjective so i disagree with pretty much everything you said and prefer the C64 version by a fair distance. And it's years of playing Uridium that mean i'm a reasonable Killer Cobra or Fres Attack player because they're both scrolling at about the same speed as Uridium does at full tilt.

I knew you would. ;-) I still fail to see the entertainment value in a game where you crash into things because you hadn't memorised what's about to come up. It all just seems a little bit too random for my tastes.

Quote from: andycadley on 21:56, 04 September 12
From a purely academic point of view, of course the judgement of any game should be entirely down to the playability, it's all that should matter. Reality is entirely different though, the cosmetic details can and do make all the difference.

i'd disagree with that because it doesn't necessarily make a difference to everybody in the first place and we can't realistically assume that even 50% of those who formed an opinion of R-Type back then did so with knowledge of the Spectrum version or having read a review of the CPC port. So some people at least judged the game purely on it's playability rather than comparative cosmetic detail but the overall consensus remains the same.

Quote from: andycadley on 21:56, 04 September 12I knew you would. ;-) I still fail to see the entertainment value in a game where you crash into things because you hadn't memorised what's about to come up. It all just seems a little bit too random for my tastes.

That's because you're crap at it and i'm not. [Smiles sweetly =-]

The Manta can be flown at low speeds for working through trickier parts of the terrain and there's a change of height when turning which can be used to dodge collisions as well so it's just a matter of of practising a bit to become proficient at handling the ship before you can take things at a more sedate, easier to respond to pace.

Quote from: andycadley on 21:56, 04 September 12From a purely academic point of view, of course the judgement of any game should be entirely down to the playability, it's all that should matter. Reality is entirely different though, the cosmetic details can and do make all the difference.

About R-Type CPC, the problem are both.
You get a "2 colors like" playfield with a poor playability and a very slow scrolling. The Spectrum version is far better.
A good game is before all a good concept with a good gameplay.