Arawn Davies [Mon, 15 Dec 2025 03:19:36 +0000 (03:19 +0000)]
Refactor boolean type definition for C++/-std=gnu23 compatibility
Changed the definition of 'boolean' type for C++ & -std=gnu23 compatibility, and included base <stdbool.h> header.
This is to help bring it more inline with other source ports (Chocolate Doom mainly) and keep compatibility with new toolchains I think. I didn't come up with this fix (https://blog.svgames.pl/article/the-little-bool-of-doom) but it's helped me work on a port of doomgeneric to PlayStation 2
How easy would it be to get audio working? I think only SDL 1.2 works well on that platform so I'll be using GSKit instead
techflashYT [Sun, 10 Aug 2025 09:37:43 +0000 (02:37 -0700)]
linuxvt: various framebuffer improvements
2 main improvements coming in here:
- Handling for nonstandard stride values, since some devices have
non-linear framebuffers, and the previous assumption, that
stride = width * bytesPerPixel, no longer necessarily holds true.
This distinction doesn't matter for many devices (and thus, it can
fall back to the former assumption if checking the real stride fails),
but for those where it does matter (e.g. the NVIDIA Jetson Orin Nano I
just tried it on), it does indeed make the game display correctly,
whereas it didn't before.
- Clean up the pointer math needed to center the image on screen a bit.
It was previously a bit of a mess, this version should be marginally
faster, and much easier to read/understand.
Since TryRunTics() can absolutely return without running any gametic
(and it 100% will every-other time on fast enough hardware), it's a
waste of processing power to draw a new frame on every
doomgeneric_Tick(). This quick fix optimizes it down so it'll only try
to draw a new frame if TryRunTics() actually ran any gametics (and thus,
we have new frames to display).
In the best case scenario (the platform's DG_DrawFrame() is incredibly
fast), this will save a minute amount of processing power.
In the worst case scenario (the platform's DG_DrawFrame() is incredibly
slow), this can save several miliseconds of useless drawing, allowing
more actual gametics to be processed. In fact, without this, slower
platforms can actually dig themselves into a hole that they can never
escape from. It could start running behind on gametics due to the
useless render, which results in doing more work to catch back up in
every TryRunTics() call, further compounding the slowness.
This should work on any Linux box with no additional software installed
(e.g. Xorg, SDL). The only requirement is a basic framebuffer, and
input via evdev - both are things provided by the kernel.
It does not currently have audio support, though I hope to eventually
make it work with ALSA if possible.
This allows for changing the color mode, rather than the currently
hardcoded always RGBA8888. That default is preserved for compatibility,
but this allows also specifying RGB565, and is extensible to allow more
modes later on.
This is a temporary file that gets built every time, and should not be
committed to the repository. Delete the current copy in the repository,
and add it to the .gitignore so that it won't get added back here.
This allows byteswapping, no matter what features are enabled. This is
necessary for builds that don't use SDL to work properly on Big Endian
platforms. Rather than relying on SDL's implementation (and just not
doing any swapping if sound is disabled???), this adds a minimal inline
implementation for Big Endian, and equates to a no-op (as the original
did) on Little Endian.
Daniel Bomar [Wed, 27 Apr 2022 06:11:39 +0000 (01:11 -0500)]
X11: Improve performance by using XImage over XPixmap
This method does not need to copy pixel data greatly improving
performance. The doom framebuffer data is already in a format that Xlib
can accept so all we need to do is a single XPutImage call whenever the
engine wants us to draw a frame.
projects / doomgeneric-snom360 / log