Let’s start an experiment

Over the past few years I’ve been developing a nice little toolbox for game development: NRender. What started as an experiment to run code on a PSX has evolved into a quite capable gaming middleware. It offers many features you would expect such as 3D rendering, resource management, sound / music playback, input abstraction and the like. It even became pretty platform-independent with it now supporting Win32 (Win95 / NT4 and yes, even Windows 3.1 with Win32s!), DOS-compatibles and even modern browsers via Emscripten. It, intentionally, is not a full blown game engine.

Development of NRender has always been accompanied by game prototypes. Exercising new code and subsystems as you develop them is absolutely vital, and experimental games are a fun way to do so. Many were just dumb experiments from the beginning, some were pretty cool. One even made it to an actual release: Way Home! This has proven to be incredibly useful.

What is a bit sad, though, is that only one game actually made it.

So, the idea is to go the same route again. However, to make things a bit more interesting, I’ve decided to conduct an experiment: Public development! What this means is that I will publicly document my little journey, posting updates about once or twice a month. Things can and will get quite technical at times, but will also sway into game design topics as development progresses. I am in no way an experienced game developer, but I hope you will find some of my processes and findings as interesting as I do.

Technical scope

There is a really cool thing about developing for retro hardware: Instead of being bound by the technology of your time, you pretty much decide on limitations yourself. NRender itself is designed for 32-bit machines with a few megs of RAM, fixed-function graphics pipelines and no floating point usage. This only makes sense, since this is pretty much what the PSX is. Indeed, I’ve choosen systems mostly comparable to a PSX in performance as the target for Way Home. This yields about 1000-1500 polygons per frame and mostly free use of texturing et cetera.

For this game, I want to punch a bit lower: I will try to get it playable on a mid-range 486. The target I’m eyeing is a 486DX2/486SX2 at 66 Mhz. A machine like that will not reach 60, or indeed 30, FPS, but I hope to approach a somewhat playable framerate. A high-end 486 or Pentium, on the other hand, should be able to run the game fine.

First steps towards a game

So, what should the game be? I was thinking an asteroids-like game: A game set in space where the player controls a space ship and shoots down all the things - viewed from above.

However, I want to expand on that a bit:

• Make the play area be bigger than the actual screen, scrolling if necessary
• Enemies appear in waves across multiple stages
• A stage should end in a fun little boss fight
• Game play should be a bit faster than traditional Asteroids
• Stage hazards like gravity fields
• Powerups for kitting out your ship

Some of these are actually already in place. Namely, the stage already scrolls and enemies also already appear in waves. There is just one stage at this point, however. One of my ideas for making the game faster paced is also already there: The player is able to dash (Tab on PCs, Square on PSX).

This all hasn’t been fleshed out to any extent. But the groundwork is mostly there. Entities like enemies already are part of a pretty flexible entity system (adapted and heavily modified from an unrelated protoype) including state and resource management, collisions and the like. There even are some basic entities already. Movement is a little more floaty than I would like at this point, but we’ll see how things go.

Space-themed games actually provide a huge advantage: Since the background is mostly a single color (that is, black), we don’t need to draw it - we just fill in the non-black parts. That’s the reason why many early games were just like that. Our hardware target also directly influences the art design. Rendering flat shaded, untextured polygons is the fastest, so models should rely mostly on that. We can sprinkle in a few textures here and there, though.

New stuff

There is now a software renderer

Well, there already has been a software renderer for a long time. NRender has been incorporating Fabrice Bellard’s TinyGL, a software OpenGL 1.1-ish implementation. We still use NRenders OpenGL 1.1 renderer (called render_opengl11) in that case, but direct calls to TinyGL.

TinyGL performed very well, both in term of image quality and runtime speed. It’s big downside, though, stems from it’s nicest feature: It’s OpenGL-like, so it uses floating point number quite a lot. It’s development also pretty much halted, with the odd fork springing up on GitHub once in a while (in fact, I’m using one those random forks).

So, I’ve decided to implement my own, integer-math-only software renderer as part of NRender. I’ve hoped to squeeze out a little more performance (after all, I don’t have to conform to what OpenGL does at all). I can also try to employ some tricks, such as cheap pixel- and line-doubling, to improve performance even more. I also expect to perfom much better on FPU-less targets.

nrender_soft, as I’ve called it, has been cooking for a while now and seems ready for inclusion. It still has some problems left (some off-by-ones as it seems), but is good enough to render this early iteration of the game.

Mouse support

NRender now knows about mice and allows games to use them. This is currently only on SDL2, but will be introduced to Win32 and DOS platforms as well. The game already utilizes mouse support for navigating your ship.

NRSL

NRSL, or NRender Support Library, is a collection of functionality not quite suited for inclusion into NRender, but is nevertheless handy to have. This provides a lot of “auxiliary” stuff typically found in a full game engine. Note that even NRender with NRSL still do not make a full game engine.

The current modules are:

• devscreen, a console-like overlay for debug output. Supports arbitrary widgets, including TTY-like output and graphs
• startup, common code that supports pre-loading resources and displaying disclaimer screens where needed
• loop, a common main loop implementation that calls into subsystems correctly
• licenses, a license viewer (really just an image viewer…)
• resources, a build-time resource system for converting stuff and determining dependencies correctly. Also supports stuffing things into RAO files transparently when desired

pixelfmt refactor

One of NRender’s subsystems, pixelfmt, handles how images and framebuffers are laid out. The previous design used opaque handles for each format and snippets of code to deal with each and every peculiarity. This worked well when the number of formats was small, but has proven to become very cumbersome as NRender grew. The new approach describes each and every format, paletted/indexed as well as RGB ones, in a single struct. Applications are encouraged to not access struct members directly, but can. I’ve found that application code (and even non-pixelfmt code in NRender) mostly needs to determine the storage size of a specific number of pixels, for which there is now nrender_pixelfmt_pitch().

One particularly tough spot has always been nrender_pixelfmt_convert(). This function converts a buffer of pixels in one format to another. The code there was really ugly and filled with hacks and workarounds. This has now been mostly streamlined. The new code is slower but a lot more maintainable. I’ve decided this is a fine trade-off, since NRender tries to avoid pixel format conversions at runtime as much as possible. I’ve also written a bunch of tests to guard against regressions in the conversion code, as stuff has broken multiple times in the past.

The future

Game

• More enemy types
• A HUD
• Actual combat, health for the player
• Maybe a first boss?
• Tighter controls

NRender

• Mouse support for Win32 and DOS
• Analog controls on PSX
• Factor out fixed point arithmetic into seperate library. This will eliminate fsin/fcos/… usage
• Maybe a Glide renderer?
• Optional floating point usage?