VESA pixel alignment...

Question about which tools to use, bugs, the best way to implement a function, etc should go here. Don't forget to see if your question is answered in the wiki first! When in doubt post here.
Post Reply
JJeronimo
Member
Member
Posts: 202
Joined: Wed Oct 18, 2006 3:29 pm

VESA pixel alignment...

Post by JJeronimo »

Today I wrote some code to use VESA's LFB...

At first, I selected a 24bit video mode but assumed that each pixel was aligned to 32bit boundaries, but it didn't work. After that, I assumed that it was not aligned to 4 byte, and it worked.

Now, I'm scared! If I select a mode with 15-bit color depth, can I assume any special alignment, or am I doomed to pack the bits all over the frame buffer?!

JJ
Top
frank
Member
Member
Posts: 729
Joined: Sat Dec 30, 2006 2:31 pm
Location: East Coast, USA

Post by frank »

It is 16 bit aligned. It is just 16 bit mode with 1 less bit for the green. At least thats how the color modes work in Direct X.
Top
JJeronimo
Member
Member
Posts: 202
Joined: Wed Oct 18, 2006 3:29 pm

Post by JJeronimo »

frank wrote:It is 16 bit aligned. It is just 16 bit mode with 1 less bit for the green. At least thats how the color modes work in Direct X.
So the general algorithm to obtain the number of bytes per pixel consist in rounding up the bits per pixel value to a multiple of 8, and dividing by 8, right?

JJ
Top
User avatar
Brendan
Member
Member
Posts: 8561
Joined: Sat Jan 15, 2005 12:00 am
Location: At his keyboard!
Contact:
Contact Brendan

Post by Brendan »

Hi,
JJeronimo wrote:
frank wrote:It is 16 bit aligned. It is just 16 bit mode with 1 less bit for the green. At least thats how the color modes work in Direct X.
So the general algorithm to obtain the number of bytes per pixel consist in rounding up the bits per pixel value to a multiple of 8, and dividing by 8, right?JJ
Yes, except for 16 colour modes and text modes... ;)


Cheers,

Brendan
For all things; perfection is, and will always remain, impossible to achieve in practice. However; by striving for perfection we create things that are as perfect as practically possible. Let the pursuit of perfection be our guide.
Top
Pavia
Posts: 23
Joined: Mon Jun 25, 2007 2:54 pm
Location: Russia

Post by Pavia »

JJeronimo wrote:
frank wrote:It is 16 bit aligned. It is just 16 bit mode with 1 less bit for the green. At least thats how the color modes work in Direct X.
So the general algorithm to obtain the number of bytes per pixel consist in rounding up the bits per pixel value to a multiple of 8, and dividing by 8, right?

JJ
Not, right.
If you bits per pixel value to a multiple of 8, and dividing by 8, then have not round value.
Right.
BitsPerPixel=(BitsPerPixel+7)/8*8;
BytesPerPixel=(BitsPerPixel+7)/8

10Fh - 320x200 16.8M (8:8:8 )
112h - 640x480 16.8M (8:8:8 )
115h - 800x600 16.8M (8:8:8 )
118h - 1024x768 16.8M (8:8:8 )
11Bh - 1280x1024 16.8M (8:8:8 )
The modes can be 24bpp or 32bpp depend on video card. Test bit per pixel.
Top
JJeronimo
Member
Member
Posts: 202
Joined: Wed Oct 18, 2006 3:29 pm

Post by JJeronimo »

Pavia wrote:Not, right.
If you bits per pixel value to a multiple of 8, and dividing by 8, then have not round value.
Right.
BitsPerPixel=(BitsPerPixel+7)/8*8;
BytesPerPixel=(BitsPerPixel+7)/8;
You tell me that it's wrong, but then point me the same solution...

To round a number up to a multiple of x, you do:
num = int( (num+x-1) /x ) *x;

So, my assembly code will be (original bpp value in ax):
add ax, 8-1
shr ax, 3 ;Divide by 8, discarding remainder...

And now I have the bytes per pixel value...
10Fh - 320x200 16.8M (8:8:8 )
112h - 640x480 16.8M (8:8:8 )
115h - 800x600 16.8M (8:8:8 )
118h - 1024x768 16.8M (8:8:8 )
11Bh - 1280x1024 16.8M (8:8:8 )
The modes can be 24bpp or 32bpp depend on video card. Test bit per pixel.
What are those "16.8M"?

JJ
Top
User avatar
Brendan
Member
Member
Posts: 8561
Joined: Sat Jan 15, 2005 12:00 am
Location: At his keyboard!
Contact:
Contact Brendan

Post by Brendan »

Hi,
JJeronimo wrote:
10Fh - 320x200 16.8M (8:8:8 )
112h - 640x480 16.8M (8:8:8 )
115h - 800x600 16.8M (8:8:8 )
118h - 1024x768 16.8M (8:8:8 )
11Bh - 1280x1024 16.8M (8:8:8 )
The modes can be 24bpp or 32bpp depend on video card. Test bit per pixel.
What are those "16.8M"?
That'd be the approximate total number of colours (16777216 seperate colours to be exact).


Cheers,

Brendan
For all things; perfection is, and will always remain, impossible to achieve in practice. However; by striving for perfection we create things that are as perfect as practically possible. Let the pursuit of perfection be our guide.
Top
JJeronimo
Member
Member
Posts: 202
Joined: Wed Oct 18, 2006 3:29 pm

Post by JJeronimo »

Brendan wrote:
JJeronimo wrote:
10Fh - 320x200 16.8M (8:8:8 )
112h - 640x480 16.8M (8:8:8 )
115h - 800x600 16.8M (8:8:8 )
118h - 1024x768 16.8M (8:8:8 )
11Bh - 1280x1024 16.8M (8:8:8 )
The modes can be 24bpp or 32bpp depend on video card. Test bit per pixel.
What are those "16.8M"?
That'd be the approximate total number of colours (16777216 separate colours to be exact).
Right.
I hadn't identified the number, cause in computing I usually consider 1K to be 1024units, even if we talk about colors...

However, I guess this isn't rigorous...

JJ
Top
jnc100
Member
Member
Posts: 775
Joined: Mon Apr 09, 2007 12:10 pm
Location: London, UK
Contact:
Contact jnc100

Post by jnc100 »

JJeronimo wrote:I usually consider 1K to be 1024units
k = kilo = 10^3 = 1000
ki = kibi = 2^10 = 1024
M = mega = 10^6 = 1,000,000
Mi = mebi = 2^20 = 1,048,576
...

IEEE 1541

but I guess I'm just being pedantic.

Regards,
John
Top
JJeronimo
Member
Member
Posts: 202
Joined: Wed Oct 18, 2006 3:29 pm

Post by JJeronimo »

jnc100 wrote:
JJeronimo wrote:I usually consider 1K to be 1024units
k = kilo = 10^3 = 1000
ki = kibi = 2^10 = 1024
M = mega = 10^6 = 1,000,000
Mi = mebi = 2^20 = 1,048,576
Thanksssssssss!

JJ
Top
Post Reply

Return to “OS Development”