HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
ssloy
tinyraycaster
C++2019–2022
ssloy / tinyraycaster

tinyraycaster

486 lines of C++: old-school FPS in a weekend

Learning & ReferenceCreative & Media
Explore on GitHubRead Hacker News discussions
7Distinct people
7Mentions
0Explicit recommenders
2.1KGitHub stars
REPOSITORY AT A GLANCE

What to know before exploring

What it is

486 lines of C++: old-school FPS in a weekend

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, 3:56:07 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 year7 dated mentions

Observed mentions: 2019-02-10 22:38:29 UTC to 2022-01-01 22:20:54 UTC.

0123452019-01-01 00:00:00 UTC to 2020-01-01 00:00:00 UTC (exclusive): 5 mentions; 3 submissions, 2 comments20192020-01-01 00:00:00 UTC to 2021-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments20202021-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 comments2022

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 UTC532
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

What Hacker News says

7 sources
pfranz·Jan 1, 2022
That sounds like a fun challenge. If you're constraining yourself to use as few libraries as possible, I'd go with OBJ [1] for the 3d mesh and PPM [2] for writing images. It's easy to implement a bare bones reader/writer and some OSes (like macOS) can show them in the file browser. Raytracing in One Weekend goes over PPM. There are a bunch of header-only libraries that handle different file formats like stb_image [3]. I usually end up using those when I start dealing with textures or UI elements. I don't use Windows so I haven't used their APIs for projects like this. I'd usually go for imgui or SDL (like you mentioned). tinyracaster, a sibling project of tinyrenderer, touches on those [4]. I liked LazyFoo's SDL tutorial [5]. Good luck! [1] https://en.wikipedia.org/wiki/Wavefront_.obj_file [2] https://en.wikipedia.org/wiki/Netpbm#PPM_exam
Read the rest
ple [3] https://github.com/nothings/stb [4] https://github.com/ssloy/tinyraycaster/wiki/Part-4:-SDL [5] https://lazyfoo.net/tutorials/SDL/index.php
In Finding your home in game graphics programming
dragontamer·Feb 15, 2019
> Does std::vector automatically handle the memory releases? Yes. What is going on here is that "img" is being assigned. The "old vector" will have its destructor called, which will call the destructor of all of its elements by default. ------- I assume you're talking about this code: https://github.com/ssloy/tinyraycaster/blob/master/framebuff... void FrameBuffer::clear(const uint32_t color) { img = std::vector<uint32_t>(w*h, color); } Which seems inefficient to me. But it is correct code, even if it is inefficient. There's no memory leak here, but the code probably would be way more efficient if it were instead a simple memset. memset(&img[0], color, w*h*sizeof(uint32_t)); This memset is likely easier to understand, since it doesn't rely upon destructors / constructors / assignment C++ Magic. And its more efficient
Read the rest
to boot. Vectors are guaranteed to be contiguous in memory, which is why it is compatible with memset. EDIT: Hmmm... the img is never initialized. You'd also have to do "img = std::vector<uint32_t>(w*h, color);" somewhere. ---------- The rectangle is also inefficient. for (size_t i=0; i<rect_w; i++) { for (size_t j=0; j<rect_h; j++) { If i and j were reversed, the draw rectangle function would be more efficient. As it is, "j" iterates in the wrong direction with regards to cache lines... // This would be faster! for (size_t j=0; j<rect_h; j++) { for (size_t i=0; i<rect_w; i++) { Overall though, efficiency isn't a goal at all. Its designend to be a quickie project to get things done as soon as possible. Thinking about all of these details slows down development, so there's something to be said about "just getting it done"
In Build your own old-school 3D shooter in a weekend

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.