My brother introduced me to this app, and I immediately fell in love with the simplicity of the game. So, natively, I decided a port of this to the calc would be awesome. I've written some code in DCS-aided TI-BASIC, and so far I have it loading levels from an AppVar/prgm, displaying splashscreens, and doing some tilemap things. The first line of the AppVar/prgm will be used later to store what level to start loading from, and I have written a program to aid in the creation of new levels. Here is my code, please feel free to comment suggestions or questions. I have not written anything for gameplay, so pressing enter "solves" the puzzle.

Level Creation Code:

Code:


The LOOPLVLS AppVar/pgrm with 10 level, in the pattern of :scrambled1:solved1:scrambled2:solved2:..., a / indicates an x-shift of 4 pixels, * is a y-shift, and - shifts both x and y 4 pixels away from the top-left corner.

Code:


And the game part:

Code:


Pic6 looks like this:

Alright, I have "completed" the game, in that it works and functions the way I want it to. Here is the game code:


Code:


It creates a new file "thetathetaZZLOOP" to save current level and graphical preference, the picture is the same (could be modified to look better), and the level appvar/prgm has lost it's first line, and I've ported over 10 more levels.

Please feel free to comment with suggestions to optimize on speed or size.

I guess this is always true, inString returns a number from 0 upto the length of the string.
Secondly, I recommend you to replace

Code:
with this:
Code:
which is much faster

Ah, at the end of that line, I am subtracting 2, so -1 would correspond with the string being "0", which, for the game, is a blank space and has to be handled a special way.

The Ans usage is definitely faster, thanks for recommending that.


Another thing: Is there a better way to store this than in a matrix. Matrices are memory heavy, make for cumbersome number<->coordinate code, and are probably the slowest thing to read and write to as far as BASIC variables go. I want to use something smaller and faster, possibly a list, but I have been using the matrix to do spritemap (though, in hindsight, I may not need to do that now that I changed how things are displayed). Would a list be a good option? What else could I use?

You could remove "0" from the search string. If inString( can't find the character it returns -1.


Code:

However, this would make "1" return 1 instead of 0.

Yeah, so for my purposes, removing "0" from the search string would not do me much good. My current code allows me to check for blanks ("0"'s) while simultaneously adjusting the numbers in a way that lines up with the sprites in the PicVar.

I have contacted the developer of ∞ Loop via email, and he loves the idea of a port, and has even worked on some 8x8 sprites and a splashscreen, which I will use un the game, probably abandoning my own implementations in respect for the original dev's work. I asked him yesterday if he could send me the level's initial and solved states in some form, to which he has not replied yet (I am not expecting fast responses), but looking into it, it seems that most of the levels are randomly generated. A Google search came up with no definite results as to what algorithm was/can be used, and I have no idea where to start. If anyone has any ideas into how levels of increasing size/intricacy could be randomly generated for this game, please post a reply. And, as always, feel free to comment on any optimizations or questions you have.

Alright, here's the deal. I have totally scrapped attempting to store levels individually, because without a time-consuming compression/decompression algorithm, I can only store 600 levels in a 64kB AppVar. So, that being said, I have created an algorithm that generates random levels. Here is some updated (albeit un-optimized) code, nicely annotated for your reading pleasure.


Code:

So, the game is all done, gameplay is smooth and the graphics are nice and the levels generate randomly, just as intended. But I have one small issue: tilemaps.

The program uses the DCS reincarnations of the xLIB tilemap routines to run, eg. real(2,blah,blah,...). But it does not seem that the routine draws on the 64th row of pixels.

Setting [A] to:
Code:

with Pic1 that has
Code:

in its top-lefthand corner, any variation/combination of
Code:

fails to draw a black line at the bottom of the screen.
Kerm and I discussed this over SAX for a while this afternoon, and no solutions came up (and no problem was found in source). I am using DCS7.2b3 on a 2.40 ROM version 84+SE