Doom was the first and last “full graphics” I played I think. Doom feats after hours in the 1990’s maybe?
Bring back Commander Keen lol. (Yes, have played it some times with Win3 emulators!) Regards, Tim. > On 8 Nov 2025, at 13:20, Gregory Nutt <[email protected]> wrote: > > * > Thanks again everyone for your help so far! One step closer to DOOM on > > NuttX :) > > Back in the old days when games were pure software, I enjoyed writing games > for NuttX. I have wolfenstein-like engine and an experimental 3D ray-casting > engine. These used to run on NuttX. The latter was once a part of the apps/ > repository but I removed it when I donated NuttX to Apache (since I didn't > intend to donate that [art). But I suppose it is still in the GIT history. > > UNRELATED: When NuttX was donated, there were a lot of files in the > repository that should not have been released and were removed in this way. > Many other files with different licenses were present at the time of release > and these had to be sanitized, to make them Apache correct (thanks almost > entirely to Alin Jerpelea). When we talk about NuttX being Apache 2 > copyrighted by the ASF, we really only the git repository from a certain > point forward > > Prior to that, checkouts from the repository are BSD licensed and copyrighted > by me. > > I also used to run the public 2-D Wolfenstein-like screen saver on NuttX. It > worked fine mostly out of the box. > > ________________________________ > From: Matteo Golin <[email protected]> > Sent: Friday, November 7, 2025 9:31 PM > To: [email protected] <[email protected]> > Subject: Re: RPI 4B Roadmap > > I managed to get something working with the frame buffer interface, so > success so far! https://github.com/apache/nuttx/pull/17294 > > Unfortunately, I encountered an issue trying to compile the LVGL demo so it > hasn't been much more interesting than some test rectangles so far. > https://github.com/apache/nuttx-apps/issues/3208 > > The frame-buffer driver was actually really simple to get working after > looking at Lup's blogs, so thank you for the tip Tomek (and Greg, for the > easy-to-implement driver)! I will probably go back and document the bit of > the frame buffer lower-half that I understand, since a little bit of > developer documentation for how to write a lower-half and what's exactly > needed to get running would be useful. There's also no docs for the > framebuffer example application, which I plan to fix shortly. It would be > good to know what the output should look like so I'm not scratching my head > wondering if I got it right or not :) > > Thanks again everyone for your help so far! One step closer to DOOM on > NuttX :) > > Matteo > >> On Thu, Nov 6, 2025 at 2:37 PM Tomek CEDRO <[email protected]> wrote: >> >>> On Thu, Nov 6, 2025 at 5:53 PM Matteo Golin <[email protected]> >>> wrote: >>> 1) I am actually familiar with the rpi4-osdev project. In part 5, the >>> author uses the framebuffer approach for graphics: >>> https://github.com/babbleberry/rpi4-osdev/tree/master/part5-framebuffer. >>> This is actually a really simple approach to implement, which is why I >>> imagine it wouldn't be difficult to integrate with NuttX's frame buffer >>> method of graphics. The main problem for me is that it's very slow. I >> want >>> to figure out how to leverage the actual GPU so that graphics can be >> faster >>> and more complex. I have not started looking extensively into that yet, >> but >>> was mainly wondering how that approach fits into NuttX's graphics system. >> >> From the long years on FreeBSD desktop where nvidia is the only vendor >> providing native high quality GPU drivers it seems good to have >> "generic" framebuffer driver that will work on any hardware in the >> first place and then GPU specific drivers with hardware acceleration >> where available. This allows not only having graphics on anything, but >> more importantly a fallback when GPU drivers fail / buggy / >> unavailable. Anything here means not only Xorg (and similar) but also >> raw console that can launch framebuffer applications or a mouse >> pointer that can copy-paste in the raw console! :-) Console woks on >> top of the video framebuffer (i.e. /dev/ttyv0..7), Xorg also works on >> top of the framebuffer (when launched it goes to place of /dev/ttyv8). >> This is modular and versatile design that allows text mode console on >> video display, graphical applications in raw video console, and Xorg >> or similar. >> >> There are two framebuffer drivers on FreeBSD: >> 1. VESA (old / bios machines): >> https://man.freebsd.org/cgi/man.cgi?query=vesa. >> 2. SCFB (new / usefi machines): >> https://man.freebsd.org/cgi/man.cgi?query=scfb >> >> Therer are two console drivers on FreeBSD: >> 1. SYSCONS/SC (old / bios machines): >> https://man.freebsd.org/cgi/man.cgi?query=syscons >> 2. VT (new / uefi machines): https://man.freebsd.org/cgi/man.cgi?query=vt >> >> SCFB / VT works also on embedded systems like rPI (over HDMI if that >> works). It seems work-in-progress but works for years already. The >> only problem I saw so far is the console colors packed into two bit >> field (afair) that may need structure changes to get dedicated 8..24 >> bit bit field to get more colors that will be breaking change thus it >> may be good to think ahead and use this wider field if we want to do >> something similar in NuttX :-) >> >> Here is newcons / vt wiki: https://wiki.freebsd.org/Newcons >> >> Hope this helps a bit or gives some reference point :-) >> >> On Linux ~20 years ago it was also possible to draw on raw video >> framebuffer using DirectFB (now version 2) even with no Xorg, see >> https://en.wikipedia.org/wiki/DirectFB :-) Current DRM/KMS approach is >> a moving target and kind of PITA because FreeBSD followed that path to >> have GPU drivers compatible with Linux for easier porting and this >> only brings problems because things change constantly and are pain to >> maintain / use thus I would recommend to avoid this path :-( >> >> I guess we care most about this design / approach where we have >> FrameBuffer that allows drawing directly (i.e. LVGL), having console, >> or Xorg or similar (there is example Xorg compatible server in >> NuttX!!) :-) >> >> -- >> CeDeROM, SQ7MHZ, http://www.tomek.cedro.info >>
