thx
where to build your GUI
where to build your GUI
hi all, my OS can do just about anything needed to program a GUI, but i don't want to make it on my OS ( far too unstable ) but i still want to work on it, is their a way i can write my GUI under windows? all i need is mouse and keyboard input and video output but how??? any ideas
thx
thx
A couple of suggestions...
You are probably going to get mouse/keyboard events in some sort of a queue. Wrap around your OS queues with some generic library, then write a version that emulates that functionality on top of whatever system you want to use for development. Once you know how your GUI is going to manage these events, it shouldn't make much different if they are coming from a host OS or directly from hardware drivers.
Then define some minimal set of graphics driver functionality. I'd say you can build a GUI on top of two things, first being a methods to set the current screen mode, and another to copy in-memory bitmap to screen. Then write a driver that implements those methods on top of your development system.
Say, you could wrap around SDL input and map your minimal output on SDL's BitBLT. You could also do the same on Win32. Or X11 (if you are feeling lucky).
You probably don't want to write your GUI to rely on nothing but BitBLT ofcourse. So define a larger set of driver functionaly, say, how to allocate in-memory bitmaps, how to do screen-to-screen blits, with or without alpha channel, and so on. Then implement software versions of those, and map them on your minimal driver with just memory-to-screen BitBLT...
This way you need very small wrapper to run the all-software version on almost any operating system, and you also have the added benefit that writing a basic driver for your own OS becomes easy: just write those two functions for a given graphics card. Then when that works, one can extend some drivers to implement more of the full driver interface in hardware, while some can use the software version if the hardware sucks, or nobody had time to figure it out.
Oh... and if you build your display driver as something like "object-oriented in C" style function pointers in struct thingie, you can even easily do stuff like initialize software emulation version with basic or MMX/SSE accelerated codepaths based on what the CPU supports, which the real device driver can then replace with GPU accelerated version selectively.
You are probably going to get mouse/keyboard events in some sort of a queue. Wrap around your OS queues with some generic library, then write a version that emulates that functionality on top of whatever system you want to use for development. Once you know how your GUI is going to manage these events, it shouldn't make much different if they are coming from a host OS or directly from hardware drivers.
Then define some minimal set of graphics driver functionality. I'd say you can build a GUI on top of two things, first being a methods to set the current screen mode, and another to copy in-memory bitmap to screen. Then write a driver that implements those methods on top of your development system.
Say, you could wrap around SDL input and map your minimal output on SDL's BitBLT. You could also do the same on Win32. Or X11 (if you are feeling lucky).
You probably don't want to write your GUI to rely on nothing but BitBLT ofcourse. So define a larger set of driver functionaly, say, how to allocate in-memory bitmaps, how to do screen-to-screen blits, with or without alpha channel, and so on. Then implement software versions of those, and map them on your minimal driver with just memory-to-screen BitBLT...
This way you need very small wrapper to run the all-software version on almost any operating system, and you also have the added benefit that writing a basic driver for your own OS becomes easy: just write those two functions for a given graphics card. Then when that works, one can extend some drivers to implement more of the full driver interface in hardware, while some can use the software version if the hardware sucks, or nobody had time to figure it out.
Oh... and if you build your display driver as something like "object-oriented in C" style function pointers in struct thingie, you can even easily do stuff like initialize software emulation version with basic or MMX/SSE accelerated codepaths based on what the CPU supports, which the real device driver can then replace with GPU accelerated version selectively.
The real problem with goto is not with the control transfer, but with environments. Properly tail-recursive closures get both right.