Space Gun

[MacDeath]

This is a late release from OCEAN.

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 :

C64 :

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://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... ( )

[MacDeath]

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 :


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.

[Gryzor]

The Speccy version is quite impressive for the platform, great presentation too.

[Xyphoe]

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! 

[MacDeath]

Wikipedia : space gun page :

http://en.wikipedia.org/wiki/Space_Gun_%28video_game%29

Programmer 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.






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.

[Xyphoe]

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?

[SyX]

For infinite continues change $24BA from $3D to $00

[Xyphoe]

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?)

[SyX]

Thank you kind sir!

You are welcome! 

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!

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.

(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! 

I tried to find the inifinite energy, but my sleep time had pasted an hour before and i was so tired 

[MacDeath]

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.

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...)

[Johnny Olsen]

Hi Xyphoe

Try &776a,&a7  infinite lives

[MacDeath]

Cool, I may them get to see the rest of the game.

[Xyphoe]

Hi Xyphoe

Try &776a,&a7  infinite lives

Cheers Johnny! I thought you might come through with a few pokes 

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.

[Xyphoe]

Video is now online

[TFM]

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.

[MacDeath]

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.

[Xyphoe]

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'

[MacDeath]

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...

[Johnny Olsen]

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!!

[MacDeath]

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.

[Xyphoe]

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?

[Xyphoe]

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.

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.

[kawickboy]

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

[TFM]

Does it use Plus features at all? (I can't remember having seen some).

[arnoldemu]

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.