Recursive example XB

[1980gamer]

I think I did it?

 

This example draws a box and randomly places "B" or "C"  in each location within the box.

I then start at a single location and "loop" until all contiguous B's are replaced with spaces.

 

I display some variables below the box that were used for trouble shooting.  But may help you understand what is going on while it runs.

I also use overdrive in Classic99.  But have a delay built in.  KEY PRESS required to loop.  JUST HOLD A KEY to go fast! LOL

 

It is not a clean program.  I was fudging around with it and got it working....  It is as it was!  I res 10,10 to make it a little cleaner.

 

What do you think?

 

VARS:  

SP=char of the Starting Position  if it =67  that round is over and it redraws.

L=char to Left of current position.

R=char to right of current position.

U=char 1 up from current position.

D=char 1 down from current position.

II and JJ are the row and column of the current position

DIR is the direction we are going to clean the block.

LV is the nesting level of our recursion.

Loop Count is self explanatory.

 

 

 

rec.txt

[1980gamer]

Is it possible to PEEK at the current line number of a running basic/xb program.  Like TRACE, but so I can display it in the upper right, or lower left...  Current Line only would be great.

If we could make a "trace window"  Maybe like the last 5 lines executed? 

 

I tried looking at the classic99 debug etc. but either I don't understand how it works ( very possible! ) or it doesn't do this.

 

Anyway, I was getting trapped in a loop and not falling out.  This feature would have been handy!  This is where the LOOP COUNT var came from!  Found my bug!  LOL

 

Good night all...

[senior_falcon]

On 8/21/2021 at 12:38 AM, 1980gamer said:

Is it possible to PEEK at the current line number of a running basic/xb program.  Like TRACE, but so I can display it in the upper right, or lower left...  Current Line only would be great.

If we could make a "trace window"  Maybe like the last 5 lines executed?

Depending on how long your program is, one way to do this would be to add the line number to the beginning of each line and print it using a subroutine or a subprogram:

10 L=10::GOSUB 1000 !LINE CONTINUES

20 L=20::GOSUB 1000 !LINE CONTINUES

30 L=30::GOSUB 1000

40 L=40::GOSUB 1000::GOTO 10

1000 DISPLAY AT(24,1):L::RETURN

 

I worked out a small utility that runs as an interrupt routine. It looks at >832E to get the current line number and prints it on the screen. As per your request, it prints up to 5 line numbers on the screen in the upper left, scrolling up to make room for the newest one. This could be useful to you, but one problem is that lines that execute in less than 1/60 second can be missed. Here it is for what it's worth:

TRACE5-O

To use it:

CALL INIT

CALL LOAD("DSK1.TRACE5-O")

CALL LINK("TRACE5")

CALL LINK("OFF") to turn off the routine

 

[1980gamer]

Wow,  That is awesome!  I will try it.

Thank you!

 

I just let my recursive demo run for a few hours and it gave me an out of memory after 1400 iterations.

On setting c=rnd function.

 

Anyway, I have added a few more vars.  Max Loop Counter and Max nesting Level.  Just to see if these are the cause.

 

Also, to be true, this should be a SUB that calls itself.  But I figured out how to do it without that.

 

Now, I should be able to make it call itself if I needed.  But I am wondering if I should?  I see memory issues doing that!

 

I am doing a quick test run.  Then I will compile and see what happens!

 

Be well.  The eye of Henri is approaching me now, so hoping to not lose power etc.

I don't know where Lansing is, But I know this storm is tracking north west.  So I hope you are all good too.

 

 

[1980gamer]

So, complied has run over 3500 iterations

 

The max nesting level was 68 for a long time then jumped to 71 and then 74.  Close to crashing 75!!!

Loop count max has reached 169

 

update, just looked at 3800+ max loop count is now 171.  Edit:  Now over 4300...  Must have been a nesting level exceeding the DIM.  Cool!  This is awesome!

 

Still running.  I think I can solve the mouse in the maze challenge now.  LOL 

 

My only tweaks would be directional bias.  That is.  Look right first, then up.  etc.

 

With a bored prescan.  I guess I could base the directional bias on relative position.   If the mouse is north of the exit.  Look down before up.  etc.

 

When the exist is reach.  I would have all of the dim data reaching the exist.  So then it would be just "playing" back the steps that worked.

 

Pretty easy, now that I have this working.

 

EDIT: Got to almost 12000 iteration and crashed.  I think if I increased the DIM it would run without issue.

 

Edited August 22, 2021 by 1980gamer
updated info