HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
ozkl
doomgeneric
C2019–2026
ozkl / doomgeneric

doomgeneric

Easily portable doom

10Distinct people
11Mentions
0Explicit recommenders
2.2KGitHub stars
REPOSITORY AT A GLANCE

What to know before exploring

What it is

Easily portable doom

GitHub

Where it is used

No documented product use has been verified yet.

What people are saying

No recommendation phrase was found in the indexed comments.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

No other repository is repeatedly linked in the same discussions.

This week on Hacker News

Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 1:49:46 PM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by year11 dated mentions

Observed mentions: 2019-09-07 15:41:39 UTC to 2026-07-21 10:15:12 UTC.

01232019-01-01 00:00:00 UTC to 2020-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments20192020-01-01 00:00:00 UTC to 2021-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2021-01-01 00:00:00 UTC to 2022-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2022-01-01 00:00:00 UTC to 2023-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments20222023-01-01 00:00:00 UTC to 2024-01-01 00:00:00 UTC (exclusive): 3 mentions; 1 submissions, 2 comments2024-01-01 00:00:00 UTC to 2025-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2025-01-01 00:00:00 UTC to 2026-01-01 00:00:00 UTC (exclusive): 3 mentions; 1 submissions, 2 comments2026-01-01 00:00:00 UTC to 2027-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments. Incomplete calendar period.2026*

* An incomplete calendar period is marked with an outlined bar. Its count is not directly comparable with a full period.

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges
UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
PeriodStart (UTC)End (exclusive, UTC)MentionsSubmissionsComments
20192019-01-01 00:00:00 UTC2020-01-01 00:00:00 UTC101
20202020-01-01 00:00:00 UTC2021-01-01 00:00:00 UTC101
20212021-01-01 00:00:00 UTC2022-01-01 00:00:00 UTC000
20222022-01-01 00:00:00 UTC2023-01-01 00:00:00 UTC101
20232023-01-01 00:00:00 UTC2024-01-01 00:00:00 UTC312
20242024-01-01 00:00:00 UTC2025-01-01 00:00:00 UTC101
20252025-01-01 00:00:00 UTC2026-01-01 00:00:00 UTC312
2026 (partial)2026-01-01 00:00:00 UTC2027-01-01 00:00:00 UTC101

What Hacker News says

11 sources
If you don't want to delegate the fun of learning to an LLM, here's how I've built a RV64IM simulator in C in a weekend. All you need is an opcode table, the RISC-V specs and to implement each instruction; the good thing of RISC CPUs is that instructions are very simple (i.e. pretty much everything is a variation of `dest = src1 OP src2`) and memory instructions are dedicated. The other cool thing is that there are no "flags". Start with the base instruction set, then you can add M on top later. 64-bit support requires just a handful more instructions to zero/sign extend from 32-bit. Then, wire your simulator to https://github.com/riscv-software-src/riscv-tests, and there you have an official test suite. When everything passes, you have a fully-compliant RISC-V CPU. You can at this point tell GCC or Rust or your favourite language to comp
Read the rest
ile to RV32IM and see it run on your simulator. It's a very gratifying process. If you get at this stage, you might want to use the ecall instruction to hard-code I/O operations such as "read from stdin" or "print a character", and there you have a sandboxed CPU that you can target with your favourite programming language. Make it run DOOM (start with https://github.com/ozkl/doomgeneric and see which I/O do you need), or turn it into a toy game console; the sky's the limit. --- Here's a copy-paste of the list of resources I have saved in my notes: - https://github.com/libriscv/libriscv A very fast RISC-V VM with sandboxing of memory and syscalls. - https://luplab.gitlab.io/rvcodecjs/ RISC-V Instruction Encoder/Decoder - https://www.cs.sfu.ca/~ashriram/Courses/CS295/assets/noteboo... Reference card - https://cs.brown.edu/courses/csci1952y/2024/assets/docs/risc... Spec - https://riscv-software-src.github.io/riscv-unified-db/manual... - ABI: https://lists.riscv.org/g/tech-psabi/attachment/61/0/riscv-a... Good luck!
In Running Doom on Our Custom CPU and Going Viral
vk6·Jan 13, 2025Submission

Show HN: Doom (1993) in a PDF

I made a Doom source port that runs within a PDF file. I was inspired by the recent HN post about Tetris in a PDF (https://news.ycombinator.com/item?id=42645218) and I wondered if I could get Doom to run using a similar method. It turns out that old versions of Emscripten can compile C to asm.js code that will happily run inside the limited JS runtime of the PDF engine. I used the doomgeneric (https://github.com/ozkl/doomgeneric) fork of the original Doom source, as that made writing the IO fairly easy. All I had to do was implement a framebuffer and keyboard inputs. Unlike previous interactive PDF demos, the output for DoomPDF is achieved by creating a text field for each row of pixels in the screen, then setting their contents to various ASCII characters. This gives me a 6 color monochrome display, that can be updated reasonably quickly
Read the rest
(80ms per frame). The source code is available at: https://github.com/ading2210/doompdf Note that this PDF can only run in Chromium-based browsers that use the PDFium engine.
369 points · Open discussion
First of all, thank you for the kind words :) Secondly, don't feel bad! I'm sure you know much much more than you give yourself credit for. This took about a full weekend plus another day, and a few more days of working here and there when I have time. 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
In Doom-htop: The classic DOOM game over htop
Andras Tantos has ssh and X11 working [1] on his simulator so maybe there's a fairly straight-forward path to porting something like this? [2] Seems possible that this aspect of the platform might drive the need some rework though [1]: sizeof(unsigned int) = 8; UINT_MAX = 18446744073709551615 sizeof(unsigned long) = 8; ULONG_MAX = 18446744073709551615 sizeof(unsigned char) = 1; UCHAR_MAX = 255 sizeof(unsigned short) = 8; USHRT_MAX = 4294967295 i.e. ints are 64-bit longs, shorts are 32-bit but use 64-bits [1] http://www.modularcircuits.com/blog/articles/the-return-of-t... [2] https://github.com/ozkl/doomgeneric
In Nobody ever ported Doom to run on a Cray 1

MAKE YOURSELF AT HOME

A few shortcuts

/
Search the collection
?
Open this guide
Esc
Close dialogs and navigation

Your saved repositories and interests stay in this browser.