This post explains how I wrote directory-reading code for use in C, with links to working code.
[read more...]
[read more...]
For testing and debugging 3D rendering it is convenient to have the ability to generate some three-dimensional "primitive" shapes from code. You might think of a placeholder mesh to use when a mesh file doesn't load properly, or a variety of generic mesh shapes to test a new shader on. I didn't have this in my graphics helper code. I remembered reading about generation of the Platonic Solids in Jim Blinn's Corner: A Trip Down the Computer Graphics Pipeline, Chapter Four, 1996. I have the book, so thought this might be an interesting exercise to start with.
I talked about building a software 3D rasteriser in some of my recent live streams, and people asked if I could share my resources. If you start with a program that can write out an image then you can progressively add features one by one, which is quite fun. If you find a triangle fill algorithm to rasterise one triangle (colour the correct pixels between 3 corner points) then you're on the right path. It's easier, and arguably more fun, to write a simple software rasteriser than get a modern 3D API started, which is kind of silly. Yes, it is a good way to learn 3D graphics concepts, much like writing a software ray tracer. Here is some of my demo code.
During virus lock-in I'm doing some streaming of educational/hobby coding. My warm-up was an introduction to computer programming using the C programming language. Other requested topics are an intro to 3D programming with OpenGL, some bits relevant to a book I'm working on - especially how to use fuzzers - and just me coding some 3D game stuff.
Here is a tentative schedule...
This week Binomial LLC adopted my little BMP image loader library into Basis Universal, which is a Google partner project. Here is a Google blog post from 20 March 2020, which provides more information.
I'll write a few blog posts to share some experience about working on larger projects or coordinating with teams. I want to start out easy so here's a little aside about avoiding code tangles. Even projects that start off simple can quickly become quite complicated to follow as they grow, and as more people work on parts of them.
I'm on holidays since yesterday! I have a bit of time get back to side projects (and lifting weights). What better to celebrate this auspicious occasion than to bundle my OpenGL learning resources together in a sale.
I have always been interested in languages. I have been adding multilingual text rendering support to my kick-around hobby game project over the last year or so. The project is written in C99 and OpenGL. Here's an overview of rendering text and how I support various other languages.
Because I was asked, here is an overview of how I code quickly in C without getting log-jammed in structural mess. A lot of this should work for other languages too. Key concepts - keep it quick to get stuff on screen, keep it fun, let structure emerge on it's own, write code that's low cost to throw out if it doesn't work out, don't make refactoring work for yourself. Basically don't follow any of the rules™!
I made a simple dissolve effect in WebGL. The idea was to replicate something like the dematerialisation shader effect you see in video games as a way of removing 3D models of dead monsters.
I am collecting optimisation guides, tools, and resources for 3D graphics programming, with particular focus on OpenGL. I'll put these on my OpenGL page in a little article when I have collected a few resources. I'll update this post as I get more things. Send me a message if you have a suggestion!
A did a short talk about rendering the WAD files from DOOM (1993) in OpenGL. The previous blog post discusses extracting the contents of the WAD files with some hexedit hackery. The slides should be embedded here:
A hobby project that has been on my list since about 1994 was to figure out Doom's (Id Software, 1993) data file
format -
the vaunted
DOOM.WAD file. My brother and I used to enjoy making maps with 3rd-party editing tools around 1994/5,
which was
a nice way to get a grip on the 3D technology involved in the game. When I started programming I occasionally
looked
at the Doom source code to see
[
read more...]