Turrican 2 AGA (PC-DOS conversion) - Released!

[giantclam]

Kudos for this ~ kids gave it a good workout (school hols here), running in Amiberry. Really good OOTB experience there, HDF is fastest but the ISO isn't far behind with turbo read on...just start with a 8mb expanded A1200 config (ks3.0), set CPU speed to fastest (68020), load the HDF/ISO and go...really not a lot to fix if anything ~ looking forward to beating the kids' highscores when they go back to school =)

[Don_Adan]

Originally Posted by Muzza

That is what the game does. It allocates a single block of Chip and Fast and then manages it internally. It doesn't solve fragmentation though, in fact it makes it worse in cases like this where the system has plenty of additional free RAM. WHDLoad only allows a single block to be allocated and it happens before the game code even starts running.

Consider that when the player transitions from level A to B, some game assets are required in both (so are preserved in RAM), other game assets are no longer needed (so are free'd), and then new assets are allocated.
Then when you go from level B to C, the same again, but different. Even the main display gets reallocated, for different colour/fetch modes.

Having every level release all allocations, and then the next level re-load/re-create them would solve it, but at the expense of loading times.
My less than ideal compromise was to check the largest free block size during each loading phase, and once it gets to a critical low point, do complete release and re-load of that level. It only really happens once you've done multiple play-through's of the game, and it seems I didn't tune it perfectly - although it is the first report of it in seven months of release so not all that common.

Ok, but Your game allocate memory many times. Allocation can be done only ONCE in init or via BSS hunk (better), You know size of all files necessary to be in memory. Then You allocate one big area for chip and one big area for fast/other memory, You dont free these areas before player QUIT from game. You must allocate maximum area which is necessary in same time for chip and for fast. If You will be using this method, You will be never have problem with memory fragmentation, after running game.

[Muzza]

Like I say, that’s what I do. One system alloc for chip, one for fast. (WHDLoad does not allow any other way - although it would occasionally be useful!)
I still have to virtually alloc and free within those blocks though because you can’t fit the entire game in RAM at once. Things need to be loaded and unloaded. So fragmentation still exists.

[Cris1997XX]

Originally Posted by Muzza

Speed run and Challenge modes don't save. Every other game mode saves the progress at the start of a level.
If you start a new game, the progress on your last game is lost, yes.



I may re-visit it, but I'm not sure what I'd do with it beyond some minor bug fixes. Players did seem to appreciate the new features, but I think only a small number really played the new game modes.

I know there is no MS-DOS version of Turrican 1, but I think it would be neat to make a sort of "definitive edition" with more color and smoother framerate

[Muzza]

Originally Posted by Cris1997XX

I know there is no MS-DOS version of Turrican 1, but I think it would be neat to make a sort of "definitive edition" with more color and smoother framerate

If someone wants to volunteer to redo all the artwork…

[Don_Adan]

Originally Posted by Muzza

Like I say, that’s what I do. One system alloc for chip, one for fast. (WHDLoad does not allow any other way - although it would occasionally be useful!)
I still have to virtually alloc and free within those blocks though because you can’t fit the entire game in RAM at once. Things need to be loaded and unloaded. So fragmentation still exists.

Seems You dont understand me, my english is poor.
I know that WHDload alloc memory only once.
But Your game alloc memory many times.
MUST ALLOC MEMORY ONLY ONCE TOO.
f.e. for chip memory You need:
2x320kB for screen buffer
graphics data for Level 1 and music for Level 1 in total 500kB (You choosed the biggest value from all T2 AGA levels)
other data located in chip memory 100kB
then in total You need maximum of chip memory equal 2x320+500+100=1240kB
and You allocated 1240kB of chip ram only ONCE, via BSS_C or AllocMem.
Later game is handling this chip area for all game levels, intro and outro.

[Torti-the-Smurf]

The "Amiga Dos" version works flawless; maybe give that one a try.

Greetings & good luck;

Torti

[Muzza]

Originally Posted by Don_Adan

Seems You dont understand me, my english is poor.
I know that WHDload alloc memory only once.
But Your game alloc memory many times.
MUST ALLOC MEMORY ONLY ONCE TOO.
f.e. for chip memory You need:
2x320kB for screen buffer
graphics data for Level 1 and music for Level 1 in total 500kB (You choosed the biggest value from all T2 AGA levels)
other data located in chip memory 100kB
then in total You need maximum of chip memory equal 2x320+500+100=1240kB
and You allocated 1240kB of chip ram only ONCE, via BSS_C or AllocMem.
Later game is handling this chip area for all game levels, intro and outro.

Sorry, I don't really understand. Take this simplified scenario:
You have 1000k of Chip RAM total.
Level 1 needs 4 files loaded into RAM from disk:
A: 400k
B: 100k
C: 400k
D: 100k

Level 2 needs these 6 files loaded:
B: 100k
D: 100k
E: 300k
F: 200k
G: 200k
H: 100k

When going from level 1 to level 2, I have two options.
Option 1: Trash A,B,C,D and load B,D,E,F,G,H over it. Zero fragmentation, but I am reloading B and D - increasing loading times.

Option 2: Keep B and D in RAM and discard A and C.
Then I have:
FREE SPACE: 400k
B: 100k
FREE SPACE: 400k
D: 100k

Now load E,F,G,H in the Free Space so I end up with:
E: 300k
H: 100k
B: 100k
F: 200k
G: 200k
D: 100k

Level 2 fits in RAM and loading/decompression is faster because 200k of data was preserved from level 1. The downside is that over time, fragmentation increases.

I remember dealing with this back on the Playstation 1 era. There is no perfect solution, but there are several less-than-perfect work-arounds. For this game I prioritized load times because of the floppy version and because some of the decompression times can be significant too.

[Bruce Abbott]

Originally Posted by Muzza

For this game I prioritized load times because of the floppy version and because some of the decompression times can be significant too.

In your example the data loaded/decompressed is 1000k vs 800k, which doesn't seem like like a big difference to me. After all you won't be changing levels that often, right?

But how many disks is that data spread over? Ideally there should be no more than one disk change between levels and no changes if restarting the same level.

The downside is that over time, fragmentation increases.

If this is fragmentation of system memory it could make the system unstable. Better to allocate the maximum amount required at startup and use it as your own private pool. If memory allocation fails you just flush and reload all, then the worst case is no worse than option 1.

[Don_Adan]

Originally Posted by Muzza

Sorry, I don't really understand. Take this simplified scenario:
You have 1000k of Chip RAM total.
Level 1 needs 4 files loaded into RAM from disk:
A: 400k
B: 100k
C: 400k
D: 100k

Level 2 needs these 6 files loaded:
B: 100k
D: 100k
E: 300k
F: 200k
G: 200k
H: 100k

When going from level 1 to level 2, I have two options.
Option 1: Trash A,B,C,D and load B,D,E,F,G,H over it. Zero fragmentation, but I am reloading B and D - increasing loading times.

Option 2: Keep B and D in RAM and discard A and C.
Then I have:
FREE SPACE: 400k
B: 100k
FREE SPACE: 400k
D: 100k

Now load E,F,G,H in the Free Space so I end up with:
E: 300k
H: 100k
B: 100k
F: 200k
G: 200k
D: 100k

Level 2 fits in RAM and loading/decompression is faster because 200k of data was preserved from level 1. The downside is that over time, fragmentation increases.

I remember dealing with this back on the Playstation 1 era. There is no perfect solution, but there are several less-than-perfect work-arounds. For this game I prioritized load times because of the floppy version and because some of the decompression times can be significant too.

Ok, more infos. If file must be depacked then use fast memory to load and depack to chip or fast.
Think how works original Turrican 2. This game needs only 0.5MB chip from $0 to $80000 area.
Then if You allocate 0.5MB of chip ram under OS and relocate all absolute addresses to new values, You can run this game from different memory, but it still needs only 0.5MB of chip.

F.e for original T2, of course I dont remember exactly location.

all ingame music are loaded at $60000, no difference if TFMX song has 60kB or 50kB,
all graphics level data are loaded $20000 and memory area from $20000 to $60000 is
reserved for level graphics data, not important if some levels used f.e only $20000 KB or $30000 KB. $40000 KB of memory is reserved for graphics level data.

Original T2 has short loading screen, then all old level data can be overwritten.

From Your example You need 1000k of memory. Then alloc only 1000k once.

And show short loading screen, and load/depack all necessary to 1000k area.

[Muzza]

Originally Posted by Bruce Abbott

In your example the data loaded/decompressed is 1000k vs 800k, which doesn't seem like like a big difference to me. After all you won't be changing levels that often, right?

But how many disks is that data spread over? Ideally there should be no more than one disk change between levels and no changes if restarting the same level.

I did say it was a simplified example. The game requires 2MB Chip and 1 to 2MB Fast to give a better indication of how much data is loaded. And on level transitions you may find 80% of the data changes or just 10% of it changes.

I just did a timing and level 1-2 would take 40 seconds rather than 16 seconds to load on floppy if I did not preserve files from level 1-1. I think the players prefer the 16 second version. Also bare in mind that much of that time is on decompression rather than actual disk access.

The game is on three floppies (and I went to great lengths to get it to fit - hence the compression) and there is never more than a single disk change.

Originally Posted by Bruce Abbott

If this is fragmentation of system memory it could make the system unstable. Better to allocate the maximum amount required at startup and use it as your own private pool. If memory allocation fails you just flush and reload all, then the worst case is no worse than option 1.

It is not, it is a private pool that gets fragmented. It also does the flush and reload. (I both mentioned these things a few posts back). The problem is that the flush and reload is not activating correctly under this one particular circumstance - I don't expect it will be hard to fix, but it is pretty rare so I haven't rushed to doing it.

[Muzza]

Originally Posted by Don_Adan

Ok, more infos. If file must be depacked then use fast memory to load and depack to chip or fast.
Think how works original Turrican 2. This game needs only 0.5MB chip from $0 to $80000 area.
Then if You allocate 0.5MB of chip ram under OS and relocate all absolute addresses to new values, You can run this game from different memory, but it still needs only 0.5MB of chip.

F.e for original T2, of course I dont remember exactly location.

all ingame music are loaded at $60000, no difference if TFMX song has 60kB or 50kB,
all graphics level data are loaded $20000 and memory area from $20000 to $60000 is
reserved for level graphics data, not important if some levels used f.e only $20000 KB or $30000 KB. $40000 KB of memory is reserved for graphics level data.

Original T2 has short loading screen, then all old level data can be overwritten.

From Your example You need 1000k of memory. Then alloc only 1000k once.

And show short loading screen, and load/depack all necessary to 1000k area.

OK, that's what I thought you were suggesting at the start, but I was trying to explain why I think it is a bad idea.

It might make sense when working with tight 500k/ASM/1 floppy games, where the musicians, artists and level designers can be given hard limits. But there is a reason gamedevs moved away from this approach as games increased in size.

On the surface it may looks like all that changed in my AGA version was double the number of bitplanes, but there is a lot more to it. There is 600k of sound data the original did not have for a start (due to this version using a sound effect mixer). The loading/decompression times can not be compared between a 512k/1 floppy game and a 3MB/3 floppys game.

World 2-2 uses 128k of unique sound effects (mostly the wind tunnel). If I reserved that 128k globally, it would be wasted space for every other level. Instead World 5-2 can use that space for the final boss battle sprites (just an example - but every level has a different distribution of assets). I also desired to keep it flexible for future additions or new projects.

At the end of the day, it would have resulted in greater RAM usage and slower loading times (e.g. I measured 16 seconds to 40 seconds for World 1-2). So I prefer the dynamic approach in this case.

[Don_Adan]

Ok, this is Your choice, how you handle allocated memory, but if World 2-2 need 128k of unique SFX, then this memory must be allocated too. If You allocated this memory later and free this area some times then memory can be fragmented. Much better is allocated all necessary memory area only once and later overwritten this area many times without allocation and deallocation. Original Turrican 2 is good example how this is done. Game is showing short loading screen and short/jingle music is played when game data are overwritten (loaded and depacked). And if Turrican 2 AGA needs 2MB fast, then You have perhaps enough memory for storing inside fast most used game data for reduce disk swapping and loading time. You must/can be smart using all available for game memory. Allocation and deallocation too many times is not good idea for me. And Your later projects will be affected too. I dont think that someone who played Turrican 2 AGA or Your other game after 2-3 hours of playing will be happy seeing "Not Enough Memory!" requester. But this is Your choice. I know that it needs extra work and time for changing how memory is handling in T2 AGA, but of course You can use this method in Your other projects too.

BTW. Could You tell me how many times Turrican 2 AGA was downloaded ?

[Bren McGuire]

can this be made into a CD32 image that does not require Fast RAM for those with stock CD32s? i remember JOTD making some of these at some point I think using CD32Load maybe

this game is incredible the ultimate Turrican II for real!!

[Muzza]

Downloads:
Turrican2_AGA_Amiga_v1.0.zip 6,506
Turrican2_AGA_Amiga_v1.1.zip 1,779
Turrican2_AGA_Amiga_v1.15.zip 248
Turrican2_AGA_Amiga_v1.18.zip 2,937

[Muzza]

Originally Posted by Bren McGuire

can this be made into a CD32 image that does not require Fast RAM for those with stock CD32s? i remember JOTD making some of these at some point I think using CD32Load maybe

this game is incredible the ultimate Turrican II for real!!

It would not fit in RAM nor run at full speed with only stock 2MB chip, I’m afraid.
If it did, then I would have released it like that!

[Don_Adan]

Originally Posted by Muzza

Downloads:
Turrican2_AGA_Amiga_v1.0.zip 6,506
Turrican2_AGA_Amiga_v1.1.zip 1,779
Turrican2_AGA_Amiga_v1.15.zip 248
Turrican2_AGA_Amiga_v1.18.zip 2,937

Thanks for info.

[TCD]

Originally Posted by Muzza

Downloads:
Turrican2_AGA_Amiga_v1.0.zip 6,506
Turrican2_AGA_Amiga_v1.1.zip 1,779
Turrican2_AGA_Amiga_v1.15.zip 248
Turrican2_AGA_Amiga_v1.18.zip 2,937

Thank you from me too I've added the v1.0 download number to HOL.

[Bruce Abbott]

Originally Posted by Muzza

I did say it was a simplified example... I just did a timing and level 1-2 would take 40 seconds rather than 16 seconds to load on floppy if I did not preserve files from level 1-1.

Right, I get the picture now.

it is a private pool that gets fragmented. It also does the flush and reload... The problem is that the flush and reload is not activating correctly under this one particular circumstance - I don't expect it will be hard to fix, but it is pretty rare so I haven't rushed to doing it.

OK.

One more question:- would it be possible to relocate data blocks to close up gaps and prevent fragmentation?

[Don_Adan]

Originally Posted by Muzza

Sorry, I don't really understand. Take this simplified scenario:
You have 1000k of Chip RAM total.
Level 1 needs 4 files loaded into RAM from disk:
A: 400k
B: 100k
C: 400k
D: 100k

Level 2 needs these 6 files loaded:
B: 100k
D: 100k
E: 300k
F: 200k
G: 200k
H: 100k

When going from level 1 to level 2, I have two options.
Option 1: Trash A,B,C,D and load B,D,E,F,G,H over it. Zero fragmentation, but I am reloading B and D - increasing loading times.

Option 2: Keep B and D in RAM and discard A and C.
Then I have:
FREE SPACE: 400k
B: 100k
FREE SPACE: 400k
D: 100k

Now load E,F,G,H in the Free Space so I end up with:
E: 300k
H: 100k
B: 100k
F: 200k
G: 200k
D: 100k

Level 2 fits in RAM and loading/decompression is faster because 200k of data was preserved from level 1. The downside is that over time, fragmentation increases.

I remember dealing with this back on the Playstation 1 era. There is no perfect solution, but there are several less-than-perfect work-arounds. For this game I prioritized load times because of the floppy version and because some of the decompression times can be significant too.

I rethinked Your loading and I think that for level 1 You must/can load files to next offsets:

B-100k
D-100k
A-400k
C-400k

For level 2 it will be as:
B-100k unchanged
D-100k unchanged
E- 300k
H-100k
F-200k
G-200k