Jump to content
Asmusr

F18A Zaxxon demo

Recommended Posts

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

 

 

  • Like 1

Share this post


Link to post
Share on other sites
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 🙂

  • Like 3
  • Thanks 1

Share this post


Link to post
Share on other sites

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! 

  • Like 1

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

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.
  • Like 12

Share this post


Link to post
Share on other sites

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.

  • Like 4

Share this post


Link to post
Share on other sites
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!!!

  • Like 4

Share this post


Link to post
Share on other sites
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.

 

  • Like 2

Share this post


Link to post
Share on other sites

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

  • Like 4

Share this post


Link to post
Share on other sites
10 hours ago, HOME AUTOMATION said:

Yesterday's version is stupendous!:-o

Why not posted yet?

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

zaxxon8.bin

  • Like 4
  • Thanks 4

Share this post


Link to post
Share on other sites

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

  • Like 3

Share this post


Link to post
Share on other sites

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

  • Like 2

Share this post


Link to post
Share on other sites

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!

  • Like 1

Share this post


Link to post
Share on other sites
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

 

Share this post


Link to post
Share on other sites
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...

  • Like 2
  • Haha 2

Share this post


Link to post
Share on other sites
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.

  • Like 1

Share this post


Link to post
Share on other sites
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. 

image.png.00b4d99cf8eb937479f46231af6f06f0.png

genial!

Share this post


Link to post
Share on other sites

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

  • Like 1

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...