Daimakaimura (Ghouls 'n Ghosts) for the Atari STE

[AtariCrypt]

That palette does look really good. Amazing. Nice job! Too bad my STE is only 8MHz and 4MB.

That's exactly what I was thinking. But the video is a jaw-dropper, amazing work. Beautiful!!

[Anima]

That looks awesome . But ... somehow hard to believe that can be same on bare STE with 4MB. Maybe Exxos will make fortune now by selling accelerator/RAM expansion boards. Are you 2 together in this project ?
Seriously: OK for faster CPU needed for early test version, but why it needs 14 MB RAM ?

The problem is that sprites can be referenced at every stage so they need to be sorted out by hand to reduce the amount of storage needed. Still it will be though to squeeze all into 4 MB.

[Ragstaff]

Along with the hand sorting, perhaps some load points within levels? I know it's a killer on a real floppy drive but an STE with 4mb and a hard disk / sd card is far more common than STE's with >4mb RAM

[Anima]

Along with the hand sorting, perhaps some load points within levels? I know it's a killer on a real floppy drive but an STE with 4mb and a hard disk / sd card is far more common than STE's with >4mb RAM

Exactly. This will work only with an HD installation and loading data on demand at certain points.

[Greyfox™]

How is this even possible on an Atari STe? Simply incredible..I'm baffled ?

With Tim Follin's music this will be the ultimate Home computer port.

[dlfrsilver]

That looks awesome . But ... somehow hard to believe that can be same on bare STE with 4MB. Maybe Exxos will make fortune now by selling accelerator/RAM expansion boards. Are you 2 together in this project ?
Seriously: OK for faster CPU needed for early test version, but why it needs 14 MB RAM ?

14mb because it's a coin-op game where all the assets and ressources are not seperated but unified. And there is so many sprite frames as well as game tiles that you need 14mb to store everything, even in 16 colors.

And as Anima's said, there is a great chance that in order to seperate each levels and sprites, a more deeper ressourcing of the 68000 game code will be needed.

[calimero]

I am trying to find demo that Anima made with Final Fight sprites - I remember that there was MSA file uploaded on forum but I can not find it now :/

[AtariZoll]

14mb because it's a coin-op game where all the assets and ressources are not seperated but unified. And there is so many sprite frames as well as game tiles that you need 14mb to store everything, even in 16 colors.
And as Anima's said, there is a great chance that in order to seperate each levels and sprites, a more deeper ressourcing of the 68000 game code will be needed.

OK. Then, how long is complete game ? It is hard to expect that all sprites (objects, creatures, fire, etc.) can be appearing at any level - at least not common in games.

This will work only with an HD installation and loading data on demand at certain points.

Again: how long is complete game ? Loading at certain point is common practice in games, so even very complex ones can work fine with 512KB machines - like 4 floppy Microprose F1 GP. Of course, I'm not saying that in this case so low RAM need is possible. What worries me is said about that low 1MB RAM is needed for game. In that case, normal hard disk access is simply not possible - TOS is disabled. Then 2 ways of hard disk access are possible:
1. low level, direct access - it is fast, but needs separated code for every adapter type - ACSI, ICD ACSI, IDE, SCSI . RAM usage is minimal.
2. Copying and keeping copy of low RAM, together with TOS workspace, hard disk driver in high RAM, and swapping back when hard disk access is needed. That uses installed hard disk driver - and it is good. Bad is that it needs about min 200 KB RAM - if user has nothing resident, but is is rather 300-500KB in case of STE. RAM swap takes some time too, so if there is need to access short files frequently, better to use some cache - what means need for even more RAM.
Data compression can make all it better - than can put more in cache, and if using fast depacking all it will be fluid.

Better would be to not use low RAM, hard disk driver space, but accessing disk via regular filesystem calls. Then code should be regular TOS relocatable.
Don't know is it possible, will it make the whole task harder.

[dlfrsilver]

OK. Then, how long is complete game ? It is hard to expect that all sprites (objects, creatures, fire, etc.) can be appearing at any level - at least not common in games.

I have already referenced all the sprites and bosses per levels for Anima a few pages back. Some of them are common to some levels, others not.

It's not exactly hard to seperated all the sprites metadata inside the program code, it's just very long and tedious.

Again: how long is complete game ? Loading at certain point is common practice in games, so even very complex ones can work fine with 512KB machines - like 4 floppy Microprose F1 GP. Of course, I'm not saying that in this case so low RAM need is possible. What worries me is said about that low 1MB RAM is needed for game. In that case, normal hard disk access is simply not possible - TOS is disabled. Then 2 ways of hard disk access are possible:
1. low level, direct access - it is fast, but needs separated code for every adapter type - ACSI, ICD ACSI, IDE, SCSI . RAM usage is minimal.
2. Copying and keeping copy of low RAM, together with TOS workspace, hard disk driver in high RAM, and swapping back when hard disk access is needed. That uses installed hard disk driver - and it is good. Bad is that it needs about min 200 KB RAM - if user has nothing resident, but is is rather 300-500KB in case of STE. RAM swap takes some time too, so if there is need to access short files frequently, better to use some cache - what means need for even more RAM.
Data compression can make all it better - than can put more in cache, and if using fast depacking all it will be fluid.

Better would be to not use low RAM, hard disk driver space, but accessing disk via regular filesystem calls. Then code should be regular TOS relocatable.
Don't know is it possible, will it make the whole task harder.

About all this, i'd say that about the memory, once every part of the game code/Logic/graphic routines/Sound routines/Sprites&tiles metadatas will be recognized and splitted, it will make things very easy to sort out on the I/O side.

Right now, and Anima will confirm it, since the arcade program is done as a whole, you can't break up the program so easily in chunks.

Just to let you know that in the CPS game, the main tree (i mean the program in itself) is about 250-300kb, and all the remaining are the Sprites and tiles metadatas, which are quite big !

I will try tonight to put my nose inside the arcade code to find arthur's sprites metadatas, and evaluate their raw size.

[Oldskool]

Maybe this will be the first program/game to use the extra mem of the monster card. I bought this for the IDE and I always wondered were the extra 8 mb was for (12MB total). Now I know this game

[Anima]

I am trying to find demo that Anima made with Final Fight sprites - I remember that there was MSA file uploaded on forum but I can not find it now :/

Here it is: http://atari-forum.com/viewtopic.php?f= ... 25#p317216

[calimero]

I am trying to find demo that Anima made with Final Fight sprites - I remember that there was MSA file uploaded on forum but I can not find it now :/

Here it is: http://atari-forum.com/viewtopic.php?f= ... 25#p317216

Thanks! I made small video from it using hatari, can I upload it to youtube or you will?

[Anima]

Thanks! I made small video from it using hatari, can I upload it to youtube or you will?

Go ahead and upload it.

[calimero]

EDIT: new link (previous was not of good quality)

Published https://youtu.be/9ZIs-NQHZKc

btw why youtube made "360p" video when original source is: 832x552px 50fps? Is it possible to control conversion process on youtube?

[Ragstaff]

Sometimes YouTube takes a while to do other versions.
Check back again in a day or so

[Anima]

2. Copying and keeping copy of low RAM, together with TOS workspace, hard disk driver in high RAM, and swapping back when hard disk access is needed. That uses installed hard disk driver - and it is good. Bad is that it needs about min 200 KB RAM - if user has nothing resident, but is is rather 300-500KB in case of STE. RAM swap takes some time too, so if there is need to access short files frequently, better to use some cache - what means need for even more RAM.

I think that this would be a viable option. I still have to check the graphics data requirements of the stages.

I will try tonight to put my nose inside the arcade code to find arthur's sprites metadatas, and evaluate their raw size.

It would be nice to get some infos about this because it's a nightmare to understand the source code.

[dlfrsilver]

Anima, i have PMed you.

[Anima]

New update: gameplay demo running on an original Atari STE (8 MHz, 4 MB RAM):
https://youtu.be/TM0Y8E6v1qc

[EvilFranky]

Spectacular Anima, great stuff.

[AtariCrypt]

That video... Wow. Just wow. Amazing work Anima.

[Cyprian]

just awesome.
would be possible to add raster color to the sky?

[MM41]

Wow!!!, great work Anima

[dlfrsilver]

good job !!!

[calimero]

it is almost perfect port: only bunch of birdies slow down STe

so STe execute original game logic from arcade ROM? If so, how then it is possible that STe can run everything (graphics) fast enough if arcade CPU alone run at 12MHz; not to mention dedicate graphics subsystem ?!?


btw
with such "sorcery" of Anima code, how good Amiga games could look like?!? with Amiga dual play fields, sprites, cooper ... ?!?

[dlfrsilver]

i think that on the amiga you could use maybe 32 colors instead of 16. Any other "magic effect" would raise the bar i think on the memory requirements.

it would be cool if anima could explain what he applied in order to make the STE display the tiles without any dedicated chipset