[SOLVED] Graphics buffer issues with large "objects"

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
73CN0109y
Posts: 5
Joined: Fri Jul 22, 2016 1:05 am

[SOLVED] Graphics buffer issues with large "objects"

Post by 73CN0109y »

I'm trying to implement a sort of graphics buffer into my OS. Now I'm not doing this the best way, (I'm sure) but just trying to get it working first.
I have an array that holds the ARGB values where each block of 4 represents a single pixel.
Of course the Alpha isn't actually copied into the video memory, but is just used to calculate blending between the color behind.

I have a struct called Object that I'm using to draw the shapes to the screen. This holds the objects size, location, background color, etc.
I re-draw the entire screen every second calling vesa_drawObjects(), which calls the objects_draw() for each of the objects and puts them into the buffer. Then after that's all done vesa_draw simply does a memcpy.

The issue is that for large objects with a size over 100(w)x100(h) it seems to put incorrect values into the vram or object_draw puts incorrect values into pixelData.
For example, with an object of 400x400 and a background color of blue, the top third will be blue then after that it turns white then it's just all random colors.

Here is a screenshot showing that example: http://imgur.com/a/nax6c

Code: Select all

// vesa.h
unsigned char buffer[1024 * 768 * 4]; // This is the buffer
// --

// vesa.c
// Don't shoot for terrible code
void vesa_drawObjects(Object *objs, long len) {
  Object sortedObjects[len];
  sortObjects(objs, sortedObjects, len); // This just re-orders the objects based upon zOrder

  for(int i = 0; i < len; ++i) {
    // ... SNIP ...
    unsigned long bufSize = sortedObjects[i].size.Width * sortedObjects[i].size.Height * 4;
    unsigned char pixelData[bufSize];

    object_draw(pixelData, bufSize, sortedObjects[i]);

    for(unsigned long p = 0; p < sizeof(pixelData) / sizeof(pixelData[0]); p += 4) {
      unsigned long where = (x * (fb_width / fb_xres)) + (y * fb_width);

      // buffer goes RGB but video memory goes BGR so gotta switch it around
      buffer[where + 0] = pixelData[p + 2];
      buffer[where + 1] = pixelData[p + 1];
      buffer[where + 2] = pixelData[p + 0];
      //buffer[where + 3] = pixelData[p + 3]; // Alpha

      // ... SNIP ...
    }
  }
}
// --

// object.c
// More terrible code
void object_draw(unsigned char* buffer, unsigned long bufSize, Object obj) {
    for(unsigned long p = 0; p < bufSize; p += 4) {
        buffer[p + 0] = obj.backgroundColor.R;
        buffer[p + 1] = obj.backgroundColor.G;
        buffer[p + 2] = obj.backgroundColor.B;
        buffer[p + 3] = obj.backgroundColor.A;
    }
}
// --
Oh and just as a quick note this works fine...

Code: Select all

// pseudo code but you get the idea...
for(int y = 0; y < 400; ++y) {
    for(int x = 0; x < 400; ++x) {
        vram[where + 0] = 255;
        vram[where + 1] = 0;
        vram[where + 2] = 0;
    }
}
Last edited by 73CN0109y on Fri Jul 22, 2016 5:20 am, edited 1 time in total.
Octocontrabass
Member
Member
Posts: 5587
Joined: Mon Mar 25, 2013 7:01 pm

Re: Graphics buffer issues with large "objects"

Post by Octocontrabass »

How are you allocating those buffers? It looks like you're using ROM instead of RAM.
73CN0109y
Posts: 5
Joined: Fri Jul 22, 2016 1:05 am

Re: Graphics buffer issues with large "objects"

Post by 73CN0109y »

To what buffers are you referring too? There are a couple buffers there :|
Octocontrabass
Member
Member
Posts: 5587
Joined: Mon Mar 25, 2013 7:01 pm

Re: Graphics buffer issues with large "objects"

Post by Octocontrabass »

The one that looks like it's pointing to ROM is pixelData, but you should know how all of them are allocated.
73CN0109y
Posts: 5
Joined: Fri Jul 22, 2016 1:05 am

Re: Graphics buffer issues with large "objects"

Post by 73CN0109y »

Alright. I've made pixelData use malloc and all works fine now. But I was changing buffer initialization a little and tried to do this:

Code: Select all

// vesa.h
extern uint8_t* buffer;

// vesa.c
void vesa_init(...) {
    // ...
    fb_xres = xres; // 1024
    fb_yres = yres; // 768

    buffer = malloc(fb_xres * fb_yres * 4);
    memset(buffer, 0, fb_xres * fb_yres * 4);
}
... so I could resize the buffer based upon screen resolution. But I get a "... execute outside RAM or ROM..." error. Probably something basic I'm missing here but if I just initialize buffer like

Code: Select all

extern uint8_t buffer[1024 * 768 * 4];
it works fine :?
Octocontrabass
Member
Member
Posts: 5587
Joined: Mon Mar 25, 2013 7:01 pm

Re: Graphics buffer issues with large "objects"

Post by Octocontrabass »

73CN0109y wrote:Alright. I've made pixelData use malloc and all works fine now.
Fixing the symptoms of the problem does not fix the problem. (And where are you getting malloc from, anyway?)
73CN0109y wrote:But I get a "... execute outside RAM or ROM..." error.
This sounds like another symptom of bad memory management. How does your kernel keep track of available RAM?
73CN0109y
Posts: 5
Joined: Fri Jul 22, 2016 1:05 am

Re: Graphics buffer issues with large "objects"

Post by 73CN0109y »

I actually didn't implement malloc. I'm co-making (new word) this with someone. Turns out this is all it does

Code: Select all

void* malloc(int nbytes) {
    char variable[nbytes];
    return &variable;
}
Also I didn't do any of the asm work as I'm just terrible at it and can't get a good handle on it. Don't have any memory management either :| #-o
So looks like I'll wait for that to be implemented and then come back to this. Cheers anyways for the help
onlyonemac
Member
Member
Posts: 1146
Joined: Sat Mar 01, 2014 2:59 pm

Re: [SOLVED] Graphics buffer issues with large "objects"

Post by onlyonemac »

73CN0109y wrote:The issue is that for large objects with a size over 100(w)x100(h) it seems to put incorrect values into the vram or object_draw puts incorrect values into pixelData.
Try to figure out which one it is. Is "it" putting incorrect values in "the vram" or is "object_draw" putting incorrect values in "pixelData"? If it's the former then the bug lies in the routine that "it" uses to write to "the vram"; if it's the latter then the bug lies in the routine that "object_draw" uses to write to "pixelData".

(I'm using quotation marks because it isn't particularly clear from your post what "it" refers to and where "pixelData" is used.)
When you start writing an OS you do the minimum possible to get the x86 processor in a usable state, then you try to get as far away from it as possible.

Syntax checkup:
Wrong: OS's, IRQ's, zero'ing
Right: OSes, IRQs, zeroing
User avatar
Ch4ozz
Member
Member
Posts: 170
Joined: Mon Jul 18, 2016 2:46 pm
Libera.chat IRC: esi

Re: Graphics buffer issues with large "objects"

Post by Ch4ozz »

73CN0109y wrote:I actually didn't implement malloc. I'm co-making (new word) this with someone. Turns out this is all it does

Code: Select all

void* malloc(int nbytes) {
    char variable[nbytes];
    return &variable;
}
Also I didn't do any of the asm work as I'm just terrible at it and can't get a good handle on it. Don't have any memory management either :| #-o
So looks like I'll wait for that to be implemented and then come back to this. Cheers anyways for the help
That code wont ever work at all xD
1. Most compilers fail miserably if the allocation size is not static (known at compile time)
2. This allocates data on the stack
3. Returning from a function CLEARS the stack

=> You access random data on stack and **** up alot of stuff while doing so

Implement a proper malloc function before you play with vesa please, having a working malloc is crucial
73CN0109y
Posts: 5
Joined: Fri Jul 22, 2016 1:05 am

Re: Graphics buffer issues with large "objects"

Post by 73CN0109y »

That code wont ever work at all xD
1. Most compilers fail miserably if the allocation size is not static (known at compile time)
2. This allocates data on the stack
3. Returning from a function CLEARS the stack

=> You access random data on stack and **** up alot of stuff while doing so

Implement a proper malloc function before you play with vesa please, having a working malloc is crucial
Yeah I know. I'm going to wait until a proper memory management system of sorts is implemented before continuing with the vesa stuff.
Post Reply