COMBAT XB COMPETITION

[Switch1995]

9 minutes ago, SteveB said:

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

 

 

 

Thanks, Steve.  So it sounds like Subroutines can have local variables that can be changed/updated from turn to turn without those variables being declared at the top of the parent program (?)

[SteveB]

1 hour ago, Switch1995 said:

Thanks, Steve.  So it sounds like Subroutines can have local variables that can be changed/updated from turn to turn without those variables being declared at the top of the parent program (?)

This is correct ... you can even DIM an array there. 

[+Vorticon]

1 hour ago, Switch1995 said:

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

It should be 2, but remember this value of Q is not available outside of the subroutine.

[Switch1995]

10 minutes ago, SteveB said:

you can even DIM an array there.

Oh!  Now that is cool.  Thanks!

[SteveB]

For those of you who never used TiCodEd before I made a short video to help you setting it up in Windows and use the integration with Classic99.

 

 

Download TiCodEd Version 2.4, unpack it to a directory and copy CCombat.sxb to this directory as well. For simplicity I use the ToCodEd directrory directly as the DSK5 in the emulator to load the tokenized file. No need for Cut&Paste anymore.

 

TiCodEd.pdf will give you a quick overview of the features and the usage, TiCodEd Beginners Manual.pdf is a complete tutorial. You might ignore all features except the labels. The label name needs to be unique and is not case sensitive. Use the label instead of a line number and define the label by putting it in the beginning of a line, followed by a colon. That's all there is to it. But if you want, there is much more... REPEAT/UNTIL, WHILE/WEND, ... explore and enjoy.

 

 

Edited February 15 by SteveB

[SteveB]

20 hours ago, Vorticon said:

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...

I investigated the issue ... for some reason TiCodEd expects the CALL before the SUB. Those two routines are declared first with SUB and later used by CALL. You get rid of the warning by moving both routines further down in the code. I did so and renamed DELAY to VDELAY (VorticonDelay) because I prefer Warning-Free code.

 

CALL DELAY is part of XB256 which in integrated in the Jewel BASIC Compiler and a reserved word there, and TiCodEd is especially aimed at compiling BASIC.

 

[SteveB]

I also inserted some code in SUB TANK1 I wanted to share, as this is a friendly competition and not a fierce contention.

 

SUB TANK1(X,Y,DIR,X1,Y1,DIR1,CODE)

// GOTO NormalTank1
CALL JOYST(1,jx,jy)::CALL KEY(1,k,s)
code=1
IF jx=4  OR k=3 THEN code=2
IF jx=-4 OR k=2 THEN code=3
IF k=18         THEN code=4
SUBEXIT

NormalTank1:
IF X1=0 THEN
   nolos
...

 

This way I can steer TANK1 with the joystic or (E)SDQ to test my TANK2 code. Simply setting/removing the comment // before the GOTO NormalTank1 toggles automatic and manual mode.

 

My first impression is that 100 steps will often not suffice for a real fight when the programs are reasonable clever. 

[+Vorticon]

47 minutes ago, SteveB said:

My first impression is that 100 steps will often not suffice for a real fight when the programs are reasonable clever. 

It's certainly easy enough to raise that limit. Do others here feel the same?

[SteveB]

May we use CALL SCAN to check if the enemy sees me (I only have his coordinates when I see him) and and CALL LOS if the way to a position is free? This would free me from duplicating code. This does not reveal additional information.

[+Vorticon]

10 minutes ago, SteveB said:

May we use CALL SCAN to check if the enemy sees me (I only have his coordinates when I see him) and and CALL LOS if the way to a position is free? This would free me from duplicating code. This does not reveal additional information.

Sorry but no. The fact that the enemy tank could be tracking you without you knowing is an important aspect of the game. For example, if the opposing tank is behind you, then it will see you but not the other way around. If you knew that tank was behind you, then you might take evasive action and that would not be fair. You can try to scan as you move, but since the opposing tank sprite will be off screen during your turn in the real competition, that would not help.

[SteveB]

I think your argument is wrong. If I can't see the enemy, X1, Y1 and DIR1 are 0, I have no data to CALL SCAN. I don't know that he sees me then. I can only check if he sees me when X1, Y1 and DIR1 are filled, so if I am in advantage (being undetected) or we see each other.

 

So it is either I copy your routine or call it. Either way, I get no advantage concerning the data.

 

[+Vorticon]

2 hours ago, SteveB said:

I think your argument is wrong. If I can't see the enemy, X1, Y1 and DIR1 are 0, I have no data to CALL SCAN. I don't know that he sees me then. I can only check if he sees me when X1, Y1 and DIR1 are filled, so if I am in advantage (being undetected) or we see each other.

 

So it is either I copy your routine or call it. Either way, I get no advantage concerning the data.

 

Maybe I'm misunderstanding your request. You want to use the SCAN routine to detect if the opposite tank sees you, correct? In this case, unless you also have LOS on the opposite tank, you will have no location data for that tank and the SCAN routine will simply not work. 

What am I missing here?

[SteveB]

7 hours ago, Vorticon said:

Maybe I'm misunderstanding your request. You want to use the SCAN routine to detect if the opposite tank sees you, correct? In this case, unless you also have LOS on the opposite tank, you will have no location data for that tank and the SCAN routine will simply not work. 

What am I missing here?

There is 3:1 chance when I see the opponent he points to another direction. I am interested to know if I have been detected or not, leading to an aggressive attack or being cautious not moving in front of his cannon... even the most stupid program will shot me then. You are right, this is only relevant when I see the enemy, otherwise I don't have the data to check if he sees me.

 

 

I 

 

[+Vorticon]

2 hours ago, SteveB said:

There is 3:1 chance when I see the opponent he points to another direction. I am interested to know if I have been detected or not, leading to an aggressive attack or being cautious not moving in front of his cannon... even the most stupid program will shot me then. You are right, this is only relevant when I see the enemy, otherwise I don't have the data to check if he sees me.

Ah I see where you are coming from. Once you have eyes on the opposite tank and your routine has its coordinates and direction, you want to run SCAN on it to see if it has LOS on you as well. That's perfectly legitimate and you are free to use the SCAN and LOS routines in the host program as you see fit.

 

[senior_falcon]

Just curious as to how much of the tank has to be in view. For example:

My tank is at r23,c16 looking up

There is a wall coming from the left at r13 and ending at c15

The enemy tank is at r3,c14

Here the tank is behind the wall and cannot be seen and I assume my subprogram would not be told I could see it

Move the enemy tank up a row to r2,c14

Now just the edge of the tank can be seen. Would my subprogram be told that the other tank is in sight?

[SteveB]

Vorticon used Bresenham's line algorithm to build the line of sight and stops when touching a wall. 

 

I didn't know this one before I implemented in in the Multicolor Library, but now I recognize it 50 yards against the wind....  🤪

[+Vorticon]

Yes that's Bresenham's alright, but remember that it's limited by the 32x24 block resolution, so it may not be perfect is some cases.

[senior_falcon]

We are overthinking this a little bit. If you can see the enemy tank, then the enemy tank can see you, provided he is turned in your direction. And that is easy to determine since you know the x,y coordinates of both tanks and which direction the enemy tank is turned.

[+retroclouds]

1 hour ago, SteveB said:

Vorticon used Bresenham's line algorithm to build the line of sight and stops when touching a wall. 

 

I didn't know this one before I implemented in in the Multicolor Library, but now I recognize it 50 yards against the wind....  🤪

Yes, same here. I learned about Bresenham while working on the rope implementation in Pitfall! for the TI-99/4a. 😃

 

You see, the TI-99/4a makes us smarter! 😁

[+Vorticon]

1 hour ago, senior_falcon said:

We are overthinking this a little bit. If you can see the enemy tank, then the enemy tank can see you, provided he is turned in your direction. And that is easy to determine since you know the x,y coordinates of both tanks and which direction the enemy tank is turned.

Not necessarily. Since the cone of vision is +/- 45 degrees from the frontal centerline, your tank could be facing up and the opposing tank facing either to your right or left and both *could*  still see each other. The further away the tanks are, the wider the field of view.

[+OLD CS1]

3 hours ago, senior_falcon said:

If you can see the enemy tank, then the enemy tank can see you, provided he is turned in your direction.

Chuck Norris tank wants a word with you.

 

2 hours ago, retroclouds said:

You see, the TI-99/4a makes us smarter! 😁

Bill Cosby was right: This is the one!

[+Retrospect]

35 minutes ago, OLD CS1 said:

Bill Cosby

Everything is not exactly dark, but it's too FUZZY to see! 
Oh God .... he got me!

[SteveB]

57 minutes ago, OLD CS1 said:

Bill Cosby was right: This is the one!

but not this TI ...

[+OLD CS1]

3 hours ago, Retrospect said:

Everything is not exactly dark, but it's too FUZZY to see! 
Oh God .... he got me!

Tasteless off-topic meme...

Spoiler

 

[+Vorticon]

Tursi uncovered an edge-case bug with the host program related to an infinite loop situation with firing. This has been corrected and I have uploaded a new version of the host program to the first post.

Also under the Project tab of TICodEd in the Parameters section, you should set the GOSUBs at 5000 and the SUB's at 10000 in order to avoid strange errors with large line numbers in case your subroutine is pretty large.