I am trying to work with the framebuffer and I have a very weird bug where movement of an object on the screen is very choppy but then when i hold down a key it becomes smooth, even though I have no input handling in my code what so ever. The bug also persists when I download your code and run for the bouncing flags example. I tried setting a fixed update loop and some other stuff but nothing works. I am on ubuntu running on a different tty. Any ideas?
@@anthonyceponis2491 idk Tony that sounds really weird. Maybe try to kill the entire GUI service like it recommends here askubuntu.com/questions/378046/how-to-run-ubuntu-xubuntu-in-a-complete-non-gui-mode . Also maybe try the SCHIZONE examples with a cursor, I wonder if that would be less choppy because it is actually processing some input.... I'll try on my Ubuntu machine today and get back to you
@@xmdi0 Thanks for the hint. I ended up reinstalling my whole os and now it works, after testing on a vm. Super dodgy. But anyways, your videos are fricking amazing, keep doing what you do man!
I used the maped linux framebuffer with a matrox millenium pci graphic card with 4 mb vram in 1024x768x32 with a knoppix boot CD on 32 bit AMD CPU with NASM. Using other graphic cards(Geforce,Radeon) the bits per pixel are reduced to 24 bit. The VBE-Bios of the other cards have mode numbers for 32 bit per pixel and i don’t understand why the 32 bit are not used by default on Geforce&Radeon. Booting MS DOS i can use the 32 bit per pixel with Matrox,bRadeon, Geforce. Modern Geforce&Radeon PCIe have VBE modenumbers for wide screen 16:9 aspect ratio1920:1080x32 and 16: 10 aspect ratio 1920x1200x32. But how to change from 24 bit to 32 bit per pixel on linux framebuffer?
Interesting problem. I believe if you start xorg there are several commands you can use to query and set the color depth of the framebuffer; you could try those for a start. But in my experience (very limited) 24 and 32 bit color depth are essentially the same thing, with the latter having a (useless) 8 bits of transparency. Could be wrong, but if that's the case, you could just accomodate both cases in your code.
@@xmdi0 I like to write 32 bit or mmx 64 bit(2 pixel) directly into the framebuffer and there is no single instruction to write 3 bytes. We have instructions for one, two bytes or 4 bytes, but not for three bytes. With 24 bit per pixel we have to use at minimum two instructions for one singel pixel.
You're going to do a revolution I guess.
Thank you!
SUPER SIGMA
I am trying to work with the framebuffer and I have a very weird bug where movement of an object on the screen is very choppy but then when i hold down a key it becomes smooth, even though I have no input handling in my code what so ever. The bug also persists when I download your code and run for the bouncing flags example. I tried setting a fixed update loop and some other stuff but nothing works. I am on ubuntu running on a different tty. Any ideas?
@@anthonyceponis2491 idk Tony that sounds really weird. Maybe try to kill the entire GUI service like it recommends here askubuntu.com/questions/378046/how-to-run-ubuntu-xubuntu-in-a-complete-non-gui-mode . Also maybe try the SCHIZONE examples with a cursor, I wonder if that would be less choppy because it is actually processing some input.... I'll try on my Ubuntu machine today and get back to you
@@xmdi0 Thanks for the hint. I ended up reinstalling my whole os and now it works, after testing on a vm. Super dodgy.
But anyways, your videos are fricking amazing, keep doing what you do man!
I think it doesn't work for me because X overrides it. will try in qemu without X, super informative, thanks !
Try in a tty: Ctrl+Alt+Fn
How do activate this framebuffer thing on WSL?
I did some digging, and it doesn't look possible at least as of the WSL git issue tracker from 2016. Check if you have any devices at /dev/fb .
I used the maped linux framebuffer with a matrox millenium pci graphic card with 4 mb vram in 1024x768x32 with a knoppix boot CD on 32 bit AMD CPU with NASM.
Using other graphic cards(Geforce,Radeon) the bits per pixel are reduced to 24 bit. The VBE-Bios of the other cards have mode numbers for 32 bit per pixel and i don’t understand why the 32 bit are not used by default on Geforce&Radeon. Booting MS DOS i can use the 32 bit per pixel with Matrox,bRadeon, Geforce. Modern Geforce&Radeon PCIe have VBE modenumbers for wide screen 16:9 aspect ratio1920:1080x32 and 16: 10 aspect ratio 1920x1200x32.
But how to change from 24 bit to 32 bit per pixel on linux framebuffer?
Interesting problem. I believe if you start xorg there are several commands you can use to query and set the color depth of the framebuffer; you could try those for a start. But in my experience (very limited) 24 and 32 bit color depth are essentially the same thing, with the latter having a (useless) 8 bits of transparency. Could be wrong, but if that's the case, you could just accomodate both cases in your code.
@@xmdi0 I like to write 32 bit or mmx 64 bit(2 pixel) directly into the framebuffer and there is no single instruction to write 3 bytes. We have instructions for one, two bytes or 4 bytes, but not for three bytes. With 24 bit per pixel we have to use at minimum two instructions for one singel pixel.