English Amiga Board


Go Back   English Amiga Board > Other Projects > project.Amiga Game Factory

 
 
Thread Tools
Old 22 May 2020, 13:37   #1
ElectricCafe
Registered User

 
Join Date: May 2020
Location: Cambridge
Posts: 29
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 12:18.
ElectricCafe is offline  
Old 30 May 2020, 14:35   #2
ElectricCafe
Registered User

 
Join Date: May 2020
Location: Cambridge
Posts: 29
No worries Bricknash, I'll start this from scracth in C and have located all the arcade assets.
ElectricCafe is offline  
Old 30 May 2020, 15:40   #3
DamienD
disengaged
DamienD's Avatar
 
Join Date: Aug 2005
Location: London / Sydney
Age: 44
Posts: 18,717
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
DamienD is offline  
Old 30 May 2020, 22:39   #4
saimon69
J.M.D - Bedroom Musician

 
Join Date: Apr 2014
Location: los angeles,ca
Posts: 1,577
Quote:
Originally Posted by ElectricCafe View Post
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
saimon69 is offline  
Old 30 May 2020, 22:58   #5
ElectricCafe
Registered User

 
Join Date: May 2020
Location: Cambridge
Posts: 29
Quote:
Originally Posted by saimon69 View Post
I did help around a lot with ports, if you need some music let me know
Thanks Saimon, i'll bear that in mind!
ElectricCafe is offline  
Old 30 May 2020, 23:00   #6
DamienD
disengaged
DamienD's Avatar
 
Join Date: Aug 2005
Location: London / Sydney
Age: 44
Posts: 18,717
@ElectricCafe; I think we should move all these posts out of Brick Nash's thread and into a new one

Edit: done.
DamienD is offline  
Old 07 June 2020, 22:37   #7
ElectricCafe
Registered User

 
Join Date: May 2020
Location: Cambridge
Posts: 29
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.
ElectricCafe is offline  
Old 07 June 2020, 22:47   #8
stevelord
Registered User

stevelord's Avatar
 
Join Date: Apr 2019
Location: UK
Posts: 176
Is there a reason you're going for C rather than ASM?
stevelord is offline  
Old 07 June 2020, 23:28   #9
ElectricCafe
Registered User

 
Join Date: May 2020
Location: Cambridge
Posts: 29
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.
ElectricCafe is offline  
Old 08 June 2020, 00:06   #10
jotd
This cat is no more
jotd's Avatar
 
Join Date: Dec 2004
Location: FRANCE
Age: 49
Posts: 4,610
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.
jotd is offline  
Old 08 June 2020, 00:38   #11
alpine9000
Registered User

 
Join Date: Mar 2016
Location: Australia
Posts: 835
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)
alpine9000 is offline  
Old 08 June 2020, 00:47   #12
jotd
This cat is no more
jotd's Avatar
 
Join Date: Dec 2004
Location: FRANCE
Age: 49
Posts: 4,610
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; 08 June 2020 at 00:52.
jotd is offline  
Old 08 June 2020, 11:36   #13
ElectricCafe
Registered User

 
Join Date: May 2020
Location: Cambridge
Posts: 29
Hey guys, thanks so much for the feedback! Really great stuff. We will discuss all these comments.
ElectricCafe is offline  
Old 08 June 2020, 11:42   #14
jotd
This cat is no more
jotd's Avatar
 
Join Date: Dec 2004
Location: FRANCE
Age: 49
Posts: 4,610
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...
jotd is offline  
Old 08 June 2020, 12:50   #15
ElectricCafe
Registered User

 
Join Date: May 2020
Location: Cambridge
Posts: 29
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 is offline  
Old 08 June 2020, 12:54   #16
ElectricCafe
Registered User

 
Join Date: May 2020
Location: Cambridge
Posts: 29
We of course will need an efficient pipeline for converting assets for use with the Amiga.

We will set this up soon.
ElectricCafe is offline  
Old 08 June 2020, 13:01   #17
ElectricCafe
Registered User

 
Join Date: May 2020
Location: Cambridge
Posts: 29
Quote:
Originally Posted by alpine9000 View Post
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 is offline  
Old 08 June 2020, 13:27   #18
ElectricCafe
Registered User

 
Join Date: May 2020
Location: Cambridge
Posts: 29
Quote:
Originally Posted by jotd View Post
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.
ElectricCafe is offline  
Old 08 June 2020, 14:42   #19
jotd
This cat is no more
jotd's Avatar
 
Join Date: Dec 2004
Location: FRANCE
Age: 49
Posts: 4,610
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.
jotd is offline  
Old 08 June 2020, 14:47   #20
mcgeezer
Registered User

 
Join Date: Oct 2017
Location: Sunderland, England
Posts: 2,004
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
mcgeezer is online now  
 


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 13 28 December 2018 01:00
Double Dragon 2 The Master project.WHDLoad 2 04 June 2006 20:20
Double Dragon 2 Whdload? fryguy request.Old Rare Games 2 17 November 2005 02:31
Double Dragon 2 HD-Install Konrad support.Games 3 09 October 2002 00:04

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +2. The time now is 15:44.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2020, vBulletin Solutions Inc.
Page generated in 0.09184 seconds with 14 queries