Double Dragon remake progress update

[mcgeezer]

Originally Posted by jotd

@mcgeezer out of curiosity: but the "sliding window" technique you're describing needs you to write on a big memory range right?

Doing my calculations, if you need to scroll horizontally a 3200 wide tiled image (10 screens worth) you need 3200/16 = 200 bytes ahead which is very small (but you have 4 or 5 bitplanes so make it 1kb), but is that the same vertically wise? Vertically wise you don't divide by 16. 1 pixel = +40 bytes times the number of bitplanes.

It's not the same for vertical scrolling, the most efficient use of vertical scrolling is using video splitting (i think mentioned above), but it comes at a price of complexity.

My current project will need to do vertical scrolling also, but I'm just going to use two screens to do it and move down to single buffering as not alot happens on the game when vertical scrolling is in progress.

I would approach DD by not having any vertical scrolling at all, only use horizontal scrolling and when you want to move up and down just move the display window accordingly.

[Dan]

To do the Scrolling in amos pro, you can use two ways. Either tile based or Image based scrolling.

The image based scrolling would be easier, as all you need to do is to load the stage as an iff image, to setup the screeen display, and to update it whenever you want to scrolling to happen.

The Wonderland game, a mario-alike-game (on the productivity #2 disk, also known as Dithell's Wonderland) uses this techique for its levels.

The commands that you need are

1. Either LoadIff or ScreenOpen for the level setup
2.Screen Display for setting up the screen size and place
3. In game loop: ScreenOffset to do the scrolling.

For tilebased scrolling i guess it's best to use the TOME extension (i guess that the version 4 is the latest).
It has its own tile-based maps. There are examples which shows you how to do the scrolling.

The TOME extension would be faster (in my oppinion) than your own routines (amos code) for tilebased scrolling.

[Samurai_Crow]

I would agree except that TOME uses blitter scrolling and could be faster without.

[Dan]

Here is a picture of the 2 horizontal tile scrolling methods, as i'v understood it.

What i have left out is the complete redrawing of the tiles method.

The only thing to consider is, which one produces less jittery scrolling on the target machine.

Explanation of the bottom part, as the picture does not clearly show's it:

First you open a screen of, lets say, 656x250, and set the displaying screen to 640,250. Tile width=16. (640+16=656)

Then you copy the part of your displayed screen. Starting point is your h-scroll value to the end of the screen (the one with width of 656).
Repeat that until you reach the point when you are able to draw new tiles (at least after 15th pixel of scrolling)

Of course this it's slower method.

[Retro1234]

Large images only work up to 1024 and software scrolling is slow never use screen copy only use hardware scrolling.

And Tome is not fast it's faster without it.

[Retro1234]

Sorry guys I won't post anymore but if you look at how Amiga games were made on this forum you don't use large Bitmaps, you don't turn a large Tiled map into a IFF?

It doesn't matter what language you use the scrolling methods are the same you don't software scroll like on the ST

This is how games are made if you come up with crazy scrolling ideas and not stick to the know formula it goes nowhere.

And why o why do we have this sillyness of" no don't work" in 2018, if something works remember instead of going through this again and again.

[Dan]

Retro1234, please give us, at least, code with which we can WORK with, and which works in the AMOS pro language, since Brick Nash is working with it.

I'v just found the "Def Scroll" and "Scroll" commands in the Amos Pro help. So looking at my attached picture, instead of using copy, use "Scroll".
It is probably faster, but someone need's to test it.

[Retro1234]

I suggest looking at idrougge's examples this includes both methods of scrolling.

[Dan]

Yeah saw it, and by my understanding i draw a short animation of how the process can be done horizontally:



So the advantage of this method is having 2 tiles pasted occasionally, to fill up the map. And it would not impact the speed of the game at all.

Of course this is only for the one way scroll, just like Double Dragon game is.

[Retro1234]

Just paste your 2 tiles every 1 pixel you scroll


Theres an even easier way for horizontal but that is a good way.

Your notice if you scroll past the full width of the screen what happeneds you see the beginning of our image (it's wrapped round like a Zoetrope)but it's risen by 1 pixel so we only need to realign our Tiles every screen width by 1 Y pixel.

But on Amos you will get Bob clipping at the end of the screen width I just Moved the Bob to the new position but adrazar found a way to disable Bob clipping if this works with Corkscrew scrolling this is a brilliantly simple scrolling method for a game like this
http://eab.abime.net/showthread.php?t=87636
On Blitz apparently you need to disable the Debuger.

Both methods can be adapted to scroll 2ways.

If you can, can you do a similar small animation for corkscrew scrolling this would be a good reference

[dlfrsilver]

excellent idea ! By the look of it, it's exactly how the CPS-1 system is doing for a game like Cadillac and Dinosaurs, and many others.

[Retro1234]

I always used the method described by Dan until MrsBeanBag told me about the easier corkscrew for horizontal, I assumed that scrolling past the end of the screen like this was considered wrong or something.

[Samurai_Crow]

Originally Posted by Retro1234

I always used the method described by Dan until MrsBeanBag told me about the easier corkscrew for horizontal, I assumed that scrolling past the end of the screen like this was considered wrong or something.

It is. It might not work on future versions of AmosPro but maybe in an extension.

[Retro1234]

Originally Posted by Samurai_Crow

It is. It might not work on future versions of AmosPro but maybe in an extension.

Future versions your going to write in 2065 stop your stupidness.

[Samurai_Crow]

Originally Posted by Retro1234

Future versions your going to write in 2065 stop your stupidness.

What year it comes out I don't know but I'm going to keep working on it as long as I have an Amiga to keep tinkering with. Also, I'm not the only one working on AmosPro so it appears there's enough stupidity to go around.

[redblade]

Originally Posted by Brick Nash

Been tinkering about with this again.

Tried to get the palette down to 32 shared colours which makes it more washed out but not terrible (Billy's golden locks have taken a hit). Creating compatible palettes for all the Bobs and all the level backgrounds is continuing to be a bitch though.

Interestingly, the original Amiga DD's Level 1 background seems to have 64 colours when run through an analyser. Who knew.

Hi. How much RAM does the character sprite use up? Are you using sprites? What happens if player 2 joins in? Do you re-colour the blue to red or do you have another copy of the player sprites in RED? I wonder how he did double dragon II?

How much RAM do the map tiles take up? Looks real nice, well done with the graphics conversion

[Epo]

Originally Posted by Samurai_Crow

What year it comes out I don't know but I'm going to keep working on it as long as I have an Amiga to keep tinkering with. Also, I'm not the only one working on AmosPro so it appears there's enough stupidity to go around.

Thank you Samurai_Crow for your dedication and to the rest of the team. Please do not stop working on it, there is a lot of people using this great programming language also looking for an update. Speaking of... Did you guys fix the compiler bug with Val() instruction? It is so annoying. It converts negative values to positive, but only after compilation - in the editor everything works fine. If so, I would embrace a quick release just for this bug only.

[Samurai_Crow]

@Epo
The compiler hasn't been touched. The next release is focusing on bugs in the installer and interpreter.

@thread
Any additional questions about future releases of AmosPro should be posted in a dedicated thread in the AMOS development category.

[Codetapper]

Originally Posted by Brick Nash

Interestingly, the original Amiga DD's Level 1 background seems to have 64 colours when run through an analyser. Who knew.

Actually it's 32 colours not 64. The tiles are 16x16 interleaved.

[Brick Nash]

Hey folks, sorry about the horribly rude lack of replies but I've been busy with other stuff.

I had all but given up on this conversion as I was just hitting too many brick walls, plus I've been working on a Double Dragon sequel for the PC using Game Maker which I released a demo for a few months back.

I'm getting the itch to go back and try something with this Amiga port but truth be told I'd probably need to collaborate with someone a bit more experienced to get things moving and provide some proper motivation. However I also realise that it's a big ask of anyone's time and I'm assuming that like me, we're all post 40 in years and free hours are rare.

If anyone is interested I can maybe make a download pack to all the resources and the most recent Amos project file and maybe we could set up some sort of pass-around system where different people can "have a go" as it were. Given the lack of decent beat 'em ups on the Amiga it'd be nice to get even a one level demo made, and I'm not precious about sharing credit or any ego stuff like that. I just want a cool brawler for the Miggy.

I haven't looked at Amos in a while either so I'm unaware of any updates or new extensions which might help that weren't there before, so by all means fill me in.

Cheers!