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

hoffa · « **Reply #150 on:** April 03, 2012, 08:37:38 am »

Quote from: Lionel Debroux on April 03, 2012, 08:19:52 am

Quote
8 BPP support for CX (thanks to atiatini for the idea; makes it possible to port 8 BPP programs for the CX),
FWIW, while their screen sucks beyond usability, the Clickpad & Touchpad models do support 8 bpp, as shown by nDOOM

In this case it's software 8 BPP for CX (i.e. if 8 BPP used, the 8->16 conversion is done at the very end), the same way as it's software 8 BPP for Touchpad/Clickpad (8->4 conversion done at the end). I indeed read that it was possible to change the bit depth on the grayscale display, but I suppose the screen'll still only have 16 shades of gray, and the advantages of switching to hardware 8 BPP are limited (not sure how it would behave in weird situations or sudden crashes).

Quote from: Lionel Debroux on April 03, 2012, 08:19:52 am

Quote
many font-related changes (if you're the observing type you can notice one thing on the screenshot below)
Transparency ?

Nope, that should already work with SDL_SetAlpha(). It's non-monospaced fonts (e.g. see "quick"). I acknowledge the font isn't the best to show that, but it wasn't the point either.

Lionel Debroux · « **Reply #151 on:** April 03, 2012, 08:58:00 am »

Quote

but I suppose the screen'll still only have 16 shades of gray,

AFAICT (from watching DummyOS changing colors smoothly enough), the grayscale screen can do 256 shades of gray... or at least, it can do more than 16 shades

Quote

and the advantages of switching to hardware 8 BPP are limited (not sure how it would behave in weird situations or sudden crashes).

(emphasis mine)
Indeed, this can be used as an argument against hardware 8 bpp...
The normal 320 x 240 x 4 bpp screen area is stored in SRAM, but the 320 x 240 x 8 bpp area cannot be stored there, it needs to be stored in SDRAM. Upon exit, one has to make sure that the memory is freed and the screen base address pointer is restored, otherwise funny stuff will occur.
And reading from display memory stored in SDRAM might have some unwanted effects (-> critor ?).

The case for hardware 8 bpp mode, on Clickpad & Touchpad, would be to reduce the risk that Clickpad & Touchpad users are left in the cold for SDL-based programs.

Quote

It's non-monospaced fonts

Oh yeah, that's good

hoffa · « **Reply #152 on:** April 03, 2012, 09:18:06 am »

Quote from: Lionel Debroux on April 03, 2012, 08:58:00 am

AFAICT (from watching DummyOS changing colors smoothly enough), the grayscale screen can do 256 shades of gray... or at least, it can do more than 16 shades

If that's true, I might be more inclined to try 8 bpp out.

Quote from: Lionel Debroux on April 03, 2012, 08:58:00 am

The normal 320 x 240 x 4 bpp screen area is stored in SRAM, but the 320 x 240 x 8 bpp area cannot be stored there, it needs to be stored in SDRAM. Upon exit, one has to make sure that the memory is freed and the screen base address pointer is restored, otherwise funny stuff will occur.
And reading from display memory stored in SDRAM might have some unwanted effects (-> critor ?).

If I have some documentation and facts I can rely on, it should be very possible to implement. SDRAM should never be read anyway, in nSDL's case all reads go through the buffer. I could just write some experimental code through a bunch of #if's like I've been doing until now and add a static library to the list (libSDL-TC8.a or something) for those who want to try it out. It might very well be that the advantages of having a 8 bpp display outweight the disadvantages of the rare occasion when the calculator explodes because of access violations.

Quote from: Lionel Debroux on April 03, 2012, 08:58:00 am

The case for hardware 8 bpp mode, on Clickpad & Touchpad, would be to reduce the risk that Clickpad & Touchpad users are left in the cold for SDL-based programs.

How so left in the cold?

Lionel Debroux · « **Reply #153 on:** April 03, 2012, 09:25:55 am »

Quote

SDRAM should never be read anyway, in nSDL's case all reads go through the buffer.

Yup, but nSDL itself has to read from the buffer stored in SDRAM, and there might be some quirks in doing so. I vaguely remember something about that, but I'll stop talking about that matter until someone more knowledgeable than I am (e.g. critor, on that aspect) has a more definitive input

Quote

How so left in the cold?

8 bpp is much more usable than 4 bpp for graphics. IMO, chances are that more people will care about Clickpad & Touchpad compatibility if they support 8 bpp, than if they support only 4 bpp

DJ Omnimaga · « **Reply #154 on:** April 03, 2012, 11:59:25 pm »

Quote from: hoffa on April 03, 2012, 08:00:18 am

Just to give you a quick heads up, the next version--0.2.0--and rather major step, will have numerous changes. Among those will be mouse support, 8 BPP support for CX (thanks to atiatini for the idea; makes it possible to port 8 BPP programs for the CX), many font-related changes (if you're the observing type you can notice one thing on the screenshot below) and a lot of under-the-hood modifications (performance, stability, etc.). Also a few surprises. Quick screenshot to show 16 BPP and palettized 8 BPP on CX (actually it's just an excuse to give the thread some color):

Wow nice. 8 bit support would be great for game sprites especially, to save space. ALso for large images on the small screen, if you use dithering, the quality drop won't be as noticeable.

Also the mouse seems nice. How is the touchpad sensitivity? I know the cursor of the one in the OS stutters a lot when I move the finger around, but maybe it was the OS fault.

hoffa · « **Reply #155 on:** April 05, 2012, 05:18:05 am »

Okay I tried switching to 8 bpp using nDoom as my main source of information. I then decided to draw--what I thought it would be--a gradient, just copying bytes from lower to higher, and this is what I got (actual calc and on the emulator):

Only the first 16 pixels show a gradient (the usual 16 "colors"), after that it's just a clusterfuck of seemingly random shades of gray. I thought it would be darker to lighter from 0 to 255.

In other news, atiatini ported some plasma demo effect, here's the result:

And on CX using the 8 bpp mode:

Quote from: DJ_O on April 03, 2012, 11:59:25 pm

Also the mouse seems nice. How is the touchpad sensitivity? I know the cursor of the one in the OS stutters a lot when I move the finger around, but maybe it was the OS fault.

Seemed pretty fine to me when I tried, no stuttering as far as I could notice.

calc84maniac · « **Reply #156 on:** April 05, 2012, 08:28:11 am »

You'd have to fill the palette RAM with 256 grayscale color values, each from 15 (black) to 0 (white).

DJ Omnimaga · « **Reply #157 on:** April 05, 2012, 08:49:36 am »

Wow that looks great.

When this is available for download, I need to try the color version to see how this looks like on my CX (assuming a demo of the above is made available?).

atiatinini · « **Reply #158 on:** April 05, 2012, 09:03:07 am »

Quote from: DJ_O on April 05, 2012, 08:49:36 am

Wow that looks great. When this is available for download, I need to try the color version to see how this looks like on my CX (assuming a demo of the above is made available?).

Of course!

CX:
http://www.mediafire.com/?7omfqojuxjjrpp2
Touchpad/Clickpad:
http://www.mediafire.com/?ax8dyd9xqgjb2z5

And here's the source (just ignore my dirty random generator at the end):
http://pastebin.com/gqjXDTBw

Also, please note that the actual code that generates the plasma effect was not made by me, this is just a port of a demo available here.

DJ Omnimaga · « **Reply #159 on:** April 05, 2012, 09:15:03 am »

Oh cool to hear there's one.

Also welcome to the forums if I didn't welcome you already (I don't remember since I was less active at one point and there were many posts per day I missed)

Now students can hallucinate without the use of drugs.

hoffa · « **Reply #160 on:** April 05, 2012, 09:56:11 am »

Quote from: calc84maniac on April 05, 2012, 08:28:11 am

You'd have to fill the palette RAM with 256 grayscale color values

Oh of course, I was thinking about that.

Quote from: calc84maniac on April 05, 2012, 08:28:11 am

each from 15 (black) to 0 (white)

So there after all is only 16 colors available? My main reason to even try to switch to 8 bpp is for some extra shades of gray, the speed increase is negligible.

calc84maniac · « **Reply #161 on:** April 05, 2012, 02:27:20 pm »

Yeah, only 16 shades (well, really 15 since both colors 14 and 15 are solid black). But even the CX screen only supports 32 shades of gray

However, I think a 256-entry palette mode could still be useful, as nDoom used that even in its original grayscale form.

hoffa · « **Reply #162 on:** April 05, 2012, 02:50:12 pm »

Quote from: calc84maniac on April 05, 2012, 02:27:20 pm

However, I think a 256-entry palette mode could still be useful, as nDoom used that even in its original grayscale form.

In what way could it be useful? In its current form SDL uses a 256-color software palette; the result is exactly the same whether using software or hardware palette.

calc84maniac · « **Reply #163 on:** April 05, 2012, 05:39:08 pm »

A hardware palette will always be faster than a software palette (on the CX you won't have to waste the memory of expanding into a 16-bit buffer either)

DJ Omnimaga · « **Reply #164 on:** April 05, 2012, 05:40:02 pm »

How many colors total does the CX support? Was it 65536 like the PRIZM?

Also, the above, at least for now, justifies buying a CX over the PRIZM. Now with a CX, you can feel the effects of hallucination without having to buy drugs, so you save money!

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

hoffa

Re: nSDL (0.1.4 beta)

Lionel Debroux

Re: nSDL (0.1.4 beta)

hoffa

Re: nSDL (0.1.4 beta)

Lionel Debroux

Re: nSDL (0.1.4 beta)

DJ Omnimaga

Re: nSDL (0.1.4 beta)

hoffa

Re: nSDL (0.1.4 beta)

calc84maniac

Re: nSDL (0.1.4 beta)

DJ Omnimaga

Re: nSDL (0.1.4 beta)

atiatinini

Re: nSDL (0.1.4 beta)

DJ Omnimaga

Re: nSDL (0.1.4 beta)

hoffa

Re: nSDL (0.1.4 beta)

calc84maniac

Re: nSDL (0.1.4 beta)

hoffa

Re: nSDL (0.1.4 beta)

calc84maniac

Re: nSDL (0.1.4 beta)

DJ Omnimaga

Re: nSDL (0.1.4 beta)