Cosmic Hero revision 2 ... final release ... RXB

[Retrospect]

  COSMIC2B <<< Bug fix.  Fixed "Thruster Overheat" that stays overheated after it over heats.

 

 

For use with the Rich Extended Basic 2022G which is available on this forum from Rich Gilbertson.  Guide your rescue ship down the screen, pick up hostage, get back up and dock with mothership.

On way down screen, pressing FIRE will enable you to slow down with the Thruster - be careful as too long on the thruster in one go will overheat the ship!  As seen in the video.

It's not easy but it's fun!  Enjoy!  There will be more RXB games available soon. 

The above video shows revision 2 of the game.  now, with each level the time for the thruster to overheat is faster, at game over you get a summary telling you how many hostages you rescued, how many you killed (yes, you can kill them now, if you are carrying a hostage and you crash the hostage will fall to their death in comical fashion)

 

 

[+eebuckeye]

Very nice!

[fabrice montupet]

The game seems might as well have been programmed just using Extended Basic. What did RXB bring more?

[RXB]

24 minutes ago, fabrice montupet said:

The game seems might as well have been programmed just using Extended Basic. What did RXB bring more?

Did you even look at the program code first before you posted this?

Being this negative before you even know the answer is showing an apparent judgement without any evidence.

[fabrice montupet]

Really nothing negative in my question, you should stop systematically seeing the bad in all things.

Considering the large number of functions provided by RXB, I was surprised that this was not visible for the player.

[Retrospect]

39 minutes ago, fabrice montupet said:

The game seems might as well have been programmed just using Extended Basic. What did RXB bring more?

You see the mothership at the top of the screen that goes side to side?  Well with normal XB it would literally MISS the code that wants it to move to the other side, which would mean I had to put in more checks for the mothership , which would then cause slow-down in the rest of the game.  There's a neat command in RXB called CALL RMOTION() and it works very well.  It reverses the automotion of either specific sprites or all sprites.  

 

This is one of my first RXB games, or at least, my first serious attempt at making on with RXB.  We have to bare that in mind.  Normally I code for Compiled XB.  Making a game work well that is not compiled is tricky at best.  

[RXB]

1 minute ago, fabrice montupet said:

Really nothing negative in my question, you should stop systematically seeing the bad in all things.

Considering the large number of functions provided by RXB, I was surprised that this was not visible for the player.

RXB has Assembly routines for many routines that used to be GPL in XB normal version.

CALL CLEAR alone is 3 times faster then XB version.

CALL HPUT takes the place of DISPLAY and uses entire screen not just PRINT area, also shown to be 3 times faster.

 

These lines alone is not something you can do in any other XB:

 

2025 CALL COLLIDE(#13,#1,8,C1,C2,#14,#1,8,C3,C4)

or

3025 CALL COLLIDE(#28,#13,8,A,B) :: IF A+B THEN 3100

or

3055 CALL COLLIDE(#28,#14,8,A,B) :: IF A+B THEN 3100

or

16220 MO=1 :: CALL RMOTION(#2,#16) :: GOTO 16299

 

It is clear without any checking you question the value of RXB as a Cartridge.

This is not a new thing.

[Retrospect]

Well as far as I know, RXB cartridge will work on any stock 16K console, am I right?  If this is the case then it should suit all "purists" out there,  I can just about forgive people when they are critical of say the F18A card, yeah it's not a "proper TI" but I tell you now, RXB has got things in there that have attracted MY attention .... and I'm an out-and-out games programmer.  I'm giving it the thumbs up.  My next projects will have elements in them that aren't in XB , such as the new joystick locate commands etc etc.  They're written in Assy not GPL so they're faster.  

 

Anyone not making a game for compiled XB256, should try RXB at least give it a go and see if you like it?  I did.

[Retrospect]

16 minutes ago, fabrice montupet said:

Considering the large number of functions provided by RXB, I was surprised that this was not visible for the player.

This particular game didn't need some of the extra commands provided with the RXB language due to how the player ship is controlled, however, future projects with RXB will probably need those new commands.  I was expecting this sort of critic from someone.  I was well prepared.  What I will say is this;  Try programming with it yourself.  See the difference over normal plain vanilla XB it offers. It's nice.  

[RXB]

Yes Retospect is correct.

RXB is designed to work with only a Console and all the Assembly added is in the ROM's to replace the GPL slower code.

Many commands are up to 9 times faster than normal XB code like CALL HCHAR or CALL VCHAR is 9 times faster in just a console and RXB Cart.

[Retrospect]

It's okay .... by the time I'm onto my tenth or eleventh RXB game people might start seeing the difference between this and standard XB.

[oddemann]

2 hours ago, Retrospect said:

It's okay .... by the time I'm onto my tenth or eleventh RXB game people might start seeing the difference between this and standard XB.

I think that showing off RXB in this way is the best way, to "sell" it.

And also by more games popping up, more stuff will show up. So I think now in the beginning it is a valid question to ask... "What makes it better!" But as I say, over time and more practical use of RXB will show what is better. A show and tell of a feature in RXB is not the same as the practical application of RXB in a game.

Looks very nice! Great job @Retrospect Looks very smooth!

Looking forward to more practical examples of RXB in a game!

[fabrice montupet]

Thank you Restrospect for your information.

I Know the advantages of RXB, its improvements, its impressive features and additional routines for graphics or easy memories access (RAM, VDP RAM or SAMS) that it brings for any stock TI-99/4A. What I have just said in my previous message is that when I saw the game, I just thought about a game made with XB like one used to see. But knowing the ability for Restrospect to make captivating games, I'm sure that his futures ones for RXB will offer to players surprising things 🙂

By my side, I consider (maybe incorrectly) that the most of people using a real 99/4A have (or can have) a 32K expansion too. Its low price (today) and the easy to get one make that this expansion has become as essential as common. People that buy a FlashROM, FinalGROM or a EPROM cartridge (between 40 to 100 USD) to benefit from the TI-99 software library (if only to easily run programs for XB, E/A, RXB, XB256/GEM,... ) are also able to buy a 32Kb side expansion for less than 50 USD. This is why I use it for programming. But once again, I do not claim to have the truth. Everyone does as they feel.

Restrospect, have fun for your next creations! I look forward them  🙂

 

[Retrospect]

thankyou @oddemann and @fabrice montupet and @eebuckeye 

 

Yes, I will always try my best to make good games, for various platforms, xb256 and rxb being two of them.  I've made games for TI basic before, that is the biggest struggle of all, to make a playable game in TI Basic I take my hat off to those of us who have managed it.  

 

As I said before though, the main thing about RXB is that we can do with rxb , in just a few lines , what would take more lines of code in plain xb to do, and even then plain xb might fail -miss collisions, positions etc... it's known for it.  XB should of had all those routines done in assembly just as rxb is now.  

 

I tend to find though with anything not compiled, games are possible if we bare in mind to keep them at a steady speed, not try to be too fast.  We can make graphical demo's that run fast in xb / rxb , but when we then attempt to put things in like joystick and positional checks, is when it needs to be steady.  We will see what can be done with future games 

 

[Retrospect]

Here's a little demo of the CALL JOYLOCATE command within RXB.  Now, my code isn't the best, and I'm giving the source out here ... so if anyone knows better routines to do what I'm doing here let me know ... but I think it executes fine for now.  

We have a player ship that moves around the screen at 4 pixel increments and fires a missile.  The player ship faces four ways, and fires four ways.  The missile firing direction is decided by a variable and an "ON GOTO" situation for both initially firing the automotion missile, and the upkeep of it's position on the screen.  If we can think of better code to do this , then I can probably have the missile maybe go a little faster than automotion value 11 which it is at now.

 

RXB SHOOTING SPRITES.txt < Documented code

 

 

 

[Retrospect]

Here's one more little program done for RXB  ... this one is "snake in the grass, starring billy ball"

 

Within the program is a variable called "lev" which is used to ascertain which screen, and enemies, we have present.  There's two source files here, one with one screen only, and the other is with two screens and a different enemy.

 

There is going to be ON GOTO and ON GOSUB for the LEV variable which will bring another screen and enemies if Billy makes it to the other side.

Used in this program is CALL JOYMOTION, CALL RMOTION and CALL COLLIDE which are all assembly written routines rather than the old Granny Programming Language ones used in plain XB.

 

Source and video here.  Play with the source make your own game

BILL BALL RXB.txt <<< 1 screen only

BILL BALL RXB 2.txt <<< 2 screens and two enemies.

If you can't get to screen two, alter line 900 to say LEV=2 and it'll start from the 2nd screen.

 

 

Edited January 29, 2023 by Retrospect

[+TheBF]

@Retrospect You have a great system for building these games in BASIC and a great imagination for themes.

It's always a challenge for me to consider how I would put these games together in Forth.

Thanks for the ideas which I could never think of.

Cheers.

[Retrospect]

4 hours ago, TheBF said:

a great imagination for themes

Thanks BF.  I do me bestest.     

[RXB]

So today released RXB 2023

 

 

RXB 2023.zip

[Retrospect]

@fabrice montupet , here's a slightly better example of what RXB does over standard XB.  This program is called "Big Nose Goes To Hell" and it is using CALL SWAPCHAR to animate fire, and send down 3 bolts of electricity.  Also uses the CALL JOYMOTION subprogram, for the movement of Big Nose.  We could, granted, do this in normal XB, but it is in my opinion that it would be slower and execution would be sloppier.  Also more bytes used because the CALL VCHAR command in RXB can have extra repetitions, so again, would be a bit slower.  It would have been nice to have seen more games written in rxb.  I've done loads for XB256 , for example.  We should be more inclusive and give things a chance. 

 

BIGNOSE RXB.txt

 

 

 

 

 

[+OLD CS1]

With Rich's new machine language HCHAR subroutine, is this statement

 

CALL HPUT(Q,1,"rrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrr")

any faster than

 

CALL HCHAR(21,1,82,128)

?

 

(Also removing the loop for Q)  It would take up a little less memory, for sure.  Poor Big Nose.

[Retrospect]

30 minutes ago, OLD CS1 said:

With Rich's new machine language HCHAR subroutine, is this statement

 

CALL HPUT(Q,1,"rrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrr")

any faster than

 

CALL HCHAR(21,1,82,128)

?

 

(Also removing the loop for Q)  It would take up a little less memory, for sure.  Poor Big Nose.

I'm not sure OLD CS1 , on that one, might be one for Rich to answer .... I was assuming his HPUT command might be faster than CALL HCHAR.

[Retrospect]

If after all we have seen, Big Nose and all, we 're not fully satisfied and we want a little more .... then allow me to take you into insanity!

INSANITY.txt <<< Commented Source.

 

EDIT: I have NO idea why the player ship has a ghost, but it does.  

Edited January 31, 2023 by Retrospect

[RXB]

1 hour ago, OLD CS1 said:

With Rich's new machine language HCHAR subroutine, is this statement

 

CALL HPUT(Q,1,"rrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrr")

any faster than

 

CALL HCHAR(21,1,82,128)

?

 

(Also removing the loop for Q)  It would take up a little less memory, for sure.  Poor Big Nose.

Actually just timed them using this test:

100 CALL CLEAR
110 OPEN #1:"CLOCK"
120 INPUT #1:A$,B$,C$
130 FOR C=1 TO 10000
140 CALL HPUT(1,1,"rrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrr") or CALL HCHAR(1,1,114,32)
150 NEXT C
160 INPUT #1:D$,E$,F$
170 PRINT A$,D$:B$,E$,C$,F$
180 END

 

I got CALL HPUT  4 minutes 28 seconds and CALL HCHAR  5 minutes 8 seconds.

So yea HPUT is sometimes faster depending on how the commands are used.

[+OLD CS1]

4 minutes ago, RXB said:

I got CALL HPUT  4 minutes 28 seconds and CALL HCHAR  5 minutes 8 seconds.

So yea HPUT is sometimes faster depending on how the commands are used.

Unexpected.