How can I speed up an XB program?

[+Lee Stewart]

The time measurements must be in fractions of seconds. Does anyone know what they are? Also, I am having trouble understanding 'per RPT #' used in three spots. Can someone clarify what is intended?

 

Looks like milliseconds. This image is from the original page:

 

...lee

[Willsy]

Wow! Look how fast it is to call a user defined SUB. SEE! I've *always* said people should be using SUBs all the time in XB.

 

Hrmph... Nobody ever listens to me! <sulk>

[+RXB]

Wilsy you are correct, we need to give Barry Traver credit for Tiger Cub being entirely written in CALL [program] format.

 

In the GPL code it uses all temporary variables and forces a garbage collection (XML COMPCT) and XML SPEED

(makes XML faster by cutting down on support routines use in ROM)

 

Very well played Wilsy. Maybe I should look at RXB and borrow some of the tricks to speed up other things in XB.

[sometimes99er]

CALL sub - 7
GOSUB    - 1

 

Yes, I've seen the light.

Edited November 17, 2011 by sometimes99er

[+RXB]

GOSUB and RETURN are faster but use normal memory to access Variables and as such do not use XML COMPCT or XML SPEED that often.

 

But GOSUB and RETURN are in the NUD table so you are correct that they are faster as they use Assembly ROM for access.

 

So you are right and I was mistaken.

[sometimes99er]

I would have expected CALL "SUB" to be slower than GOSUB, and the timing table indicated just that.

 

There's the option to use local and/or global variables, but I'd still expect GOSUB to be faster. For this topic (speed) it's GOSUB over CALL SUB. Though the timing table list CALL SUB as one of the faster statements.

 

For speed one might also consider the power of ON GOSUB.

[Willsy]

Yep. For speed in XB its GOTO and GOSUB. That is definately true.

 

I can say though (having written programs using spaghetti GOTOs GOSUBs and SUBs that writing with SUBs is so much nicer. Passing locals into the SUBs is a nice high-level system.

 

But yeah, for speed I can see that you'd want to use GOTO & GOSUB (or, not use XB at all and use something else, like assembler

[sometimes99er]

or, not use XB at all and use something else, like assembler

 

Besides compiling an XB program (which I haven't tried), then I don't think it's been directly suggested here, or maybe considered outside topic, but you can of course "speed up an XB program" using an Assembly routine(s). And there's already quite a few routines out there, for example Matthew's music player or some of my own one shot and hook up effect routines. Like this one (sorry, animation is not as smooth as on the real iron) ...

 

 

Also not forgetting your own The Gamewriter's Toolkit.

 

One could write a hook up that monitors the hardware collision detection, and when sprung, freezes action (sets number of sprites for auto movement to zero) and stores information in a byte for XB to read at any time. XB might be a bit late to pickup and react upon the collision, but the collision isn't missed.

 

Lots of possibilities.

[+RXB]

XB has a added bonus of being able to create outlines for more complicated languages like Assembly.

 

Most programs you see had the first concept in XB for a good reason.

Also XB is much more easy to transfer over into another language then say C into XB or C into Logo or Forth.