OSDev.org

How do they contradict? Both of those snippets of code do the same thing.

As Octocontrabass said, they do the same thing. Note that the first one is clearer, the second one is faster

They are not exactly the same. The first works for pixels in the (8,8,8) RGB format only, but for arbitrary pixel widths. The 2nd works for 4 bytes-per-pixel only and expects the caller to have already created the pixel value in the appropriate format. If the framebuffer is 4 bytes-per-pixel and the pixel format is (8,8,8) RGB, which is likely, then both examples will have the same effect.

By "(8,8,8) RGB" I mean there are 8 bits each for the red, green, and blue components of each pixel, and they are packed together with blue in the least significant 8 bits, green the next 8 bits and red the following 8 bits.

What you should understand is that both of them are writing to a pixel value to a memory location. They first calculate the correct location (which is offset from the framebuffer base, which is screen in the first example and gop->Mode->FrameBufferBase in the 2nd). The first example stores colour components one byte at a time, whereas the 2nd stores an entire pixel value (a uint32_t value). Despite these differences, if you look at what the code does you will see it is effectively the same in both cases, if the assumptions they make about pixel format hold true.

Let me rephrase:

I would prefer the latter, because it is faster, and I don't have to figure out those values myself.

HOWEVER

I don't know what dependencies the latter has, so I am nervous to use.

PavelCheckov wrote:Let me rephrase:

I would prefer the latter, because it is faster, and I don't have to figure out those values myself.

HOWEVER

I don't know what dependencies the latter has, so I am nervous to use.

The one you tagged "former" is likely to be faster. Why do you think the "latter" is faster?

(edit: Also what are the values you think you'd need to "figure out" by yourself?)

Also: what do you mean by "dependencies"? Those snippets of code are pretty minimal. They're not calling any library functions. You can check that easily just by reading the code. "The former" uses the GOP, so it needs UEFI headers if copied verbatim, but you could easily replace "gop->Mode->FrameBufferBase" and "gop->Mode->Info->PixelsPerScanLine" with other suitable expressions.

By second one, I meant what you called the former. The reason why it is faster is because it does one memory access instead of 3.

The other one does a bunch of bit shifting and does 3 memory access, making it slower. In a tutorial, that one is good, as it present a clearer picture as to what it going on. In a real application, the other one is better as it isn't as verbose.

What do I need to do to access this GOP struct that is in the second one?

You don't need that specific structure, it's just an example. What you need is the base address and stride of the framebuffer. Your bootloader can provide that information.

Which bootloader are you using?

How would I find the screen resolution and video memory base?

I would eventually (in the far future) like to roll my own, but for now, BOOTBOOT looks like the best choice.

PavelCheckov wrote:How would I find the screen resolution and video memory base?

This was answered on the first page of this thread:

Octocontrabass wrote:The frame buffer provided by GOP works exactly the same as the frame buffer provided by VBE.

PavelCheckov wrote:How would I find the screen resolution and video memory base?

Your kernel gets that information from your bootloader. Your bootloader gets that information from the firmware.

PavelCheckov wrote:I would eventually (in the far future) like to roll my own, but for now, BOOTBOOT looks like the best choice.

The information you need is provided in this structure. I believe you need to define a symbol in your linker script so the loader can put that structure where you want it to go.

I don't want to use PC Screen Font or other dependencies, so how would I implement a font?

PavelCheckov wrote:so how would I implement a font?

That's a low-effort question which requires high-effort answers. How about you start with your own thoughts on the matter, lay out any problems that you can foresee and any possible solutions (even if not complete), outline what background reading you've already done, and ask more specific questions?

PavelCheckov wrote:I don't want to use PC Screen Font or other dependencies, so how would I implement a font?

The same way as PSF, but using a different file format.

PavelCheckov wrote:I don't want to use PC Screen Font or other dependencies, so how would I implement a font?

If you want an easy way you can use bitmap fonts, and you can use them as well in basic text mode if they are the good size.