XB Game Developers Package

[+Vorticon]

I'm going to work on it this weekend and see how it goes. Since I cannot chain compiled program, what I'll do is just compile the main program which is the most important one anyway.

I'll reach out if I get stuck.

[senior_falcon]

. Since I cannot chain compiled program, what I'll do is just compile the main program which is the most important one anyway.

 

Yes you can. See page 10 of the compiler manual.

[senior_falcon]

I just ran STRATINIT through the compiler. It compiled fine, but there was one error when assembling. The TI assembler reports two errors: "MULTIPLE SYMBOLS - 2837". Good luck finding the error with that information.

Assm994a gives this error message: ERROR #1: Line #2[334]: "multiple definition of symbol RESTOR". Now we're getting somewhere. Looking at the compiled code we see:

L2390

RESTOR

DATA NV52,NA6

So now we know the error is in line 2390 of the source XB program. Looking at that line we see:

2390 SUB RESTOREB(ID,ARRY(,))

And that tells us what we need to know. The compiler takes the first 6 letters of RESTOREB which is RESTOR and this becomes the label for the start of the sub.

Unfortunately RESTOR is also a label for a sub in the compiler that will RESTORE the pointer to a line number. You cannot have the same label twice.

The solution is simple: change the subprogram name from RESTOREB to something like RESTRB that cannot be confused with the XB RESTORE which is shortened to RESTOR or with any other XB instruction.

 

The runtime routines use a lot of labels and the subprogram cannot duplicate any of them. I suppose I could make an alphabetized list of all the labels and include it in an appendix so you know which ones cannot be used for subprogram names.

[+Vorticon]

Easy enough to fix. I do need to make sure all the sub names in the main program don't shorten up to similar names. My bigger issue though is going to be the IF THEN ELSE limitation as I have a lot of nested conditionals in the program. I'll have to go through it carefully. Also one of the routines uses the SQR function with float results, so I will need to find a workaround. Should be all doable though.

[+Vorticon]

And yes it would be extremely helpful to have an alphabetized list of the labels used by the compiler in order to preserve the programmers' hair

[senior_falcon]

Easy enough to fix. I do need to make sure all the sub names in the main program don't shorten up to similar names. My bigger issue though is going to be the IF THEN ELSE limitation as I have a lot of nested conditionals in the program. I'll have to go through it carefully. Also one of the routines uses the SQR function with float results, so I will need to find a workaround. Should be all doable though.

You haven't been keeping up. The IF THEN ELSE limitation has pretty much been eliminated. From the compiler manual:

 

IF-THEN-ELSE now can use the more versatile Extended BASIC format. The following line of code will compile and run the same as it does in XB:

100 IF X=7 THEN Y=3::Z=12::GOSUB 100::PRINT A ELSE Y=5::Z=14::GOSUB 200:: PRINT B

You do have to be a bit cautious when using complicated IF-THEN-ELSE statements. If you use ELSE you should only use one IF, one THEN and one ELSE as in the example above.

If you do not use ELSE the line will just run like in XB. The following two lines run properly:

100 S=S+1 :: IF S=60 THEN S=0 :: M=M+1 :: IF M=60 THEN M=0 :: H=H+1 :: IF H=13 THEN H = 1

100 IF X=3 THEN IF Y=1 THEN IF Z=4 THEN PRINT “PI” (but you cannot use ELSE)

By using AND you can eliminate the multiple IF statements and then you can use an ELSE:

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

The line below using multiple IF-THEN-ELSE statements does not run properly if compiled:

100 IF A=1 THEN IF B=2 THEN C=3 ELSE D=4 ELSE E=5 (line is from the XB manual)

SQR gives the INT of SQR so you will definitely need to work around that.

(EDIT) I thought you would have to make changes to the IF THEN ELSE logic due to using multiple ELSEs in a line. From STRATINIT:

240 IF N<=2 THEN CALL HCHAR(Y,X,35)ELSE IF N>8 THEN CALL HCHAR(Y,X,36)

I wasn't sure how this would behave, so I made a test program:

200 INPUT N

240 IF N<=2 THEN PRINT "N<=2" ELSE IF N>8 THEN PRINT "N>8"

250 GOTO 200

This works as expected, so there should be no problem with your line 240.

Really convoluted IF THEN ELSE logic can cause trouble, so when in doubt you can do a little test program to be sure.

If line 240 did had trouble you could split it up like so:

240 IF N<=2 THEN CALL HCHAR(Y,X,35)::GOTO 250

241 IF N>8 THEN CALL HCHAR(Y,X,36)

Edited March 17, 2019 by senior_falcon

[+Vorticon]

I have carefully read the manual Harry. You state that if ELSE is used, then there should only be one IF, one THEN and one ELSE used. That is a limitation in my book unless I'm misunderstanding what you are trying to convey. Below is a line from my initialization program which should not work with the compiler:

IF NT=1 THEN 
     COMP(N,1)=6::NC=NC-1 ELSE
	IF NT=2 THEN COMP(N,1)=5::NL=NL-1 ELSE
	    IF NT=3 THEN COMP(N,1)=3::NM=NM-1 ELSE
	        COMP(N,1)=11::NB=NB-1

And yet you said that the program compiled normally, so before I take the time to make changes to the code I want to make sure this is needed.

[senior_falcon]

As noted above, you can easily test the IF THEN ELSE logic to see if it will work. Your line can be changed to:

80 INPUT NT

100 IF NT=1 THEN PRINT "NT=1" ELSE IF NT=2 THEN PRINT "NT=2" ELSE IF NT=3 THEN PRINT "NT=3" ELSE PRINT "NONE OF THE ABOVE"

120 GOTO 80

According to my docs that should not work, but actually it does perfectly. You don't have to change that line. So it looks like I need to revisit the docs so as to be totally clear on what can and cannot be done.

Another point: If it compiles normally, that does not necessarily mean it compiled correctly! It just means it compiled without finding any errors.

(edit)

100 IF A=1 THEN IF B=2 THEN C=3 ELSE D=4 ELSE E=5 (line is from the XB manual)

The logic here is IF THEN IF THEN ELSE ELSE which does not behave properly when compiled.

Your logic is IF THEN ELSE IF THEN ELSE IF THEN ELSE and the compiler is happy with that.

So some revisions to the docs are in order.

Edited March 18, 2019 by senior_falcon

[atrax27407]

Compiling a program will return "00 errors" when there are no syntax errors but logic errors can certainly exist. The same is true when assembling source code.

[senior_falcon]

I have carefully read the manual Harry. You state that if ELSE is used, then there should only be one IF, one THEN and one ELSE used. That is a limitation in my book unless I'm misunderstanding what you are trying to convey.

Sorry, I thought you were referring to the earlier limitation where IF THEN ELSE could only use line numbers. Anyway, it is gratifying to see that the compiler can do more than I thought it could!

[senior_falcon]

I have re-uploaded the package. This is in Post #497. The only difference is in the documentation which now accurately describes how to use IF-THEN-ELSE with the compiler. Also page 12 of the compiler manual has a list of reserved names that cannot be used as subprogram names.

 

An interesting feature of how subprograms were implemented on the compiler is that they can now be called recursively - i.e. a subprogram can call itself. But this is not particularly useful since it cannot be tested in XB, which complains when you do that.

 

(Edit) Here is the revised description of IF-THEN-ELSE

 

IF-THEN-ELSE now can use the more versatile Extended BASIC format. The following line of code will compile and run the same as it does in XB:

100 IF X=7 THEN Y=3::Z=12::GOSUB 100::PRINT A ELSE Y=5::Z=14::GOSUB 200:: PRINT B

You can use multiple IF-THEN-ELSE in one line as long as they follow the logic:

IF-THEN-ELSE-IF-THEN-ELSE-IF-THEN-ELSE. (the final ELSE is optional)

You must be cautious when the IF-THEN-ELSE logic does not follow the above pattern.

If you do not use ELSE any line should run like in XB. The following two lines run properly:

100 S=S+1 :: IF S=60 THEN S=0 :: M=M+1 :: IF M=60 THEN M=0 :: H=H+1 :: IF H=13 THEN H = 1

100 IF X=3 THEN IF Y=1 THEN IF Z=4 THEN PRINT “PI” (these two lines do not use ELSE)

By using AND you can eliminate the multiple IF statements and then you can use an ELSE:

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

The XB manual shows this line of code: 100 IF A=1 THEN IF B=2 THEN C=3 ELSE D=4 ELSE E=5

The logic is IF-THEN-IF-THEN-ELSE-ELSE and this will not execute properly compiled.

Edited March 18, 2019 by senior_falcon

[+Vorticon]

Excellent! This was a major limitation for complex programs, so I'm really glad this is no longer the case.

[senior_falcon]

Also one of the routines uses the SQR function with float results, so I will need to find a workaround. Should be all doable though.

I don't know what accuracy you require, but remember that if you multiply a number by 100 the SQR will be multiplied by 10

SQR(2)=1.414

SQR(200)=14.14 or with the INT it would be 14

[1980gamer]

 

An interesting feature of how subprograms were implemented on the compiler is that they can now be called recursively - i.e. a subprogram can call itself. But this is not particularly useful since it cannot be tested in XB, which complains when you do that.

 

 

Hmmm, I needed this in my necco factory game. I dropped the project because I could not make it work properly.

I wonder if a I can make this work now? Granted, it will take trial and error.. well everything does, but compiling.

Actually, this is a great place for a demo.

 

looking back at the code.. yuk. to many abbreviated vars. LOL had a variable in one game for Fuel Unit Consumption. Guess what the variable was?

 

It needed a rewrite anyway.

[senior_falcon]

The problem is, how do you test it? GOSUB can be used recursively in XB or BASIC, but not subprograms. Writing in XB and then doing the testing in the compiled program is not the easiest thing to do. But if you are clever I'm sure there is a way.

[+chue]

Just a thought - for testing, perhaps you can have two identical subprograms, just named differently. Instead of one function recursively calling itself, it just calls the other one.

[LASooner]

The problem is, how do you test it? GOSUB can be used recursively in XB or BASIC, but not subprograms. Writing in XB and then doing the testing in the compiled program is not the easiest thing to do. But if you are clever I'm sure there is a way.

 

 

I think you underestimate how quick it is to go from XB code to E/A 5 with your package, it's not as fast as typing "run" but, the way you have it pseudo automated, it doesn't take that long to test a compiled program at all. I do it all the time, because it's better to test at the speed the game will run at. At the very least it's great to have the option to do stuff like this if it's absolutely necessary to your program.

[senior_falcon]

That's true. Even with my slow 10 year old computer the development process is much faster now that the compiler and loader are in assembly. If you use Asm994a or another cross assembler then things are even faster.

[1980gamer]

It is pretty quick to compile and test. But I tend to write big stuff. To the point where I have to shrink 3 letter vars to 1 or 2 so I have enough room. (then I can't figure it out when I look back on it. )

 

That is why I was stating a demo.

 

Anyway, I know senior_falcon has made some great improvements. Speed, memory, speech? If-then-else etc. I am a few versions back.

The funny part on the if-then's is.. when i first heard of this limit, I was bummed out. Now, I have a hard time not working around that limitation. LOL.

What am I going to do without all those GOTO's?

 

This is where I needed the recursive function: http://atariage.com/forums/topic/283290-new-game-demo-lots-of-hearts/?hl=%2Bnecco#entry4120260

Game 5. You can find the game I was ripping off... A web based game: Chocolate Factory I think. To see how the original game played.

 

I want to complete this game. I spent a bunch of time on it. I usually FINISH games and just think they are too slow or are not very good.

This one kicked my bottom! But now... maybe?

[+Vorticon]

So I tried compiling the STRATINIT file (Statego initialization file) and the compiler kept crashing the system... Classic 99 is set up per the compiler instructions and STRATINIT runs properly in straight XB. The file is attached. What am I doing wrong here?

 

https://youtu.be/u9TupHl3rY8

STRATINIT.bin

[+arcadeshopper]

So I tried compiling the STRATINIT file (Statego initialization file) and the compiler kept crashing the system... Classic 99 is set up per the compiler instructions and STRATINIT runs properly in straight XB. The file is attached. What am I doing wrong here?

 

https://youtu.be/u9TupHl3rY8

 

are you in overdrive? try it normal speed if so

[+Vorticon]

 

are you in overdrive? try it normal speed if so

 

I did. Same issue.

[LASooner]

 

I did. Same issue.

 

What happens on line 1360?

[+Vorticon]

 

What happens on line 1360?

 

It chain runs the main program. I think this might be the problem. Didn't know the numbers displayed by the compiler corresponded to the actual XB program line numbers There is a fix detailed in the compiler manual.

[LASooner]

 

It chain runs the main program. I think this might be the problem. Didn't know the numbers displayed by the compiler corresponded to the actual XB program line numbers There is a fix detailed in the compiler manual.

 

I believe he uses the line numbers to create unique labels in the compiled program.

Edited March 20, 2019 by LASooner