Religion has absolutely nothing to do with Omnimaga and should be completely and in every way left out of here. And that means no special privileges for anyone. I've been enough on the Internet to know any "discussion" or "debate" on religion eventually turns into a massive shitfest (my yesterday's flamebait quote was there to release the Kraken and end the vicious circle of retarded arguments and one-way thinking; it thankfully got locked quickly). It's like the YouTube comment section all over again when it comes to religion and the Internet. If something does not fit with one's beliefs on Omnimaga or any other nonreligious place, then he or she must turn away or leave.

Actually this'll be the last update for today. On the previous screen you can see that gradient, but it only shows 7 colors and it doesn't seem to be consistent. That's because SDL's palette color mapper is crap (or not suited for 4-bit displays), so I decided to get completely rid of the palette and replace the color mapper code by a one-liner. It should be faster, much better, and should simplify and speed things up generally as all the bytes in the screen buffer are already within the 0-15 range. I'm not entirely sure that it won't cause any issues later (not sure how SDL deals with blitting surfaces with different formats etc.), but currently it seems to be working well, and here's the result (compare with the previous one, it's the same code for the gradient) (oh, also notice odd coordinates work well):



Here are the basic things I still need to do before we have a first beta version of SDL for the TI-Nspire:
- Get the BMP blitting to work
- Fix the events (it currently sends loads of them and at inappropriate moments; also some stuff with the joystick I need to fix)
- Implement the timers system fully
(- Add own function to blit images from array data)

Those are the most important things and the first things that come to my mind.

BTW, on my calculator performance-wise it seems quite fast, it's rather snappy and responsive although it's updating the whole screen every time and a lot more than it should (event system that needs working on). It's a very simple program but it's good to see it runs fast.

And last update today: I wrote a first version of the non-CX video code. It works poorly with anything odd (as opposed to even; doesn't handle single nibbles when copying data), but I have some results:



(Oh, and I got to try it on my own TI-Nspire, which is nice; seems to be working well with that primitive example)

Seems like getting it working on the classical TI-Nspire has been more difficult than I thought. I can feel I'm pretty to close to getting it run, but those palettes, 4-bit pixels and whatnot have been a pain in the ass. This is the sort of thing I've been looking at for the last few hours:

Figuring out the cause of the issue is also always a major buttpain. Even more annoying is to go to sleep and leave it in its current state.

Anyway, on a side note, that whole Ndless-being-blocked-in-3.2 thing gave me quite a blow to the head. I have to admit I'm pretty fucking frustrated; I expected it but didn't think it'd come this quickly. Right now I feel like the work I'm doing is completely useless, and realistically speaking it is. It may take a month (or more) to have a first more or less stable version of SDL, from then on it takes time for people to learn the library/port programs. At that time 3.2 will be out, it'll be the shiny new thing and 3.1 will be outdated. Even I won't feel like staying on an "old" platform developing for a tiny minority. Even if I'd like to, I can't, as I'm getting my ass conscripted for about a year in the Finnish Army (yes I'm Finnish and we have conscription), and after that I'm moving to the UK for my university studies. There I will hardly ever use my TI-Nspire and will most probably develop on other platforms. I will try to finish this thing even for the sake of it (and to be able to add "ported SDL to a calculator" on my CV). Just realized it'll possibly be my last project on a calculator, but we'll see how it eventually turns out.

It shouldn't, no. Weird, works very well on the emulator.
It's still some early code though, I haven't thoroughly tested it (and more generally, the tinspire_test.tns on github doesn't necessarily have to work; I just push the changes when I feel like it). I think I'll write the video driver for non-CX first so that I have a better idea of the behavior on both machines.
Thanks again anyway, I'll look into it more tomorrow.

EDIT: It does try to load a BMP, but I don't think it should stop it from running, as it just returns NULL and moves on. It's normal that it doesn't work when holding the key, that's how events work in SDL. SDL_EnableKeyRepeat() should enable that behavior though, but I'm not entirely sure if it works currently as I haven't fully implemented the timers system (in fact there's only SDL_Delay()).

You're trying it on the classical TI-Nspire I suppose (and hope)? I forgot to mention it but I'm only working on the CX right now (the classical one is another story because of its annoying 4-bit pixels, which requires some special care), and as such it should only work on that calculator (which, funnily enough, I do not own; relying fully on the emulator).

EDIT: I'd appreciate it if somebody could check if the TNS works as it should on their physical CX.

1) None currently, but it's sometimes a bit of a mystery to know whether or not a certain issue is caused by global variables (e.g. I'm currently unable to blit BMPs although reading and loading seems to be working; it takes quite a bit of time to go through the code always having in mind the problem might not be caused by the code itself).

2) Video, events, timers and input (i.e. "joystick") are the main things I'm planning to implement. I haven't looked at audio, but it's not impossible that it'll also be included. EDIT: SDL_image and SDL_gfx shouldn't be too difficult to port.

SDL_DisplayFormat is a practically platform-independent function, so it should already work.