[AMSTRAD CPC] Double Dragon Longplay part 1/4 (http://www.youtube.com/watch?v=fnAYiCYcu-U#)
The good version with digitized graphics ported from the Amiga. Plays well, but looks like shit in my humble opinion. Has the graphics been redone by anyone? Would anyone like to give it a try? I have no clue how much work it would be.
Enlighten me ;)
I found a great interview about it here: Double Dragon Dojo: Nick Speakman interview on Double Dragon (http://doubledragon.kontek.net/interviews/speakman-dd.html)
A very good read about what went wrong, the rewrites and the chaos and how the Amstrad 128k version showed the 16-bit coders how it was supposed to be done
(http://i.imgur.com/Xdzk3.gif) (http://i.imgur.com/Xdzk3.gif)
Half finished mock up I had done a while ago.
I'm too deeply involved with my own beat em up, so it's not something I intend to do anytime soon. Has been put in the sock draw along with Rodland for now :)
P.S. The Spectrum remake is looking absolutely fantastic. That version looks like it will be the best version hands down surpassing all the other 8 bit and 16 bit home computer versions. A definite "must" download for me!
Quote from: ivarf on 23:23, 26 September 12
[AMSTRAD CPC] Double Dragon Longplay part 1/4 (http://www.youtube.com/watch?v=fnAYiCYcu-U#)
The good version with digitized graphics ported from the Amiga. Plays well, but looks like shit in my humble opinion. Has the graphics been redone by anyone? Would anyone like to give it a try? I have no clue how much work it would be.
Enlighten me ;)
I thought they were ported from the st, or perhaps ported from the arcade board?
128k version by Richard Aplin I believe, coder of Flyspy. The same code is used in Final Fight I think, but coded by somebody else.
The sprites may be in some kind of compressed form. I don't know to be sure.
The tiles I am assuming would be uncompressed.
Would be interesting to see a dissassembly and see how it was all done, it does move well and play well.
Quote from: arnoldemu on 09:19, 27 September 12
I thought they were ported from the st, or perhaps ported from the arcade board?
Double Dragon sprites were from the ST and Double Dragon II sprites were ripped from the arcade.
I reckon that if coded where the multi directional scrolling could be smoother in the same vain as Dynamite Dux and Skate Crazy, the music from the Spectrum remake and the sound effects of Renegade - it would be super awesome!
Quote from: arnoldemu on 09:19, 27 September 12
The sprites may be in some kind of compressed form. I don't know to be sure.
..and they can still move that fast in compressed form?!?!? Wow!
Better to redone the full arcade game, because both versions are poor.
Quote from: TotO on 10:10, 27 September 12
Better to redone the full arcade game.
Agreed. This is exactly what I would do.
DD2 had quite better 16bit versions, very more faithfull graphically to the Arcade so DD2 on CPC is also a port from the 16bit homeversions I guess.
DD1 (the good one) can be a port from the poor 16bit versions but strangely, to pass the graphics into semi automatic Mode0 converter gave a result actually closer to the Arcade than the 16 bit versions.
Yes it seems some games used some automatic converters.
The result is somewhat half good alf bad... mostly we have very strange colour choices but on overall the result is not that bad looking.
Defender of the Crown devs told us they used some same device to roughly port the Atari ST graphics into CPC, then they edited them betterly...
DD1 clearly shows the ported graphics are not redone a lot which is sad.
Final Fight gains from the fact the sprites are a lot bigger so the result is better looking while still being rough.
Concerning DD1, just some work on re-inking would be enough IMO. the pixels are here, they are just screwed up but poor ink choices.
Would an engine like Alienstorm or Golden Axe be good for such game ?
The main problem is the Mode 0 here, because wide pixels don't match with "stringy" players and NPC sprites style.
An alternative was found on Master System by making "eXtra Deformed" like sprites, and the Spectrum remake look to do the same.
Double Dragon is one of my favorite game ever. (got the PCB)
The sound and sfx part of the game are very important to keep the arcade spirit.
But, before all, it need to be dynamic.
Quote from: MacDeath on 10:56, 27 September 12
Concerning DD1, just some work on re-inking would be enough IMO. the pixels are here, they are just screwed up but poor ink choices.
It needs a lot more than just re-inking. The hair grab move for instance needs to
look like a proper hair grab move along with the judo throw which aren't animated that well. When they pick up a box/barrel, their legs don't animate making them slide around. The music - Double Dragon has a piece of dedicated music track per stage (Mission 2 being my favourite.) The sound effects are also very meaty. There's a lot that can be improved and I for one would not at all find it acceptable if it were just "re inked" without sorting out all these other issues. It's important that it "feels" like Double Dragon.
Quote from: TotO on 11:07, 27 September 12
The main problem is the Mode 0 here, because wide pixels don't match with "stringy" players and NPC sprites style.
I don't think the mode 0 is a problem at all with this or any game. (I was never a fan of the super deformed look of DD.)
For me - I would prefer if the game looked like the original as much as possible regardless if the pixels are wide or single.
I think I might finish that mock up.....
Quote from: sigh on 11:41, 27 September 12I don't think the mode 0 is a problem at all with this or any game. [...] I would prefer if the game looked like the original as much as possible regardless if the pixels are wide or single.
In this case, I though that you will be confronted to the same problem as the original CPC port, except if you got a great pixel skill to do miracle. Good luck!
Well, I'm hoping that the mock up I did does have a Double Dragon feel to it despite the wide pixel from and looking at them side by side, (arcade - mock up) I think it's closer to the original than the other 2 CPC versions. Though trying to get the sprites to resemble Jimmy and Billy took quite sometime, but I think it works....?
(...or maybe it doesn't? :D )
Sure, it's better.
QuoteThe hair grab move for instance needs to look like a proper hair grab move along with the judo throw which aren't animated that well. When they pick up a box/barrel, their legs don't animate making them slide around.
That's perhaps another limitation of the engine.
More animated frames for the sprites = more RAM used to store them... and perhaps even more address.
Often you got a 256 tile limitation due to them being addressed in 1byte.
So it could be like 256 tiles for sprites and 256 tiles for background...
to add extra sets or bigger address capability means... it all get a lot heavier too.
DD game may encounter the following problems :
=no hardware support to flip sprites... gotta double them (no CPU but Extra RAM) pre-shifted (left-right flip)
=no easy palette swaps for sprites : an Arcade machine could re-use the same sprite with easy hardware palette swaps, not on CPC or else you need extra RAM to pre-swap, or "attribute like" soft effect (CPU intensive I guess).
=and so on...
DoubleDragon has to manage a 2player option, or else it sucks, the background are quite complex and nice looking.
And the fighters have to deal with a lot of movements /fighting techniques.
Also to have those weapons well managed can be a big deal to get it good looking on the screen... (extra sprites sets ?)
Double Dragon was an 8bit arcade game... stretched to the limit... it used to lag badly because it was a very heavy game.
To do it "well" on a CPC it could really need like 256-512k RAM and even though...
Barbarian on CPC per exemple, (no scrolling
, animation limited to a pair of sprites and a few elements ) used a method to get some palette swap.The sprites are actually stored as Mode1 datas... 2bpp (4 colours) this matches the C64 version, use twice less RAM space... but you then can't have nice sprites in 15 colours. Still it fits 64K limitation.
And to colourswap means some CPU work.
Quote from: MacDeath on 14:49, 27 September 12
To do it "well" on a CPC it could really need like 256-512k RAM and even though...
I reckon, after seeing the Speccy 128kb remake version in the works, you could still do well with 128kb.
Think Target renegade, with the throw, barrel throwing, headbutt and elbow:)
Quote from: sigh on 15:23, 27 September 12I reckon, after seeing the Speccy 128kb remake version in the works, you could still do well with 128kb.
The Spectrum got a faster display, and only hard scroll or more RAM to preshift sprites and/or tiles can help to do the same... It's why, I though, MacDeath speak about more memory.
I like a lot ... the gameboy b&w version :D
I know is a very different game, but i played to death it (and Robocop too), amazing music (and Robocop too) :)
Quote from: TotO on 15:40, 27 September 12
The Spectrum got a faster display, and only hard scroll or more RAM to preshift sprites and/or tiles can help to do the same... It's why, I though, MacDeath speak about more memory.
Ahhh - I had no idea that the speccy has a faster display.
Yes, speccy is only 6 KBs of video + 768 bytes for colour attributes (2 colours in each block of 8x8 pixels).
The usual CPC screen size (320x200 mode 1) takes 16 KBs (2,66 times more ram) and even when we reduce the screen size using a speccy screen size in CPC (256x192 mode 1) takes 12 KBs.
That means that in CPC for getting a similar speed, we need to work hard and use every trick in the hat (scroll hardware, double buffers, precompiled sprites, ...) but that is part of the charm of our machine ;)
Exactly...
When I say 256-512K game... I mean it can of course use many multiloads between each levels (here the disk Drive is helping a lot more than Tapes...) and to be faire, an arcade/action game with like 178K Datas (a whole 3" disk side) is already more than enough to have a kool looking game...
After all CPU can only address 64K and many greatest hits were in less than that.
But still, 16K of "VRAM", doublebuffered (so 32K easily)... get all those sprites prebuffered/flipped/processed... add in for extra cinematics, effects, sounds, and so on... 128k is really a minium for a "super production", despite a lot being "wasted" in fancy fullscreen pages.
Good examples are R-Type 128 (swweeeeet intro) and Orion Prime (the intro is something like a whole 3" disk side... if I recall well...)
But yeah, it is just extra content and don't make an engine run smoothly during actual game.
To be fair, ZxSpectrum is sweet when dealing with 1bpp animation, sadly it remains 1bpp (= 1 colour... sort of). Also the lightweight Video make up for better AY sound handling (also the AY is clocked a bit faster)...
But you got to know that the CPC can generate a 192x256x16 fullscreen too (no attributes, but easier if static, not fully animated...)).
Which weights like 4x the Speccy screen (without counting attributes).
Quote from: arnoldemu on 09:19, 27 September 12
I thought they were ported from the st, or perhaps ported from the arcade board?
128k version by Richard Aplin I believe, coder of Flyspy. The same code is used in Final Fight I think, but coded by somebody else.
From the interview linked to in my first post:
"Glad to hear that. So what was the deal with the two Amstrad ports?
Nick: "In version 1 (the poor CPC 464 game) Ben (Jackson) did the original Spectrum graphics and Jez (Nelson) colored them up a bit. The second set of graphics (in the good CPC 6128 game) were "ported" from the excellent Amiga version... which is why they look better but have strange color combinations.""
Double Dragon, an excellent Amiga version? :o
This poor lazy port... Sure, it's a joke! :-X
It's the perfect exemple of a 512K game that you load only one time...
EDIT: And format... ;)
Hahaha that was a good one :D
And is based in real events :D
Contradicting things is being said in the interview
"But finally, Nick gives a proper reason for the two Amstrad CPC ports. Richard Aplin, who (almost) saved the Amiga and ST ports showed the new guys who had ruined DD with their Amstrad port, how it was done with his excellent version. "
I don't know, read the interview yourself and see if it has any new interesting information for you. I enjoyed it a lot, it gave a lot of information about the chaotic times. Some version only got 14 days of coding
Double Dragon Dojo: Nick Speakman interview on Double Dragon (http://doubledragon.kontek.net/interviews/speakman-dd.html)
I just played the Richard Aplin version again and I'm even more convinced that a remake would just be stupendously awesome! The actual scrolling seems to be moving at 4 mode 0 pixels horizontally(16 single pixels) and 4 "single" pixels vertically It's not as smooth as Dynamite Dux or Skate Crazy, but as the playing area is quite large, it doesn't feel too choppy. The actual sprites moving around the scrolling are also moving at around 4 wide pixels (16 single pixels) when moving from left to right. 4 "single" pixels when moving up and down. You can move the screen back and forth (while with Dynamite Dux you can only move forward.)
I'm guessing that as the frame rate is constant - it helps with the game feeling somewhat smooth despite the huge pixel movements.
There's no flickering or slowdown with 6 characters on screen including the giant Abobo. Almost all the moves are present apart from the stun animation frame that actually pauses, the full nelson hold, spin kick and the uppercut. The jumping back kick isn't airborne like in the arcade and when landing a punch; only the right hand on the punches connect.
Guys, I'm the bloke working on the graphics of the new 128k Speccy version, if you guys can use my graphics in anyway then please let me know. Then again, I know how you guys hate Speccy ports :)
(http://img.photobucket.com/albums/v661/Swainy_boy/mission2_mockup.png)
(http://img.photobucket.com/albums/v661/Swainy_boy/flyingkick-6.gif)
This said a Mode1 version could be fun too.
Wasn't DD3 in Mode1 ? oh yeah, sorry.
Speccy ports are detestable (abject) mostly because the graphics are never ported as they should... we get some 1bpp backgrounds or even whole games... which is bad.
But redone well, Mode1 can be cool, despite not colourfull.
(http://i.imgur.com/PinA6.gif)
Finish mock up the end of Mission 2
I would put the health/scoreboards on either side for each player, so that there is more vertical space like the original. Mission 2 is quite a complex level in terms of tiling, though Mission 1 does have the car, posters and skyscrapers in the background.
Quote from: Swainy on 21:42, 29 September 12
Guys, I'm the bloke working on the graphics of the new 128k Speccy version, if you guys can use my graphics in anyway then please let me know. Then again, I know how you guys hate Speccy ports :)
(http://img.photobucket.com/albums/v661/Swainy_boy/mission2_mockup.png)
(http://img.photobucket.com/albums/v661/Swainy_boy/flyingkick-6.gif)
Lovely work you're doing there!
Yes, as MacDeath said we detest them because they're not properly done... in this case here, although your sprites are great, they'd need to be coloured in (perhaps not that hard), but the difference in pixel size would probably mean it'd have to change a lot... so maybe no real sense in doing it instead of starting from scratch.
QuoteFinish mock up the end of Mission 2
Sprites look great but I'm not sure concerning the use of purple for some shadows...
Also the ditherings for the backgrounds looking so... random or complicated, it may add extra un-needed tiles.But it looks like you did a great job anyway.
DD1 is full of greyish colours... sadly we know CPC can't do it that way.
a complicated job on the palette must be clearly needed, not sure if to aim at maximum accuracy (concerning colours) is the best way...
I should try something myself.
Have you done a whole tileset or are you mocking-up relatively freely ?
Should be nice to try on a real CRT monitor though.
Ok, your amstrad part of the picture looks like being "214x200" which is then 107x200 mode0.
107x200 ?
What was the original arcade resolution ?
It is suposed to be like 240x224... which seem "reachable" easily for a CPC.
I mean, "256x256" (or 128x256 in mode0) is even a bit lighter than a whole 320x200 (160x200) in VRAM.
But needless to say, to get the sprites a bit smaller than on arcade can be a nice way to ease a potential engine running on a real CPC.is this exploitable ?(http://spritedatabase.net/files/mobile/1834/Sprite/DDEx_Tiles.png) (http://spritedatabase.net/files/mobile/1834/Sprite/DDEx_Tiles.png)oops, it's a mobile phone version...
Sprite Database :Double Dragon (http://spritedatabase.net/game/603)
(http://spritedatabase.net/files/arcade/603/Background/Area1.png) (http://spritedatabase.net/files/arcade/603/Background/Area1.png)
(http://spritedatabase.net/files/arcade/603/Background/Area2.png) (http://spritedatabase.net/files/arcade/603/Background/Area2.png)
(http://spritedatabase.net/files/arcade/603/Background/Area3.png) (http://spritedatabase.net/files/arcade/603/Background/Area3.png)
(http://spritedatabase.net/files/arcade/603/Background/Area4.png) (http://spritedatabase.net/files/arcade/603/Background/Area4.png)
Exactly, Double Dragon is 240x224.
That is perfect for a 128x256 Mode 0 screen, using 2 chars for the scrolling "buffer" and a area for displaying scores and lives outside the playfield.
Quote from: MacDeath on 05:05, 01 October 12
Sprites look great but I'm not sure concerning the use of purple for some shadows...
Also the ditherings for the backgrounds looking so... random or complicated, it may add extra un-needed tiles.
But it looks like you did a great job anyway.
DD1 is full of greyish colours... sadly we know CPC can't do it that way.
a complicated job on the palette must be clearly needed, not sure if to aim at maximum accuracy (concerning colours) is the best way...
I should try something myself.
Have you done a whole tileset or are you mocking-up relatively freely ?
Should be nice to try on a real CRT monitor though.
Ok, your amstrad part of the picture looks like being "214x200" which is then 107x200 mode0.
107x200 ?
What was the original arcade resolution ?
It is suposed to be like 240x224... which seem "reachable" easily for a CPC.
I mean, "256x256" (or 128x256 in mode0) is even a bit lighter than a whole 320x200 (160x200) in VRAM.
But needless to say, to get the sprites a bit smaller than on arcade can be a nice way to ease a potential engine running on a real CPC.
is this exploitable ?
I thought that by making the width screen size smaller, it would save on data as well as look closer to the original arcade as well as having more vertical space as the game has vertical scrolling. Myabe it was the wrong approach?
Regarding the tiles, the wall ditherings are made tileable along with the floor and not random, though they may appear to be as I haven't fully optimised them :D . Again, dithering should present a small amount of tiles that can be used on the roof and floor for that whole mission. Same with the background wall which should be only 2 or 3 tiles. I didn't cut them up properly because I wont be making the game, but you can be sure that I took all these aspects in account when doing the mock up, otherwise there's just no point. If I were to cut them up - then there would be most likely even less tiles and maybe a little less floor detail. (Not to sure whether that floor would be an eyesore or not when playing...)
Quote from: TotO on 08:01, 01 October 12
Exactly, Double Dragon is 240x224.
That is perfect for a 128x256 Mode 0 screen, using 1 char on each side for the scrolling "buffer" and a area for displaying scores and lives outside the playfield.
Would this be a preferable option to the 107 x 200? Would the current resolution cause problems?
Well, concerning certain purposes (like soft scrollings), to have a screen width of mode1 256 pixels (128 in mode0) can ease.
Since width is a power of 2 it's quicker to process the offsets for lines addresses because you don't have to use multiplications but can instead use "shifts".
QuoteWould this be a preferable option to the 107 x 200? Would the current resolution cause problems?
the problem with 107x200 is that it is somewhat bastard.
Tiles are powers of 2 in size, 107 is a multiple of nothing.
The engine would have to get a number of tiles, so why getting one of those tiles only partially displayed ?
Quote from: MacDeath on 12:42, 01 October 12
Well, concerning certain purposes (like soft scrollings), to have a screen width of mode1 256 pixels (128 in mode0) can ease.
Since width is a power of 2 it's quicker to process the offsets for lines addresses because you don't have to use multiplications but can instead use "shifts".
the problem with 107x200 is that it is somewhat bastard.
Tiles are powers of 2 in size, 107 is a multiple of nothing.
The engine would have to get a number of tiles, so why getting one of those tiles only partially displayed ?
Yes - I see what you mean about the 107. So a 128x256 is the perfect option for ease of programming this type of game.
Thanks.
As TotO suggested...
Double Dragon is 240x224.
So just do it in 120x224 mode0
The extra 8x mode0 pixels (= 2x8 mode1 pixels = 2 characters) could not be displayed but used as scrolling buffer.
As long as you aim for multiples of 8 for the resolution, it's all good otherwise.
DD1 is not really continuous smooth scrolling. well it doesn't need to be actually.
There are zones or sequences of scrollings, but to get more scrolling/ to(progress the level you need to kill opponents during fixed screens parts.
The background/scenery is far bigger than the screen too. I always though the ladders and platforms at some places are somewhat useless... but hey the arcade is cheated anyway by many buggs or killer hits (head butt and elbow blow)
The area with score and lives and credits and so on will have to be outside of the playfield, because on those arcade they were often masked sprites/stuffs... overlayed on the background/other sprites... but on CPC (and computer games generally) they are often separeted because then you gain in CPU and many things as you don't have to mask/overlay them.Soft mask is always a pain in the @$$ for the CPU you know.
But as the CPC can quite easily into 256 vertical resolution, it leaves a cool margin.
you can even aim at a 200pixels vertical playfield and 24pixels vertical HUD (the Score/information zone).While Arcade games are generous concerning all sort of scrolling, I guess the Amstrad could simplify them a bit for most parts of the levels.The higher you put vertical resolution the less you need of vertical scrolling.As I told in another topic concerning Final Fight... the CPC could have displayed the original arcade verticalness so no need to actually implement a vertical scrolling, sadly speccy can't and it was the same engine...Same per example for R-Type on PC-Engine... the PC-Engine has a more limited vertical resolution than the arcade, but the whole graphics are directly (somewhat) ported with the same scale so they needed to add a vertical scrolling.
On a more limited machine such as CPC you have to accept not always being 100% accurate.
But actually the amstrad CPC can manage same "theorical dimensions" as those early 8-16 bit arcade games.
The main issue being the problem to deal with numerous big masked sprites and smooth scrollings and shittons of tiles all at the same time.
But this can be treated a bit.
Like reducing the animations frames number, reducing a bit the scale of a few sprites, reducing a bit of gameplay options and so on, reducing the smoothness of animations...
And using the 6128 configuration to begin with. ;D