22 May 2020, 12:37 | #1 |
Registered User
Join Date: May 2020
Location: Cambridge
Posts: 36
|
Double Dragon - Arcade port in C
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 Last edited by ElectricCafe; 08 July 2020 at 11:18. |
30 May 2020, 13:35 | #2 |
Registered User
Join Date: May 2020
Location: Cambridge
Posts: 36
|
No worries Bricknash, I'll start this from scracth in C and have located all the arcade assets.
|
30 May 2020, 14:40 | #3 |
Banned
Join Date: Aug 2005
Location: London / Sydney
Age: 47
Posts: 20,420
|
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 |
30 May 2020, 21:39 | #4 |
J.M.D - Bedroom Musician
Join Date: Apr 2014
Location: los angeles,ca
Posts: 3,604
|
|
30 May 2020, 21:58 | #5 |
Registered User
Join Date: May 2020
Location: Cambridge
Posts: 36
|
|
07 June 2020, 21:37 | #7 |
Registered User
Join Date: May 2020
Location: Cambridge
Posts: 36
|
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. |
07 June 2020, 21:47 | #8 |
Registered User
Join Date: Apr 2019
Location: UK
Posts: 540
|
Is there a reason you're going for C rather than ASM?
|
07 June 2020, 22:28 | #9 |
Registered User
Join Date: May 2020
Location: Cambridge
Posts: 36
|
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. |
07 June 2020, 23:06 | #10 |
This cat is no more
Join Date: Dec 2004
Location: FRANCE
Age: 52
Posts: 8,383
|
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. |
07 June 2020, 23:38 | #11 |
Registered User
Join Date: Mar 2016
Location: Australia
Posts: 882
|
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)
|
07 June 2020, 23:47 | #12 |
This cat is no more
Join Date: Dec 2004
Location: FRANCE
Age: 52
Posts: 8,383
|
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) Last edited by jotd; 07 June 2020 at 23:52. |
08 June 2020, 10:36 | #13 |
Registered User
Join Date: May 2020
Location: Cambridge
Posts: 36
|
Hey guys, thanks so much for the feedback! Really great stuff. We will discuss all these comments.
|
08 June 2020, 10:42 | #14 |
This cat is no more
Join Date: Dec 2004
Location: FRANCE
Age: 52
Posts: 8,383
|
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... |
08 June 2020, 11:50 | #15 |
Registered User
Join Date: May 2020
Location: Cambridge
Posts: 36
|
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. |
08 June 2020, 11:54 | #16 |
Registered User
Join Date: May 2020
Location: Cambridge
Posts: 36
|
We of course will need an efficient pipeline for converting assets for use with the Amiga.
We will set this up soon. |
08 June 2020, 12:01 | #17 |
Registered User
Join Date: May 2020
Location: Cambridge
Posts: 36
|
Looks great and exactly what we are aiming for. 25fps looks fine too.
|
08 June 2020, 12:27 | #18 | |
Registered User
Join Date: May 2020
Location: Cambridge
Posts: 36
|
Quote:
|
|
08 June 2020, 13:42 | #19 |
This cat is no more
Join Date: Dec 2004
Location: FRANCE
Age: 52
Posts: 8,383
|
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. |
08 June 2020, 13:47 | #20 |
Registered User
Join Date: Oct 2017
Location: Sunderland, England
Posts: 2,702
|
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 |
Currently Active Users Viewing This Thread: 1 (0 members and 1 guests) | |
Thread Tools | |
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
DOUBLE DRAGON II vs DOUBLE DRAGON 3 AMIGA TITLE MUSIC | ZEUSDAZ | Retrogaming General Discussion | 20 | 16 January 2021 13:29 |
Double Dragon 2 | The Master | project.WHDLoad | 2 | 04 June 2006 19:20 |
Double Dragon 2 Whdload? | fryguy | request.Old Rare Games | 2 | 17 November 2005 01:31 |
Double Dragon 2 HD-Install | Konrad | support.Games | 3 | 08 October 2002 23:04 |
|
|