change of vesa buffers

[grenders22]

Code: Select all

memcpy(screen, system.framebuffer, screen_height * screen_pitch);

I fill the back buffer. After I copy it into video memory, the first byte that issued vesa.

Code: Select all

typedef struct mode_info_block {
/*...*/
  uint32_t physbase;
/*...*/
}mode_info_t;

Can I change the first byte of vesa, so that the back buffer becomes a video memory? Now I see on the screen how the copying from the back buffer to the video memory occurs. That is, flicker is visible.

PS Sorry for broken English, it's all Google)

[Wukl]

I think you want to implement page flipping? In that case these threads could help:

Page flipping in vbe
VGA hardware double buffering

[grenders22]

I think you want to implement page flipping?
viewtopic.php?f=1&t=22128

Yes, indeed one of the links raises the right question. But the answer was never received. It seems they said that flip pages are not what I need. I want to know whether this is possible:

Instead of rendering the back buffer and then copying it to the front one, i'd like to change the frame buffer pointer to point to the back buffer, then rendering on the old front buffer, and switch again.

[Brendan]

Hi,

I want to know whether this is possible:

• Instead of rendering the back buffer and then copying it to the front one, i'd like to change the frame buffer pointer to point to the back buffer, then rendering on the old front buffer, and switch again.

If the backbuffer is in normal RAM (and not in video RAM), then it's not possible for VBE to use a buffer in normal RAM.

The best you can do with VBE is to have 2 buffers in video RAM (one for the frame buffer and a spare, for "page flipping"), where you'd:

• draw everything in your buffer in RAM (to avoid potentially expensive writes to video RAM while drawing)
• copy everything from your buffer in RAM to whichever buffer in video RAM is currently the "spare buffer"
• tell VBE to wait for vertical sync and then switch the buffers in video RAM (e.g. using "int 0x10, ax=0x4F07, bl=0x02"), so the spare buffer becomes the frame buffer and the frame buffer becomes the spare buffer

Unfortunately; if this works you can waste 50% of CPU time while VBE waits for vertical sync (as a worst case) - e.g. 16.666 milliseconds of drawing and copying then 16.666 milliseconds waiting for vertical sync because you just missed it, for every frame. Also, it may not work - e.g. if each buffer needs to be 3 MiB and the video card has a 4 MiB "memory mapped video RAM" area; then the "memory mapped video RAM" area would be too small to allow 2 buffers to be used (even if there's many GiB of video RAM). Finally, it means that you'd have to use VBE while the OS is running, which means that you can't set it up during boot and forget it (and make it easy to support UEFI later) and need an ugly mess to call VBE's functions from protected mode or long mode.

For these reasons, I'd simple forget about it. With double buffering (draw everything in RAM, then copy everything from RAM into the frame buffer) there's a small chance that you'll get some tearing (and an even smaller chance that the user will notice), but you avoid a lot of hassle (and save a lot of time that could be spent on native video drivers that have none of the problems and restrictions that VBE has).


Cheers,

Brendan

[grenders22]

For these reasons, I'd simple forget about it. With double buffering (draw everything in RAM, then copy everything from RAM into the frame buffer) there's a small chance that you'll get some tearing (and an even smaller chance that the user will notice), but you avoid a lot of hassle (and save a lot of time that could be spent on native video drivers that have none of the problems and restrictions that VBE has

thank you very much for the answer. I now and do, as you at the end described. but unfortunately these artifacts are visible when dragging my windows. and it's very annoying. can there be advice on how to avoid them? I read that it's possible to synchronize memcpy and fake screen updates, is this true?