Done!

I finally managed to port SDL_image. The relocation issues were so frustrating I today decided to hardcode the cancerous part. Here's nSDL drawing the OpenBSD fish loaded from a GIF file:



Using the freshly ported SDL_image (which can be downloaded, as usual, here), you can now load images of the following formats: GIF, LBM, PCX, PNM, TGA and XCF.

You should now be able to use much less memory to store those pictures as opposed to using BMP (or the in-code NTI format). GIF images are usually at least 4 times smaller than their BMP counterpart.

Yeah, worst thing there's no logic at all behind the issues I'm having. And I've done some serious debugging before, but this just takes it all to a whole new level.

Fuck me. For last few hours I've been trying to port SDL_image, and it has been one of the most frustrating experiences ever. I fucking hate debugging, someone please shoot me in the head, blow my brains out and burn my body with fire. ExtendeD I really would like you to fix the relocation issues, it's unbelievably horrible (but I suppose you know more than well enough the feeling I'm feeling right now, so no hurry). I even managed to film the whole process (actually now, the video begins after about 2 hours of debugging). Watch it. Feel my pain. We need to raise awareness!



I will never ever work as a code monkey in some gigantic corporation, I'd kill myself  before that. Debugging some mysterious black magic is not my thing. I don't mind coding but FUCK this is crazy my brain is completely fucked and I need to hit some boxing bag to release the tension inside me. My brain has been literally violated with the force of a thousand supermassive black holes. Goddamn global static arrays of structures with constant fucking strings and pointers to functions. The issues I'm having go against all the laws of physics and the behavior fluctuates faster than a Thai whore's mouth in Pattaya. It doesn't even have anything to do with the would-be complexity of the code. Even porting SDL and fixing its own flock of relocation issues wasn't this annoying. It should be a war crime to make me go through this kind of shit. If C was a person it would have been considered rape. Please ban me from the Internet for such vulgar terminology, tell me I'm a bad boy for saying no-no words and traumatizing the 7-year-old boys here. Give me a ticket, tell me I need to watch my language. Hack my IP, call the cyber cops, neg me to oblivion, tell your mom, I don't give a fuck. I feel like punching kittens right now.

Alright, calm down hoffa, everything's alright.

ALSO, I HATE THIS SHITTY LOW RESOLUTION ON MY LAPTOP.

• What is nSDL?
  nSDL is a port of the widely used, cross-platform and open source SDL graphics library for the Ndless-fueled TI-Nspire.
  
  
• What is SDL?
  According to Wikipedia, "SDL acts as a thin, cross-platform wrapper, providing support for 2D pixel operations, sound, file access, event handling, timing, threading, and more." It's basically a graphics library with event handling, timing and other nice little things.
  
  
• Where can I download nSDL?
  On the nSDL website.
  
  
• How do I install/use nSDL?
  Copy lib and include folders' content in the nSDL package to the respective folders in your Ndless SDK folder. To build your nSDL programs, use and adapt the Makefile.sample file.
  
  
• Is there some nSDL wiki?
  Yeah.
  
  
• Which version of SDL is nSDL based on?
  1.2.15.
  
  
• Do I need to recompile my code for each machine separately?
  No, compile it once and it'll work on any of the calculators. If however it doesn't, check out some other part of the code isn't causing the trouble.
  
  
• What functionalities of SDL are/aren't supported?
  Supported: video, events, SDL_GetTicks()
  Not supported: audio, threads, timers, mouse
  
  
• Will there ever be mouse support?
  Most probably yes. There was partial mouse support in an earlier nSDL version, but it was removed in a later release because the behavior on CX and non-CX calculators was different, making it desperately frustrating to debug as I only have a Touchpad.
  
  
• Are SDL_image or SDL_gfx supported?
  Yes, both have been ported and can be found here.
  
  
• How do I draw text?
  Using the included nSDL-exclusive functions. First load the font with whatever color you want using nSDL_LoadFont(), then draw your stuff with nSDL_DrawString(), and finally free the font using nSDL_FreeFont(). Simple as that. Here's an example:
  
  nSDL_Font *font = nSDL_LoadFont(NSDL_FONT_TINYTYPE, 255, 0, 0);
  nSDL_DrawString(screen, font, 10, 10, "I love your string, baby.");
  nSDL_FreeFont(font);
  
  For more information about the different fonts and available flags, check this page out.
  
  
• What are those nSDL-exclusive functions?
  Here's a list of them.
  
  
• Can I draw text in different sizes?
  No.
  
  
• How do I use cos(), sin() and other mathematical functions?
  Using the ported fdlibm library which can be found here. Just include libfdm.h in your code. It implements all of the functions defined in math.h. Install it the same way as you'd install nSDL. Remember to link fdlibm using the -lfdm switch.
  
  
• Can I draw text in different sizes?
  No.
  
  
• Where do I see which key is mapped to which SDL key value?
  Check out the last part of this file for the latest keymap.
  
  
• Does it run Crysis?
  Yes, the latest tests show that nSDL runs Crysis at about 47 FPS in ultra (note to Fox News: the TI-Nspire doesn't actually run Crysis at 47 FPS). nSDL has been designed with performance in mind.
  
  

Tiny update that handles arrow keys better (diagonal arrow keys supported) and maps the Nspire's touchpad click button to SDLK_KB_ENTER. Those were supposed to be included in an update with functional mouse support, but as it's been taking so long and can't test my code on an actual TI-Nspire (and probably won't for long), I decided to push those changes to master so they're outta the way.

(Download's on the website, as usual)

Isometric 3D would look extremely weird and is not at all suitable for first person games.

A few things: you're using dynamic allocations enormously, you should use static allocations a lot more. They're generally safer, easier to handle and makes your code more readable and maintainable. Only use malloc if the dynamic solution is actually better (i.e., when you know the size of your data structure, go for static allocation). In your case why not just have int activeShot[128] instead of activeShot = malloc(128 * sizeof(int)), for instance? It saves you from redundant memory management and avoids all the hassles of it.

Also there's no need to allocate memory for the screen surface, SDL takes care of it. SDL has a pretty good event system, you should use it for your key handling.