XB Game Developers Package

[+Vorticon]

STRATINIT will run STRATMAI-X fine, but the latter still displays the sprite issues.

STRATINI-X works exactly at it should, and successfully chain loads and runs STRATMAI-X which again has the sprite issues.

STRATINI-X will chain load and run STRATMAIN, and the latter works as it should.

 

Hope that helps frame the problem better. The issue clearly lies with the STRATMAI-X program.

[senior_falcon]

OK, thanks. Now let's try to narrow it down a little more. When STRATINIT (or STRATINI-X) runs it saves some data to disk. It also redefines characters and sprites. I am assuming that STRATMAIN does not redefine those characters, but expects them to already be set by STRATINIT.

What happens if you run STRATMAIN by itself without it being preceded by STRATINIT?

Any chance you could determine the line number where the problem is happening? Or even better, a short XB program that has this sprite problem.

 

Just had an insight. STRATINI-X works as expected. What happens if you start it up in line 10 with CALL LINK("RUNV") instead of CALL LINK("RUN")? Do the sprites still work as expected?

Edited March 25, 2019 by senior_falcon

[+Vorticon]

OK I'll do some additional tests this evening and let you know what I find.

[senior_falcon]

I could be wrong, but I can see no reason why RUNV would cause any problems with sprites. I am a little suspicious of these lines.

 

1140 IF K=83 OR K=115 THEN IF (MFLAG=0 AND SX=9)OR(MFLAG=1 AND SSX=9)THEN 720 ELSE IF MFLAG=0 THEN SX=SX-24 ELSE SSX=SSX-24

1150 IF K=68 OR K=100 THEN IF (MFLAG=0 AND SX=225)OR(MFLAG=1 AND SSX=225)THEN 720 ELSE IF MFLAG=0 THEN SX=SX+24 ELSE SSX=SSX+24

1160 IF K=69 OR K=101 THEN IF (MFLAG=0 AND SY=1)OR(MFLAG=1 AND SSY=1)THEN 720 ELSE IF MFLAG=0 THEN SY=SY-16 ELSE SSY=SSY-16

1170 IF K=88 OR K=120 THEN IF (MFLAG=0 AND SY=145)OR(MFLAG=1 AND SSY=145)THEN 720 ELSE IF MFLAG=0 THEN SY=SY+16 ELSE SSY=SSY+16

They use the logic IF THEN IF THEN ELSE IF THEN ELSE which may be too complex for the compiler to handle. Also, none of the IF THEN branching in STRATINIT is this complex. They are more straightforward: IF THEN IF THEN or IF THEN ELSE IF THEN or similar

Edited March 26, 2019 by senior_falcon

[+Vorticon]

So STRATINIT defines all the characters and draws the screen. STRATMAIN assumes this has been done and so no character definition occurs. If I run STRATMAIN alone, assuming that the data files it expects are present, it will happily run with just a blank screen, but since it depends on the GCHAR function to figure out its environment, it won't work properly. Furthermore, none of the sprites will show up because the characters they are based on have not been defined.

I suspected an issue with the GCHAR function in STRATMAI-X so I compiled this test program and had it chain run by the STRATINI-X program:

10 FOR I=1 TO 24::CALL HCHAR(I,1,33,32)::NEXT I
20 CALL SPRITE(#1,65,14,100,100)
30 CALL KEY(0,K,S)::IF S=0 THEN 30
40 CALL LOCATE(#1,150,150)
50 CALL KEY(0,K,S)::IF S=0 THEN 50
60 CALL LOCATE(#1,100,100)
70 CALL GCHAR(1,1,C)
80 DISPLAY AT(5,1)SIZE(6):C
90 GOTO 30

It seems to work as it should, including the GCHAR function. At this point I am totally stumped...

[senior_falcon]

See my post #554.

[+Vorticon]

I simplified the statements you mentioned and it solved the player movement issues. Nice catch!

Unfortunately, there is still the problem with the computer side moving its pieces. Is the statement below OK with the compiler?

IF CE1=120 THEN
   CALL CHECKEN(PLAY(,),KNOWN(),EMOVED(),PV,X,YH-2,KFLAG)::
   IF KFLAG=1 THEN
      SCORE=-1::
      GOTO next_square

or this one?

IF (C>=40 AND C<=55) OR C=58 THEN
   IF YH=Y+2 THEN 
      SCORE=-1::
      GOTO stop_ray_search ..
   ELSE
      SCORE=5::
      YH=YH-2::
      GOTO stop_ray_search ..
ELSE
   IF C<>120 THEN ray_not_done

I suspect the latter is probably an issue with the compiler.

[senior_falcon]

Your first example has the logic:

IF THEN IF THEN which according to the manual should be fine. (There are no ELSES)

The second example has the logic:

IF THEN IF THEN ELSE ELSE which is specifically mentioned in the manual as not being OK

 

IF THEN IF THEN IF THEN is fine

IF THEN ELSE IF THEN ELSE IF THEN ELSE is fine

For anything else you have three choices:

Write it the way you want and hope it works.

Write a short test program to see if the particular logic you want to use will execute properly when compiled.

Write it as described above.

 

You can use a text editor to look at the program for suspicious IF THEN ELSE statements. Load the program and search for "THEN".

Edited March 26, 2019 by senior_falcon

[+Vorticon]

I am now able to run STRATMAI-X with both sides moving appropriately, however there are residual issues I need to sort out. It looks like some of the play logic is not working properly, there are some display issues, and the computer is declaring defeat within a few moves. There might be other issues as well I have not encountered.

I'm going to make a list of bugs and start looking for obvious problems related to the compilation process. I should point out that the original STRATMAIN program is now too large to run within XB (I only had a few bytes left originally), and I don't suppose this would be an issue regarding the compilation and assembly process.

[senior_falcon]

Good to hear that you are making progress. The program being too long to run is not a problem as far as the compiler is concerned.

 

Get the programs STRATINIT and STRATMAIN in a text editor and look for:

"THEN" - you should be 100% sure that no funny IF THEN ELSE stuff is going on. IF THEN IF THEN IF THEN or IF THEN ELSE IF THEN ELSE is fine. Anything else is suspect.

"/" - Remember the integer arithmetic. If you start with integers then add, subtract, and multiply give the same result in integer or floating point. Divide and SQR give the INT of the result and are usually different in floating point and integer math. Remember too that GCHAR, HCHAR and VCHAR can round up or down. GCHAR(8/5,8/5,G) reads the screen at 2,2 in floating point and at 1,1 with integer math.

"SQR" - I don't think you use this but it could be a problem if you did.

 

Keep in mind that you can use all 32K in XB for testing purposes

 

(EDIT) One other thing that can trip you up is if your numbers are big. The largest number you can have is 32767 and the smallest is -32768.

 

(ANOTHER EDIT) I'm pretty sure your problems are from IF THEN ELSE that the compiler does not like. I think lines 1550, 1570, 1990, 2210 ,2500, 2620, 2700 make the compiler unhappy.

I set up a test that shows different behavior when compiled, but it turns out it is a little different from what you are doing.

IF X=3 THEN IF Y=23 THEN Z=523 ELSE Q=5280 executes wrong when compiled. I think it can be restated

IF X=3 AND Y=23 THEN Z=523 ELSE Q=5280 which the compiler likes.

I confess to having a great deal of difficulty understanding IF THEN logic when it gets more complex than a single IF THEN ELSE

Edited March 27, 2019 by senior_falcon

[+Vorticon]

Harry, is the following structure OK with the compiler?

 

IF THEN

IF THEN

ELSE

 

The ELSE belongs to the second IF statement.

 

Or this one:

 

IF THEN

ELSE

IF THEN

 

These structures occur frequently and it would be a major pain to change them unless absolutely necessary.

[senior_falcon]

(From the docs) "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)"

So your second example is fine. (IF THEN ELSE IF THEN)

 

IF THEN IF THEN ELSE is not OK with the compiler. What happens is that the ELSE goes back to the first IF, not the second.

This line from STRATMAIN uses this structure:

2210 IF EMOVED(I)=1 THEN IF HFLAG=0 THEN HFLAG=1 :: GOTO 1510 ELSE SCORE=-1 :: TFLAG=0 :: GOTO 2330

Change this ^^^^^ to AND and it should work the same, but now the structure is IF THEN ELSE and it will run properly when compiled

(edit) I don't think that is equivalent after all.

 

 

I am looking to see if there is a way to make this work for all possible IF THEN ELSE statements. I am hopeful, but not very optimistic.

Edited March 27, 2019 by senior_falcon

[+Lee Stewart]

...

IF THEN IF THEN ELSE is not OK with the compiler. What happens is that the ELSE goes back to the first IF, not the second.

...

 

This confuses me. Without parenthetical coercion of the logic, ELSE should always be associated with and terminate the nearest unterminated IF, should it not?

 

...lee

[senior_falcon]

Yes that is correct. XB sends it back as you describe, but the compiled code sends it back to the first if. In any event, ideally the compiled code would match XB's behavior. In this case it does not.

[+Vorticon]

Ok. I'll give it a little rest to see if it is possible to come up with a fix before making changes to the code.

Harry, please let me know if you determine that it will not be possible.

[senior_falcon]

GOT IT!!!

 

Will post later tonight.

[senior_falcon]

No time for a complete package tonight. To get an early start, replace RUNTIME2 with the attached RUNTIME2. This seems to always handle IF THEN ELSE the same way that XB does. I need to update the manual to reflect this change.

RUNTIME2.zip

[+Vorticon]

Strong work Harry! The program logic now seems to work normally.

There is still one last remaining issue however: I am certain the compiler is not compiling the following code correctly, leading to a display corruption after a battle.

// Restore background behind piece
SUB BRESTR(ID,ARRY(,))
N=4
FOR XB=ARRY(ID,2) TO ARRY(ID,2)+2
	FOR YB=ARRY(ID,3) TO ARRY(ID,3)+1
		CALL HCHAR(YB,XB,ARRY(ID,N))::
		N=N+1
	NEXT YB
NEXT XB
SUBEND

Any thoughts?

[senior_falcon]

Looks to me like that should work. I will take a look at it tonight. Is this subprogram (BRESTR) called from another subprogram or from the main program?

[+Vorticon]

It's called from the BATTLE subprogram.

[senior_falcon]

It looks like at present you cannot use a passed array as FOR/NEXT limits in a user subprogram. It is fine to use array elements as FOR/NEXT limits in the main program. Working on a fix...

(edit) Looks easy. I'm gonna take a break for a bit.

100 ARRY(3)=1
102 FOR J=ARRY(3)TO ARRY(3)+11 :: PRINT J :: NEXT J   this works fine when compiled
110 CALL TESTSUB(ARRY())
120 END
130 SUB TESTSUB(ARRY())
140 FOR J=ARRY(3)TO ARRY(3)+4  this does not work in a subprogram; you can change like 140 and 150 below to do the same thing
140 X=ARRY(3)
150 FOR J=X TO X+4
160 PRINT J
170 NEXT J
180 SUBEND

Edited March 30, 2019 by senior_falcon

[senior_falcon]

This should do the trick. As before, substitute this RUNTIME2 for the existing RUNTIME2.

Thank you for your patience! A change in one place in this program can have unexpected side effects in a different part of the program that used to work perfectly.

RUNTIME2.zip

Edited March 30, 2019 by senior_falcon

[+Vorticon]

Harry my friend, I think you've done it! Stratego now runs in its entirety without any noticeable issues. I still have to do some additional testing to make sure the program logic is still intact, but it looks extremely promising so far. And in the process, you managed to substantially enhance the compiler and remove some major limitations. Honestly, as it stands currently, there is very little that cannot be done with it from a game development standpoint. Really amazing achievement.

I'll report back later tonight or tomorrow morning and fingers crossed should be able to release the compiled Stratego version.

Thank you for taking the time to work with me on this.

[senior_falcon]

 

Thank you for taking the time to work with me on this.

The feeling is mutual!

[wolhess]

Hi Vorticon and senior_falcon,

I have been following your chat for some time and I am very impressed, especially with the quick fixes. I have played the game Stratego several times and I am very curious about the speed of the compiled version. Today I compiled a small xb program with xb256 and it works very easy. Many thanks to senior_falcon for this tool. this is much easier for me than AL.

@Vorticon: If you will, I can make someone tests with your compiled Stratego.