Yup yup, that makes sense to me. Anyway, I look foward to a final beta or a final version so I can post news about it..

Well, it's getting really close now. The hardest part left to do before an 'official' release would be the inputting of a name when you get a high score.

/me once again promotes the Doors CS routines such as GUIRTextLineIn. Best of luck writing such a routine, how about just an initials spinner? Those are very easy to write

I wish I could use that if only I could change the graphics to match with my popup window...
I suppose I could do that, it's just not very user-friendly in my opinion. But I've been thinking about it and my idea was to do it very much like you do it, with a lower/uppercase/numerals switch and just using the keypad. But a routine that does that with debouncing incorporated into that would be quite hard to write indeed I guess and perhaps just not worth it memory-wise.

Yeah, let me not even start in about how long that routine took to get right. And you can use it on your current popup window if you want; the Doors CS GUI stack would allow that if you rendered your popup window, then pushed a GUIRNull with value $FE and a GUIRTextLineIn on top of that.

Even still, there goes Ion and MirageOS compatibility... Don't get me wrong, I appreciate your effort on every aspect here, but I also like to write stuff myself so I'll probably be making a spinner. I'll credit you for that idea, haha!

Cheers! I think I take issue with your basic premise that MirageOS is still worth supporting with Doors CS out in the wild, but to each his own.

I have no idea whatsoever on how many people are using what shell or even what type of calculator for that matter to run their games.
I understand your bias towards DoorsCS (duh), but even if you have 80 percent of all calc users using your shell, I'd still want to give my game to the other 20 as well.

Definitely understandable. The philosophy that I usually take with the games and programs that I write (which as you point out, is because that I have a superobvious bias) is that if the games and programs I write as DCS-only are awesome enough, that it will force people to replace whatever they're running with Doors CS.

Ah, I understand. Well, as it is now, I am not yet hasting to make other versions, before I finish it.

By the way, the bug is back in its full form in the version I have now... Sometimes it screws up the graphics, but mostly it just clears the RAM on my 83+. I applaud you for allowing DoorsCS to run from archive. This way I don't have to resend the program to my calc every time it happens. Still, it has to be removed somehow...

Thanks for the applause. Is the version you have now the same version that we have now in the archives?

No, it's not... I've updated a couple things. I could upload it, though, if you want to have a look.

And it appears that you did indeed upload. Now, shall I just play in normal mode, and the problem should appear?

I've seen it in Classic and Action mode so far, but I assume that that is just because I haven't really tried the other modes. Also, remember that I am using a 83+. I think the error will not appear on any others (at least not the 84+).

I just played Classic mode, made a few moves until I got No More Moves, and came back to the main menu. No crash so far. My emulator is a TI-83+, OS 1.19, for what it's worth.

Emulator... Which one if I may ask? Anyway, I think it needs to be a real calculator for it to show up. Mine is a TI-83+ and it's using 1.19 as well, but it is one with 1.17 originally installed on it - you know, the ones with the faulty LCD driver. And I keep thinking that that might be it.

I'll update my WabbitEmu to 1.19 as well (using 1.16 now) and see if it happens there. So far WabbitEmu has been running without any problems. Still, I think it would only happen on a real 83+.

I thank you for trying anyway!

I'm interested to hear if it is indeed a hardware-calc-only problem, which could indicate it's something that emulators don't perfectly emulate; the most common thing I can think of might be interrupts and the values and results of manipulating interrupt-related ports. I was testing on PindurTI, since that's what I've been using for a lot of my CALCnet testing.