F18A Zaxxon demo

[Tursi]

Classic99 does not support most of the F18A advanced graphics. For now, you have to use hardware or 99er.net

 

 

[Asmusr]

34 minutes ago, Tursi said:

Classic99 does not support most of the F18A advanced graphics. For now, you have to use hardware or 99er.net

That's https://js99er.net ?

[Nick99]

Played it on my TI and it looks superb! ? 

I have to learn that down is up and up is down, a good part of the challenge to master the game. Wonderful! 

[+9640News]

31 minutes ago, Nick99 said:

Played it on my TI and it looks superb! ? 

I have to learn that down is up and up is down, a good part of the challenge to master the game. Wonderful! 

Same issue here.  I do not recall if the original game had that same response or not.

[Asmusr]

A bit of technical info:

• As mentioned before, the scrolling background requires far more than 256 characters in total, and it's very close to 256 at the individual screen level. If I need to save some patterns for displaying score, fuel etc., I need to find the best alterative for some patterns. That's what I have been working on for the last couple of days.
• The original hardware had sprites with a size of 32x32 pixels. The TI sprites are only 16x16, so I'm working with virtual sprites that consists of 1 to 4 hardware sprites. One example of a virtual sprite is the orange fuel tank, which consists of 4 hardware sprites.
• I have worked on offloading a substantial part of the work to the F18A GPU, so currently the CPU is only aware of the virtual sprites while the GPU is handing everything to do with the hardware sprites.
• The GPU is sorting the sprites according to their 3D distance from the user and is applying priorities (which sprites overlap each other) accordingly.
• The GPU is also calculating collisions between sprites and reporting this back to the CPU. That alone would take almost half of a CPU 60Hz cycle.
• The last thing the GPU does is to generate sprite attribute tables from the virtual sprites. Since there are up to 16 virtual sprites, and each consists of up to 4 hardware sprites, 64 hardware sprites may be required. That's partially resolved by having one sprite attribute list at the top of the screen and another at the bottom. Sprites that overlap are added to both lists. And a scan line handler is changing the VDP register that's managing the sprite attribute table on the fly (that is also possible on the 9918A, but because of the 4 sprite per line limitation it has limited value).
• All this is done during blanking, between the last line of the screen and the first line of the screen are drawn. 
• The CPU is still doing everything that has to with controlling the user input, moving the virtual sprites, and then it's doing the much simpler task of checking the sprite collisions reported by the GPU.
• There should still be time left on the CPU side for an advanced sound player and other game logic.

[+Ksarul]

This is a definite bit of a killer app for the F18A--I watch the development with enjoyment. Many thanks for bringing this tour-de-force into the world, Rasmus.

[+9640News]

28 minutes ago, Asmusr said:

A bit of technical info:

• As mentioned before, the scrolling background requires far more than 256 characters in total, and it's very close to 256 at the individual screen level. If I need to save some patterns for displaying score, fuel etc., I need to find the best alterative for some patterns. That's what I have been working on for the last couple of days.
• The original hardware had sprites with a size of 32x32 pixels. The TI sprites are only 16x16, so I'm working with virtual sprites that consists of 1 to 4 hardware sprites. One example of a virtual sprite is the orange fuel tank, which consists of 4 hardware sprites.
• I have worked on offloading a substantial part of the work to the F18A GPU, so currently the CPU is only aware of the virtual sprites while the GPU is handing everything to do with the hardware sprites.
• The GPU is sorting the sprites according to their 3D distance from the user and is applying priorities (which sprites overlap each other) accordingly.
• The GPU is also calculating collisions between sprites and reporting this back to the CPU. That alone would take almost half of a CPU 60Hz cycle.
• The last thing the GPU does is to generate sprite attribute tables from the virtual sprites. Since there are up to 16 virtual sprites, and each consists of up to 4 hardware sprites, 64 hardware sprites may be required. That's partially resolved by having one sprite attribute list at the top of the screen and another at the bottom. Sprites that overlap are added to both lists. And a scan line handler is changing the VDP register that's managing the sprite attribute table on the fly (that is also possible on the 9918A, but because of the 4 sprite per line limitation it has limited value).
• All this is done during blanking, between the last line of the screen and the first line of the screen are drawn. 
• The CPU is still doing everything that has to with controlling the user input, moving the virtual sprites, and then it's doing the much simpler task of checking the sprite collisions reported by the GPU.
• There should still be time left on the CPU side for an advanced sound player and other game logic.

All I can say is "Wow!"

Excellent work, very impressive.  Where were you 35 years ago?  You could have made a fortune on the TI-99/4A back then!!!

[CrazyChris]

What emulator should I use to run this?

 

Thanks for your help.

 

Chris

[rgjt]

10 minutes ago, CrazyChris said:

What emulator should I use to run this?

 

pppppeeeeexxpp[]==-Thanks for your help.

 

Chris

it runs with the js99er.net java emulator. Load the BIN using the LOAD CART option and make sure the F18A is selected under the OPTIONS menu.

I also have the PC Keyboard enabled allowing the use of the directional keys, TAB is fire. Recall that the DOWN key up and the UP key is down.

 

[Tiziano Silvestri]

Super fantastic ! I Love this Forum 

[CrazyChris]

Tried it out. Great job! Looks like a PC game.

[+9640News]

Well, I opened up the joystick pad and cleaned the contacts.  Fire button works now!

[HOME AUTOMATION]

Yesterday's version is stupendous!

Why not posted yet?

[Asmusr]

10 hours ago, HOME AUTOMATION said:

Yesterday's version is stupendous!

Why not posted yet?

I wasn't able to test it on hardware yesterday, but here it is.

zaxxon8.bin

[fabrice montupet]

On space fly sequence, the shadow of the ship is present and covers stars and planets, maybe you could remove it during this sequence.

[Asmusr]

 

 

zaxxon8.bin

[rgjt]

This looks awesome.

[Asmusr]

I have sacrificed 22 patterns of the original scrolling background to make room for the patterns needed for the foreground.

[+Ksarul]

I am truly loving the development cycle here, as one of my favorite old-school arcade games becomes an awesome TI port! Thank you Rasmus!

[whoami999ster]

On 5/7/2021 at 8:44 PM, Asmusr said:

A bit of technical info:

• As mentioned before, the scrolling background requires far more than 256 characters in total, and it's very close to 256 at the individual screen level. If I need to save some patterns for displaying score, fuel etc., I need to find the best alterative for some patterns. That's what I have been working on for the last couple of days.
• The original hardware had sprites with a size of 32x32 pixels. The TI sprites are only 16x16, so I'm working with virtual sprites that consists of 1 to 4 hardware sprites. One example of a virtual sprite is the orange fuel tank, which consists of 4 hardware sprites.
• I have worked on offloading a substantial part of the work to the F18A GPU, so currently the CPU is only aware of the virtual sprites while the GPU is handing everything to do with the hardware sprites.
• The GPU is sorting the sprites according to their 3D distance from the user and is applying priorities (which sprites overlap each other) accordingly.
• The GPU is also calculating collisions between sprites and reporting this back to the CPU. That alone would take almost half of a CPU 60Hz cycle.
• The last thing the GPU does is to generate sprite attribute tables from the virtual sprites. Since there are up to 16 virtual sprites, and each consists of up to 4 hardware sprites, 64 hardware sprites may be required. That's partially resolved by having one sprite attribute list at the top of the screen and another at the bottom. Sprites that overlap are added to both lists. And a scan line handler is changing the VDP register that's managing the sprite attribute table on the fly (that is also possible on the 9918A, but because of the 4 sprite per line limitation it has limited value).
• All this is done during blanking, between the last line of the screen and the first line of the screen are drawn. 
• The CPU is still doing everything that has to with controlling the user input, moving the virtual sprites, and then it's doing the much simpler task of checking the sprite collisions reported by the GPU.
• There should still be time left on the CPU side for an advanced sound player and other game logic.

What I can surely understand is that this wondefull example of arcade on TI99/4A with basic configuration even with 32K expansion will never be sufficient to manage the game graphics requisite . that's really a pity ... maybe a very semplified versione would be possible? what's you opinion ? 

Just  a clarification for a very newbie : "a scan line handler is changing the VDP register that's managing the sprite attribute table on the fly" it means changes of the SAT itself (i.e sprite position, color,..) or chage the position of SAT in VRAM ?   

  Thanks a lot for your work with TI99/4A always at the top level

 

[+Vorticon]

On 5/23/2021 at 4:16 PM, Asmusr said:

I have sacrificed 22 patterns of the original scrolling background to make room for the patterns needed for the foreground.

They will be for ever remembered...

[Asmusr]

9 hours ago, whoami999ster said:

Just  a clarification for a very newbie : "a scan line handler is changing the VDP register that's managing the sprite attribute table on the fly" it means changes of the SAT itself (i.e sprite position, color,..) or chage the position of SAT in VRAM ?   

The latter. The content of the 2nd SAT is ready at that point, so changing the position of the SAT in VRAM is all that's needed.

[whoami999ster]

On 3/5/2021 at 6:03 PM, Asmusr said:

Yes. The F18A can mirror sprites both vertically and horizontally by setting bits in the 4th attribute byte. If I run out of patterns again, I'm going to use that approach for something like this explosion where you would hardly notice if the left and the right sides were mirrored. 

genial!

[+dhe]

Is there an F18A manual that's the equivalent of TI's TMS9918A manual?

[Retrospect]

Loving this!