Author Topic: OxygenBasic  (Read 9302 times)

Offline Mike Lobanovsky

  • BASIC Developer
  • Posts: 193
    • FBSL
Re: OxygenBasic
« Reply #15 on: December 20, 2013, 05:35:12 PM »
Thanks for the heads up, John, and I guess that's it for tonight. :)
Mike
_________________________
(3.6GHz Intel Core i5, 16GB RAM / 2 x GTX 650i SLI-bridged, 2GB VRAM)

Offline John

  • Forum Support / SB Dev
  • Posts: 1765
    • ScriptBasic Open Source Project
Peacock Plume
« Reply #16 on: December 20, 2013, 06:23:42 PM »
Quote
-- just a simple "( b << 16 ) Or ( g << 8 ) Or r" byte arrangement, which is unlikely; or

The SB SDL_Draw extension module is using 32 bit color by default. I might add another optional argument to the Window() function (title is currently optional) for 8/16/24/32 bit color. I'm not sure why anyone would want to use anything other than 32 bit color. I have never been a fan of backwards compatibility. If you have moved beyond it, forget about it.

Offline Mike Lobanovsky

  • BASIC Developer
  • Posts: 193
    • FBSL
Re: OxygenBasic
« Reply #17 on: December 20, 2013, 07:02:53 PM »
In fact, both 24- and 32-bit color is actually the same as far as color goes. Both use an &HFFFFFF value for color gradients proper. But 24 bits just ignore the &HFF000000 component while 32 bits use it for coding alpha-transparency of pixels. Since most everyday pictures don't have transparent areas, coding only 3-byte color pixels instead of 4 bytes yields a huge saving in size especially in lossy formats like e.g. JPEG. OTOH low-end colors produce yet far smaller files and draw much, much faster than 24 or 32 bits but yield lower color quality (variety).

You'd be surprised how many more color formats are there in Gdi+, OpenGL and DirectX libraries. Dozens of them and each one has its merits and drawbacks.

I was talking about another aspect. Windows stores the B component at &HFF0000, G at &HFF00, and R at &HFF. The corresponding Linux palette might be R at &HFF0000, G at &HFF00, and B at &HFF. That's why we seem to be getting inverse colors in our respective renders. This is because the line color is given not by an RGB() function call which would correct the endianness on the respective platform, but rather by numeric literals "c  = d ^ 2.1" which aren't endian-compensated in any way.

I'm not implying that Linux or Windows are good or bad. I'm saying they may be simply different in this regard. But the good thing is that the both would store alpha-transparency at &HFF000000. :)
Mike
_________________________
(3.6GHz Intel Core i5, 16GB RAM / 2 x GTX 650i SLI-bridged, 2GB VRAM)

Offline John

  • Forum Support / SB Dev
  • Posts: 1765
    • ScriptBasic Open Source Project
Windows may be color blind
« Reply #18 on: December 20, 2013, 07:07:07 PM »
Did I forget to say that I think the SB example looks more like a Peacock Plume?  ;D

Thanks for the extra effort to try to unravel what is going on. Maybe Charles or Armando might have some ideas.


Offline Mike Lobanovsky

  • BASIC Developer
  • Posts: 193
    • FBSL
Re: OxygenBasic
« Reply #19 on: December 20, 2013, 07:35:44 PM »
No, you didn't. The implication was wa-a-a-ay too obvious! :))

But I still admire my 5-pixel wide render too. It looks so pleasantly, er, cacophonic... (had to look it up in the dictionary :) ).

Have a nice night!
Mike
_________________________
(3.6GHz Intel Core i5, 16GB RAM / 2 x GTX 650i SLI-bridged, 2GB VRAM)