doomgeneric
nanoprintf
| doomgeneric | nanoprintf | |
|---|---|---|
| 19 | 5 | |
| 1,068 | 575 | |
| - | - | |
| 6.9 | 5.5 | |
| 7 days ago | 3 days ago | |
| C | C++ | |
| GNU General Public License v3.0 only | GNU General Public License v3.0 or later |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
doomgeneric
-
Doom-htop: The classic DOOM game over htop
But as was written somewhere else in the comments and as I wrote myself in the README, the hard work of making Doom more portable was done by the incredible project doom-generic which I forked: https://github.com/ozkl/doomgeneric
- What functions need to be changed when porting?
- Doomgeneric: Make porting Doom easier
- Doomgeneric: Make Porting Doom Easier
-
Retrogame INSIDE a Godot game?
It can surely be implemented with a GDNative add-on (3.x) or GDExtension (4.0). Someone on the Godot Contributors Chat is looking into integrating doomgeneric with GDNative, so you can play Doom within Godot :)
-
Just picked these up from sams club, I will try to get Doom running on it
You also could alternatively start from https://github.com/ozkl/doomgeneric and all you'd have to do is feed it functions for drawing to the display and getting inputand
-
Is there a way i can convert DooM it to lua?
Another alternative is to compile Doom to an intermediate representation and a corresponding virtual machine in Lua. Then you build something like https://github.com/ozkl/doomgeneric where you only need to implement a handful of platform specific functions.
nanoprintf
-
nanoprintf VS callback_printf - a user suggested alternative
2 projects | 16 Aug 2023
- Nanoprintf – The smallest public printf implementation for its feature set
-
DOOM! on the #emfcamp TiDAL badge
It turns out that DOOM expects a little more POSIX compliance from it's C library than Micropython provides, in particular the printf implementation is lacking many features. The good part is that because I'm building an entirely separate binary application, I can use someone elses printf, and finally, after a lot of pain, it runs!
-
Actual Challenges Faced In Software
You might be interested in this or similar: https://github.com/charlesnicholson/nanoprintf
- Nanoprintf v0.1.0 Released, drop-in [v]snprintf
What are some alternatives?
esp32-doom - A proof-of-concept port of PrBoom to the ESP32. Needs psram hardware.
printf - Tiny, fast, non-dependent and fully loaded printf implementation for embedded systems. Extensive test suite passing.
Craft - A simple Minecraft clone written in C using modern OpenGL (shaders).
defmt - Efficient, deferred formatting for logging on embedded systems
DOOM - DOOM Open Source Release
printf - Tiny, fast(ish), self-contained, fully loaded printf, sprinf etc. implementation; particularly useful in embedded systems.
bareDOOM - DOOM ported to run within the barebox bootloader
lfbb - A Lock Free Bipartite Buffer Library written in standard C11
TI-84-CE-DooM - A version of DooM for the TI-84 CE written in C.
esp-idf - Espressif IoT Development Framework. Official development framework for Espressif SoCs.
MicroPython - MicroPython - a lean and efficient Python implementation for microcontrollers and constrained systems
callback_printf - callback_printf allows the implementation of portable sprintf, snprintf, vsprintf and vsnprintf like output functions. The code includes wrappers for those functions. It supports all formats of the C 11 standard. wchar_t arguments and strings are printed as UTF-8. It's pretty fast, threadsafe and has no dependencies to other libraries.