A certain number of sprites and backgrounds are allocated to the bottom screen by default if left unspecified. I forget exactly how many, but that's bitten me unexpectedly before. So if you want to use all of the sprites and backgrounds on the top screen, you'll have to specify that.

You might want to do BGMSTOP -1 which forcibly stops all audio (for example if a user-defined instrument was set to never release and just kept on playing forever). You may also want to specify thr number of sprites and backgrounds for the top screen in the XSCREEN. VISIBLE shouldn't be necessary as that is handled by ACLS. Any particular reason you're making the graphics screen pop-out?

To decrease the amount of repeated code, we can write a function to help out: DEF NEXT_TOKEN S$,I OUT TOKEN$,J J=INSTR(I,S$,",") IF J<0 THEN J=LEN(S$) TOKEN$=MID$(S$,I,J-I) INC J IF J>LEN(S$) THEN J=-1 END I=0 NEXT_TOKEN GAMESAVE$,I OUT HP$,I NEXT_TOKEN GAMESAVE$,I OUT SP$,I

For example, if you were using a comma: START=0 COMMA=INSTR(START,GAMESAVE$,",") HP$=MID$(GAMESAVE$,START,COMMA-START) START=COMMA+1 COMMA=INSTR(START,GAMESAVE$,",") SP$=MID$(GAMESAVE$,START,COMMA-START) To illustrate, I assumed you put a comma after the final value. Otherwise you would need to use COMMA=LEN(GAMESAVE$) for the last one.

You would probably want to separate your numbers with some kind of delimiter like a space or comma or something so you can tell where one value ends and the next one starts. For example, if you had HP$="1337" and SP$="42" you would end up with GAMESAVE$="133742", and there is no way to say you didn't start with HP$="133" and SP$="742". You can then use INSTR to search for the delimiter.

Ohhh, have you been trying to port the raycaster I made in Petit Computer? I made a raycasting library for SmileBASIC that's a lot better, it comes in the RAYCAST.LIB file in public key QK4N3PZF.

I've covered all of those things in the roughly 200 lines of documentation I wrote in the library. I can't help much with general questions like that here, but if there's anything specific you're hung up on, I would be happy to help.

I think the best way to start is to get the library up and running with your own code and play around with the basics like movement and collision with walls, and maybe placing some sprite objects in the map.

I assume you're planning to use my library? If so, definitely take a look at the documentation in the source code. After that, if you have any specific questions, feel free to respond here and I'll try to answer them.

It's time for a throwback! I cloned the classic TI-84+ game Block Dude (originally by Brandon Sterner). Stack up blocks and make it to the exit door, but don't get stuck! Public Key: 4KX3PX7D

You can also use the built-in constants #BGROT180 and #BGREVV instead of &H2000 and &H8000, which might make your code more readable.

You can use the LEN function to get the length of the array, so you don't have to keep track of it yourself.

USE does also give slot 1 its variable pool, *but* none of the variables are initialized. The array variables can't be used (except by assigning a reference to an existing array) and number/string variables are left as 0 or the empty string. EXEC fixes this by actually running the initialization lines as a program.

Maybe try EXEC instead of USE so the arrays get initialized? Ideally that should run the variable initializations and then skip over the function definitions, then return to the previous slot.

I'm afraid it's not possible to resize a multi-dimensional array at all. However, it may be possible to make a function that creates a new array of the correct size and then uses COPY to fill it with the old array and the new values. Either that, or use a one-dimensional array and COPY to the end of it (but you'd have to do the index calculations yourself).

The only one I know of is the one I made, Spooky Maze. Here's the code: QK4N3PZF Hope you enjoy it!

If you have an empty program slot (for example slot 1), you can do LOAD "PRG1:FILE", and then the PRGEDIT and PRGGET$() functions to access one line at a time. Alternatively, you can LOAD("TXT:FILE") to get the entire program as a string, and use string manipulation functions to extract each line.

Example of TRY/CATCH/ENDTRY/THROW: TRY C=A/B CATCH IF ERRNUM==7 THEN PRINT "Divided by zero!" ELSE THROW ERRNUM ENDIF ENDTRY To make error identification easier, constants for common errors could be added, such as #ERRDIVBY0. Some errors cannot feasibly be caught, such as syntax errors, but others like division by zero, array subscript out of range, or type mismatch could be done.

Another feature request: TRY/CATCH/ENDTRY blocks. If an error occurs in the block between TRY and CATCH, then jump to the CATCH block (which should be able to use ERRNUM to identify the error). If no error occurs between TRY and CATCH, skip the CATCH block and go to ENDTRY. In addition there could be a THROW command that throws an error given its number.

After running it, just go into the program editor and it should already be there!