Xybots - how did they do it?

[laoo]

On 10/8/2021 at 10:59 AM, LordKraken said:

@laoo could confirm, but I think the only reason MK is doable at this level of quality on the lynx is because all animations are streamed from cart!

 

So yeah I'm more and more confident the rotation as seen in the arcade game are achievable on the lynx too

I confirm

There are more than 100kb of sprites animations. The cartridge is blazing fast - loading 2kB sector takes about 1/3 of a frame.

On 10/8/2021 at 3:22 PM, karri said:

There is a noticable delay when the data is loaded.

Taking into consideration what I've just have written and what we where able to do in MK I don't think that your delays are unavoidable. The sprite on this animation isn't too big. Maybe try to load a frame of animation at a time? Or maybe try to write more low-level stuff in assembly?

[Fadest]

I guess you optimised your reading routines and made your own kind of directory structure, and all assets are aligned on sectors (and you know which one for each asset), this way, your access is faster than reading directory structure, getting the sector/offset and then reading data, that is maybe more versatile, but less optimised.

[+karri]

Actually, the delay is not that bad after all. Here is an example.

wizzy.lnx

 

Opt1 switches character

B - jump
B - long - mount/unmount broom
A - shoot / slash

 

The witch has directional animations in place
The barbarian has just right/left animations

 

Total number of animations is 30 so far.

 

This is just a concept demo - not a game.

 

[laoo]

48 minutes ago, Fadest said:

I guess you optimised your reading routines and made your own kind of directory structure, and all assets are aligned on sectors (and you know which one for each asset), this way, your access is faster than reading directory structure, getting the sector/offset and then reading data, that is maybe more versatile, but less optimised.

Fankly I even don't know what is standard directory structure whatsoever. Generally I do retrocoding for fun and most fun is from doing everything by myself in bare metal and I don't use any existing libraries and standards. In this instance I wrote my own cartridge space allocator that can allocate space for two kinds of data: fast and slow. Fast data is aligned to sector (2048 bytes) boundaries and sectors are in sequence traversable by shifting-in only one bit to the shift register (0,1,2,4,8,16,32,64,129,3,6,12 etc) and slow data fills in the gaps that has left. All character sprites are fast and loading them takes almost no time.

 

50 minutes ago, karri said:

Actually, the delay is not that bad after all. Here is an example.

Looks great. Changing direction is almost instant but slanted movement is noticeably slower.

[+karri]

1 minute ago, laoo said:

Looks great. Changing direction is almost instant but slanted movement is noticeably slower.

 

I have not coded in slanted movement logic yet. So it fetches in two animations all the time instead of one animation just once.

[sage]

On 10/12/2021 at 1:26 PM, laoo said:

 sectors are in sequence traversable by shifting-in only one bit to the shift register (0,1,2,4,8,16,32,64,129,3,6,12 etc) and slow data fills in the gaps that has left. All character sprites are fast and loading them takes almost no time.

Splendit idea.

[dipdop]

On 10/12/2021 at 4:33 AM, karri said:

Actually, the delay is not that bad after all. Here is an example.

wizzy.lnx 58.98 kB · 7 downloads

 

Opt1 switches character

B - jump
B - long - mount/unmount broom
A - shoot / slash

 

The witch has directional animations in place
The barbarian has just right/left animations

 

Total number of animations is 30 so far.

 

This is just a concept demo - not a game.

 

I finally got a spare minute to check this out. It's really rad! It's way more responsive than I was expecting