Xerus wrote:If you make a Falcon version, will you choose between a better framerate or keep this one and add the parralax?
The main goal is to preserve the gemaplay as good as possible. So if a parallax layer will eat up too much performance on a Atari Falcon I would not implement it.
So far I think it is possible and using a planar mode for this makes more sense here instead of the direct colour mode (like Cho Ren Sha 68k does). I am not sure which mode I should choose for this: eight bitplanes with like 32 colours (five layers for sprites and background) + 8 colours (three layers for parallax background) or four bitplanes with 16 total colours where the parallax background has to be blitted into the background.
Regardless if you choose 8 or 4 bitplanes, you'll end up blitting/updating the parallax background each frame as you''ll hardscroll the foreground.
You should have enough time to do 5 + 3 bitplanes. We did 6 + 2 bitplanes in Willie's Adventures.
dhedberg wrote:Regardless if you choose 8 or 4 bitplanes, you'll end up blitting/updating the parallax background each frame as you''ll hardscroll the foreground.
You should have enough time to do 5 + 3 bitplanes. We did 6 + 2 bitplanes in Willie's Adventures.
Thanks for the info. I haven't tested it so far how much time will be spend on this. Well, I think that 6 + 2 could also be another option.
Just curious: does the sprite drawing in Willie's Adventure use the Blitter?
I do remember that we had sprite routines using the blitter, but I also remember implementing sprite routines using the CPU. I think we eventually used the blitter for most (all?) sprites though. We had lots of animations and wanted everything to work on 4 MB so we could not afford using preshifted sprites if I remember correctly.
Sorry for not being more specific, but I haven't touched the code the last 20 years.
FedePede04 wrote:question: sprite on a STE when is it better to blitter and when is it better to use CPU?
On the Atari STE I would say that you cannot beat the Blitter for this task. Especially when you need space for animation frames where the precalculation is not an option at all.
ok thx, i read some place, that if the object was to small, then i would be better to use the cpu.
how about object that is being shift, like 8x8, chrs?
Atari will rule the world, long after man has disappeared
sometime my English is a little weird, Google translate is my best friend
Here's a first test version for you to try. It shows the attract mode but has still some issues while redrawing some screens. However, it should work on Atari STE machines with 4 MB of RAM and colour monitor/TV set.
Please note: you also need to put the original arcade program ROMs from Daimakaimura (Japan Resale Ver.) in the same folder and please try to load the HD driver as the only program to save memory.
Daimakaimura - Test 1 [2017-10-16]
----------------------------------
Arcade version (c) 1988 by Capcom.
Atari STE port by Sascha Springer.
Requires an Atari STE with 4 MB RAM.
You also need to add these two ROM
files from the arcade machine in
this folder to run:
DAMJ_23.8F (CRC32: C3B248EC)
DAMJ_22.7F (CRC32: 595FF2F3)
Please refer to the Atari-Forum
thread for details.
http://atari-forum.com/viewtopic.php?f=26&t=31479
Have fun!
Last edited by Anima on Tue Oct 17, 2017 11:17 am, edited 2 times in total.
FedePede04 wrote:question: sprite on a STE when is it better to blitter and when is it better to use CPU?
On the Atari STE I would say that you cannot beat the Blitter for this task. Especially when you need space for animation frames where the precalculation is not an option at all.
Ok, I turned off everything and just booted with HDDriver and now it is running.
But the castle scene at the beginning is cut in half. But the forest scene is good. The game demo mode is working with some graphical errors, but what is there is truly amazing! Can't believe it's running on a STE!
4mb STE NTSC, HDDriver 10.10 and tried with both TOS 1.62 and TOS 2.06.
TheNameOfTheGame wrote:Ok, I turned off everything and just booted with HDDriver and now it is running.
I'm glad that it works now. I just forgot that Hatari does not have any memory problems due to the built in driver and the current approach doesn't check the available memory. Well, those are things to fix for the second public test version.
TheNameOfTheGame wrote:But the castle scene at the beginning is cut in half. But the forest scene is good. The game demo mode is working with some graphical errors, but what is there is truly amazing! Can't believe it's running on a STE!
Thanks. Unfortunately there's a problem with the proper screen refresh so the observed display issues are known to be present in this version. Hint: you can refresh the screen manually by pressing F7.
Brume wrote:Tried on my STE 4 Mb / HDdriver 10.10 / French TOS 1.62 :
--> sorry, black screen for me after the message Press Space to start.
Sorry for the inconvenience. Actually there's no warning about insufficient memory so can you please try again with the HD driver loaded from disk as the only program in memory?
I'm not going to believe anything about this project, because it blows my mind so much.
Anima, you are a legend.
Own: Wood grain 2600, Atari 800, 520STFM (1MB), 1040STE (4MB), TT, Falcon 030, Atari Lynx (Both the first one with the crap paint and the v2), Jaguar and too many x680x0 Macs to list, oh and also an Amiga 1200 (Boo!)
My first Mac was Spectre GCR on a 1040STFM with an SM124 and 30MB third party HDD
