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.
Was it difficult to write the compositor? I've just started planning on mine and I think I know how to do it including stuff like blitting a surface of ARGB32 onto one of RGBA24 et.c. which in itself isn't very hard to do but might prove inefficiant. Do you get descent performance?
Jezze wrote:Was it difficult to write the compositor? I've just started planning on mine and I think I know how to do it including stuff like blitting a surface of ARGB32 onto one of RGBA24 et.c. which in itself isn't very hard to do but might prove inefficiant. Do you get descent performance?
My RGBA blitting is very inefficient, but runs okay if you don't have too many windows open. My 32-32 RGB blitting is extremely fast. Sadly, I abandoned most of my support for 24-bit display surfaces a while ago.
This is a screenshot from my little piece of code called MicroBe OS.
Aimed to "learn how things should be done". Pure x86 assembly only.
a bit more info (but a bit outdated) on http://microbe.clew.cz
Here is my command-line interpreter. Nothing special here. I still have a lot to do with the basic underlying OS functionality. All the GUI related things are not very current issues yet.
This is further than I got before, though still damn little compared to the rest of you. Boots in the higher half, does GDT, IDT, remaps IRQs and then redoes the paging in C++. All my code is C++ and uses namespaces throughout to separate my code. I've used PDCLIB for the majority of my C library but also took the quad parts from OpenBSDs libc so I can do arithmetic on 64 bit integers. That compiled pretty easily with only a few typedefs and disabling clang using sse etc.
klange wrote:Care to share some details on your windowing system?
i went for what i tought was the most easy, not the most efficent in memory space but every window have its own surface to write/draw to. conponent or user code write on it and the os draw it when it need.
in memory i also have a zlevel buffer for every pixel on the screen, nothing like 3d stuff but a byte so unless u have more than 255 window its fine. that make it easy for drawing, when i draw my window, it mark its zlevel in that buffer for every pixel drawed. if the zlevel is already marked i test if its lower or higher. if the value is lower then its not drawed else i replace the pixel and set the new zlevel value. front windows is always zlevel 0