XB Game Developers Package

[senior_falcon]

 

Will this equate to faster execution times when compiled, or is it more about trying to better emulate something more faithful to the standard XB syntax?

 

I have now gotten used to writing the way the compiler demands!

It won't be any faster, but the more versatile XB IF-THEN-ELSE logic should be a welcome addition. Of course, it is perfectly OK to use just line numbers for this and in theory the older way is a tiny bit faster, but I doubt if you would be able to notice it.

[LASooner]

Can you use THEN GOSUB? or do you still have to go to a line number to do that?

[senior_falcon]

I have an idea for an ambitious game.... Is it known what the maximum size of program can be compiled? I have, honestly, no idea if what I want to do will fit, but... I think it may be worthwhile to attempt....

I believe that a 24K XB program can be compiled. The runtime routines take nearly 7 or 8K of memory, which leaves you with 16 or 17K of memory for the program. But when an XB program is compiled, it comes out considerably smaller; usually around 2/3 the size or less. As an example, Aperture used 13693 bytes of RAM and compiled it needs 16860. If you subtract the runtime routines it is around 10K long.

A couple observations: numbers take 2 bytes instead of 8, but strings take the same amount of memory. So if you use a lot of strings there will be less memory savings than if you use a lot of numbers.

Compressed data statements can pack in a lot of information in a smaller amount of space.

Bones is using a bunch of memory saving tricks in Gridslugger.

[senior_falcon]

Can you use THEN GOSUB? or do you still have to go to a line number to do that?

One of my test programs was something like this and it worked fine:

100 INPUT X

110 IF X=7 THEN GOSUB 200::PRINT "BACK FROM 200" ELSE GOSUB 300::PRINT "BACK FROM 300"

120 GOTO 100

200 PRINT "SUB 200"::RETURN

300 PRINT "SUB 300"::RETURN

 

From the XB manual:

100 IF X>5 THEN GOSUB 300 ELSE X=X+5

100 IF Z THEN C=C+1::GOTO 500::ELSE L=L/C::GOTO 300

All should compile and run properly

Also,

100 IF X=3 THEN IF Y=1 THEN IF Z=4 THEN PRINT "PI"

This too works fine, but you might as well just use AND: 10 IF X=3 AND Y=1 AND Z=4 THEN PRINT "PI" ELSE PRINT "NOT PI"

Edited February 14, 2018 by senior_falcon

[Opry99er]

[Opry99er]

Its about to get ridiculous up in here.......

[senior_falcon]

Here is the Extended BASIC Game Developer's Package "Bordeaux" The big change is the ability to compile the more versatile XB style IF/THEN/ELSE format.

 

Read XBGDPDOCS for set up information.

 

(Edit Feb 14th) A new zipped file was uploaded with some revisions to the compiler documentation. If you already downloaded this all you need is the XB compiler docs.

XBGDPbordeaux.zip

XB Compiler docs.pdf

Edited February 15, 2018 by senior_falcon

[Opry99er]

Got it!

 

This upcoming weekend I shall attempt to compile my two sub-par arcade games and see if I can get them to perform!

 

I don't remember, Harry... can the sound-list player available in XB256 be incorporated into compiled XB code as well?

 

I ask because while my two arcade games have the typical XB sluggishness, they are unique in that they utilize background music (using matthew's soundlist player). If I decide to change the format up and compile these, I would like to have the opportunity to integrate the soundlists from these games.

[LASooner]

 

 

I don't remember, Harry... can the sound-list player available in XB256 be incorporated into compiled XB code as well?

 

 

I can answer that, yes it can

[unhuman]

Thanks for the compiler update! The documentation is a bit inconsistent on the bordeaux updates with XB style IF / THEN / ELSE.

 

I'm planning stuff now!

[senior_falcon]

The documentation is a bit inconsistent on the bordeaux updates with XB style IF / THEN / ELSE.

 

I thought the docs were all consistent, but I see now that there is a part that must be excised. I will do that and repost the package and also just the revised docs.

 

(edit) The revised compiler docs are attached; also I will update the zip folder with the complete package.

XB Compiler docs.pdf

Edited February 15, 2018 by senior_falcon

[senior_falcon]

It does the same demo as yours but starts at bottom and twice as fast as XB, also faster then your demo.

 

(But I assume your demo in Assembly has delays in it to slow it.)

 

A couple of points:

If my compiled demo just has "Hello World" then it is twice as fast as your version in RXB. But you have a good point - as the string gets longer then it takes longer to print to the screen. You have to remember that these programs get there via very different paths. The compiled version does it the TI BASIC way: it takes a string, uses SEG$ to extract a one character string, converts to an ASCII number, uses HCHAR to get a row and colum and prints the ascii at the screen location. That's a lot of steps and they have to be done for each character. In your RXB program the bottleneck is at the beginning: it takes time to CALL the routine, to fetch the string and the screen location, etc. Once that is done then it can efficiently move the bytes to VDP memory. Writing 200 bytes wouldn't take very much longer than writing just one byte - the initial overhead is the same.

 

One thing you can be sure of is that I would not intentionally put delays in the compiler as the whole idea is to run as fast as possible. I chose the TI BASIC method not as an example of how you should print text on the screen (It's a lousy way to do that) but just as an example of how much the compiler can speed up the code and how easy it is to modify the original XB program with the new package.

 

In XB256 there is a subroutine called DISPLY that is used to print text on the screen. I mimicked your program but used DISPLY instead and the results are in the video below. The programs are running in RXB and XB and you can see that they run at virtually the same speed.

I don't want people getting the idea that my poor old compiler is hard pressed to keep up with XB or RXB, so I then break my program and run the same program that has been compiled. I think you will be able to detect a difference...

 

(The choppiness is because the frame rate is too slow)

 

(edit) In fairness to RXB, Rich's example could be sped up a lot by including a space after Hello World and eliminating the 2nd 1 byte long string. This cuts the overhead in half and and it runs twice as fast as the similar assembly subroutine DISPLY.

 

How can that be? It turns out that XB and RXB are considerably faster performing a CALL compared to performing a CALL LINK. Additionally, it takes longer to pass strings and numbers to the routine when using CALL LINK. So CALL LINK starts out slower. Once it is running the assembly routine should always be faster, but in this case that is not enough to make up for the slow start.

Edited February 15, 2018 by senior_falcon

[Opry99er]

Very slight difference there....

[unhuman]

One thing that I think would be helpful is the ability to track time... I'd like my game loop to be consistently timed, no matter how long things take....

 

Something like this - let's say I want my loop to have a total time of ~ 100ms....

 

Loop Start

Capture TimeStart

Do Stuff

Capture TimeEnd

Sleep for 100-TimeEnd-TimeStart

End loop

 

My plan is to not use sprite motion, but to move sprites around manually. Why? Because I anticipate having too many objects on screen, so will need some sort of flickering algorithm.

 

Honestly, I don't know if the FPS I anticipate will work, but constraining the loop to be consistent will be important.

 

Thanks!

[Opry99er]

Hmm... so, your loop time would obviously change depending on the goings-on therein... if users are inputting via joystick, etc, it would necessarily lengthen the amount of time required to complete said loop versus NOT doing so, right?

 

And obviously, adding an incrementing timer would change the timing.... so thats not REALLY a viable option if you are going for millisecond-accurate loop times...

 

Im thinking via software, it would be a fairly strenuous trial and error process to get the balance you want... but it could be done, I think.

 

Maybe Im not quite understanding your request.

[Bones-69]

I haven't done anything yet that required a need to slow down a compiled program, but in my thoughts on the subject I had speculated that it could be feasible to put a transparent sprite into motion - say horizontally on a part of the game screen not used. Then by regularly fetching the X value using CALL POSITION you could use the returned value to trigger program events. I had thought that by speeding up or slowing down the motion of the sprite, and therefore the speed it arrives at certain screen positions (or value ranges), might be a practical way to adjust timing within a game. Higher levels in games could be sped up by increasing the speed of the sprite, and therefore the frequency of values returned. Would almost be a case of just setting it in motion and forgetting about it. No need for individual delays, or timers, or loops & no need to reset counters... Just wait until you return a value within some set limit and then execute some function/s as desired.

 

Not tested, just an idea/concept.

Edited February 15, 2018 by Bones-69

[senior_falcon]

One thing that I think would be helpful is the ability to track time... I'd like my game loop to be consistently timed, no matter how long things take....

 

Something like this - let's say I want my loop to have a total time of ~ 100ms....

 

Loop Start

Capture TimeStart

Do Stuff

Capture TimeEnd

Sleep for 100-TimeEnd-TimeStart

End loop

 

My plan is to not use sprite motion, but to move sprites around manually. Why? Because I anticipate having too many objects on screen, so will need some sort of flickering algorithm.

 

Honestly, I don't know if the FPS I anticipate will work, but constraining the loop to be consistent will be important.

 

Thanks!

You have a clock that ticks 60 times a second, so something like this should work.

Set the number of clock ticks per loop with CALL LOAD(-1,3) for 3 ticks or 1/20 second per loop. You could have a custom routine like CALL LINK("SYNCDL",3) but it hardly seems worth the effort. Then include CALL LINK("SYNC") at the end of the loop. (This subroutine is yet to be written.)

When the compiler comes to SYNC it then loops doing LIMI 2 and LIMI 0 until the value at the clock byte (I think it is at >8379) is the same or greater than the value at -1. If so then reset the clock to 0 and resume program execution.

 

It would be nice if the loop executed in less than 1/60 second but I don't know how likely that is.

Edited February 15, 2018 by senior_falcon

[unhuman]

You have a clock that ticks 60 times a second, so something like this should work.

Set the number of clock ticks per loop with CALL LOAD(-1,3) for 3 ticks or 1/20 second per loop. You could have a custom routine like CALL LINK("SYNCDL",3) but it hardly seems worth the effort. Then include CALL LINK("SYNC") at the end of the loop. (This subroutine is yet to be written.)

When the compiler comes to SYNC it then loops doing LIMI 2 and LIMI 0 until the value at the clock byte (I think it is at >8379) is the same or greater than the value at -1. If so then reset the clock to 0 and resume program execution.

 

It would be nice if the loop executed in less than 1/60 second but I don't know how likely that is.

 

Yeah, I don't know how it's going to wind up and I'm getting ahead of myself. I'm largely not planning on using auto-sprite motion for this because it'll be far easier to be able to cycle sprites to permit flicker / allow more than 4 sprites on a line. It'll also allow me to track objects in a space that's larger than the screen an only render them if needed.... Like I said, I'm getting ahead of myself, but maybe it falls into "planning."

 

Anyhow, assuming I get time this weekend, I'll be able to handle the feasibility of my implementation.... The game is definitely doable. Just if my brain can put it into the right form for the TI.

[RXB]

Yea XB256 being assembly has way more speed advantages then RXB.

But then Interpreted instantly vs Compiled both have draw backs and advantages.

Interpreted is much quicker to edit and debug.

Compiled has way more speed, unless you have to edit then has way more steps to do so.

 

I did think of using GPL MOVE routine is way more powerful then HCHAR or DISPLAY AT it will move

any amount of any memory of any type (i.e. VDP, RAM, GRAM/GROM) from any address to any address.

(Also works with STRING VARIABLES or NUMERIC VARIABLES)

 

Several routines in RXB should be in XB, and a XB256 version of RXB would be really more powerful.

Edited February 15, 2018 by RXB

[Asmusr]

I have used sprite flicker/rotation routines in several games, and for a satisfactory result you need to switch sprite priorities every frame (60/50 FPS). Even then the effect is not that great on modern screens.

.

[LASooner]

Sprite flicker/rotation routine in XB256 would be a great feature, Mr Falcon, sir.

 

One that would flip a sprite left or right or up or down would be welcomed as well.

 

You know, if you have time to kill..

 

[senior_falcon]

Yea XB256 being assembly has way more speed advantages then RXB.

But then Interpreted instantly vs Compiled both have draw backs and advantages.

Interpreted is much quicker to edit and debug.

Compiled has way more speed, unless you have to edit then has way more steps to do so.

 

You (and I suspect others) still seem to have a misunderstanding of what XB256 is. XB256 is a collection of assembly subroutines that expand the capabilities of Extended BASIC, allowing you to select from two different screens, one of which can use all 256 characters. Plus a bunch of other subroutines that enhance the graphics capabilities. But it still is Extended BASIC. It is interpreted. You can edit and test and debug quickly, same as with XB and RXB. It can do everything that XB can do; floating point numbers, 100% compatibility,etc and is just as slow as XB. It is a stand alone utility and it is disappointing that, to my knowledge, no one has ever written an XB program that uses its capabilities.

 

A program written for XB256 can also be compiled. If you do that you can get a big increase in speed, but you also have to deal with integer arithmetic and some incompatibilities. But it doesn't have to be compiled - to reiterate, a program written for XB256 runs fine in XB.

 

You comment that "XB256 being assembly has way more speed advantages than RXB". If you re-read my post you will see that RXB can do the "hello world" twice as fast as the all assembly routine used in XB256. The reasons for that are discussed in the post. (I did an edit this morning and so you may not have read that.)

 

When you write a program to be compiled it should first be thoroughly debugged in XB or XB256. The XB interpreter makes that easy. Then when you compile it should work. If not the new menu program makes it a whole lot easier to debug and recompile. Clearly there are more steps, but it pretty much is a matter of pressing Enter whenever there is a prompt.

 

(edit) I put a line through part of my post where it sounds like I am whining.

Edited February 16, 2018 by senior_falcon

[Opry99er]

Wasnt Doncaster Racecourse done using XB256, falcon?

[Opry99er]

Also Eric in Monsterland, I believe. XB256, then compiled, IIRC

[senior_falcon]

Yes, quite a number have been done and then compiled. I believe that all those you mentioned were compiled. I just think it would be cool to see a program written that runs in straight XB. Obviously you couldn't have anything with fast action, but maybe an adventure with a bunch of detailed graphics?