Can't display pixel

[GUGDUN]

I've decided to create a graphical operating system and at the first steps I met a huge problem. I'm setting video mode with GRUB2(1024x768 32 bpp), but can't draw pixel. I'm doing it like this:

Code: Select all

uint32_t color;
uint8_t *video = (uint8_t*)framebuffer_address;
int where = x * (framebuffer_bpp / 8) + y * framebuffer_pitch;
video[where]  = color;
video[where + 1] = color >> 8;
video[where + 2] = color >> 16;

With the changing of X and Y coordinates only color of pixel changes, but pixel displayed in the upper left corner of the screen.
I'm using color in 0xRRGGBB format. Is it right?

[osdever]

My code, Gugdun Frumin
Really - first you need to use unsigned int for where - normal int may overflow and do something wrong.
Show us your screenshots and full code, please.

[glauxosdever]

Hi,

My code, Gugdun Frumin
Really - first you need to use unsigned int for where - normal int may overflow and do something wrong.
Show us your screenshots and full code, please.

No, you should best use size_t for this.

What happens when you hardcode for example 100 and 200 for x and y respectively? Is the pixel still in the upper-left corner? Are you sure that x and y are really nonzero?

Code: Select all

(framebuffer_bpp / 8)

If framebuffer_bpp is 15, then this statement evaluates to 1, while 2 bytes are occupied in these modes. This is probably unrelated to the problem, though.

Code: Select all

((framebuffer_bpp + 7) / 8)

This should fix the issue easily.


Regards,
glauxosdever

[SpyderTL]

Try replacing your variables with hard-coded numbers that you know are correct, temporarily. This will tell you whether the problem is on the software side (pixel offset calculation) or the hardware side (wrong address, wrong pitch, etc.)

My guess is that your framebuffer_pitch or framebuffer_bpp are zero...

[GUGDUN]

Using unsigned char* for video buffer and int for framebuffer_bpp and framebuffer_pitch helped, now all works fine

[Schol-R-LEA]

No, you should best use size_t for this.

That reminds me:
Note to self: The standard Thelema libraries should define at least one counter type specifically for use as definite loop indices, with zero-indexed indices as the default but supporting an optional lower bound for ranged indices. Set it up so that defining an index will silently define an anonymous Integer subtype for the specified index range. I will need to figure out how to default the handling of runtime overflow conditions, though it's probably best to throw an exception - while for the most common use case, this should only come up if there is some kind of memory corruption, dynamically defined ranges will require runtime checks. Include an analysis specializer to detect fixed ranges, to allow type generation and bounds checking to be done at compile time when possible.