The modes are as follows:
"w" = "Param"
"r" = "Ans"
"+" = ","
Where "Param" and "Ans" are tokens
I think that you can do "Param," as w+ and "Ans," as r+ ?
Thanks to DrDnar for {28,char:Asm(prgmTEXTLIB !
(chars are the askii codes for w,r, and +, "a" doesn't seem to work)

Got any code for making a menu routine??

Here’s some pseudocode for you:

1: display your title and the options.
2: if the user presses up and they are not at the top already, go up, and increment a variable.
3: Likewise, if they press down and aren’t at the bottom, go down (in the options) and decrement a variable.
4: If they press enter, do different things based on what the variable you incremented/decremented is

I'll give that a try, I might need literal code. We'll see what happens...

Bug report time
I keep getting "You have the wrong number or arguments" (is that a typo?) when I try to compile a program with only two lines,
" iCOMP" and
" det(59,52+A-10*(A/10),x,y "
using ICE v2.0.
V1.5 didn't give me this error.
Strangely enough, if I put the same exact command in another program that has actual code in it, it gives me a different error, "You have an invalid expression", pointing to the line with the command.
If I try to compile with windows command prompt with the .exe included in the dropbox link you provided I get "You have the wrong number or arguments" with it saying the error is on line 0 (zero).

Also, what is this "prescanning" ICE does when compiling programs now? It takes literally one minute to compile a program that took ice v1.5 less than 1 second to compile.
The prescanning progress bar is also not very informative, it fills up and resets 5 times before actually compiling the program, then the compiling also takes a lot longer than it did before.

The program that takes a while to compile (and worked fine in ICE v1.5, just change one token at the beginning from "AsmComp(" to "CompilePrgm(" if you want to compile the program in ICE 1.5) is here in this link
https://drive.google.com/open?id=0B36Z6j9NdZndMldaVlNBMXlVemc
DISCLAIMER: Nothing in that program is complete and it's a mess of many different programs I made just to have fun with ICE, nothing in that program is going to be practical for anyone other than me.
NOTE: ASPACE and ZSPRITE are one program, ZSPRITE just contains the text character sprites that are compiled into ASPACE so that the huge array of sprites aren't in the main program when I'm editing. ZSCHED and ZTIM are TI-BASIC programs to do various time/date functions that ICE doesnt have.
WARNING: If you're messing with my program, don't go to "SCHED" from the main menu if your calculator's date is not up to... date. Like I said, nothing in that program is done and if you open SCHED (which is my high school schedule btw ) with your calc's clock set wrong, it's either get stuck in an REALLY LONG repeat loop or if your date is before August 31st, freeze.

I see there is a title maps command but no where can I find it on the command.html

Hmm, this is really weird, I will try to give it a shot. Thanks!


When ICE is prescanning, it loops through the entire program. Then, if it hits an AsmComp(, it needs to prescan the subprogram too, thus that is why the loading bar gets reset like 5 times. Basically the first time it scans the program(s), it finds all the graphx functions, allocates memory for the OS strings/lists, and the second time all the fileioc functions. It's probably that slow, because it needs to redraw the loading bar everytime. I can change it, such that it only updates at every line, instead of every token.


Thanks to jacobly, I figured out you mean "tilemap command". If it's not in commands.html yet, it means I didn't implement it yet. No worries, Mateo added ICE tilemap output in ConvPNG, so I give it a try one of these days.

Bug report
I found out when u try disp something on the screen with det(18,"test v1.0-bug test",20,20) it comes up with something different

Nevermind it has been fixed

Updated version:
- Fixed strings. Now 'w' or 'r' is actually a 'w' or 'r', and not the BASIC token. This means, however, that all BASIC tokens are converted to the characters, which means that "sin(" is now 4 bytes instead of 1 byte.
- Fixed the main bug reported by KryptonicDragon

https://www.dropbox.com/s/7a3qiexqgc2r01i/ICE_3.zip?dl=0
Commands: http://htmlpreview.github.io/?https://github.com/PeterTillema/ICE/blob/C-version/documentation/commands.html

Is there a way to only draw a cropped portion of a sprite to the screen?

EDIT: Nevermind, was told about the det(43 command.

Fixed few important bugs: https://www.dropbox.com/s/ynnjwrf2dwmgj6u/ICE_4.zip?dl=0
Also updated the documentation.

Has there been an update that allows you to use a variable in the getKey command? Also, why does running a BASIC proram after using det(0) make things look so strange? Why does it obstruct the program? Has this been fixed?

No, should it be?


Because you don't have a det(1 ?

Running a BASIC program after det(0) makes everything look strange because det(0) sets up the display to be used with the CLIB graphics commands, such as for drawing shapes and sprites.
You then need to use det(1) to close the graphics setup and prepare the calculator for the TI-OS graphics, which is what BASIC programs use.
Running a BASIC program after det(0) is like trying to make an oil painting with a pencil; it does not work and is not supposed to work. Remember to use det(1) at the end of a program or before executing a graphical BASIC program after using det(0)

But I mean that this applies even when no graphic commands are used in the BASIC program. Is there a way to run any BASIC program without ruining/ending the graphic display that is generated by the ICE program?

I'm quickly posting this here so I don't forget to tell you and so you see it ASAP,
About the feature addition to ICE v2 we were talking about, where [1,2,3,4,5]->L1 would store a list into any var's pointer (so [1,2,3,4,5]->A would store to wherever A points to), I was thinking about it and had the idea to make the first argument the byte sizes, like in the data() command.
So [3,1,2,3,4,5]->A would store the 3 byte variants of 1,2,3,4, & 5 into wherever A points to (or [3,1,2,3,4,5]->L1 to store to wherever L1 points to, etc) , and [1,1,2,3,4,5]->A would store the 1 byte variants of 1,2,3,4, & 5 into wherever A points to (or [1,1,2,3,4,5]->L1 to store to wherever L1 points to, etc). Same applies to 2 byte variants.
OR, instead of the first argument being the byte size, it could be the amount of brackets.
so [[[1,2,3,4,5]]]->A would be 3 byte values
[[1,2,3,4,5]]->A would be 2 byte values
[1,2,3,4,5]->A would be 1 byte values
OR, same as above but inverted, because 3 byte values are more commonly used
so [[[1,2,3,4,5]]]->A would be 1 byte values
[[1,2,3,4,5]]->A would be 2 byte values
[1,2,3,4,5]->A would be 3 byte values
The first argument one seems to be the best idea though.
It's a quick little argument that would add a sizable amount more use cases to [1,2,...]->POINTER.

All of this is, of course, if you decide to implement the feature we talked about in the first place (please do, I'm tired of "copy(var,data(size,data1,data1,...),size*3" ).

When I make an appvars it does not appear in the mem menu in appvars
By the code is
itest
Sum(1,"ALVA","w+")
Det(0

Code for test run

Det(1

You need to close all the open slots before trying to open a new one, with CloseAll.

getKey(<key>) is really slow!

Code:


This seems much faster.

Code:

Ohh thank you PT_ that helped a lot