Unfortunately the authors have to update them, you should ask them directly.
We know they're trying to hire people to harden their OS.When was this discovered? I haven't heard about it.
Don't worry, that's not a double post ;)BTW,
Don't worry, that's not a double post ;)BTW,
Do you know about my question?
char buf[20];
sprintf(buf, "%i", thenumber);
The screen is 240x320.So the string is called buf in this example?
Use something like this to convert it to a string:char buf[20];
sprintf(buf, "%i", thenumber);
Then display the string with nRGBlib.
Also, is there a way to save high scores?
FILE * f = fopen("/documents/mygame_highscore.tns", "w+");
char buf[integerSize(highscore) + 2];
sprintf(buf, "%d", highscore);
fputs(buf, f);
fclose(f);
refresh_osscr(); // refresh OS screen so that we can see the created file when we exit the program
int integerSize(int n) {
int i;
for(i = 0; n > 0; n/= 10, i++);
return n
}
I suppose so, but it isn't the most easy thing to do. Maybe someone can make a lib for it :)That would be nice. /me thinks he'll skip high scores for now
I wonder... is self-modifying code possible in Ndless, as in highscores storing themselves inside their respective games rather than external files? I saw that happen often on the TI-83 Plus in the past.
Levak, if you store the data on the end of the tns file, and you can get the size of it using Ndless there should not be any problem.But you will lose highscore on each modification, it was a part of what I meant.
char *fgets(char *str, int num, FILE *str2eam) {
char *str2 = str;
while (num--) {
char c = fgetc(str2eam); //THIS IS THE BUGGY LINE
if (c == EOF) {
*str2 = '\0';
return NULL;
}
*str2++ = c;
if (c == '\n')
break;
}
*str2 = '\0';
return str;
}I Fear that if i do that after formating it will force me to update to 3.2...No reason why it should :)
"3.0.2.1793" dosnt haves anyproblems ammirite...?It has at least two known major problems:
The fgets function seems to have a glitch:Code: [Select]char *fgets(char *str, int num, FILE *str2eam) {
char *str2 = str;
while (num--) {
char c = fgetc(str2eam); //THIS IS THE BUGGY LINE
if (c == EOF) {
*str2 = '\0';
return NULL;
}
*str2++ = c;
if (c == '\n')
break;
}
*str2 = '\0';
return str;
}
The c variable should be specified as an int, not a char -- it looks like the compiler treated the char as unsigned and optimized out the return NULL entirely! Plus, it is possible that an 0xFF character exists in the file, so signed char is not the way to go.
char *fgets(char *str, int num, FILE *str2eam) {
char *str2 = str;
while (num--) {
int c = fgetc(str2eam);
if (c == EOF) {
if (str2 != str)
break;
return NULL;
}
*str2++ = c;
if (c == '\n')
break;
}
*str2 = '\0';
return str;
}Thanks, it's fixed.I'm sorry, if i'm too picky about this, but i think is still there.
sorry about that. Can you tell me if r684 is ok for you?Yes, r684 is fine for me. Thanks.
Hello, I have a "TI-nspire CAS With ClickPad" and OS version # 3.2.0.1219, Boot1 Code Version # 1.0.1.8916 and Boot2 Code Version # 3.0.1.131Downgrade to 3.1
That version of this Ndless I can install, thanks
Why does refresh_osscr() crash on a non-cx in the emulator (on a cx it works)?
The non-CX address may be wrong, I'll check it (once again any patch for bug fixes or suggestions are welcome from anyone willing to contribute :)).btw, i've noticed the same is happenning with the 'srand() and 'rand()' calls. I mean, they work fine in cx and crash in non-cx (at least in the emulator they do). Could you (ExtendeD) please check also these two calls are they are very much used in games. Thanks.
4. Link "libRGB.a" to your project using the "-lRGB" to Nspire-gcc.
Is there a limit to array size?It depends what type of array you're trying to initialize. If you're putting this as a global variable this can be the cause.
When I try to store large map data in an array, it crashes the emulator when it is too big
Also it doesn't recognize bool as a type :PBooleans have been introduced in c99 with a simple enum but are highly unportable since in C, any value is true and 0 is false.
int map[252][40] causes it to crash, but that just may be from something in my code.You can use bkpt() to put a breakpoint and see what line causes the crash (using the emulator and the 'c' command).
int map[36][4][7][10]General note: you should avoid multiple-dimension arrays (especially with such high dimension !), for efficiency reasons. Write your maps as a single-dimension array, and use accessor macros: this will avoid a huge amount of pointers ;)I guess I'll see if int map[10080] works.You may use malloc() if you still have issues
What are accessor macros?
#define WIDTH 100
#define GET(Tab, X, Y) ((Tab)[(X) * WIDTH + (Y))
....
int tile = GET(my_tab, 69, 42);
FILE * f = fopen("/documents/miner/mapdata.tns", "r");
for(j = 0; j < 10120; j++)
fscanf(f, "%d", &map[j]);
fclose(f);
show_msgbox_2b("Title", "Text", "Button 1", "Button 2");Gives that :char filename[256];
show_msg_user_input("Test", "Test this", "Default", &filename);
printf("%s", filename);
free(filename);
return 0;Plop,
I've been encountering some problems with Ndless' UI features. This code :Code: [Select]show_msgbox_2b("Title", "Text", "Button 1", "Button 2");Gives that :
(http://img.removedfromgame.com/imgs/bugNdls.PNG)
And it's basically the same with show_msgbox_3b (displays a dialog box with 3 buttons) ; the labels are "Button 1Button 2Button 3", "Button 2Button 3" and "Button 3".
char button1_16[14];
char button2_16[14];
This explains your problem. Do not make your button text longer than 7 characters (without the \0). char button1_16[(strlen(button1) + 1) * 2];
char button2_16[(strlen(button2) + 1) * 2];
char button3_16[14];
char button3_16[(strlen(button3) + 1) * 2];
Also, this code just crashes nspire_emu :Code: [Select]char filename[256];
show_msg_user_input("Test", "Test this", "Default", &filename);
printf("%s", filename);
free(filename);
return 0;
I think that it's a bug with Ndless ...
int main()
{
char *filename;
if(show_msg_user_input("A", "B", "C", &filename) != -1) free(filename);
return 0;
}Indeed, you don't know its size and putting arbitrary size (here 256) is a bad programming behavior.I don't want to be a nitpicker, but I have to disagree. In a practical context, using "big enough" buffers when dealing with arbitrary-sized strings is in many cases better than hassling around with a bunch of pointers and dynamically allocated memory. Using the latter method complexifies and bloats the code unnecessarily, gives the programmer additional responsibility (gotta compute the size of the data, malloc it, remember to free the memory, etc.), decreases the programs maintainability (as the code for that filename container is scattered around, when modifying bigger chunks better check it doesn't cause any undefined behavior), and generally the whatever academic perfection of the code doesn't outweigh the pain of dealing with such trivial stuff. We're not talking about security-critical government-class programs here, and it's not like there aren't any functions to avoid buffer overflows and whatnot.
This code crashes :It runs fine for me. Update your Ndless (on the handheld) to the latest.Code: [Select]int main()
{
char *filename;
if(show_msg_user_input("A", "B", "C", &filename) != -1) free(filename);
return 0;
}
And I can't find any libndls directory in /ndless/ ... (I use the Ndl3ss SDK)Okay ... in the sources, so here is the sample code :
const char * title = "Title";
const char * msg = "Element";
char * defaultvalue = "default value";
char * value;
unsigned len = show_msg_user_input(title, msg, defaultvalue, &value);
if (len >= 0)
{
printf("%s (%d)\n", value, len);
free(value);
}
else
puts("Canceled");
EDIT : second question on the go : why does libndls's refresh_osscr() crashes ? :banghead:Same, I think your Ndless version on the handheld is not up to date.
I know, but this applies in a context you can't control the length of the string. Here, the popup does not limit the number of characters entered, and at first it was a 256 buffer. Some people complained because it crashes when you enter a 120 chars string, and indeed ... the popup does not limit it. Thus, without having to allocate a 1024 buffer, I prefer using the dynamic length String API the Nspire uses. I think this API is the only one that runs really nicely compared to a lot of things on Nspire development.Indeed, you don't know its size and putting arbitrary size (here 256) is a bad programming behavior.I don't want to be a nitpicker, but I have to disagree. In a practical context, using "big enough" buffers when dealing with arbitrary-sized strings is in many cases better than hassling around with a bunch of pointers and dynamically allocated memory. Using the latter method complexifies and bloats the code unnecessarily, gives the programmer additional responsibility (gotta compute the size of the data, malloc it, remember to free the memory, etc.), decreases the programs maintainability (as the code for that filename container is scattered around, when modifying bigger chunks better check it doesn't cause any undefined behavior), and generally the whatever academic perfection of the code doesn't outweigh the pain of dealing with such trivial stuff. We're not talking about security-critical government-class programs here, and it's not like there aren't any functions to avoid buffer overflows and whatnot.
I'm not saying you should be using statically allocated data for everything (quite the contrary usually), but for string buffers and such, a char buf[BUF_SIZE]; is usually good enough.
I'm using nspire_emu_easy from Ti-Planet, it's a version with Ndl3ss already in it. Do you think it could be the wrong version ?I've never heard of that before and I cannot find any archive having this name on TI-Planet.
And there is a SaveAs popup ? O.o I didn't see it.Yes and No. It is a syscall I did not added to Ndless for the moment as it is part of nFrame, still under development.
I'm using nspire_emu_easy from Ti-Planet, it's a version with Ndl3ss already in it. Do you think it could be the wrong version ?I'm pretty sure that's the all-in-one nspire_emu package I made. I think it has an older version of Ndless installed (that did have some issues), so I suggest you download the newest Ndless, install it on the emulator, and save the flash image.
Do I need to get ndless 3.1, and should I?Ndless 1.0 and 1.1 only work on the oldest OS 1.1 versions, and those are only for the Clickpad models. For a CX / CX CAS calculator, you need OS 3.1.0.392 and Ndless 3.1.
Do I just download os 3.1 from tiplanet and then follow the nspire 3.1 instructions?Depends on the manufacturing date and hardware revision of your calculator. It's a group of 1 letter, 4 figures and 1 letter written on the back, at the right of the serial number.
Is there any particular order that I should install nlaunch and ndless in?Yes, it's described in the instructions :)
Do I install nlaunch or nlaunchy?nLaunchy is the newer, community-maintained version of nLaunch and nLaunch CX, which were made by unknown author(s).
Is there any way to find all user uploaded games for nspire cx ndless (and can I use games for the regular nspire ndless on the cx?)?In the Omnimaga, ticalc.org and TI-Planet archives. There's also a site by compu, but I'm not sure how to date it is.