COMBAT XB COMPETITION

[SteveB]

27 minutes ago, Tursi said:

Idea for the benefit of the viewing public - how about an onscreen 'lock' indicator for when a tank has the other in its sights, so the viewer can tell when one tank SHOULD see the other?  

A tank might change the color (to red?) when it is in sight of the opponent?

 

Furthermore I think 100 steps are still way too few, I think of implementing three modes, Cruise, Flight and Attack .. Excaping an unfaivorable situation and start a counter-attack will take some steps ... And I think strategic waiting for some cycles should be possible somehow. 

[SteveB]

1 hour ago, Vorticon said:

Almost done with the host program. A few more bugs to root out. 

I am thinking we should allow the subroutines to poke and peek into and from low memory (NOT VDP)  for the purpose of data storage since all variables in the SUBs are local and do not survive the sub exit. 

The player's subroutine call will also pass the address of the low memory block assigned to it not to exceed 3K and that block can be used as needed. No sabotaging of the opponent's memory block allowed! 😁

I'll update the first post accordingly.

Local variables do survive ... but I don't know if they also survive a garbage collection though. 

 

Same result with XB 2.9 GEM. "13" is printed on the second call to TEST and not in the main program. Alternatively you may provide a DIM a(20),a$(10),b(20),b$10 and add these a resp. b to the CALL, so we have a set of 32 variables we can rely on.

 

I would like use a dump of the VDP RAM of the screen (not the sprite table, no cheating...) to have a map I can pencil in my strategy. Perhaps you can provide a wrapper to do so, so we don't need MOVES in our own program.

 

[Tursi]

That's fair, subprogram variables are documented to survive.

Edited February 14 by Tursi

[senior_falcon]

Rich brings up an interesting point. In XB, it is possible to poke an assembly program into low memory and run it. Since the title of this thread is "Combat XB Competition," doing this would seem to be against the spirit of the competition. Opinions?

[SteveB]

I think speed does not matter in this competition, so I don't see a point in assembly language.

[+Vorticon]

2 hours ago, Tursi said:

Idea for the benefit of the viewing public - how about an onscreen 'lock' indicator for when a tank has the other in its sights, so the viewer can tell when one tank SHOULD see the other?  

Great idea! I'll work on that.

[+Vorticon]

2 hours ago, Tursi said:

So is it 3 stationary turns kills you, or more than 3? Seems like a u-turn is already two turns, if you u-turn then fire that's 3. So that's important to know

 

Again good point. We should make it 4 instead of 3. 

[+Vorticon]

1 hour ago, SteveB said:

Local variables do survive ... but I don't know if they also survive a garbage collection though. 

 

Same result with XB 2.9 GEM. "13" is printed on the second call to TEST and not in the main program. Alternatively you may provide a DIM a(20),a$(10),b(20),b$10 and add these a resp. b to the CALL, so we have a set of 32 variables we can rely on.

 

I would like use a dump of the VDP RAM of the screen (not the sprite table, no cheating...) to have a map I can pencil in my strategy. Perhaps you can provide a wrapper to do so, so we don't need MOVES in our own program.

 

Did not know that! Well then there is no need to open the door on low memory access. Let's keep it in pure XB as Senior Falcon suggested. 

[+RXB]

1 hour ago, Vorticon said:

Did not know that! Well then there is no need to open the door on low memory access. Let's keep it in pure XB as Senior Falcon suggested. 

So no variant of any other XB is out.

So RXB CALL MOVES is out (moves any type of memory VDP/RAM/GROM to any type of memory VDP/RAM/GRAM)

CALL HGET or CALL VGET is out (is like a FOR/NEXT of GCHAR but into a string up to 255 characters in a string)

CALL EXE is out (does a BL @address using GPL registers faster then CALL LINK as it does not use VDP Stack)

CALL LOAD or CALL PEEK is out (only change is no need to do a CALL INIT to use them)

CALL POKEV or CALL PEEKV is out (GKXB routines originally)

CALL COLLIDE is out (it is a RXB version of COINC & POSITION in one command that returns location of any sprite collision with other sprites or locations)

 

What about RXB changes to other commands like normal XB CALL GCHAR(row,col,variable) only 1 character fetched each command?

RXB can do this CALL GCHAR(row,col,variable,row,col,variable,row,col,variable,row,col,variable.row,col,variable,row,col,variable) 

Will this be cheating?

 

[senior_falcon]

On 2/12/2023 at 1:09 PM, RXB said:

So I guess a RXB version of this type of contest should be suggested.

Rich, instead of spamming every other thread with ads for RXB, you should do as you suggested earlier. Have an RXB competition and that would be a perfect opportunity to extol the the merits of the cartridge, educate users in what can be done, provide tips on how to use it, etc.

Edited February 14 by senior_falcon

[+Vorticon]

OK! I have updated the first post with the latest changes and added the host program.

Let the games begin! Please submit your entries (subroutine only in sxb format) by the March 15 deadline and may the best algorithm win the day 

 

[retrodroid]

Running!  Wow. After living in assembly for the last few months the er, "performance" of XB is a little startling.

 

Thank goodness for Classic99's CPU OverDrive mode!    

[SteveB]

On 2/12/2023 at 1:54 PM, Vorticon said:

Please let me know if you find any bugs.

I get three warnings, two of themmight be bugs:

 

Warning: Subroutine DELTA not declared.
Warning: Subroutine FIRE not declared.

[+Vorticon]

16 minutes ago, SteveB said:

I get three warnings, two of themmight be bugs:

 

Warning: Subroutine DELTA not declared.
Warning: Subroutine FIRE not declared.

Yup, I've got the same. There is nothing wrong with these routines. They are properly declared and the program runs as it should. Not sure why TICodEd has been throwing these out...

[Tursi]

3 hours ago, Vorticon said:

OK! I have updated the first post with the latest changes and added the host program.

Let the games begin! Please submit your entries (subroutine only in sxb format) by the March 15 deadline and may the best algorithm win the day 

 

Maybe a link to TICodEd in the first post too, for those of us who have never used it?

 

[+Vorticon]

Here it is: 

 

[Tursi]

I found it, but not everyone might Google.

 

I found a potential bug - I got a syntax error after a bit of runtime for the CALL MOTION under the left: label (CALL MOTION(#S,0,-5)) - only reason I could see for it was S is zero, and that's not a legal sprite number. In looking at the code though, I can't see why it became 0. And shouldn't that be bad value anyway?

Found some gotchas... it's difficult to debug the code when the line numbers only exist in the final code and the labels do not - perhaps an option for labels to be included as comments? Also managed to generate line numbers greater than 32767, and the build just quietly dies in that case without explaining why - eventually I noticed this in the XB code text which was saved. Also, any label defined goes through a search and replace everywhere. For instance I had a label "FIRE", this ended up replacing the SUB FIRE in the main code. So watch for that.  

Now gotta make my tank stop spinning in place...  

 

Edit: This seems to loop forever if you shoot and the bullet never collides with the tank?

 

checkhit:
CALL COINC(#3,#ST,4,H)
IF H=0 THEN
   checkhit

 

I never saw OUT OF RANGE come up, I wonder if that code is broken?
 

Edited February 15 by Tursi

[SteveB]

3 hours ago, Tursi said:

Found some gotchas... it's difficult to debug the code when the line numbers only exist in the final code and the labels do not - perhaps an option for labels to be included as comments? Also managed to generate line numbers greater than 32767, and the build just quietly dies in that case without explaining why - eventually I noticed this in the XB code text which was saved. Also, any label defined goes through a search and replace everywhere. For instance I had a label "FIRE", this ended up replacing the SUB FIRE in the main code. So watch for that.  

Yes, a designator is a designator: variable, subroutine or label ... they must be unique.

 

I will include a check and error-message when the generated line number exceeds 32767, good idea. I never managed to do so. 

 

When you set the log-level to "verbose" or above, you get a "Line Number Table" in the log-page:
   LABELNAME -> LINI-NUMBER

 

You can also use a line-number like an AORG in your code to force it, as long as it is higher than the current automated one, perhaps a temporary help while debugging.

 

[+Vorticon]

8 hours ago, Tursi said:

I found it, but not everyone might Google.

 

I found a potential bug - I got a syntax error after a bit of runtime for the CALL MOTION under the left: label (CALL MOTION(#S,0,-5)) - only reason I could see for it was S is zero, and that's not a legal sprite number. In looking at the code though, I can't see why it became 0. And shouldn't that be bad value anyway?

Found some gotchas... it's difficult to debug the code when the line numbers only exist in the final code and the labels do not - perhaps an option for labels to be included as comments? Also managed to generate line numbers greater than 32767, and the build just quietly dies in that case without explaining why - eventually I noticed this in the XB code text which was saved. Also, any label defined goes through a search and replace everywhere. For instance I had a label "FIRE", this ended up replacing the SUB FIRE in the main code. So watch for that.  

Now gotta make my tank stop spinning in place...  

 

Edit: This seems to loop forever if you shoot and the bullet never collides with the tank?

 

checkhit:
CALL COINC(#3,#ST,4,H)
IF H=0 THEN
   checkhit

 

I never saw OUT OF RANGE come up, I wonder if that code is broken?
 

I sounds like you have duplicate labels somewhere. That's one thing TICodEd could probably do better since it does not flag duplicate labels at build time, and this has more than once caused weird errors where the code jumps unexpectedly to another part of the program. This is likely the case with the CALL MOTION and CALL COINC errors you are seeing. Do a search for your labels and make sure they are unique since the host program has a bunch of them. OUT OF RANGE will come up when you attempt to fire beyond 8 squares or at a non-existent target.

I can't seem to replicate any of your errors, so if you are still having problems send me your subroutine so I can look into it.

[+Vorticon]

I think this is worth reiterating:

Make sure you do not have duplicate labels with the host program as this will cause weird errors. Best to do a search for your labels making sure they are unique before building.

[+Vorticon]

Here's a version of the host program with 2 computer controlled tanks. You can let it run to get a feel of how the battle will unfold. FYI the tanks are pretty dumb...

 

CCombat.sxb CCombat

[SteveB]

3 hours ago, Vorticon said:

That's one thing TICodEd could probably do better since it does not flag duplicate labels at build time, and this has more than once caused weird errors where the code jumps unexpectedly to another part of the program.

I see this competition will lead to further improvements of TiCodEd ... My To-Do List for version 2.5 is growing ... keep sending feedback!

[oddemann]

Looking forward to this!

"SUPER TI WALL & WAR!" - Final!!!

 

[Switch1995]

On 2/12/2023 at 7:54 AM, Vorticon said:

SUB X,Y,DIR,X1,Y1,DIR1,CODE
...
SUBEND

I'm a little rusty on my subroutine variable persistence.   If my code was:

 

SUB X,Y,DIR,X1,Y1,DIR1,CODE

.....

Q=1

.....

.....

Q=Q+1

.....

SUBEND

 

 

On my next turn would Q=1 or 2?  Thanks!  Looking forward to this

[SteveB]

The actual SUB code is SUB TANK2(X,Y,DIR,X1,Y1,DIR1,CODE) and numeric variables are initialized with 0. So if you have some initialization to do you a

SUB TANK2(X,Y,DIR,X1,Y1,DIR1,CODE)
  if firstrun=0 then notfirst
    Q=1
    firstrun=1
notfirst:
  Q=Q+1
  ...
subend