XB Game Developers Package

[RXB]

Nice useful routines, but not compatible with the compiler.

To bad my RXB CALL JOYLOCATE and CALL JOYMOTION only need one time access to SCAN to check Joystick and Fire button with built in GOTO if fire pressed.

And even if fire button not pressed still returns any key that was pressed, thus if you scan for Joystick 1 it also checks Keyboard 1 and returns value.

So if you pressed enter or X or Z you could use that same routine that shows other options in same XB line used.

 

I was thinking like Plane Simulators in XB that have multiple inputs thus need for less SCAN times all compressed into a single command.

 

With you compiler you are stuck with normal XB drawbacks.

[senior_falcon]

With you compiler you are stuck with normal XB drawbacks.

30x faster and the ability to use all 256 characters do not seem like major drawbacks to me.

Edited January 23, 2019 by senior_falcon

[+OLD CS1]

So will the changes to the compiler break my CALL KEY on unit 3 after the CALL JOYST?

[senior_falcon]

So will the changes to the compiler break my CALL KEY on unit 3 after the CALL JOYST?

Only if you have CALL JOYST immediately followed by CALL KEY then call key will not scan the keyboard a second time but instead will report the key and status that was detected in CALL JOYST. i.e. 1,K,S or 2,K,S. If you do CALL KEY first then the results will be just like XB. If you put an instruction between CALL JOYST and CALL KEY the results will be just like XB.

(By the way, this change has not been uploaded yet.)

[LASooner]

I looked at my routine in NightStalker and it would be a quick change as they are opposite at the moment, as this is what it is currently

CALL KEY(1,K,S) :: CALL JOYST(1,PX,PY) :: L=L+4 :: IF S>0 AND G(1)=0 THEN GOSUB _SHOOT

So it would be interesting to see how much of a performance boost I'd get if it's checked in one pass.

[+OLD CS1]

I looked at my routine in NightStalker and it would be a quick change as they are opposite at the moment, as this is what it is currently

 

CALL KEY(1,K,S) :: CALL JOYST(1,PX,PY) :: L=L+4 :: IF S>0 AND G(1)=0 THEN GOSUB _SHOOT

So it would be interesting to see how much of a performance boost I'd get if it's checked in one pass.

 

If it is considerable then I will re-compile Tiles and include the changes in the other ones being worked on.

[senior_falcon]

I looked at my routine in NightStalker and it would be a quick change as they are opposite at the moment, as this is what it is currently

 

CALL KEY(1,K,S) :: CALL JOYST(1,PX,PY) :: L=L+4 :: IF S>0 AND G(1)=0 THEN GOSUB _SHOOT

So it would be interesting to see how much of a performance boost I'd get if it's checked in one pass.

This will only lead to a modest increase in speed. The JOYST/KEY combination will be about twice as fast compared to doing them separately. That sounds huge, but the question is, what percentage of the time is spend scanning the keyboard. If it is half the time, then it would run in 3/4 the time. If it is 1/10 the time it would be about 5% faster. To get an idea, I compiled and ran the following program for 1 minute, then reversed the KEY and JOYST. It looped 6169 times with JOYST first and 5675 times with KEY first. This program doesn't do much, so in the real world the speed increase would be even less, maybe only 1 or 2 percent. Still, that's better than nothing.

5 I=0
10 CALL KEY(1,K,S):: CALL JOYST(1,X,Y)
15 I=I+1 :: DISPLAY AT(24,1):I
16 IF I<32000 THEN 10

[RXB]

30x faster and the ability to use all 256 characters do not seem like major drawbacks to me.

LOL the discussion was conversion problems, not that it has speed advantages and moves outside what XB was designed for.

[senior_falcon]

“LOL the discussion was conversion problems”

Actually the discussion was an attempt to answer OLD CS1's question which can be simply rephrased: “What do I have to do to make this work with the compiler?”

You responded: “GPL IN XB USES A ROUTINE IN GPL called SCAN. In both JOYST and KEY both use SCAN. Thus in RXB 2019 I have a routines CALL JOYLOCATE and CALL JOYMOTION.” followed by a long listing of code. Please explain how this is a useful answer to that question?

“To bad my RXB CALL JOYLOCATE and CALL JOYMOTION only need one time access to SCAN to check Joystick and Fire button with built in GOTO if fire pressed.

And even if fire button not pressed still returns any key that was pressed, thus if you scan for Joystick 1 it also checks Keyboard 1 and returns value.”

This is exactly what CALL JOYST followed by CALL KEY does as you will see if you read post #443 again.

“With you compiler you are stuck with normal XB drawbacks.”

I am not sure what you mean by “normal XB drawbacks”. The RXB routines you mention are indeed faster than the equivalent lines of XB code. Why? You seem to think the reason is that you execute SCAN only once, but in reality that is but a tiny factor. KSCAN (or SCAN as you know it in GPL) takes about 1/1000 second to scan the keyboard and joysticks. Any CALL takes about 1/50 second to just get to the subprogram in XB before the code can even start. So by combining several subprograms into one, you gain way more by eliminating a CALL than by eliminating a keyscan.

Compiled code does not suffer from this slowness and unlike XB there is zero speed advantage in combining subprograms. There is no lookup table to wade through – when it is created the compiled program knows exactly where the subprograms are located and can get to them swiftly and efficiently. In fact it takes less time to begin a CALLed subprogram than it does to GOTO a line number. So what was a drawback in XB no longer is once the program is compiled, although it is true that you may have to use two or three CALLed subprograms in sequence where one would suffice in RXB.

[sparkdrummer]

PHD5037.DSK

 

I had tried a couple times before to compile the above DRAW POKER by TI and failed. Being less than a neophyte when it comes to programming could someone take a look and see if it can be compiled? I really like this version of poker but it's pretty slow....

[senior_falcon]

LISTing the program gives a "Protection Violation" error. So the first thing that has to happen is to remove the disk protection. But I cannot recall how to do that.

 

Never mind - I just found it. Now to take a look...

Edited January 27, 2019 by senior_falcon

[sparkdrummer]

CALL INIT

CALL LOAD(-31931,0)

[senior_falcon]

I didn't look too hard, but the main problem that I see is in how RND is used. Some examples are below. Remember that you are always using integer arithmetic so these won't work.

1560 BL=3.5*RND         (maybe 350*RND)
1570 IF BL<=3.15 THEN BL=(RND/5)+1   (If BL<=315 is OK but RND/5+1 is 1 to 1.2 in XB and always 1 compiled.

4020 IF NOT(MO(3)>LI AND MO(4)<2.5*AV)THEN 4040

4060 IF RND>.2+.17*T0(2)THEN 4110

4090 IF RND>.8 THEN 4110  (here if (RND*10)>7 should work. Remember that .8000001 will goto 4110) but will be 8 when compiled. Which is why 8 became 7)

There is a CALL LOAD(-31878,0) That just says that no sprites are in motion. Maybe this fixes a bug in XB version 100? Get rid of the CALL INIT as that is not needed.

There are some nested arrays, but the compiler can handle those now.

Good luck!

 

I should add that you can find RNDs and decimal points easily with LIST "CLIP" and then using a text editor to find them.

Edited January 27, 2019 by senior_falcon

[LASooner]

I never knew about LIST "CLIP".

 

[+TheBF]

CLIP is such a great feature. You can not only LIST to CLIP you can write programs that output TI text files to CLIP to get them into PC world easily.

 

Tursi for president!

[senior_falcon]

 

Tursi for president!

That's not an option. But he could be Prime Minister!

[Tursi]

That's not an option. But he could be Prime Minister!

I'll put TI's back into Canadian schools!

[senior_falcon]

Here is HondarrabiBeta2. This has the slightly faster combination of CALL JOYST and CALL KEY discussed above. You will only see a very modest increase in speed using this, but any little bit helps.

 

When testing on my real TI99 I found an issue in returning to the main menu from XB256, which did not show up in testing with Classic99. It was a timing issue which caused the interrupt routine to be overwritten by CALL INIT before it could finish its final task. If you want to run on real iron, the folder HONDARRA99 has the 28 files modified to provide the correct prompts. Also in that folder is the file HONDAR-ARC which has all 28 files packed into one.

HONDARRABIBETA2.zip

[Opry99er]

Sweeeeeeeeeet!!!

[LASooner]

I recompiled nightstalker and ran into an error

 

first I notice I have less memory with the same file

 

GRECHETTO

 

 

HONDARRABI

 

 

The greschetto compile works fine, the hondarrabi compile runs the title screen until I press fire to start the game and it errors out

 

This is the error when I run XB file

 

 

If I run the EA5 it just locks up at this point, which is the first joystick call

 

 

Here's some files for you to look at

 

Compiler-error.zip

 

NSTKJ-M Merge File

NSTK-GRECHETTO.TXT Compiled in Grechetto- Works fine

NSTK-hondarrabi.TXT Compiled in HONDARRABI- Generates the error above

Edited January 31, 2019 by LASooner

[senior_falcon]

I will look tonight, but I am guessing that you are running out of memory. The amount of memory left does not take string variables into account. You could try putting the runtime routines in low memory to see what happens.

Why is compiler loader white letters on blue background - did you change that?

It took 100 bytes to implement named subprograms. This is the reality that must be faced - every byte used to add a new feature means one less byte for the program.

[LASooner]

I will look tonight, but I am guessing that you are running out of memory. The amount of memory left does not take string variables into account. You could try putting the runtime routines in low memory to see what happens.

Why is compiler loader white letters on blue background - did you change that?

It took 100 bytes to implement named subprograms. This is the reality that must be faced - every byte used to add a new feature means one less byte for the program.

 

 

I will have to check, but I think I had more memory than 100 bytes available after running.

 

I'm using XB 2.7 suite, it defaults to that white on blue

[LASooner]

I just did a quick recompile here at work set it to low memory, Shows over 8k free

 

Still freezes up at the same point when I run it from XB

 

If I run the EA5 file it hangs on the spawn noise, then restarts the game.

[senior_falcon]

 

 

I will have to check, but I think I had more memory than 100 bytes available after running.

 

The amount of memory reported does not take into account string variables. The compiler uses cpu memory from >A000 to the start of the XB program for strings, and XB doesn't know about this.

The three possibilities are:

1 - not enough memory

2 - the two compilers make different source code files

3 - the additions and changes to the runtime routines have an error

 

It may be possible to modify the XB loader so that, even though you have the runtime routines in low memory, the program can be saved to disk without having to use the minimemory. I am not sure without looking at the code. It would use the s..l..o..w.. gpl loader from XB but at least you wouldn't have to switch cartridges.

[LASooner]

The amount of memory reported does not take into account string variables. The compiler uses cpu memory from >A000 to the start of the XB program for strings, and XB doesn't know about this.

The three possibilities are:

1 - not enough memory

2 - the two compilers make different source code files

3 - the additions and changes to the runtime routines have an error

 

It may be possible to modify the XB loader so that, even though you have the runtime routines in low memory, the program can be saved to disk without having to use the minimemory. I am not sure without looking at the code. It would use the s..l..o..w.. gpl loader from XB but at least you wouldn't have to switch cartridges.

 

I did use the mini mem to save, I can send you those files as well if it would help