OSDev.org

max wrote:That wallpaper is burning my eyes But awesome to see something like Xorg running. How big are the requirements for that?

As far as I know, that's the default background generated by X itself when nothing else is running.

BigBuda wrote:As far as I know, that's the default background generated by X itself when nothing else is running.

Yes, it is. It is the Xorg logo, pretty tiny and then tiled across the screen. The pattern is pretty good at making flaky CRTs produce visible errors, which is probably why they've kept it.

I switched my UI over to being rendered with Skia, which was a huge project that involved porting fontconfig, freetype, etc., implementing memory mapped files (so fontconfig wouldn't be so slow). But, Skia is allowing me to do things that would have been harder in a bespoke graphics library, such as curved buttons. I'm using this as an opportunity to create prettier UI widgets.

I'm using Yoga behind my widget framework which is a flexbox layout engine. Here's my
calculator code if you want an idea of what my API looks like.

It's been a busy week, full of bugs.
I implemented a v86 monitor and added support for VBE mode switching.

TWM! I'm always surprised how nostalgic I get at the sight of it.

max wrote:

Peterbjornx wrote: Xorg (or rather, Kdrive/Xfbdev) running on my OS, hosting TWM.

That wallpaper is burning my eyes But awesome to see something like Xorg running. How big are the requirements for that?

X's default "root weave" (as it has come to be called) is as divisive as Marmite, I think. Some love it, others hate it. I like to see it, but not for long. If I were writing a 16-bit OS, I'd use GEM's weave pattern. As for system requirements, I suffered a lot of crashes running X/twm/xterm in 4MB with 4MB swap, but very few when I increased swap to 8MB. This was with a Cyrix graphics card; I imagine XFBdev will use a bit more for in-memory image data. It's possible modern X wants far more memory for reasons I'm not clear on.

@AndrewAPrice: looking good!

In preparation for releasing ToaruOS 2.1, I have completed packaging of aarch64 builds of several ports, including gcc, binutils, SDL1.2, Quake (sdlquake), and Doom (doomgeneric, which I added a ToaruOS backend to some time ago).

While the hardware setup for the VM is rather esoteric, including the Bochs display device and Intel audio chipset and NIC (I swear I'll get around to a virtio-net driver eventually...), the aarch64 builds work in QEMU with essentially full functionality and have been tested under HVF on an M1 Mac.

@Peterbjornx your screen short looks unique to me.

Popup Menus and transparency!!

https://github.com/manaskamal/aurora-xeneva

min0911 wrote:

Impressive. How did you port the classic Windows UI into a 386 DOS OS?

Not really an OS, but an experiment with 3D graphics using a real GPU.
Bare metal intel GPU 3D pipelined triangle, took absolutely enormous amount of effort and debugging.
Next stop is spinning cube.

8infy wrote:Not really an OS, but an experiment with 3D graphics using a real GPU.
Bare metal intel GPU 3D pipelined triangle, took absolutely enormous amount of effort and debugging.
Next stop is spinning cube.

Yeah, GPU programming sucks but it's worth it once you see pixels on the screen.
Are you like using OpenGL or are you doing it directly, sending packages and whatnot?
Please fix the link, we (I) want to see it.

Octacone wrote: Yeah, GPU programming sucks but it's worth it once you see pixels on the screen.
Are you like using OpenGL or are you doing it directly, sending packages and whatnot?

No, it's a bare metal kernel, cannot use OpenGL
It's building a batch buffer that sets up a 3D pipeline with a bunch of shaders and the triangle vertices.
The batch buffer is placed on the command ring of the render engine, which then executes all the pipeline stages like VF->VS->GS->CS->SF->PS,
which outputs the final shaded triangle to the mapped pixel shader surface (which also happens to be the primary plane of the display).

Octacone wrote: Please fix the link, we (I) want to see it.

Thanks, fixed