This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
Messages - Matrefeytontias
Pages: 1 ... 28 29 [30] 31 32 ... 133
436
« on: May 06, 2014, 07:14:10 pm »
I voted 1, and moreover it would be really awesome if you could apply the same change (the economy of one or two flash pages) on an 1.19 OS to put on my TI-83+. I need every flash page you may have.
437
« on: May 06, 2014, 03:32:57 pm »
So epic I hope you'll be able to port it to monochrome Nspires as well, or let someone do it for you (yes this is a proposal)
438
« on: May 05, 2014, 04:15:14 pm »
Ben fais le alors.
Oui non mais bien sûr --' le disassembly c'est pas mon truc hein. Ça requiert un peu plus de skill que ce que j'ai actuellement. Je ne suis pas bien en français, donc excusez-mois si mes questions auraient déjà des responses, au j'avais mal compris quelque chose.
Donc, il y a une methode pour donner 64KB d'archive extra a la calculatrice ti-83+, resistant contre des garbage collects? Ce methode marche aussi sur le ti-84+? Et si, et-il encore resistant aux garbage collects (au contraire du programme nyanmem)?
Il y a une méthode oui, plusieurs même, mais aucune n'est résistante durablement contre les GC. Cette méthode ne marche que sur TI-83+ d'avant 2013.
439
« on: May 05, 2014, 03:50:35 pm »
Je dois pouvoir coder ça sans trop de problèmes, car si la méthode consiste bien à supprimer le swap de l'OS, y'a juste un secteur à effacer. Mais bon, le swap est important pour l'OS, alors bon...
/e : Ca semble plus compliqué que juste effacer le swap semble-t-il...
Ah tiens t'es Français toi ? Et oui, en général effacer un secteur c'est vaaaaachement trop simple pour marcher. Pis il est utilisé par le GC, donc il sera cherché, pas trouvé, puis restauré au moindre GC. Tout ce que ça risque de faire c'est donner 64k d'archive pendant quoi, 20 minutes si on code beaucoup. Je pense pas, mais c'est même possible qu'il soit utilisé pendant les defrags (on sait jamais, avec TI ...). Je maintiens ce que j'avais dit y'a deux ans : il faudrait dumper une ROM "normale" et une ROM avec les 64k ajoutés et étudier les différences. Qui sait, on pourrait voir ce qui change et trouver une manière plus sûre de faire pareil sur d'autres pages (si c'est bien la page le problème).
440
« on: May 04, 2014, 03:31:45 pm »
Yeah well it's not serving me pretty well for instance >_>
441
« on: May 04, 2014, 03:24:36 pm »
Yeah that's what I thought, so it's really weird ; morever I never had this problem before switching to Ndless 3.1 r914 (my CAS prototype must stay with OS 3.1).
442
« on: May 04, 2014, 03:20:56 pm »
Well I guess it won't work although I can't really test, I'm only left with a TI-Nspire CAS clickpad and a TI-Nspire CX CAS (thus touchpad) ROM, and switching keyboards within nspire_emu will make arrow keys non-working within the emu.
I also tried reading diagonals with KEY_NSPIRE_LEFTUP and such, but that didn't work either.
443
« on: May 04, 2014, 03:14:55 pm »
Since hex is a less understandable form of ASM, if you can't get around ASM don't expect anything from hex. Hex is really if you don't have a computer but want to do ASM anyway (like Xeda and I did, but I'm definitely stupid compared to Xeda when it comes to hex (and ASM) programming).
444
« on: May 04, 2014, 03:12:20 pm »
Hola,
So that one is a first for me. I have one program, and nspire_emu only detects multi-arrow-keys presses if it's emulating a non-CX Nspire. If it's emulating a CX one, the last pressed key overwrites the preceding one (like, if I hold right then press up, it'll only understand up).
At first I thought that was only nspire_emu, but testing on real HW from a TI-Planet member (I only have a Nspire CAS, on which it worked well) told me that that wasn't nspire_emu.
So I finally thought that was because of the touchpad (again, some may say). That's what I currently have :
typedef int KeyEvent; // because cleanliness inline KeyEvent getk(void) { return (((isKeyPressed(KEY_NSPIRE_UP) << 1) + isKeyPressed(KEY_NSPIRE_RIGHT) << 1) + isKeyPressed(KEY_NSPIRE_LEFT) << 1) + isKeyPressed(KEY_NSPIRE_DOWN); }
I wrote a small debug wrapper for you to test if you wish :
typedef int KeyEvent; KeyEvent getk(void) { int i; KeyEvent k; while(!isKeyPressed(KEY_NSPIRE_ENTER)) { k = (((isKeyPressed(KEY_NSPIRE_UP) << 1) + isKeyPressed(KEY_NSPIRE_RIGHT) << 1) + isKeyPressed(KEY_NSPIRE_LEFT) << 1) + isKeyPressed(KEY_NSPIRE_DOWN); for(i = 3; i >= 0; i--) printf("%d", (k >> i) & 1); printf("\n"); SDL_Delay(1000); } return k; } Look at the console while you press keys ; [enter] to quit.
Any idea ?
446
« on: April 29, 2014, 06:15:44 pm »
What do you mean "all the engines out there" ?
What do you mean 'What do you mean "all the engines out there" ?' ? Even just you have at least 4 engines (like full Axe, full ASM, full vertices and full faces or something)
Hum it's quite a compliment from you to call these "engines" (Vertex3Dlib, ThreeDee, AxeJh3D and AxVectors respectively). They are more like sets of functions (actually like the original Juha3D). You've just been pwned.
Ooooow yeah, dat useful post. ben_g : what I wondered a lot was : "is detecting occlusion slower than the actual stupid drawing ?" and it appeared to be a good question. Actually what I was saying is that instead of trying to make a full fledged engine, a per game optimized engine is better because smaller and faster since it only has the features you need and it's part of your code, not a library.
I agree.
447
« on: April 29, 2014, 02:52:35 pm »
What do you mean "all the engines out there" ?
448
« on: April 29, 2014, 02:29:26 pm »
Well, in my opinion that's pretty much everything that can achieve decent speed, I mean an engine unusable outside of its particular context. But it can be done.
449
« on: April 29, 2014, 07:17:32 am »
Hum. I call that powerful, even if it's Nostromo by benryves and not Aether3D by qarnos.
450
« on: April 29, 2014, 06:04:00 am »
If that's of any use to anyone, here is a signed AHL = AHL / DE routine - I think it's pretty optimized (70 bytes) :
sDiv2416: xor d push af xor d ld b, a jp p, divdPos xor a sub l ld l, a ld a, 0 sbc a, h ld h, a ld a, 0 sbc a, b ld b, a divdPos: bit 7, d jr z, divrPos xor a sub e ld e, a ld a, 0 sbc a, d ld d, a ld a, b divrPos:
push hl pop ix ld hl, 0 ld b, 24 divLoop: add ix, ix rla adc hl, hl sbc hl, de jr nc, $ + 4 add hl, de ; jp nc, xxxx ; it works because the carry can not be set and "inc ix" is 2 bytes .db $D2 inc ix djnz divLoop
push ix pop hl ld b, a pop af ld a, b ret p xor a sub l ld l, a ld a, 0 sbc a, h ld h, a ld a, 0 sbc a, b ret
Pages: 1 ... 28 29 [30] 31 32 ... 133
|