Author Topic: nSDL 1.1.1 Anniversary Edition—The Ultimate TI-Nspire Graphics Library (Read 143242 times)

Matrefeytontias · « **Reply #300 on:** January 10, 2013, 01:19:27 pm »

Quote from: t0xic_kitt3n on January 10, 2013, 01:17:59 pm

Quote from: Matrefeytontias on January 10, 2013, 01:11:11 pm
Of course I could, as for every SDL command but since it can be optimized to work together with SDL, why do not ask hoffa ?

Also,
Quote from: t0xic_kitt3n on January 10, 2013, 01:07:15 pm
Yeah, that would be a perfect candidate for tilemapping.
^ I don't understand that (sorry, French inside)
The picture would be good for tilemapping because there are a lot of repeated patterns in there.

Oh okay

And shaders aren't part of the original SDL, but why not make ones for nSDL ? We're not restricted to functionalities already existing in the original lib (see nSDL_LoadImage and others).

hoffa · « **Reply #301 on:** January 10, 2013, 01:40:28 pm »

I have no issues, I get this while blitting the image: (don't mind the fish)

You do understand the surface IMG_Load returns is 8bpp as the GIF is 8bpp?

Matrefeytontias · « **Reply #302 on:** January 10, 2013, 01:41:01 pm »

Yeah, but what's the code you're using ? You told me to use SDL_DisplayFormat, I did so.

hoffa · « **Reply #303 on:** January 10, 2013, 02:00:24 pm »

SDL_DisplayFormat converts the surface to the device's native format, i.e. on a CX it'll be converted to a 16-bit surface, on others it'll be 8 bpp. I think the issue is you're passing 16-bit color to the setpixel function that draws on a 8-bit surface or something. It's difficult to guess without the code.

As for the shaders, although it might be a good idea, it isn't really part of the low-level SDL philosophy, it's too high level without much use. I want to keep nSDL fast and efficient, as a razor sharp robust base for other things, or something.

EDIT: Maybe you should initialize SDL as 8 bpp? nSDL handles 8 bpp on CX, and as you're only dealing with 8 bpp stuff it would maybe be easier to concentrate only on one bit depth?

ruler501 · « **Reply #304 on:** January 10, 2013, 06:11:01 pm »

Maybe base a version of SDL2

* ruler501 hides

In all seriousness though it might be nice to have some form of shaders, but I'm not sure if they would go well with SDL. It would probably be better to have a seperate library for them.
One thing I think could be nice for some people would be to have more example programs illustrating nSDL specific programs and problems that might arise.

hoffa · « **Reply #305 on:** January 10, 2013, 07:15:43 pm »

I actually looked at SDL2, and I've been waiting for a long time for a stable version to come out (even for one PC project I'm working on that uses SDL2). Even when does come out, SDL2 has very little to add to a machine such as the TI-Nspire, expect maybe for the included drawing (lines and whatnot) functions.

As far as example programs are concerned, that's a very good point, and there'll be included sample(s) in the next release.

ruler501 · « **Reply #306 on:** January 10, 2013, 08:05:53 pm »

Quote from: hoffa on January 10, 2013, 07:15:43 pm

I actually looked at SDL2, and I've been waiting for a long time for a stable version to come out (even for one PC project I'm working on that uses SDL2). Even when does come out, SDL2 has very little to add to a machine such as the TI-Nspire, expect maybe for the included drawing (lines and whatnot) functions.

As far as example programs are concerned, that's a very good point, and there'll be included sample(s) in the next release.

yeah I see how SDL2 is more for higher power devices. I don't think there's much added that you can't easily implement as a side part.

Matrefeytontias · « **Reply #307 on:** January 11, 2013, 02:48:05 am »

Quote from: hoffa on January 10, 2013, 02:00:24 pm

EDIT: Maybe you should initialize SDL as 8 bpp? nSDL handles 8 bpp on CX, and as you're only dealing with 8 bpp stuff it would maybe be easier to concentrate only on one bit depth?

Yeah, I can try that, but I don't know how to

hoffa · « **Reply #308 on:** January 11, 2013, 03:41:03 am »

Just initialize SDL with a 8bpp bit depth, i.e. in the SDL_SetVideoMode instead of is_cx?16:8, just use 8.

But quite sure the color issue is just because of some wrong SDL_PixelFormat passed to SDL_MapRGB (first parameter) or something. Your pixel access function should handle different bit depths automatically, and the only way to have strange results is by passing a wrong color.

Matrefeytontias · « **Reply #309 on:** January 11, 2013, 09:38:11 am »

It's kinda strange in fact. If I try to just blit my gif image (exactly the one I attached above) to the screen it's ok :

But if I access it with my getPixel function I get that with 16 bpp :

And that with 8 bpp :

That's kinda strange

hoffa · « **Reply #310 on:** January 11, 2013, 10:13:19 am »

Attach the whole code here, doesn't matter if it's ugly as hell. It's difficult to fix without any code. I'm pretty sure it's either your setpixel function that doesn't work, or that the color value that you're passing to the function isn't of the same bit depth as the surface on which you're drawing.

Matrefeytontias · « **Reply #311 on:** January 12, 2013, 01:04:09 pm »

I attached all that is needed to compile and test the program. But please, you who are watching this topic, don't use any of the code I posted, it's all full of unoptimized stuffs.

hoffa · « **Reply #312 on:** January 12, 2013, 01:56:15 pm »

I quickly looked at the code.

color is taken from bitmap, which is an 8 bpp surface (the GIF, that is).
You then set color on a 16 bpp surface (the screen variable on a CX)
That must be the problem; you're drawing a 8 bpp color on a 16 bpp surface.
I suggest you to either initialize SDL with 8 bpp, or pass bitmap through SDL_DisplayFormat().

Lionel Debroux · « **Reply #313 on:** January 12, 2013, 02:31:42 pm »

8 bpp helps compatibility with Clickpad/Touchpad, although the screen is so bad that the game would hardly be playable anyway on those models, and I'm not convinced that we need much more than 256 colors for a F-Zero game on a platform without hardware acceleration... so I'd suggest using 8 bpp mode as well.

Matrefeytontias · « **Reply #314 on:** January 12, 2013, 03:08:20 pm »

I already attached a pic of the program with SDL initialized in 8bpp mode, it didn't work anymore (green display). Moreover, the use of SDL_DisplayMode(bitmap) takes out all the available memory and throws "SDL : out of memory".

Author Topic: nSDL 1.1.1 Anniversary Edition—The Ultimate TI-Nspire Graphics Library (Read 143242 times)

Matrefeytontias

Re: nSDL 1.0.2—A very fast & robust graphics library

hoffa

Re: nSDL 1.0.2—A very fast & robust graphics library

Matrefeytontias

Re: nSDL 1.0.2—A very fast & robust graphics library

hoffa

Re: nSDL 1.0.2—A very fast & robust graphics library

ruler501

Re: nSDL 1.0.2—A very fast & robust graphics library

hoffa

Re: nSDL 1.0.2—A very fast & robust graphics library

ruler501

Re: nSDL 1.0.2—A very fast & robust graphics library

Matrefeytontias

Re: nSDL 1.0.2—A very fast & robust graphics library

hoffa

Re: nSDL 1.0.2—A very fast & robust graphics library

Matrefeytontias

Re: nSDL 1.0.2—A very fast & robust graphics library

hoffa

Re: nSDL 1.0.2—A very fast & robust graphics library

Matrefeytontias

Re: nSDL 1.0.2—A very fast & robust graphics library

hoffa

Re: nSDL 1.0.2—A very fast & robust graphics library

Lionel Debroux

Re: nSDL 1.0.2—A very fast & robust graphics library

Matrefeytontias

Re: nSDL 1.0.2—A very fast & robust graphics library