Rolling Thunder - Amiga Port

[redblade]

@mcgeezer: Great work on the current video. How much RAM is that chewing up at the moment?
You are using the Sprites for main player, enemies, main player bullets and enemy bullets?!?
When you code the game are you making a custom copper list or are you using _LVOOpenScreenTagList(), _LVOAllocBitMap() ??

Hopefully the engine will be easy to modify for Elevator Action Returns or Clock Tower (SNES)

[redblade]

Originally Posted by buzzybee

The original conversion is a total waste of time, subpar on so many levels.

Not if you make those Youtube videos which compare different platforms.

[mcgeezer]

Originally Posted by redblade

@mcgeezer: Great work on the current video. How much RAM is that chewing up at the moment?
You are using the Sprites for main player, enemies, main player bullets and enemy bullets?!?
When you code the game are you making a custom copper list or are you using _LVOOpenScreenTagList(), _LVOAllocBitMap() ??

Hopefully the engine will be easy to modify for Elevator Action Returns or Clock Tower (SNES)

Thanks.

It's probably easier I tell you what the rough memory calculations are that I have available:

Screen 1	122880
Screen 2	122880
Screen 3	122880
Tiles	61440
Sprites	819200
Code	150000
Copper	2048
Maps	32768
Music	200000
SFX	200000

Total	1834096

The above is based on 6 bitplanes, but the sprites are 4 bitplanes and I can select which bitplanes they are put in and the order allowing for different colours. The BoBs are in 64px wide hardware sprite format which is useful on saving memory - but slow because I can't do interleved blits. I'm working on using linked sprites, so using 1 upper body but for many lower body frames to save memory.

I create my own copper list.

Many times I see people allocate their copper by declaring them in code/data segments. I allocate chip ram and then build the list upward which allows me to create pointers in the copper - I still don't know if this is a good way to do it but it works fast for me.

Coding is slow due to the pandemic and having a little boy. My wife is looking after him during the day while I have to work because I'm classed as a key worker, so on an evening she is handing over to me.

Absolutely no down time.

Geezer

[buzzybee]

Originally Posted by mcgeezer

Thanks.
Many times I see people allocate their copper by declaring them in code/data segments. I allocate chip ram and then build the list upward which allows me to create pointers in the copper - I still don't know if this is a good way to do it but it works fast for me.

Coding is slow due to the pandemic and having a little boy. My wife is looking after him during the day while I have to work because I'm classed as a key worker, so on an evening she is handing over to me.

I know this is not about coding in this thread, but it fits the topic and therefore hopefully may be of interest for some readers – maybe even McGeezer: I let VASM create my copperlists; put CMOVE NOOP,POINTERTOBPLPT ($01) … CMOVE NOOP,POINTERTOSPRxPOS ($10)etc. commands into the list at places where I need pointers; then let code search through copperlist in runtime, find those CMOVE-commands and create pointers.

This way I lose a tiny bit of DMA-bandwith, but can quickly create and edit copperlist with as many pointers as needed.

[mcgeezer]

Its probably six and two three’s Richard.

I like my way because i find it more readable than assembler directives which i use sparingly.

But thanks for the response! Top man

[van_dammesque]

Originally Posted by redblade

Not if you make those Youtube videos which compare different platforms.

[ Show youtube player ]

[borchen]

Well...here's my slow&dirty attempt on A500/OCS/512chip+512slow.

[ Show youtube player ]

Disclaimer: this will not be turned into a full game, because I do not have the time nor the knowledge to do this...I just wanted to see if I could get 'something' on screen that 'resembles' the arcade original. This slow attempt is the result of messing about in ASM for months; half an hour here and an hour there...

It's basically an animation using cookie-cut blits, some color changes using the copper and a sprite overlay, using manual sprite mode, for the scores on top and ammo/lives at the bottom. Using this method for the fence would not work, because you'll need all 16 spritecolors for this and these colors are badly needed for the hero/enemies....bummer.

I think I finally have a 32 color palette that should be useable for the first-part of level 1, after some tedious color reductions using ripped gfx from mame. I generated an animation, while playing the game in mame (in Linux), using the -mngwrite option and then extracted all the frames, using the convert-command, to png's

The background is build using 16x16 blocks of gfx and a table that represents 1 screen (for now) to fill the 288x224 screen.

Next challenge will be hardware scrolling....

[jotd]

it is already more playable than the Tiertex version.