Double Dragon remake progress update

[Samurai_Crow]

He said he wants to do it in AmosPro. If you want to write an extension to add the "tube scroller" and associated custom blitter routines, be my guest.

[mcgeezer]

Originally Posted by Samurai_Crow

He said he wants to do it in AmosPro. If you want to write an extension to add the "tube scroller" and associated custom blitter routines, be my guest.

I’m not familiar with amos but regardless of what language you do it in the technique is the same.

[Samurai_Crow]

Sadly, the only way to add that low-level capability to AmosPro is to code it in assembly and add custom commands to the language.

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

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

If you have a very long level, don't you have to re-blit the whole tiles at the start of the display memory at some point or you'll be gradually using all the memory right? (unless you have 4MB chip)


That said, this is the only way of achieving 50Hz scrolling. Other games use the "draw all tiles" technique and can never go above 20Hz (ex: Gods, Magic Pockets...)

[roondar]

For vertical scrolling, the most optimal way is to use update the bitmap pointers for every pixel scrolled and then use the copper to reset the bitmap pointers to line 0 somewhere down the screen. In essence, you'd have only one screen's worth of bitmap data and choose where to start and end it. You then just add a tile's worth of lines to allow for new data to seamlessly scroll in.

I'm not explaining it very clearly, but it is essentially possible to vertically scroll on the Amiga for any length without ever needing more than 1 screen of memory.

Otherwise, for a very long horizontal scroll you are indeed correct, the method described for horizontal scrolling does use more memory the longer a level gets. But it's not so bad, it's only equivalent to 1 line of the bitmap for every screens scrolled. For a 5 bitplane screen @ 320x256 that means adding 200 bytes per screen.

If you want 100 screens to scroll, that still only takes ~20k.

[Samurai_Crow]

Remember, AmosPro requires you to do your own Copper lists to obtain that performance level. That discards much of the runtime library support until you are basically writing C or Blitz code styles in AmosPro anyway.

[roondar]

Originally Posted by Samurai_Crow

Remember, AmosPro requires you to do your own Copper lists to obtain that performance level. That discards much of the runtime library support until you are basically writing C or Blitz code styles in AmosPro anyway.

Well, if you have spare memory you can actually get close to this performance by using the 'double screen' method of scrolling. This is definitely possible using AMOS.

That method only requires a screen twice as large as the area displayed and then blitting two rows of tiles for each 16 pixels moved horizontally: one directly ahead and one 1 screen ahead from there (wrapping over when the edge is reached). This way you can scroll horizontally for any size at a cost of drawing two time the tiles normally drawn and the memory for the screen.

Another potential option for games like Double Dragon might be to drop adding new information altogether and just use a giant bitmap. The levels are not that big, it may just fit.

[Retro1234]

You can use a simple corkscrew the game only scrolls right then you only need a screen of about 320+32

Big Bitmap are acceptable in a beat em up like this but Amos can only do a max big Bitmap of 1024 like Amitens games.

[Samurai_Crow]

The catch is how do you allocate it in AmosPro? It doesn't support custom bitplane allocation or structure manipulation so you actually CAN'T use a corkscrew without resorting to throwing out half of the runtime library in the process.

[Retro1234]

I have no idea what your saying too technical for me but a corkscrew is a simple scroll method that works in Amos.

[Samurai_Crow]

It's simple but doesn't work in AmosPro.

[Retro1234]

Wrong it works I used it in the Mario demo and time and time again.

Here a simple example cut and paste it into Amos and take 5 minutes to to change the syntax to Amos or ask someone like idrougge or someone to do it for you.
http://eab.abime.net/showthread.php?t=81634

Sorry to sound nasty but it's 2018 why can't you remember this stuff.

[Samurai_Crow]

Blitz can do it but there is no translation in AmosPro equivalent to it. If you want efficient corkscrew scrolling use C or E or Blitz or Assembly. They can all do the necessary hardware banging.

Doing it in AmosPro requires you to disable the automatic Copper list generation and write your own BOB drawing functions thus throwing out half of the runtime library in the process of doing low-level code in a high-level language.

[Retro1234]

sorry I have no idea what your saying even though you know ive used a corkscrew???

are you talking about Bob clipping if not I cant help you.

in another thread I cut and pasted my Amos corkscrew to blitz and changed the syntax and it worked, sorry I get so annoyed with you Samurai.

You know ive used it ???
???
[ Show youtube player ]

[Samurai_Crow]

Yes BOB clipping is different. Also you can't allocate a screen with the Open Screen command and be able to tell it that only one row of pixels is wide. The double screen width method works in AmosPro but the corkscrew method doesn't.

What I'm saying is that your Blitz example can't be done in AmosPro without bending over backwards and jumping through many hoops. It's a classic example of simple, high-level languages being inflexible while complex, low-level languages take more patience but yield more flexible results. Just because something is easy in one language doesn't make it easy in another.

[Retro1234]

the video in the link above is Amos , a corkscrew in Amos wow

Geeze who cares lets play Spinter Cell

In this example you can even see where Y is out of alignment
[ Show youtube player ]

can we now delete these silly posts and let the op carry on?

[idrougge]

Originally Posted by Retro1234

Wrong it works I used it in the Mario demo and time and time again.

Here a simple example cut and paste it into Amos and take 5 minutes to to change the syntax to Amos or ask someone like idrougge or someone to do it for you.
http://eab.abime.net/showthread.php?t=81634

Sorry to sound nasty but it's 2018 why can't you remember this stuff.

Sorry, but I think that doesn't work in AMOS. You don't have that granularity of bitmap control. Correct me if I'm wrong, I haven't coded any scrolling routines in AMOS in the last four years.

What you can do is use the "double screen" scrolling mentioned by Roondar: http://eab.abime.net/showthread.php?t=80646

[Retro1234]

Yes it works you can see from the video above it works and even see where Y is out of alignment.

I cant understand why people make things so complicated?

I even cut and pasted my Amos corkscrew in to blitz and made some simple adjustments and it worked yet people are telling me, no blitz is so different to Amos you cant do that etc.

why this sillyness, anyway thats me done.

[idrougge]

Just post the code then so we can learn. There's no point in you holding onto the code for yourself. I've already posted scrolling code both for AMOS and Blitz.