Double Dragon - Arcade port in C

[ElectricCafe]

Aiming to deliver a worthy port to the Amiga.

Minimum target specs will be the classic A500 with the RAM upgrade:

A500
Kickstart 1.3
1MB Ram

PAL
320x256 Screen Size
32 colours (palette swapping between levels)

Latest dev diary updates will be posted here: http://www.electriccafe.xyz/double-dragon

[ElectricCafe]

No worries Bricknash, I'll start this from scracth in C and have located all the arcade assets.

[DamienD]

He probably just hasn't read your post ElectricCafe...

Last time Brick Nash visited EAB was "08 October 2019 09:44".

Anyway, sounds cool if you are going to do a remake from scratch using the arcade assets

[saimon69]

Originally Posted by ElectricCafe

No worries Bricknash, I'll start this from scracth in C and have located all the arcade assets.

I did help around a lot with ports, if you need some music let me know

[ElectricCafe]

Originally Posted by saimon69

I did help around a lot with ports, if you need some music let me know

Thanks Saimon, i'll bear that in mind!

[DamienD]

@ElectricCafe; I think we should move all these posts out of Brick Nash's thread and into a new one

Edit: done.

[ElectricCafe]

We have started this project now..

First thing was to set up the compiler which we did with the aid of a tutorial by Wei-ju Wu [ Show youtube player ]

Then we did some simple tests compiling a hello world script and running it in terminal on the mac, and then on FS-UAE.

Lastly, we have now successfully integrated Amiga libraries and have a simple window running on the Amiga.

All sounds rock 'n roll I know. But we can now move on to testing some technical stuff that will inform how we can use all the power of the Amiga. We will do some copper, halfbrite and blitter tests and see where we get with that.

[stevelord]

Is there a reason you're going for C rather than ASM?

[ElectricCafe]

I know C# and C++, so this is an opportunity to extend my knowledge to C and to learn about programming for the hardware.

Also I am working on this with a friend, who is more senior, so it's going to be a social/educational thing.

[jotd]

go for C++ you'll have more power in your hands, and the overhead is the same unless you create local objects that need destructors... And you'll have less issues. C is crap.

An example of Amiga game I have written in C++: https://github.com/jotd666/bagman (uses blitter of course)
Modsurfer was written in C and uses blitter and stuff: https://github.com/amigageek/modsurfer

Both are cross compiled using Bebbo's gcc distro. If you're targetting A500, sadly it seems that assembly is the only choice for a fast game. Unless SAS C is better for performance.

A lot of old games were written in C, but those were VERY RARELY arcade games.

[alpine9000]

Metro Siege is written in C, granted it runs at 25fps but I doubt an asm rewrite would get it to 50fps as most of the time is spent blitting or other DMA stuff ( lots of copper stuff like repeating sprites)

[jotd]

okay, other main problem of C/C++ is executable size. Asm guarantees the shortest exe. But nowadays it's not really a big deal.

What must be done (and I didn't do) is to use interleaved bitplanes to do blits of all planes in one go. That way, if you wait BEFORE the next blit, then the rest of the code just runs in parallel while the blitter is working.

Also using sprites saves a lot of CPU/blit, but it's not as easy as the blitter. I suppose old games written in asm were done that way because of the size, and also the coder that knew asm better than C. As alpine9000 said, the blitter waits dwarf the CPU anyway. But old arcade games could squeeze amiga power by using super-optimized asm/blitter at the same time.

I read that programmers of Shadow Of the Beast III tried to save every cycle to get a smooth game on 68000. That's not something you can do in C (or AMOS!!), even if nowadays compilers are smarter than old SAS-C.

Anyway using C or C++ for your game is much better for your sanity (McGeezer can confirm that)

[ElectricCafe]

Hey guys, thanks so much for the feedback! Really great stuff. We will discuss all these comments.

[jotd]

you'll find hard to convert assets to amiga-compatible stuff. Audio isn't really an issue as it's only "one-dimensional" and sample players are very well done. The graphics are really a big issue

- you have to decide of a palette, when arcade assets often come as 24 bit PNG, and master the order of the colors (when even paletted formats shuffle the palette randomly)
- you have to convert the data to bitplanes

in "Bagman" I have used python scripts using Pillow to read the pngs, concat them, then use imagemagick to use the same palette, split them back into separate raw bitplane images.

Alternatives are using amiga tools like DPaint which respect the palette. That probably involves a lot of clicking, and using an amiga to edit images when python+pillow, Gimp & PSP exist... well...

[ElectricCafe]

Palette will be something of high importance, but I will worry about that a bit later.

Having already done some basic tests I know I can get good results with alot less colours, just by being selective.

With my current knowledge my plan is to select a palette of 32 colours that will serve the sprites and background for each level. And then use EHB mode to create more depth in the background tiles, and then using the copper to create the fade on the floor tiles making them darker towards the background.

That is my current understanding of what can be done (and I accept that may be very wide of the mark, but we are learning every day).

But I will soon find out after we have done some tests and created a proof of concept.

[ElectricCafe]

We of course will need an efficient pipeline for converting assets for use with the Amiga.

We will set this up soon.

[ElectricCafe]

Originally Posted by alpine9000

Metro Siege is written in C, granted it runs at 25fps but I doubt an asm rewrite would get it to 50fps as most of the time is spent blitting or other DMA stuff ( lots of copper stuff like repeating sprites)

Looks great and exactly what we are aiming for. 25fps looks fine too.

[ElectricCafe]

Originally Posted by jotd

okay, other main problem of C/C++ is executable size. Asm guarantees the shortest exe. But nowadays it's not really a big deal.

What must be done (and I didn't do) is to use interleaved bitplanes to do blits of all planes in one go. That way, if you wait BEFORE the next blit, then the rest of the code just runs in parallel while the blitter is working.

Also using sprites saves a lot of CPU/blit, but it's not as easy as the blitter. I suppose old games written in asm were done that way because of the size, and also the coder that knew asm better than C. As alpine9000 said, the blitter waits dwarf the CPU anyway. But old arcade games could squeeze amiga power by using super-optimized asm/blitter at the same time.

I read that programmers of Shadow Of the Beast III tried to save every cycle to get a smooth game on 68000. That's not something you can do in C (or AMOS!!), even if nowadays compilers are smarter than old SAS-C.

Anyway using C or C++ for your game is much better for your sanity (McGeezer can confirm that)

Having discussed possible use of C++ we concluded C is better for us for three reasons: (1) it encourages more efficient programming, (2) we'll both learn a bunch, and (3) there are more resources available for C.

[jotd]

my game is a mix between C and C++. But it came from a SDL version I did for Windows / Nintendo DS a while ago. C++ compiler can compile C all right except for some very rare incompatibilities

(1) it encourages more efficient programming

=> MAME went from C to C++. You don't have to use "new" at every line in C++. Allocate your objects in the init phase, then use them. There's almost no extra overhead with C++ if you do that properly.

(2) we'll both learn a bunch

=> True: you'll learn that you should never have chosen C

(3) there are more resources available for C.

=> That you can compile in C++ too, or compile in c and add a "extern c" directive on the C++ side (my C++ code calls phx asm replay module without any issues)

Hey that's your project, but if you want to do some OO programming, don't let that 3 reasons deter you.

[mcgeezer]

Just be aware that the levels in this game is a little tricky and would need a decent scroll routine for it to be efficient.

https://vgmaps.com/Atlas/Arcade/Doub...ewYork199X.png

As you can see the height of the tilemap is around 768pixels. I pumped that map through ProMotion and it gave me a 16x16 tile set to the size of 220Kb in 32 colours, you could hold that in fast ram and do CPU copies.

For the playfield you could go for a size of 40x768x5 but that would be pretty wasteful as that would hit ~150Kb by screen buffer, when double buffering and possibly a third buffer is added you'd run out of chip ram. So again a key hurdle will be putting in an efficient memory vertical scrolling capabililty.

I haven't looked at the sprites, but I'd be willing to bet they'd notch up a decent amount of chip ram if they are done with interleaved blits. You'd probably have to compromise on the number of frames simply due to the memory size of the sprites or don't use interleaved blits, certainly doable at 25FPS (but not something that I would be happy with personally if I were doing it).

You mentioned using EHB mode, my advice is don't because it doesn't need to and you'd soak up too much DMA away from the Blitter.

The onscreen display you could handle with hardware sprites.

But even before you do that, get a good sprite driver going with some test sprites.... it is almost always the place to start when building an action game.

Geezer