Tursi Posted May 7, 2021 Share Posted May 7, 2021 Classic99 does not support most of the F18A advanced graphics. For now, you have to use hardware or 99er.net 1 Quote Link to comment Share on other sites More sharing options...
Asmusr Posted May 7, 2021 Author Share Posted May 7, 2021 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 ? 3 1 Quote Link to comment Share on other sites More sharing options...
Nick99 Posted May 7, 2021 Share Posted May 7, 2021 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! 1 Quote Link to comment Share on other sites More sharing options...
+9640News Posted May 7, 2021 Share Posted May 7, 2021 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. Quote Link to comment Share on other sites More sharing options...
Asmusr Posted May 7, 2021 Author Share Posted May 7, 2021 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. 12 Quote Link to comment Share on other sites More sharing options...
+Ksarul Posted May 7, 2021 Share Posted May 7, 2021 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. 4 Quote Link to comment Share on other sites More sharing options...
+9640News Posted May 7, 2021 Share Posted May 7, 2021 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!!! 4 Quote Link to comment Share on other sites More sharing options...
CrazyChris Posted May 9, 2021 Share Posted May 9, 2021 What emulator should I use to run this? Thanks for your help. Chris Quote Link to comment Share on other sites More sharing options...
rgjt Posted May 9, 2021 Share Posted May 9, 2021 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. 2 Quote Link to comment Share on other sites More sharing options...
Tiziano Silvestri Posted May 9, 2021 Share Posted May 9, 2021 Super fantastic ! I Love this Forum 2 Quote Link to comment Share on other sites More sharing options...
CrazyChris Posted May 9, 2021 Share Posted May 9, 2021 Tried it out. Great job! Looks like a PC game. Quote Link to comment Share on other sites More sharing options...
+9640News Posted May 9, 2021 Share Posted May 9, 2021 Well, I opened up the joystick pad and cleaned the contacts. Fire button works now! 4 Quote Link to comment Share on other sites More sharing options...
HOME AUTOMATION Posted May 15, 2021 Share Posted May 15, 2021 Yesterday's version is stupendous! Why not posted yet? 2 Quote Link to comment Share on other sites More sharing options...
Asmusr Posted May 15, 2021 Author Share Posted May 15, 2021 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 4 4 Quote Link to comment Share on other sites More sharing options...
fabrice montupet Posted May 15, 2021 Share Posted May 15, 2021 On space fly sequence, the shadow of the ship is present and covers stars and planets, maybe you could remove it during this sequence. 3 Quote Link to comment Share on other sites More sharing options...
Asmusr Posted May 23, 2021 Author Share Posted May 23, 2021 zaxxon8.bin 21 Quote Link to comment Share on other sites More sharing options...
rgjt Posted May 23, 2021 Share Posted May 23, 2021 This looks awesome. 1 Quote Link to comment Share on other sites More sharing options...
Asmusr Posted May 23, 2021 Author Share Posted May 23, 2021 I have sacrificed 22 patterns of the original scrolling background to make room for the patterns needed for the foreground. 2 Quote Link to comment Share on other sites More sharing options...
+Ksarul Posted May 24, 2021 Share Posted May 24, 2021 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! 1 Quote Link to comment Share on other sites More sharing options...
whoami999ster Posted May 24, 2021 Share Posted May 24, 2021 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 Quote Link to comment Share on other sites More sharing options...
+Vorticon Posted May 25, 2021 Share Posted May 25, 2021 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... 2 2 Quote Link to comment Share on other sites More sharing options...
Asmusr Posted May 25, 2021 Author Share Posted May 25, 2021 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. 1 Quote Link to comment Share on other sites More sharing options...
whoami999ster Posted May 26, 2021 Share Posted May 26, 2021 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! Quote Link to comment Share on other sites More sharing options...
+dhe Posted June 4, 2021 Share Posted June 4, 2021 Is there an F18A manual that's the equivalent of TI's TMS9918A manual? 1 Quote Link to comment Share on other sites More sharing options...
Retrospect Posted June 4, 2021 Share Posted June 4, 2021 Loving this! Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.