This is a late release from OCEAN.
http://www.cpc-power.com/index.php?page=detail&num=3622 (http://www.cpc-power.com/index.php?page=detail&num=3622)
Videos of other version, I cxouldn't find videos from the 6128PLUS version...
C64 :Speccy :As we can read :
QuoteC64 :
Code : Tom Pinock
Grafix : Andrew pang & Chris Edward
sounds/tune : Sonic project
speccy :
Code : Damian Stones
Grafix : Steve B.
sounds/tune : Sonic project
Amstrad :
Code : Damian Stoned (lol)
Grafix : Chris Hansen
So ok.
We had a graphician who could do proper tiles for the background, mostly ported the cinematics graphics (some of them) yet recoloured them too...
And couldn't finish his job on the sprites because...
The coder first had to get a comlete speccy version, then couldn't do a proper Amstrad PLUS version because it was supposed to be released on cartridge but finally was released on Disk... This can make a huge difference.
The game as it was probably intended to be released, would easily need 256K or even 512K ROM.
According to the quantity of content : cinematics, lots of sprites or tiles.
just imagine if the 1bpp sprites tiles were properly 4bpp...
Ideal config could even be 6128PLUS AND 512K ROM...
Damian Stones pages :
http://uk.linkedin.com/in/damianstones (http://uk.linkedin.com/in/damianstones)
http://www.mobygames.com/developer/sheet/view/developerId,91695/ (http://www.mobygames.com/developer/sheet/view/developerId,91695/)
he may still have the source... ;)
Supposed to be released as a Cartridge version according to the various advertisement of the era, but Amstrad stopped the support of the range so no more cartridges, also the game would have needed at least a 256K cartridge and we know Amstrad never produced greater than 128k cartridges.
It is said to be a 6128PLUS only release.
I wonder then : is this because it was only released on Disk and 464PLUS had no proper and official DiskDrive option, or is it because it actually needs 128K RAM ?
The game is obviously speccy ported.
And looks unfinished.
2 theories :
=the game wasn't supposed to be that speccyported but ended up with many speccy code parts because it was rushed to the release as the Amstrad range was about to be discontinuted, so the coder added speccy parts to get shit done in 3 weeks...
=They started from the Speccy code and really wanted to improve it totally (just like many other OCEAN classic, Robocop or Batman anyone ?) but couldn't do it completely.
Features and PLUS features :intro page :
=no proper menu... quite a shame as you can't redefine keys per example.
=the "golden" title is in Hardware sprites and features colour cycling.
=there's a mode change so the text at the bottom of the screen is in mode2 probably, yet letters are 16x8 = the size of a mode1 character font.
I will assume this is mode2 but this can also be a simple emulator screwup ir corrupted .dsk. (mode1 then ?)
get it running in Mode2 yet enable less CPU waste to convert into Mode1 I guess.
=background picture is in mode0.
Cinematics :
=the game feature "cinematics", which is good, they looks like graphically ported from the C64 version I guess.
=and the text is still in mode2.
The game :ouch, now this hurts.
=the background tiles were obviously well redone and looks quite good.
=The sprite keeps the character based technic from the speccy version, but as it is in mode0 the pixelisation suffers cruelly.
=each cell from the sprites are in "1bpp" with "attributes", this means :
=== they are unmasked (black square border)
===and don't move smootly (but move character per character)
===only 2 colours per character, so the mode0 is far from being at its best.
=said character are speccy sized so 4x8 (mode0)
="monster Sprites" can be actually quite big.
=the playfield is "Speccy sized" (128pixels wide, i guess) but the overall scren is Amstrad sized (160 pixels wide).
===some graphicall border (the claws ripping the doors open...) filling the extra surface.
==Sound was obviously not well treated due to lack of CPU/RAM ressource too.
HUD :
=top of the screen is in Mode2.
=bottom of the screen is designed from the Arcade and obviously for a 2 player gameplay, but I can't see any 2 player co-op mode... does it simply need to press button with 2nd joystick ?
Hardwired sprites :They seem to be particularly badly used IMO.
=the visor is of course done with 2 HardSprites.
===It changes when you put a special fire mode on (like bombs)
=the "fires shots" are done with 2 sprites and a lot of frames, so nearly fill all the sprites slots.
=The "Radar" seems to be generated with 2 Hardwired sprites too... ( ??? )
New post because the first is getting big.
Also the game seems to use some rasters to get the roof and ground in dark cyan...
The main effect being that it displays the unmasked sprites tiles a bit more.
Looks like this screwed the screenshot here :
(http://www.cpc-power.com/images/ecran_jeu1/3622.png)
I counted 22 colours on this one.
22 colours :
15 for the normal bitmap.
the 16th colours is used for the raster effect so it adds +4 colours.
Then add perhaps 2-3 colours for the Hardsprites there.
15+4+3 = 22.
But I may be slightly wrong of course.
I just couldn't find the tiles used by the monster sprites... I mean this could be 4x8 tiles in mode2 (1bpp) wich pass through a conversion into "attributed mode0 in 2 colours" .
not easy to find with winape.
Anyway, the lack of attributeless coloured mode0 just make the whole stuff terrible.
while Speccy manage quite well through a fine pixelisation, the amstrad's sprites simply look gross.
Also the mode2 "text" parts seem to get screwed by the emulation, or is it the dowloaded .dsk that is corrupted ?
With all those mode changes and rasters, this can explain the loosy emulation too.
Good old speccy engine has simply a lot of extra PLUS features IMO.
We often get speccyports with monocolour background yet "coloured sprites, or converting 1bpp speccy graphix into 2bpp Mode1 Amstrad.
This time this seems quite messy with the "Mode0 in character attributed 1bpp" on "normal Mode0" backgrounds.
oddly I managed to find the 2nd player HUD in the memory...
I will have to investigate this too.
As I told, the Hardsprites seem to be completely badly managed.
they tried too hard to keep the same kind of bullets effect as the arcade's one, but this fail miserably.
A simpler impact effect in 2 sprites/2 frame would be enough.
also the "Radar" sprites seem totally useless to me.
And those sprites seem to use colour cycling effect, which looks like a CPU waste in absolute.
Should have betterly used some of those sprite slots for special explosions or gore effects.
Also as you can see on the picture here, the visor despite being a hardsprite don't overlap the upper part (mode2) of the screen, nor the lower HUD.
Also I only found upper parts of most tiles.
I suppose the engine use some mirror effect to reflect the same upper part upside down for the lower part of the playfield, this would then lessen the RAM impact (half the tiles I guess) but use more CPU too.
The Speccy version is quite impressive for the platform, great presentation too.
Hi mate
As I said in the other topic, I'll do a longplay video of this....
...well I would do except I find the game impossible to play properly with the horrible lag firing and shooting at enemies when too many are on the screen. Half the time your shots don't even connect!
Is this an emulator bug? I'm using the latest version of WinApe.
Otherwise, if this is what the game is like on REAL hardware ... sheesh.... could someone find me an infinite continue credit? Also infinite extra weapon supply and no gun overheat would be nice too!!!! Then I'll do a longplay! :P
Wikipedia : space gun page :
http://en.wikipedia.org/wiki/Space_Gun_%28video_game%29 (http://en.wikipedia.org/wiki/Space_Gun_%28video_game%29)
QuoteProgrammer Damien Stones spent four months on the ZX Spectrum version. He kept the graphical detail of the backgrounds simple to allow for more action in the foreground. Taking into account the system's lower capabilities compared to the arcade hardware, Stones designed the game to handle a large number of on-screen sprites. As a result, Space Gun becomes more efficient the more action occurs on the screen, but will slow down during lulls in the game.
Oooooooooooookay.
Sadly no word concerning the Amstrad version.
Yet this is quite interesting.
If the engine is that speccy optimised, this explains why the 6128PLUS performs poorly.
All the tight codes get smashed by the cheer amount of extra weight everywhere.
Another additionnal weight :
The Amstrad version is in 160x200 (mode0) (not sure but this looks like it is).
while speccy is as usual 256x192...
This would not be a problem on a cartridge version I guess, prodided the ROM is bigger than 128k (let's say 512K would be enough then) as this theorically allows to get the tiles and sprites already properly coded (4bpp per exemple) and already reversed/mirrored/whatever...
the RAM then only serve as VRAM and score/ammunition/game progression storage.
No need to try to gain extra RAM from reducing the screen.
But as the game was then put into a Disk version, this is getting harder to keep the "320x200" instead of 256x192 I think.
No wonder it needs 6128PLUS and frequently multiload stuffs.
The "3D" effect (perspective) and the big sprites are simply Huge !
Zooming sprites and backgrounds multiply all those Datas.
Or need to get them "mirrorred" by CPU intensive process.
To get such game "playable", I even suggest the use of both a 6128 with 512k Cartridge and Disk for additionnal features such as saving Hiscores or loading cinematics or chiptunes...
So the 512K ROM would be mostly shittons of Graphic Datas already prepared (=less CPU intense processing of them).
Also i'm not even sure the game actually uses the Hardware scrolling.
(which is by the way not that CPU friendly anyway)
Side scrolling is 2pixels per 2 pixels (= a mode2 character...).
Well, being mode0 I suppose you can't have something too smooth.
Also it is supposed to be a slow scrolling.
Most Hardscrolls on GX4000 (Robocop2, Navy Seal, anyother ?) are fast as hell...
Do you have exemples of smooth and slow mode0 Hardscroll on PLUS ? (demo perhaps)
It is a source of wonder to see
Operation Wolf manages to stay fast and almost smooth.
Ok it only features horizontal scrolling...
I suppose there are far less tiles or sprites and those, while numerous, are not well frame animated.
But a good variety in opponents in Operation wolf, and a sheer amount of enemies on screen too.
Does Op.Wolf uses multiload or Extra RAM ?
Speccy chiptune is good.
I managed to find the Atari ST chiptune in mp3.
http://gamesdbase.com/Media/SYSTEM/Atari_ST//music/formated/Space_Gun_-_1992_-_Ocean_Software_Ltd..mp3 (http://gamesdbase.com/Media/SYSTEM/Atari_ST//music/formated/Space_Gun_-_1992_-_Ocean_Software_Ltd..mp3)
Post Edition :Ok I tried to launch the game in 64K RAM config and it simply didn't worked past the intro cinematics.
So it is really a 6128PLUS game and not a 664PLUS game.
What's sadening me a bity is that it still features some Cartridges version elements.
Sure the multiloadings so there are no cinematic pictures in RAM during game is Fair.
But still having the 160x200 sized screen and the Datas for 2nd player HUD is not that clever, so asd still having the HUD sized as a 2player stuff...
And again, the claws on the graphical border is good looking but wastes "VRAM as long as Data RAM.
While the playfield is still 128pixels sized (=256 speccy)
But hey, what else could they do when this was rushed to the release trhat way...?
The sprites being 1bpp was certainly due to both the fact that no time to finish this properly, but also RAM issues.
Would be a lot of Graphic Datas in proper twice weighting 4bpp (but half less pixels as mode0).
On sad part is that many "characters/tiles" for the sprites are not well designed to reduce the non masked parts.
Some tiles looks like having just perhaps 2 pixels actually used inside...
So the choice was between getting a good looking game with less wastes of CPU that couldn't actually run, or a shitty looking method with lots of CPU wasted so the game could actually run on at least 1 existing configuration.
Clearly a 128K Cartridge game would even have needed the 6128 config (extra RAM and Disk Drive support) to properly run...
The cartridge then containing only In GameGraphical datas and Sounds (and also a few drivers for Disk...) while Disk would contain extras (cinematics, level design) sounds ?
A 256K cartridge could exist but need a lot of cost down stuffs (content) and/or heavy use of compressed Datas (CPU intensive ? not even sure)...
And again a few extra RAM wouldn't hurt I guess.
A 512K Cartridge could do it clearly as it should be.
I'd still like to do a longplay for this game ... can anyone help out with any cheats for the game?
Also does anyone actually own the game to play on a real 6128+ to confirm the 'lag' issues?
For infinite continues change $24BA from $3D to $00 ;)
Quote from: SyX on 23:54, 17 August 11
For infinite continues change $24BA from $3D to $00 ;)
Thank you kind sir!
A strange quirk occurs with this - the boss battle at the end of stage 2 the boss become invulnerable with this value changed - changing it back and then being killed clears this - how odd!
(How did you find this poke out of interest?)
Quote from: Xyphoe on 06:55, 18 August 11
Thank you kind sir!
You are welcome! :)
Quote from: Xyphoe on 06:55, 18 August 11A strange quirk occurs with this - the boss battle at the end of stage 2 the boss become invulnerable with this value changed - changing it back and then being killed clears this - how odd!
Ups... well, the same happen with the infinite time poke (in $06D0 put $00), when the level is finish and the game gives bonus by the time doesn't wasted, you need to change back, but how i think that i would awkard i didn't put yesterday.
Quote from: Xyphoe on 06:55, 18 August 11(How did you find this poke out of interest?)
Well, i launched the wonderful debugger of WinApe and i looked for the usual pattern of instructions to control this things (LD A,(#xxxx) / DEC A / LD (#xxxx),A and similar variations or you can try to find the game variables initialization instructions, how there are 3 continues, i looked for LD A,3 / LD (#xxxx),A ), put a few breakpoints and VOILA! :D
I tried to find the inifinite energy, but my sleep time had pasted an hour before and i was so tired :laugh:
QuoteUps... well, the same happen with the infinite time poke (in $06D0 put $00), when the level is finish and the game gives bonus by the time doesn't wasted, you need to change back, but how i think that i would awkard i didn't put yesterday.
Perhaps some anti-cheat routines were implemented ? ;)
To be fair, as you know most Hackers used to also add infinite stuffs on the copies, this could actually be some sort a clever anti-piracy method.
BDC-Iron/Ghost used to play it at the time of its release, but you know, this guy never comes here as he don't like speaking english...
(can't be good at everything...)
Hi Xyphoe
Try &776a,&a7 infinite lives
Cool, I may them get to see the rest of the game. :)
Quote from: Johnny Olsen on 18:38, 18 August 11
Hi Xyphoe
Try &776a,&a7 infinite lives
Cheers Johnny! I thought you might come through with a few pokes :D
That seemed to work in places, but on the final boss battle it didn't ... I need to do some more testing and there's some strange bugs in this game.
I have completed and recorded this, but I may not have the full video with commentary done until Sunday night now due to a busy weekend unless plans change.
Video is now online
[AMSTRAD 6128+] Space Gun - Review & Longplay (CM) (http://www.youtube.com/watch?v=uLigTsx8dg4#)
OMG! The CPC version is so crappy! Such a Shame! The Sprites look like Reddoggs first try in BASIC. Therefore I never like Ocean! Few good games, but a whole lot of cheap crap - they wanted much money for. Having said this, the game idea of space gun is actually not bad. A good CPC version would be surely nice.
The strange part is the crappy "collision" detection.
And if getting the target and bullet in Hardsprite totally screws it up...
the visor move smoothly, but the monster are character based, so I guess the mix of both don't fit the speccy code where the visor and shoots are also character based.
perhaps you even need the visor to be pixel precise to actually hit...
Or just the CPU can't always find time to handle this properly...
seriously, Hardwired sprite have the advantage to take not a lot of RAM as the sprite have their own ASIC internal RAM.
But...
1- the ASIC must actually upload a new sprite when you switch on a special weapon : the visor changes, but we know there are only 2 sprites slots used by it while the reste is used by the bullets or even the scanner.
2- Ok, to handle Hardsprites is "easy"... not that well.
===CPU must still manage continuously the colour changes/cycling for the Visor and the radar...
===when you fire, the CPU must do the frame changes in the projectiles... 6 frames using 2 sprites each. each time you fire, this launch a routine so the game must activate the full animation for the bullet in the character where you fired... not sure when the impact "actually" occurs.
this is still a "lot" of routines i guess, most of them being only cosmetic, for aesthetic purpose only...
=visor could have used only 1 sprite magnified (X=4 & Y=2) or even stick to square 16x16 (X=2 and Y=1), with no colour cycling.
look not as good, but far easier to handle.
=bullet could also use only 1 sprite (no need for so big bullet...) just like Op.wolf ou thunderbolt... and only 2-3 frames max per fire animation... so the CPU can actually work on the impact management.
And then you have possibility to get some frames for the bullets to display the fact you actually hit (blood splatch...) something or not (grey impact, as if on the background....
They simply tried too hard to look like the arcade, and failed miserably.
Also the multiload don't seem to be that serious.
Mostly, the game loads the levels maps, baddies/corridors sequences... perhaps a pair of monster sprites but no new backgrounds...
But that's not even sure, I seriously even guess the disk access/ reloads are mostly for the cinematic sequences... which then may even need to reload the HUD just after...?
(gotta check that...)
But anyway, according to the speccy video, even this version lacks a proper collision management.
Quote from: MacDeath on 22:10, 22 August 11
But anyway, according to the speccy video, even this version lacks a proper collision management.
I think that's worth noting and highlighting - the Speccy version seems to have the same issues and if that's the case then the Amstrad version had no chance with the code ported across. The problems were already present on the Speccy version.
And yea they should have got rid of the bullet animation, I suspect that it was one of the prime causes with the lag in 'hit detection'
Anyway the real strangest issue comes fro mthe way the sprites are generated...
I strongly suspect 1bpp graphics turned into attributed Mode1.
hard to find the "1bpp" graphics compaired to many usual Mode1 speccyports...
I mean, here the attributes are like 4x8 so the tiles must even be Halftiles... or perhaps even a stranger method is used (quite probable) or exotic encoding ...
The most pathetic is that the Sprites still were strongely modified-redesigned because there are even half less pixels.
This can then be a way to get those sprites weighting exactly half as on speccy, which would be rather ironic...(but what a visual shitfest )
On the other hand, the coloured background (the good looking part) weights twice as on speccy...
Problem, on speccy, priority was given to sprites because this is beter for the colour clashes.
On CPC... we have priority on background... so the "Colour clashes" (unmasked corners from attributes) are really awfull.
As you told in the video, the programmer is certainly a good speccy coder, but clearly had some issues with a machine like an amstrad PLUS with some "real weighting" video capabilities for the Z80 to handle.
There, why actually bother with colour clashes on Amstrad PLUS ?
Anyway not even sure an Operation Wolf like engine would enable to get the paralax effect and corridors... But opWolf is 64K RAM only ?
But opwolf has a fast scrolling, while spacegun is slow scrolled... which may leave some CPU time...
I checked the Arcade ROM for Spacegun, there is really an impressive number of sprites, frames and animations...
While R-Type engine was salvageable on CPC this is not even sure this SpaceGun can be salvaged even with the original source codes.
By the way, studying this game was quite interesting IMO.
Actually games like Op.Wolf (FPS) were not done recently If I remember well...
Hi Xyphoe
The poke &776a,&a7 works - but i have first release it as &776a,0 and that don't work.
Anyway i have found a key press cheat in the game,
press Left + F7 and a message will appear "BAA! ZOOM MODE"
now you can press Esc for next level.
you can toggle cheat mode on/off
It's easy to kill the worm dragon, or whatever it is, with the right ammunition.
ok I know it is to late now but!!
Yet, concerning this kind of centiped...
On the video you spend an hour to kill it, I think it just needs you to use some special ammunitions, so you need to keep them for the occasion or simply loose a life to get a re-fill...
But as you fire at his fireball you don't get killed so it take some times. just let him fire at you if you have no more special shoots. 8)
Quote from: Johnny Olsen on 00:47, 23 August 11
Hi Xyphoe
The poke &776a,&a7 works - but i have first release it as &776a,0 and that don't work.
Anyway i have found a key press cheat in the game,
press Left + F7 and a message will appear "BAA! ZOOM MODE"
now you can press Esc for next level.
you can toggle cheat mode on/off
It's easy to kill the worm dragon, or whatever it is, with the right ammunition.
ok I know it is to late now but!!
...and very sorry for the late reply!!!
Great find - could someone edit the Wiki article and put this in?
Quote from: MacDeath on 15:08, 23 August 11
Yet, concerning this kind of centiped...
On the video you spend an hour to kill it, I think it just needs you to use some special ammunitions, so you need to keep them for the occasion or simply loose a life to get a re-fill...
But as you fire at his fireball you don't get killed so it take some times. just let him fire at you if you have no more special shoots. 8)
I figured that too ... but doesn't always seem to be the case. On test runs I got to him collecting the big weapons and not using them saving them for him one time - they didn't all kill him despite aiming perfectly on him, after dieing and getting given some big weapons back it made no difference! Imagine my frustration. Other times, yes this method seems to work. How weird.
I think it's just a sympton of the laggy fire -> hit collision detection that is rampant throughout the game.
Xyphoes, on your video, the packaging shown is my own copy. funny to discover that this picture is still travelling on the web 10 years after.
This is a shame for plus series: a poor speccy port slower than the spectrum and... without tune on title screen. worth: on speccy's title screen the alien is animated
Does it use Plus features at all? (I can't remember having seen some).
Quote from: TFM on 03:39, 04 December 13
Does it use Plus features at all? (I can't remember having seen some).
Yes it does.
It uses palette, sprites, raster interrupts and screen split.
it doesn't use dma or hardware scrolling.
Don't know if it uses analogue joystick.
even with hard sprites, the game is slower than the speccy release... and where is the title tune ?
whe i look to classic games (and older) like operation wolf, operation thunderbolt (2 players mode was possible) and budget release like operation hanoi or jungle warfare... even line of fire is better to my opinion.
and the amiga/st releases are light phaser compatible. why cpc+/spectrum not ?
ocean said goodbye to cpc with a such pity game.
@Arnoldemu: Sorry, if I look a the monsters.... they are just a bad example of software sprites w/o masking, very ugly. And that impression destructs the game. Anything else I would mind. But these blocky "punchouts" around the sprites are really ugly. That kind of technique is ok, but they use toooo big blocks of "punch out".
Well, ok, they may use some plus features, but it's not obvious to me. The game could run as is on a CPC old Generation (CPCoG) too I guess, with minor modifications though.
And as somebody pointed out before, the CPC Version was made love-less: While the damn speccy get animations, the CPC don't.
Whilst that sort of unmasked sprite is handy on a Spectrum if you're doing colourful sprites it's not the only reason for doing so. Drawing sprites without any sort of transparency is significantly faster, which could well be crucial for a game like Space Gun. The biggest problem really is that whoever re-drew the sprites for the Amstrad version didn't seem to take this into consideration and so the outlining is extremely obvious. If you compare it with something like Trap Door, for example, you can see how it should be done right.
It's still a pretty shoddy port, although I can't say I was much of a fan of those type of games in the arcade either. Especially if you aren't using a light gun. I assume it was intended to go on cartridge originally (possibly with light gun support) and then ended up dumped on disk and sold off to try and recoup some losses when it was obvious the GX was a major flop.
In turn the GX flopped because it lacked games.
oh it was a mixture of things, inept decisions by Amstrad, the acid chip probably did not help maybe if Amstrad had produced a 16 bit machine with a cpc emulator built in that might have worked, but they did not.
Well, you argue from today's POV. Honestly, back the day, I assume... people just looked at games. And they decided to get a console [nb]and I only talk about people deciding for a console right now. Leaving out computers.[/nb] which is cheap and provides as much as possible for the money.
Now what did people see: There was just a dozend of games for the GX4000 and most of them looked not very great since all these games didn't really use the new hardware [nb]The new features are actually not bad, you just have to deal with it in the right way. The 2600 was a real pain to program, not the GX4000.[/nb] much. Most games were conversions of older games, just pumped up a bit. And that's just not enough. Of course there were / are few Cartridge games of great quality. But this was not enough to motivate people to buy a GX4000.
The broad mass of customers are no tech-freaks, they just want to play pretty games. They bought what pleased the eye - and that must be considered.
Anyone with half a brain cell could see that the Console was a day late and a dollar short. Utter madness
Yes, it was late. But for a cheap price they would have reached the "cheap" segment of console games. And IMHO the technology of the GX4000 is actually good. I guess I have to prove that with one of my next games ;) [nb]Or bloody fail and spend the rest of my life in a abbey ;) [/nb]
To be pretty, it needed to compete with the Megadrive/Genesis and the SNES. To be cheap, it needed to compete with the vast library of games for the NES and Master System. A few years earlier and it might of carved a small niche but by the time it came it was too little, too late.
It's still a lovely machine to develop for though.
It was just so late, The games that were reboots of existing CPC games should have been released at a competitive rate ,£10 , and exclusive titles at comparable rate to Master system and Nes . CAlso The scrolling capabilities did not seem good enough compared to these two systems (what I have seen anyhow) . They should have also got some publishers on side(Even if it was Amsoft)other than Ocean which did some great titles and went the whole hog in supporting it. All past If's now. But I can't see why they could not have seen the writing on the wall? Blind.
I would love to know the story though!
Quote from: dcdrac on 20:30, 04 December 13
oh it was a mixture of things, inept decisions by Amstrad, the acid chip probably did not help maybe if Amstrad had produced a 16 bit machine with a cpc emulator built in that might have worked, but they did not.
I believe they did ask game developers what they wanted.
They also had to work within the confines of the cpc system to make it backward compatible.
What they produced was not bad.
They should have priovided a way for a sprite to access any part of the internal ram of the asic, then it wouldn't be so bad. I believe they may have also considered more sprites which would have been much better, but cost limitations probably stopped them.
So what we have is actually not that bad and can be used to quite good effect I believe.
the gx4000 was a flop.
Some games would have been greater with larger carts. I believe the developer of Toki asked for a larger cart from Ocean, but because of costs, they said no. If they had said yes, we could have had that game done and looking great.
Quote from: arnoldemu on 10:29, 05 December 13
They should have provided a way for a sprite to access any part of the internal ram ...
Exactly! That's the only real point of criticism I second. It would have improved sprite handling in an order of magnitude. However, if we continue that way and ask for more and more we will finally end up with the PS9 [nb]Released 2025[/nb]. No seriously, you are right there. Just a pointer which tells where in the RAM the sprites starts and everything would be so easy.
Now is there an advantage to keep sprites in the ASIC?
- Saving RAM?
- Protection against accidental overwrite?
- Access sprite data independent of ROM and RAM state?
Well... These arguments don't really make much sense though.
But since we're using it since a quarter of a century, it can't be that bad. :)
The reason the sprite memory is within the ASIC is memory bandwidth.
The same reason that C64 and Amiga sprites are read during HBLANK, and hence are limited in quantity and colour. There's only so much data that can be read in this time (128 bytes - ~80 bytes for screen data). Although on the Amiga this method meant that sprites could be any height (they were frequently used for static scores/etc over the gameplay area... and for the DPaint toolbar IIRC).
Alternatively, the ASIC could have had two address/data buses, and a separate sprite RAM - costly in terms of pin count, but it would have made the system very flexible.
Or the internal sprite RAM could have become a larger Sprite Bank that the sprites could be picked from - costly in terms of silicon.
TBH they were stuck between a rock and a hard place, and they did what they could within the budget they were given.
When producing a chip like an ASIC the RAM part is by far the most expensive part of that chip.
Sadly Amstrad decided to downgrade the ASIC, you can see that at the fact that only 4 of 8 bits are used in every sprite-data-byte of the ASIC.
Would be nice to have one of the ASIC prototypes which used all 8 bits instead of 4.