flat assembler
Message board for the users of flat assembler.

Index > MenuetOS > Graphics in Menuet

Author
Thread Post new topic Reply to topic
jason



Joined: 30 Nov 2003
Posts: 8
Location: germany
jason
Can anyone tell me, why Menuet uses misaligned RRGGBB color byte format, especially with images?

I ask this regarding the current API implementation.

- At first, this data format is misaligned (3byte). For some reasons this is not really clever.
- Second, alpha is not supported. Byte one could be easily used for alpha byte. So we could implement semi-transparency as a generic principe for API drawing.
- Third, also windows and other drawing elements could be implemented in this way, if there was a well designed basic color format for the OS / API. Byte 1 is actually used for several (additional) flags with different API functions. This is not ideal and very confusing.
We should have a properly aligned 32bit color data format with the 4 bytes in the form: AARRGGBB, where AA is reserved for alpha byte (semi transparency). This also would simplify the access of new 32 bit portable graphics formats, like PNG od JEPG2000 and so on.

The only way to do some advanced graphics at the moment is to directly access the driver or doing some (unoptimized) tricks, like the "transparent window example application".

I think, before we develop some special applications, we should prepare a usable graphics/drawing interface to the API with a standardized general color format and then and a basic set of generic interface controls, like sliders, editfields and -boxes, trackbars, optionfields and so on, based on 32bit color. At the moment each developer has to invent the wheel new each time.
At least we need something like an API controlled draw context handling for windows and a well designed iterface API for easy access by application developers. The current state, with transfering images to window contents is not satisfactory. Also using simpe buttons for all thinkable UI access is somehow "primitive".

We actually do the second step before the first. We develop several new applications based on very raw user interface elements. This is dangerous, because ineffective and tends to user interface chaos, I think.
.

Excuse my english, I am not a native englisch speaker.
Post 30 Nov 2003, 16:36
View user's profile Send private message Reply with quote
Bitdog



Joined: 18 Jan 2004
Posts: 97
Bitdog
I'm no MeOS expert, but
REPZ OUTSB
REPZ INSB
will load a palette practicly instantly if there is no white space (zero bytes) in the array. (like a Dword holding 3 bytes does.)
LODSD seems quicker to load the needed 3 RGB bytes, but load to what?
Nothing that uses the palette can use it in that form ?
If it's a file being loaded, "align 4" each RGB doesn't matter.
other than is slows down the load due to the fact that it's 1/4+ bigger.
The nitti gritti of asm coding that uses 4 byte Dwords to hold the 3 RGB bytes
is that it has to shift, inc, mov, loop, or other garbage that REPZ OUTSB doesn't do.

Maybe that's the reason, a RGB color array is best stored in 3 byte chunks.

PS, I'm still looking for a general help.txt file for newbee's, plz.
Post 19 Jan 2004, 14:09
View user's profile Send private message Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  


< Last Thread | Next Thread >
Forum Rules:
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You can attach files in this forum
You can download files in this forum


Copyright © 1999-2020, Tomasz Grysztar. Also on GitHub, YouTube, Twitter.

Website powered by rwasa.