Wanted: New Graphics for Double Dragon (128k version)

[Swainy]

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

[MacDeath]

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.

[sigh]

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.

[Gryzor]

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

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.

[MacDeath]

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



oops, it's a mobile phone version...


Sprite Database :Double Dragon

[TotO]

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.

[sigh]

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

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?

[MacDeath]

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

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

[sigh]

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.

[MacDeath]

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.