| What it does at the moment is a bit hacky, in that it does not integrate with the existing graphics stack in the way people could think. I haven't written a driver for the pi graphics card or for HDMI audio. What I do with graphics is to save the existing state before beginning the game, do whatever I want during the game and restoring the state when it ends. With audio I am not doing it that cleanly as I believe that OpenBSD does not currently even touch HDMI audio registers. As for the reduction of stuttering, when the game begins I stop 3 of the four cores, assign them entirely to the game ( also with new interrupt vector tables both in EL0 and EL1 ) and when the game exits give them back to OpenBSD. That way, while the game is running without interruption, the single core that is left to OpenBSD is free to run admin tasks. Since the game has a process that can be scheduled by that single core, the game can do networking or file I/O using OpenBSD, because the different cores have the same entries in the user space MMU tables and so they share memory and can talk to each other. OpenBSD cannot interrupt the game, it can only kill it if needed. Regarding upstreaming my work the answer is "Probably not. But if the world wants it open sourced I am not against it and could think about doing a fork (Say we call it OpenBSD4Games). Or I could just give some help with the raspberry pi drivers." The reason for that is that I am doing quite some stuff that am pretty sure the OpenBSD devs would not be happy to put in. OpenBSD is strongly focused on security. I am pretty sure they would not want to have some code in there that hijacks 3 cores out of 4 and gives them to a user process. Another example: I have been told that giving several contiguous memory pages to a user task is something that should not be done in OpenBSD. I understand why but then I give a game quite a few contiguous memory pages that the hardware will use for the frame buffer and so has to be contiguous. Also, this is prototype code. It works for me, it still needs a ton of work and might not even be 100% correct. I cannot possibly understand all of the little details in the kernel in 2 months. I am proud of this achievement though and would love to be able to turn this into a real product that many people enjoy. Regarding the "home computer" part, I thought about game devs. When doing a game, it's not only the game code that is important. The tools are very important as well. So I built GNUstep ( on OpenBSD it does not currently work on arm64 ) so that it's super easy to build tools for game development in Objective-C. Also I thought about playing around and experimenting, and I am planning a GUI app with GNUstep that integrates a C/C++ interpreter called cling, which is developed by CERN for their physics simulations if I am not wrong. With that, a game developer will be able to experiment with code and tweak it in a way that is similar to what Xcode playgrounds does with swift on the Mac. |
https://youtu.be/KhRnGbVhejk