Jump to content
IGNORED

AVARIS II cart image release


Retrospect

Recommended Posts

AVARIS 2.zip << Zip folder containing Solid State Software game and instructions.

 

AVR2-G.BIN << * Bug Fix!  Fixes issue with crashing into ground sending you back to start of game.
Also added is new font, warning sounds, and ground scrolls faster, slight issue with starfield corrected.

 

 

 

 

 

 

Download Avaris II ... and have fun!  

I must mention this game was made possible by using Senior Falcon's XB256 and the compiler.  If you are curious and have a desire to tinker , go download it from the development thread, otherwise you can get it with Classic99 from HarmlessLion.com ... it's in the "distributors" folder under Harry Wihelm.  Also used was Magellan to plot out the graphics, that is also in the Development thread.  This project has been both fun and frustrating, it's all part of the hobby.  :) 

 

 

  • Like 12
  • Thanks 3
Link to comment
Share on other sites

Seems I forgot to update this thread and only the other in "computers" which not so many folks exist on.  
Programmed a few updates during my coding break.  'Cos that's what ya do, ya know.

 

So ... we now have "swooping" noises whenever cruisers enter the stage ... and a "humming" noise whenever flying saucepans enter the stage.

Now I wonder where I got that idea from. Also there's a new intro sequence that's rather explosive.  
In order to fit these updates in, I had to get rid of the funky font and go with the standard GROM font instead (Tall Font) but it's no biggie, it won't make you crash less.

 

AV2-G.BIN

AVA2-8.BIN

AVARIS Manual.pdf

 

 

  • Like 10
Link to comment
Share on other sites

On 3/4/2023 at 1:47 PM, Retrospect said:

Here's a bit of of useless trivia.  Avaris II contains 104 GOSUB statements in it's XB source.

104... It's impressive. GOSUB AND GOTO are statements that I try to reduce their number as possible it can be done (when it's possible) because they are source of execution slow down.
I see that they are not a problem for Avaris II 🙂

  • Like 1
  • Thanks 1
Link to comment
Share on other sites

30 minutes ago, fabrice montupet said:

104... It's impressive. GOSUB AND GOTO are statements that I try to reduce their number as possible it can be done (when it's possible) because they are source of execution slow down.
I see that they are not a problem for Avaris II 🙂

Being compiled seems to reduce, if not completely eliminate, the performance hits on GOSUB/RETURN.

  • Like 2
Link to comment
Share on other sites

15 minutes ago, Retrospect said:

Thanks @fabrice montupet 
In your opinion Fabrice, which would be faster, a GOSUB or a CALL to a label?  

Can't tell you, I don't use the SUB statement.

20 minutes ago, OLD CS1 said:

Being compiled seems to reduce, if not completely eliminate, the performance hits on GOSUB/RETURN.

Yes, compilation reduce but does not eliminate according to the tests I made on the XB256 game I am working on and that heavily consumes computer resources (I have to continuously do my best to optimize the code on each feature I add to keep the game playable so I try all the paths).  But, the best thing is to ask to Harry to confirm.

  • Like 1
Link to comment
Share on other sites

So when I'm doing this ..... I couldn't think of any other way.  This way with the Gosubs ensures that everything moves, and the code always jumps back to the main loop as quickly as possible for player joystick input etc etc.  

! PLACE ENEMY AND PLAYER
500 CODE HERE FOR PLAYER SPRITE
510 CODE HERE FOR ENEMY SPRITE

! *** MAIN LOOP ***
1000 GOSUB 4100 :: GOSUB 4200 :: GOSUB 4300 :: GOSUB 4400 :: GOSUB 4500 :: GOSUB 4600 :: GOSUB 4700 :: GOSUB 4800 :: GOTO 1000



! READ THE JOYSTICK
4100 CODE HERE 
4110 RETURN

! JOYSTICK UP
4200 CODE HERE
4210 RETURN

! JOYSTICK DOWN
4300 CODE HERE
4310 RETURN

! JOYSTICK LEFT
4400 CODE HERE
4410 RETURN

! JOYSTICK RIGHT
4500 CODE HERE
4510 RETURN

! FIRE KEY?
4600 CODE HERE
4610 RETURN

! INCREMENT PLAYER MISSILE?
4700 CODE HERE
4710 RETURN

! INCREMENT "ENEMY COUNTER" AND MOVE THE ENEMY
4800 CODE HERE
4810 RETURN

 

  • Like 1
Link to comment
Share on other sites

8 minutes ago, OLD CS1 said:

Ah, I see here.  You could replace the 4200, 4300, 4400, 4500, and possibly the 4600 GOSUBs with a single conditional ON/GOSUB.

I also thought about this when read the message but I thought myself that Joe has surely also thought about it. Without seeing the entire code of game it is difficult to give an advice about a way to make different and quicker.

 

Link to comment
Share on other sites

The question about speed of GOTO and GOSUB and CALL can be a bit murky. It's easier to sort out in XB because you can easily do tests to see if one method is better than another.

First off, since XB has to look through the line number table to find out where to GOTO or GOSUB, it follows that, with longer programs, it will take longer to do a GOTO. It makes a difference whether you are going to a line near the end of the program or near the beginning. This subject came up a few years ago, and as I remember, it is faster to GOTO a line near the end of the program.

This does not apply to compiled code, which knows where to GOTO without having to look it up., and the same applies to GOSUB

In XB, user CALLs are a bit sluggish compared to GOSUB. Here again, compiled code knows where the subprogram is without having to look it up, so user written CALLS may be almost as fast as GOSUB.

For Joe's purposes, ON/GOSUB might be faster, but it is not clear to me that it actually would be. To use this you must come up with a value to use, and that would involve a number of arithmetic operations. This of course will take time, and that may offset any speed gain from using ON/GOSUB.

  • Like 3
  • Thanks 2
Link to comment
Share on other sites

Thanks @senior_falcon.   I'm thinking these would be way more critical in standard XB.  I am surprised that it's quicker to GOTO the end of the program.  I remember once writing a standard XB game and I had all of my player moves code at the top of the program ... there was a line that told the program to GOTO the main code below it all .. and it had all of the character pattern definition data right at the bottom of the program.  My line of thinking was that the '99 would literally scan the code from top to bottom each update. 

 

 

Link to comment
Share on other sites

2 hours ago, senior_falcon said:

This subject came up a few years ago, and as I remember, it is faster to GOTO a line near the end of the program.

We mused quite a bit on GOSUB, which was the topic, and I suspect GOTO will behave similarly.

 

 

  • Like 2
Link to comment
Share on other sites

12 hours ago, senior_falcon said:

The question about speed of GOTO and GOSUB and CALL can be a bit murky. It's easier to sort out in XB because you can easily do tests to see if one method is better than another.

First off, since XB has to look through the line number table to find out where to GOTO or GOSUB, it follows that, with longer programs, it will take longer to do a GOTO. It makes a difference whether you are going to a line near the end of the program or near the beginning. This subject came up a few years ago, and as I remember, it is faster to GOTO a line near the end of the program.

This does not apply to compiled code, which knows where to GOTO without having to look it up., and the same applies to GOSUB

In XB, user CALLs are a bit sluggish compared to GOSUB. Here again, compiled code knows where the subprogram is without having to look it up, so user written CALLS may be almost as fast as GOSUB.

For Joe's purposes, ON/GOSUB might be faster, but it is not clear to me that it actually would be. To use this you must come up with a value to use, and that would involve a number of arithmetic operations. This of course will take time, and that may offset any speed gain from using ON/GOSUB.

XB runs from Highest Memory address to Lowest Memory address and this is true no matter in Console VDP only or 24K RAM of 32K memory.

Also as XB is slightly stack orientated anything on top of stack will get more quickly executed then bottom of stack.

Lastly any SUB programs use TEMPORARY variables thus will trigger a garbage collection more often than normal variables as they are not TEMPORARY.

As for GOSUB or GOTO or CALL all of them are searchable by NUD Table in GPL and CALL is top of list, but as it has to search subprogram names it can take longer.

Hence why shorter names of both variables and subprograms names should be as short as possible.

These name lengths can add up, whereas a line number is only just a single word (two bytes) and even a name has to have a 2 byte address in 16 bit machines.

  • Like 1
Link to comment
Share on other sites

41 minutes ago, RXB said:

Lastly any SUB programs use TEMPORARY variables thus will trigger a garbage collection more often than normal variables as they are not TEMPORARY.

I do remember making a video of Avaris during it's earlier stages and the TI decided to "Take the dustbin out" as it were ... lol 

  • Like 2
  • Haha 1
Link to comment
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.
Note: Your post will require moderator approval before it will be visible.

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...