Is implementation of the "dim()" command at all possible/coming in the future to ICE?
Another problem I am having, though I think this one might simply be from me misunderstanding something.
Using Ti 84 PCE v.5.2.2.0043
Using ICE v1.5 (after having been re-downloaded from the last hotfix, last updated 07/08/2017)
The first program here works fine:

Code:
[i]COMP2
ClrHome
0->W
Repeat W
   getKey->K
   If K=34
      1->C
      1->W
   End
   If K=26
      2->C
      1->W
   End
End
If C=1
   Disp "SELECTION 1"
   Else
   Disp "SELECTION 2"
End
Pause

When compiled and run, the screen will be blank. If you press 1 it will output "SELECTION 1", else if you press 2 it will output "SELECTION 2" and wait for you to press Enter, then it exits the program as it should.
In the Commands document included with the download of ICE, it says you can use "getKey(KEY)" with KEY being the keycode, and it will return 1 if the key last pressed matches the keycode, 0 otherwise. It also says that this routine is much faster.

So, I tried using that method with a similar program:

Code:
[i]COMP3
ClrHome
0->W
Repeat W
   If getKey(34
      1->C
      1->W
   End
   If getKey(26
      2->C
      1->W
   End
End
If C=1
   Disp "SELECTION 1"
   Else
   Disp "SELECTION 2"
End
Pause

That program, however, does not work. After compiling and launching it, the same blank screen is shown, but pressing 1, or 2, or any other key does nothing. Leaving the calculator stuck in a loop with the only way out being the reset button.

Not sure if "getKey(KEY)" is broken or if I'm doing something wrong. Also tried this both on physical calc and CEmu, same results from both.
You did not press "sin(", because that key works Razz
Will try to fix as soon as possible, thanks for the report!

EDIT: fixed and updated. I did some really weird stuff with checking the right bit for the key Razz
lol, good job for fixing it!
A few questions I have, since I've been messing around with ICE for a bit:
1: Does ICE have built in list compression when it compiles programs or is that a thing I would have to implement manually into the program itself?
2: I noticed in the FLOODSRC example file there is a label called "GETTILE", which is 7 characters long. How long can the label names be?
3: Any way of figuring out the length of a list without knowing it beforehand, like the BASIC dim() token?
KryptonicDragon wrote:
A few questions I have, since I've been messing around with ICE for a bit:
1: Does ICE have built in list compression when it compiles programs or is that a thing I would have to implement manually into the program itself?
2: I noticed in the FLOODSRC example file there is a label called "GETTILE", which is 7 characters long. How long can the label names be?
3: Any way of figuring out the length of a list without knowing it beforehand, like the BASIC dim() token?

1) ICE doesn't have any support for compression, neither with lists nor with sprites. You have to write a routine yourself I'm afraid.
2) As long as you want. 2 notes: never put a Lbl or Goto at the last line of the program. If you want to do that, please add an empty line after. The other thing is a bug in ICE that it doesn't recognise labels properly. It works fine, but be sure the labels don't look like each other (ie ABC and ABCD)
3)

Code:
0->A
While L1(A
A+1->A
End


Goodluck! Smile
PT_ wrote:

3)
Code:
0->A
While L1(A
A+1->A
End


Goodluck! Smile


For 3, I wasn't aware that trying to recall a number from a part of a list that doesnt exist (I.E trying to see what L1(5) is when L1 is only 3 numbers long) would return a zero, I just assumed it would cause an error and freeze the calc. Razz
Thanks!
KryptonicDragon wrote:
PT_ wrote:

3)
Code:
0->A
While L1(A
A+1->A
End


Goodluck! Smile


For 3, I wasn't aware that trying to recall a number from a part of a list that doesnt exist (I.E trying to see what L1(5) is when L1 is only 3 numbers long) would return a zero, I just assumed it would cause an error and freeze the calc. Razz
Thanks!

It doesn't, it's not like the OS. This routine find the first 0 in the list, basically.
I've been, uh, quite busy with ICE, testing lots of things out.
I think I've found another bug.
Ti 84 PCE OS v5.2.2.0043
ICE V 1.5 (last updated 08.08.2017, I redownloaded it from Ti-Planet a few minutes ago at 3:47am EST)

In the commands.html document included with ICE, the description for "Blit" ( det(11, .. ) ) says
Quote:
"Copies the buffer image to the screen and vice versa. 0 = copy buffer to screen, 1 = copy screen to buffer."


I encountered a problem with this when testing out a program I am making. It seems that "0 = copy buffer to screen, 1 = copy screen to buffer." is actually inverted (1 is for buffer to screen and 0 is for screen to buffer).
From some other testing I did it looks like this only applies to the Blit command, and not any other command that has "0 = copy buffer to screen, 1 = copy screen to buffer." as an argument. (Like SetDraw) (Have not tested BlitLines, or BlitArea)

Here is a test program I quickly made to show this in effect:

Code:

[i]TEST
det(0
det(5,55
Pause
det(9,1
det(5,224
Pause
det(11,1
Pause
det(1


The program first sets up the canvas with "det(0" ,
then it fills the screen with a light blue-ish color and waits for you to hit enter.
Once you hit enter, the next command, "det(9,1 " forces the command after it, "det(5,224" to draw it's red-orange color to the buffer. Visibly, nothing happens, the screen is still light blue because the red-orange was drawn to the buffer.
Hitting enter again then copies the buffer to the screen, with the "det(11,1" command. Now the screen shows the red-orange color.
The documentation says "1 = copy screen to buffer " but here we see it doing the opposite with the "det(11,1 " command.

Again, the inversion of "0 = copy buffer to screen, 1 = copy screen to buffer." seems to only be the det(11 command, as this example also shows det(9 working as intended.
This is just incorrect ICE documentation. It specifically says here the proper usage:

http://ce-programming.github.io/toolchain/graphx_8h.html#a0f00677f4368b000e110e8d4b7b9bd6d

Hope this helps Smile
Ah, thanks for the catch! Smile One day I need to rewrite the documentation.pdf and commands.html, because I'm not satisfied about both.
Wow, that makes sense, because I was having trouble with 1 and 0 seeming not meaning the same thing
I'm sure there is an absolutely overwhelming amount of feature requests already, so I'll keep my list short. These are just some things that would save tons of time and space.

    getBasicVar( and setBasicVar( for Strings and/or Lists: We can all agree that gBV( and sBV( are most useful for game saves, and data saving in general. This feature is critical to a decent game. However, when exporting or importing a large file through ICE (such as a saved sprite) It can take ages to translate a list element into an int, export it, run a BASIC program to put that into an OS list/string, go back to the ICE program, and repeat until all data is sent.

    getPixel(: This command would be so useful it would almost be cheating. It would eliminate the need for about 2/3 of the vars I set during an ICE program. it's essentially like having an instant-access list that is comprised of the entire screen's XlibC color values. Think of the possibilities!

    Compiler Goto Error: Don't get me wrong, It's quite nice for ICE to tell me when and where there's a syntax error in my code, but then I have to scroll all the way to it while counting. Having a nice "Goto Error" button in the compiler would save loads of time, especially for a very long program.


EDIT: Somebody wants you to include pointers Razz
If you included support for void style pointers; you could solve the above two issues easily and from there add support for many more fun options Razz
Bug report:

Sometimes, the program name will not be displayed while editing an ICE program, and I'm linking it to either the custom "tokens", or the [trace] helper.
Hey PT_ just noticed it's been awhile since the last update on how the C version is going. I am (and I think quite a few others) are getting really excited about this...
CalcMeister wrote:
    getBasicVar( and setBasicVar( for Strings and/or Lists: We can all agree that gBV( and sBV( are most useful for game saves, and data saving in general. This feature is critical to a decent game. However, when exporting or importing a large file through ICE (such as a saved sprite) It can take ages to translate a list element into an int, export it, run a BASIC program to put that into an OS list/string, go back to the ICE program, and repeat until all data is sent.

Maybe, especially lists is a lot harder, since ICE only supports integers, and the OS has floating point numbers. Strings would be possible as well, though.

CalcMeister wrote:
    getPixel(: This command would be so useful it would almost be cheating. It would eliminate the need for about 2/3 of the vars I set during an ICE program. it's essentially like having an instant-access list that is comprised of the entire screen's XlibC color values. Think of the possibilities!

Due to the structure of C functions in ICE currently, that's impossible, sadly. I can make a 'hack' that this works, and you could store it to a variable, i.e. "det(7,X,Y->B". No expressions with det( though, that's gonna be added in the C version.

CalcMeister wrote:
    Compiler Goto Error: Don't get me wrong, It's quite nice for ICE to tell me when and where there's a syntax error in my code, but then I have to scroll all the way to it while counting. Having a nice "Goto Error" button in the compiler would save loads of time, especially for a very long program.

This was already added, but since some programs crashed while opening the program editor (especially the archived programs Rolling Eyes ), I removed it. Need to make the code cleaner and then try it again, though.

CalcMeister wrote:
EDIT: Somebody wants you to include pointers Razz

Somebody = Mateo? If not, tell me! Razz

_iPhoenix_ wrote:
Bug report:

Sometimes, the program name will not be displayed while editing an ICE program, and I'm linking it to either the custom "tokens", or the [trace] helper.

It's probably the [trace] helper. I *did* notice it a few times, but since the bug doesn't occur always, I have a hard time finding the bug.

CodertheBarbarian wrote:
Hey PT_ just noticed it's been awhile since the last update on how the C version is going. I am (and I think quite a few others) are getting really excited about this...

Vacation was taking my time, but the C version is going rather well. I'm currently busy with implementing integer types and pointers. Not sure when it's ready though, since school starts as well, this week. Sad
So I am trying to use the getkey(KEY) command in the documentation and I am using the code:


Code:

[i]T
While not(getKey(9))
If getKey(54)=1
Disp "Works"
End
End


Based on the keycodes in the ICE zip file, 9 should be [enter] but the calculator sees it as [x]. None of the numbers return the right key. For example, when I use key numbers 50-57, the calculator always reads those as [trace]. Please help me see what am I doing wrong in my code.
Seems I already fixed that bug, but didn't update the zip in the Archives Sad
Updated it, and you can grab the latest version here:
https://www.cemetech.net/programs/index.php?mode=file&path=/84pce/asm/programs/ICECompiler.zip
Suggestion: add the ability to compile a program for testing/debugging, when you can press [on] to quit the program, unless it is being requested in a getKey routine.
  
Register to Join the Conversation
Have your own thoughts to add to this or any other topic? Want to ask a question, offer a suggestion, share your own programs and projects, upload a file to the file archives, get help with calculator and computer programming, or simply chat with like-minded coders and tech and calculator enthusiasts via the site-wide AJAX SAX widget? Registration for a free Cemetech account only takes a minute.

» Go to Registration page
» Goto page Previous  1, 2, 3 ... 14, 15, 16 ... 31, 32, 33  Next
» View previous topic :: View next topic  
Page 15 of 33
» All times are UTC - 5 Hours
 
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

 

Advertisement