Are the 'corrupt' sprites just unhandled tile rotation/flipping codes or some other issue? They seem to all have shared orientation, and the first line/column seems to be from another tile, like it was supposed to be rendered backwards.
Just curious

Moderators: simonsunnyboy, Mug UK, Zorro 2, Moderator Team
Thanks. Well, the sprite emulation is quite complete and also supports the X/Y flipping. The interesting part is that I see different "broken" sprites on my real Falcon compared to running it on Hatari. The "XSP mode 1" on the X68000 works so it's most likely a bug on my side.dml wrote:Great progress! And nice to see the stages in between.
Are the 'corrupt' sprites just unhandled tile rotation/flipping codes or some other issue? They seem to all have shared orientation, and the first line/column seems to be from another tile, like it was supposed to be rendered backwards.
Just curious
Yes, it should work on a machine connected to a VGA monitor as well. However, I only tried this on Hatari.EvilFranky wrote:Sorry I forgot to ask, is this VGA & RGB compatible Anima?
Wow, thanks. That looks great. Adding the text and the background is rather easy so I think a version for accelerated machines could be available in the next days.EvilFranky wrote:I've made a video of the latest release running on my CT60
Ok, thanks. That gives me an idea of the expected performance. Good to see it running quite fluidly even without special optimisations.EvilFranky wrote:Yes I am Anima
Sure, why not? If you have one you'll have to test it then.EvilFranky wrote:JagPad support at some point too hopefully
Yeah I have a JagPad mate. The game would lend itself well to a controller I think.Anima wrote:Ok, thanks. That gives me an idea of the expected performance. Good to see it running quite fluidly even without special optimisations.EvilFranky wrote:Yes I am AnimaSure, why not? If you have one you'll have to test it then.EvilFranky wrote:JagPad support at some point too hopefullyProbably I should buy one for myself some time.
I suppose you're referring to Galaga 88!? Yes, Cho Ren Sha feels more modern compared to Galaga 88. The amount of sprites and the dynamic animations make it very impressive. Also there is no special code like compiled sprites so the performance can be improved by a good margin.dml wrote:That looks even more awesome than last time.
Some of my 040 cables are in storage now but if I can improvise I might be able to test it on that.
Actually there's no optimisation yet. I've chosen this way to see if the graphics engine of the game works correctly without getting in trouble with some error prone optimised sprite routines. In fact, the Blitter has absolutely no advantage on a CT60 as the CPU could do everything faster.EvilFranky wrote:So what optimization work has been done so far? If this runs on a CT60 I guess your blitter routine isn't in use? (I recall for some reason that the blitter is switched off when CT60 is used).
Does this require 14Mb ST-RAM? It does not start on my Falcon/AB with 4Mb ST-RAM and 64Mb Fast-RAM.
Yes it does. However, I'll prepare a special version for accelerated machines which will run in the Fast-RAM. Please stay tuned.joska wrote:Does this require 14Mb ST-RAM? It does not start on my Falcon/AB with 4Mb ST-RAM and 64Mb Fast-RAM.
I've just tested it in both 030 and 060 modes and it's amazing!Anima wrote:Yes it does. However, I'll prepare a special version for accelerated machines which will run in the Fast-RAM. Please stay tuned.joska wrote:Does this require 14Mb ST-RAM? It does not start on my Falcon/AB with 4Mb ST-RAM and 64Mb Fast-RAM.
I wonder whether game uses gcc/MiNTlib for anything. Some of MiNTlib (timing) functions behave differently under TOS domain than MiNT one, but worst issues with that "should" have been fixed with latest MiNTlib versions (in CVS at least, not sure about Vincent's cross-gcc)...Strider wrote:On the 060 (66 MHz) it's very smooth. However I have to run it from MiNT for maximal speed. From TOS it's even slower than 030 mode.
Thanks for the report. Haven't had the time to prepare the promised version for accelerated machines yet. Hope to find some time in the next days.Strider wrote:On the 060 (66 MHz) it's very smooth. However I have to run it from MiNT for maximal speed. From TOS it's even slower than 030 mode.
I prefer playing with the keyboard, so I can switch faster between regular shoots and super-missiles.
Keep up the good work!
The program uses only a few GEMDOS functions (mostly file functions) and no additional libraries. The game synchronisation is completely bound to the VBL interrupt.Eero Tamminen wrote:I wonder whether game uses gcc/MiNTlib for anything. Some of MiNTlib (timing) functions behave differently under TOS domain than MiNT one, but worst issues with that "should" have been fixed with latest MiNTlib versions (in CVS at least, not sure about Vincent's cross-gcc)...
Code: Select all
[...]
L_00020872:
movea.l LONG_000221E2(pc),A2
lea 8(A2),A2
lea PCG_REV_ALT,A4
movea.l OX_CHK_POINTER(pc),A5
move.l #L_00EB8000+$0,D4
move.l PCG_DAT_ADDRESS(pc),D5
move.w OX_CHK_SIZE(pc),D7
move.b D6,D2
subq.b #$2,D2
bra.s L_000208A0
L_00020898:
bra.w L_000209BE
L_0002089C:
move.b D1,1(A0)
L_000208A0:
movea.l (A7)+,A0
move.w (A7)+,D0
bmi.s L_00020898
move.b 0(A3,D0.w),D1
bne.s L_0002089C
L_000208AC:
cmp.b (A5)+,D2
dbhi D7,L_000208AC
bls.w L_00020938
tst.b -(A5)
bne.s L_000208C0
movea.l OX_CHK_TOP(pc),A5
bra.s L_000208AC
L_000208C0:
move.w A5,D1
sub.w A6,D1
move.b D1,1(A0)
move.b D6,(A5)+
move.b D1,0(A3,D0.w)
add.w D1,D1
move.w 0(A4,D1.w),D3
move.b D4,0(A3,D3.w)
move.w D0,0(A4,D1.w)
ext.l D0
lsl.l #$7,D0
add.l D5,D0
ext.l D1
lsl.w #$6,D1
add.l D4,D1
movea.l D0,A0
movea.l D1,A1
move.l (A0)+,(A1)+
move.l (A0)+,(A1)+
move.l (A0)+,(A1)+
move.l (A0)+,(A1)+
move.l (A0)+,(A1)+
move.l (A0)+,(A1)+
move.l (A0)+,(A1)+
move.l (A0)+,(A1)+
move.l (A0)+,(A1)+
move.l (A0)+,(A1)+
move.l (A0)+,(A1)+
move.l (A0)+,(A1)+
move.l (A0)+,(A1)+
move.l (A0)+,(A1)+
move.l (A0)+,(A1)+
move.l (A0)+,(A1)+
move.l (A0)+,(A1)+
move.l (A0)+,(A1)+
move.l (A0)+,(A1)+
move.l (A0)+,(A1)+
move.l (A0)+,(A1)+
move.l (A0)+,(A1)+
move.l (A0)+,(A1)+
move.l (A0)+,(A1)+
move.l (A0)+,(A1)+
move.l (A0)+,(A1)+
move.l (A0)+,(A1)+
move.l (A0)+,(A1)+
move.l (A0)+,(A1)+
move.l (A0)+,(A1)+
move.l (A0)+,(A1)+
move.l (A0)+,(A1)+
dbf D7,L_000208A0
[...]
MiNT replaces TOS GEMDOS with its own GEMDOS function implementations. I guess file functions in MiNT could utilize caching, but I would assume that all the file reads are done before & between levels, not during level. What GEMDOS (or BIOS) functions you use during level play?Anima wrote:Thanks for the report. Haven't had the time to prepare the promised version for accelerated machines yet. Hope to find some time in the next days.Strider wrote:On the 060 (66 MHz) it's very smooth. However I have to run it from MiNT for maximal speed. From TOS it's even slower than 030 mode.
I prefer playing with the keyboard, so I can switch faster between regular shoots and super-missiles.
Keep up the good work!
The program uses only a few GEMDOS functions (mostly file functions) and no additional libraries. The game synchronisation is completely bound to the VBL interrupt.Eero Tamminen wrote:I wonder whether game uses gcc/MiNTlib for anything. Some of MiNTlib (timing) functions behave differently under TOS domain than MiNT one, but worst issues with that "should" have been fixed with latest MiNTlib versions (in CVS at least, not sure about Vincent's cross-gcc)...
Yes, all the file operations are used only at the program start. So far it uses only the following GEMDOS file functions: Fopen, Fread, Fseek and Fclose. There are indeed some standard C library functions in the original binary like "printf" but these are disabled in the Atari binary.Eero Tamminen wrote:MiNT replaces TOS GEMDOS with its own GEMDOS function implementations. I guess file functions in MiNT could utilize caching, but I would assume that all the file reads are done before & between levels, not during level. What GEMDOS (or BIOS) functions you use during level play?