Need some XB help

[Sinphaltimus]

So I took a couple days off and sat down to work a little.
I'm writing code in to help me troubleshoot (a bunch of print statements)
In doing this a lot, I run out of memory.

 

What can I do to increase my use of stack instead of program?

I vaguely recall something about a book on this topic in particular but not the name of the book.

 

 

 

EDIT: I'm running a gutted down version of my game to troubleshoot the specific area I need to buuuuuut....
Getting close to beta and I still need to do music and 1 more zombi type. So I think I'm going to run into this issue for real outside of the troubleshooting code.

Edited December 8, 2016 by Sinphaltimus

[+mizapf]

BTW, not related to your problem, but please do not make it a habit to use lowercase (small capitals) letters. There is no "dsk2", only "DSK2". The standard writing on the TI is AlphaLock on. If you run your programs on real iron you will get an I/O error x0.

[+InsaneMultitasker]

Numeric variables consume program space. You either can reduce your program size or reduce the total numeric variables. DIMensions eat up memory quickly, on a per-element basis.

[Sinphaltimus]

Are there methods by which I can eat up stack memory instead?

[+mizapf]

IIRC, strings are stored in the stack memory.

[+InsaneMultitasker]

As for options to use more stack memory... If you have a lot of text in your program, you can store the text in a disk file (write it up using TI Writer or other editor), read each text line from disk, load the text into an array, and then print the array items in place of the text. I use this approach fairly often. For example, my BBS software offloads about 5,600 bytes of text into a disk file which is loaded into an array, allowing for equivalent program code in place of that text. (I don't know if compiled programs can use this method)

 

Placing text in DATA statements attains the same results with one important distinction: DATA statements read into string variables consume both the original program space and the assigned stack space, which eats up valuable memory from both spaces.

[Sinphaltimus]

IIRC, strings are stored in the stack memory.

I'm sorry, I don't know what IIRC is or I'm having a brain fart and missing the obvious.

[+mizapf]

If I Remember Correctly

[Sinphaltimus]

If I Remember Correctly

Excuse me. (brain fart)

DOH!

 

 

I discovered the problem (bug) that sent me down this path. Once I get that fixed. I'll work on reducing the code size and looking further in to variables and strings. Unfortunately, I do not use a lot of text in the game. The title and instruction screens are graphically compressed using H.W.'s Compressor.

 

I.M. - "As for options to use more stack memory... If you have a lot of text in your program, you can store the text in a disk file (write it up using TI Writer or other editor), read each text line from disk, load the text into an array, and then print the array items in place of the text. I use this approach fairly often. For example, my BBS software offloads about 5,600 bytes of text into a disk file which is loaded into an array, allowing for equivalent program code in place of that text. (I don't know if compiled programs can use this method)

Placing text in DATA statements attains the same results with one important distinction: DATA statements read into string variables consume both the original program space and the assigned stack space, which eats up valuable memory from both spaces."

 

Yeah, i don't use a lot of text at all. The title and instructions screens are graphically compressed.

 

 

Edited December 8, 2016 by Sinphaltimus

[Sinphaltimus]

FILTH FLARN FILTH!




Alright, I'm goin' to bed watch some TV. Tomorrow's another day and I'll spend about half of it on a rewrite.

[Sinphaltimus]

OK, memory issues aside (resolved for now);

 

Just want to know if my issues sound familiar to anyone?

 

I have a really weird problem that I cannot find to source to.

If I can't resolve it by the end of the day today, I'll share the test source code and see if we can somehow figure it out together.

What's happening is I have a variable called ZDR (formerly know as ZEDDIR). It is either 1 (left to right) or -1 (right to left)

I store this value in an array so it's recorded for each zombie on the board. I use FOR NEXT loops to scan through the arrays.
Since there is always a chance that all 14 zombies can spawn (I spawn a minimum of 1 per board) the array is zedz(14,6)
My FOR NEXT loops are 1 to 14.

I am checking every possible collision at every movement cycle.

For performance reasons I am narrowing down the coinc checks quickly by using location.

I know what y coordinate of every level is and what sprite number will spawn on that level. It's like this....
There are 8 levels including the bottom level and nothing spawns on level 1.
Level2 is sprite number 10 and 11, level 3 is 12 and 13, etc.. for a total of 14 sprite numbers with known spawn locations.

When I check a particular zombie coinc I start with the Y position of the zombie to determine which 2 possible sprite numbers could this particular zombie be coinc with at this level with the exception of itself?
Then I do a check to ensure that sprite number even exists (was not already destroyed and removed from the board)

I have a 1-14 array for each loot item PLUS on 1-14 array for all loot items (I'm going to phase this out as it is currently only needed for bullets)
To speed up performance, the sprite value column in the zedz array will only have a value for the sprite number or 0 (there are not enough spawned zombies to fill the array).

In essence, as soon as we pass the last zombie sprite in the array, all values I check for become zero.

So in the case of ZDR where ZDR can only equal -1 or 1, if we hit the end of the array and ZDR=0 I can skip all remaining coinc checks for zombies and end the for next loop.

Upon moving or checking coincs for zombies again, I return to the array for next loops to read in the ZDR and Sprite number values etc..

I have to type this again...
ZDR=0 THEN skip all remaining coinc checks for zombies and end the for next loop.

 

Due to trouble shooting, I even went so far as to include the check for all the variable I have checks for. So the real statement looks like this:

IF AZED=0 or TZEDZ=0 or ZS=0 or ZEDDIR=0 or ZHOLX=0 THEN _ENDZHCZ

However, THIS CHECK is not working. I have run TRACE, I have inserted print statements at every other line following the variables, I have written variables out to text file from within the running program to watch it all change step by step.
Yet these zeros are making it through many of the checks at the wrong time or being assigned at the beginning of the loop making it impossible to avoid an EQUALS ZERO situation that avoids COINC altogether.

So my ZED coinc checks are not working against holes, or hearts. But yay, they work against player and I'm really not using any different of a method for that (I'm replicating what works and it's not working).

 

ALSO, I am tracking the FOR NEXT value from 1 to 14 and there are times it will be inside the loop and equal 15.

When I try to end the loop with an _ENDZHCZ I send it to...

_ENDHCOZ:
     ZHCOINC=14
_NXTHCOZ:
     NEXT ZHCOINC
_ENDZHCZ:
     ZHCK=14
_NXTZHCZ:
      NEXT ZHCK
RETURN

I'm not posting all the source just yet because I'm having some new ideas about where to check and what to change.

It would suck to review the code and put in the effort only to find it is no longer relevant so I'll hold off until I am done changing code for the day.

Just want to know if my issues sound familiar to anyone?

Edited December 9, 2016 by Sinphaltimus

[senior_falcon]

Not sure if you're doing this or not, but remember that you cannot jump out of a FOR/NEXT loop into a different FOR/NEXT loop when using the compiler. For example:

10 FOR I=1 TO 10

20 IF I=5 THEN 60

30 NEXT I

 

40 FOR I=1 TO 10

60 NEXT I

This will work in XB but will crash when compiled.

[Sinphaltimus]

I'm aware thanks to your docs and previous help.

I do things like this instead.

10 FOR I=1 TO 10

20 IF I=5 THEN 25 ELSE 30

25 I=10

30 NEXT I

40 FOR J=1 TO 10

60 NEXT J


OR THIS...

10 FOR I=1 TO 10

20 IF I=5 THEN 25 ELSE 30

25 GOSUB 40

30 NEXT I

35 GOTO 80

40 FOR J=1 TO 10

60 NEXT J

70 RETURN

80 ......

Thanks to your guidance.

EDIT:I will triple check tho'.

Edited December 9, 2016 by Sinphaltimus

[Sinphaltimus]

Didn't post code because I made a lot of progress and ran out of time. I'm confident my rewrite will fix this issue and be more efficient. My goal is to get a new version out today. We shall see.

 

 

EDIT:

 

OK so wow. Yeah, Optimized collisions and over-all game performance a lot. Break things, fix one broken thing, 3 more things break and on and on it went for over a week or tw0. I dunno, who is counting?
Chasing my tail for days it seemed.

I finally got everything working again after the previous rewrite.

Edited December 10, 2016 by Sinphaltimus

[Sinphaltimus]

Not really quoting you - just wanted to get your attention.

 

Not sure if it's an actionable item or not but I know I have to watch my typos.

 

v049 of my Zombi game was crashing consoles and classic99 in its .bin format.

 

It was this line of code right here:

 

3920 IF PFALLIN<>0 OR JMP-1 THEN 4080

 

The correct line of code is here:

 

3920 IF PFALLIN<>0 OR JMP=1 THEN 4080

 

That simple typo never triggered an error in Extended Basic XB256 during testing.

It made it through the compiler, the assembler and the loader.

It made it through Module Creator.

 

It would crash the heck out of classic99 and real iron loaded on to FR99 as soon as it was started.

 

Just an FYI.

 

I know it's my own fault for the typo. I only found it so quickly because it was a last second untested change before I took it through the compiler.

Edited December 11, 2016 by Sinphaltimus

[Sinphaltimus]

Quick Question - what is the best way to reinitialize an array in XB?

I understand DIM can only be run once in a program but I misunderstood that to mean it could only appear once in code per array not that you couldn't go back to it within a running program.

 

In this example - the array does not get reset to all zeros when I goto 10.

 

10 DIM testarray(7,7)

20 A=testarray(1,1)

30 print A

40 A=13

50 testarray(1,1)=A

60 print A

70 goto 10

 

*result - print 0 then all 13s

 

Is this all that can be done?

 

10 DIM testarray(7,7)

12 FOR aa=1 TO 7 :: FOR bb=1 TO 7

13 testarray(aa,bb)=0

14 NEXT bb :: NEXT aa

20 A=testarray(1,1)

30 print A

40 A=13

50 testarray(1,1)=A

60 print A

70 goto 10

 

*result - print 0 then 13 then 0 then 13 etc..

 

Is there a way I can delete an array (or it's contents) in less code than above example?

 

10 DIM testarray(7,7)

20 A=testarray(1,1)

30 print A

40 A=13

50 testarray(1,1)=A

60 print A

65 call delete(testarray(7,7)) <--theoretical command in my head.

70 goto 10

 

*result - print 0 then 13 then 0 then 13 etc..

 

 

EDIT: I'm barely getting by running in XB256. Screenshot taken after play test session.

Edited December 28, 2016 by Sinphaltimus

[Tursi]

There's no way I'm aware of. I'm not certain, but I think DIM is actually only used by the pre-processor to allocate the space.