Godot 4.2 Released

Events often resist efforts to package them up and stamp a Convenient Narrative on them, but it’s really tempting to me to say the history of the internet in this era is that of many people rejecting the hegemony of large corporations and doing things for themselves.

Social media has seen the rejection of Twitter, for reasons I really don’t want to hash out again here, and while some ran directly to Threads or Bluesky, a good number realized it was eventually just going to happen all over again, and that helped to increase the update of open source, federated work-alike Mastodon.

Another piece of this narrative vase that we might be able to fit into place, with creative thinking and a whole lot of glue, is the downfall of Unity and how it helped the effort to create the free open source gamedev replacement Godot. And lo, after a fairly recent release of 4.0, yesterday they already released 4.2. The changelog is here. Here is GDQuest’s rundown of the changes (22 minutes), and here are Lukky’s five favorite new features (3m), which are:

  • FSR 2.0 support (upscaling higher resolution output from lower resolution rendering)
  • Color-coding of folders in the file hierarchy within Godot’s UI
  • The ability to “bake 2D navmeshes”
  • When resizing 3D objects, the UI no longer resizes symmetrically around the object’s origin by default, but instead only the side you’re changing is modified
  • And, within the code editor, you can now create special comments to define a code region, which can be independently collapsed to reduce clutter, and expanded when you need access to its contents. And the Ctrl-K Comment Out feature works better now.

To get back to talking about software philosophy…. There are unique problems with using fully open tools to create games. Console manufacturer devtools are still locked in a mode where the maker hands you proprietary libraries, which they are unwilling to make freely available because of their economic desire to preserve trade secrets and control their platform. Most developers get around this by going through a third party, who has independently created a system of working between the open development framework and the publisher’s libraries, and then licenses it to a studio so they can get their project working on consumer hardware.

Godot is subject to this limitation, with 4.2 being no exception. But there is a sense, with it, that it’s the brightest hope for free and open game development going right now. They don’t ask for any license fees, they don’t try to count how many installs you have and they don’t track user behavior. But because they don’t try to claw in income through direct means, fair or foul, they must survive off of contributions. If you find Godot useful to your work, please consider using their donation link and signing up for an entirely voluntary plan.

Pixelfont

Pixelfont is a neat web tool that will take an image you provide, laid out in the proper format (which you have some control over, like character width and height) and will turn it into a pixel TrueType font for you to use! The gamedev applications of this should be obvious.

This isn’t the first free online font-building tool of this nature. The classic in the field is Fontstruct, which can also produce pixels that aren’t square, and can even extend outside of their cells, but also shows ads (although unobtrusive ones) and doesn’t let you import an image. Still, both are rather of use, or at least are fun to play with!

PixelfontFontstruct

Kaze Emanuar’s Adventures in Mario 64 Optimization: Calculating Sine

I’ve mentioned Kaze Emanuar’s efforts to make the best Mario 64 there can possibly be on its native hardware. He’s compiled it with optimization flags turned on, made its platforming engine much more efficient, and worked hard to minimize cache misses, which was a major source of slowdowns in the game’s code. Under his efforts, he’s gotten the engine running at 60fps (although not yet in a playable version of the original). While these optimizations are not the kind of thing that can keep being found indefinitely, he’s bound to run out of ways to tune up the code, currently he’s still finding new ways to speed it up.

I hope you’re ready for some F-U-N (approximation FUNctions)

He made a Youtube video detailing his most recent optimization find: getting the game’s trigonometric functions executing at their speediest. What is interesting is that the Mario 64 code already uses a couple of tricks to get sine and cosine results in a rapid manner: the game only uses 4096 discrete angles of movement direction, and contains a lookup table that covers each of those angles. But it turns out that this optimization is actually a mis-optimization, because the RAM bus hits incurred to read the values into the cache are actually more expensive than just figuring out the values in code on the N64’s hardware!

The video starts out decently comprehensible, but eventually descends into the process of figuring out sine and cosine on the fly, and the virtues of the various ways this can be done, so you can’t be faulted for bailing before the end, possibly at the moment the dreaded words “Taylor series” are mentioned. But it’s a fairly interesting watch until then!

Turbo Rascal

Turbo Rascal, more fully known as “Turbo Rascal Syntax Error” or TRSE, is a multiplatform game and demo development system, including a compiler, afull IDE and some miscellaneous utilities like an image editor. It’s based on Pascal, which might be annoying to people who have the conventions of C burnt into their brainmeat, but is easier on newbies on the whole, since its language idioms tend to be more readable for intent, and it doesn’t include structures like the ternary operator: (a ==0) ? isequal() : isnotequal();

While it supports a lot of different classic computing devices, TRSE’s “native” platforms, those it has the most support for, are the 8-bit Commodore machines. Using it, you can pretty rapidly put together a program to display an image on the C64’s hi-res screen:

It comes with a lot of example projects too, including a number of technically proficient demos that show off its capabilities. After you install a C64 emulator (VICE is recommended), the following can get up and running in less than a minute:

Turbo Rascal Syntax Error

The Arcade Blogger on the Development of Xevious

December 30th of last year, The Arcade Blogger did a piece on the creation of Namco’s classic vertical shooter Xevious.

Xevious was modestly successful in the US, where it was produced by Atari, but it Japan it did amazing numbers. Jeremy Parish (in his NES Works and related series) has mentioned several times that it was a vastly influential game in Japan, inspiring a whole generation of designers, and a whole bunch of clones and similar games. Its US release was around the time of the arcade crash, which was mostly an American thing. If it hadn’t had happened, maybe now we’d think about Xevious the way we consider Pac-Man.

The team behind Xevious

Xevious basically invented the vertical scrolling shooter where your ship has free movement of the screen. It also included a Bomb button to attack objects on the ground, displayed on the game’s background layer. It was a concept that would later be iterated upon in Konami’s Twinbee games.

Revealed in the article is an interesting fact. The scrolling background is stored in ROM as a huge 1024×2048 bitmapped image. That’s much wider than the screen is though. What the game does is send the player into a vertical portion of it 224 pixels wide.

When the player reaches the top, they wrap around to the bottom of another vertical stripe of the game world. In a complete loop, the player will travel from the bottom to the top 16 times. You can tell when you’re about to start another loop because the background will reach a place with trees all the way across!

You always start off a life in a tree-filled area because it begins you at the bottom of a stripe; each vertical pass over the map functions as a checkpoint. The stripes overlap somewhat, so you sometimes pass over an area you’ve seen before but offset by a bit.

For more facts on Xevious and its development, be sure to click through to the article!

The Arcade Blogger: The Development of Xevious

Classic Game Dev Andrew Braybook On Computer Conversions

Andred Braybrook is a legendary computer game dev from the Commodore 64 age, and before and after. In addition to the classic C64 games Uridium and Paradroid, which perform feats of scrolling that machine are really not designed for, he went on to many several other games, including the excellent computer ports of Taito’s sequel to Bubble Bobble, Rainbow Islands.

(Although Braybrook mentions that Taito hadn’t told him about the three secret islands that can appear at the end, so they got left out. They didn’t know about them either!)

Image from Braybrook’s blog

He has a blog post that details many aspects of he and his co-workers’ process back then that is fascinating to anyone with knowledge of these platforms, and even someone who doesn’t. Thanks to @acb@mastodon.social for the link!

Andrew Braybrook: How We Made Computer Game Conversions, from his blog

Breath of the Wild Cel Shading Break Glitch

The Legend of Zelda: Breath of the Wild is a gigantic game, and where content proliferates, so too do bugs. Many of these bugs are highly entertaining (my favorite is the bullet time bounce), but there are some that are just head-scratching, leaving one to wonder why does this happen? That the occur pulls back the curtain on the many technically complex things a big game like BotW does behind the scenes to realize its world, for, every step of a process that a system must go through is one more opportunity for something to go wrong.

Image from Nintendo Everything

Youtuber Jasper has made a 35 minute video about why, if Link stands in a specific spot in BotW, inside the broken corner of a stone wall, the cel shading usually applied to his model goes away, and he appears with normal light shading. In the way of Youtubers, the explanation is contained within a 35-minute discursive video that goes into the history of game lighting, why some older 3D games have graphics that have aged well while others don’t, the basics of cel shading, and still other topics. Here is that video, embedded:

The whole video is pretty interesting, and if you have the time and interest you should watch the whole thing. However, in the event that this is all tl;dw, allow me to summarize.

  1. Because Breath of the Wild is both a huge game and has a dynamic world, baking lighting in into textures would consume way too much storage and memory, so lighting has to be done dynamically.
  2. As an optimization measure, the more complex steps of cel shading are deferred to later in each frame’s rendering. The main rendering is done, then the cel shading is applied afterward, when the visibility of the area has been determined, so this effort-expensive process is only done for visible pixels.
  3. One of the deferred steps of rendering marks which of nine different kinds of material will be applied to each pixel. Terrain in BotW is not cel shaded, while characters link Link are, so they have different types of material that determine whether that shading is applied to them.
  4. In the location where Link’s cel shading disappears, there is a decal applied to the crumbling bridge that erroneously extends over the corner, and overwrites Link’s character material type with the terrain material, causing the cel shading not to be applied to him.

How Gravity Works in Super Mario Galaxy

Another Youtube video? Yeah I know. This one explains how gravity works in Super Mario Galaxy. It’s 29 minutes long. The basic gist is, there are eight kinds of invisible gravity field objects, based off of simple shapes, in the game, which are used in concert to create the various orientations that Mario switches to as he moves around: Parallel, Sphere, Cube, Disk, Torus, Cylinder, Wedge, Wire (basically an arbitrary path in space), and Cone, which is only used in two places.

An interesting fact from near the end of the video: gravity affects Mario’s shadow! Shadows point towards where Mario will fall, not according to how light strikes him, to give players a sense of where he is spatially in 3D space.

How Spherical Planets Bent the Rules in Super Mario Galaxy (Youtube, 30 minutes)

Super Mario Bros Level Glitches

The Youtube channel Retro Game Mechanics has done a series of three videos on glitches in Super Mario Bros. One involves using the NES game Tennis, which has a certain property of its code that allows you to load all kinds of funky levels in SMB.

They’re all interesting, but the one that floats my particular boat is the third, which turns into a deep dive in the compressed manner that Super Mario Bros. stores its levels in ROM, and uses to draw them during play in real time.

1. Access Glitch Worlds in Super Mario Bros. via NES Tennis (13 minutes)

2. Exploring Glitch Level Pointers In Super Mario Bros. (15 minutes)

3. Super Mario Bros. Glitch Levels Explained (30 minutes — this is the one embedded above)

Video: Its Programmer, On SNES DOOM

I’ve been doing a lot of high-effort posts lately, even for things that should be fairly quick. Working to make this more sustainable, here’s a laid-back post that’s mostly just a Youtube video of a talk between the guys of Digital Foundry and Randy Linden, coder of the SNES port of DOOM, which uses the SuperFX chip to make the hardware push polygons at a rate that, while not stellar by PCs-of-the-time standards, at least not abysmal.

Let’s run down the differences of hardware:

PC running MS-DOS: targets VGA monitors, displays all its pixels in software, but makes up for it with a minimum requirement of a 386 running (if memory holds up over nearly 30 years) at 33 mHz.

SNES: Its processor is a much slower workalike of the 65C816, a 16-bit version of the 6502, running at 3.58 mHz. While it makes up for its slower clock speed with a simpler design, meaning instructions complete generally in fewer cycles, it’s hard to make up for that 10-fold difference in speed.

Their use of specialized graphics hardware was an important advantage, at the time, of consoles over personal computer hardware. Even many standard home microcomputers, like the Commodore 64 and Atari 800, had dedicated graphics hardware that helped games run better than what most PCs could do. Even when VGA came out, the standard had no hardware-level support for scrolling or sprites.

Consider what it takes to scroll a screen without hardware support: something in the system has to be able to move every pixel from one spot on-screen to another. The NES pulls this task off by having a bank of memory that its PPU can be pointed within, meaning the memory could stay in the same place, and the graphics chip would just work from a different region within it. Sadly, this technique is not amenable to 3D graphics, which usually do require every pixel on the screen to be recalculated every frame, either in software or hardware.

The SNES is known for having a rather slow chip for its time, but more demanding games tended to make up for it with co-processor chips included on the cartridges. The most well-known of these are the DSP-1, which functioned as a math co-processor; the SA-1, which was basically a second 65C816 running at around triple the speed and with a few added features; and the SuperFX, which ran at about the SA-1’s clock speed but functioned as a graphics accelerator. (The later SuperFX 2 ran at twice that speed.)

These were far from the only add-on chips included on Super Famicom and SNES carts. Since the SNES had a much larger address space than the NES’s 6502-clone, the need for mapper chips was much less, but these co-processors were used in a number of more notable games to help it make framerate goals.

Hm. Well, I tried making it a laid-back kind of post. Ah well, back to playing Live-A-Live.

DF Retro: The Making of Doom on Super NES – The Original ‘Impossible Port’

Let’s Learn About Pixel Scaling and Rotation

When you start using emulators, it won’t be long before you’re brought up against the choice of which scalers to use, a bewildering collection of options with names like Nearest Neighbor, AdvMAME3x, and RotSprite.

Resizing pixel images in an intelligent way is a difficult problem for many reasons. Most techniques intended for use on photographs won’t apply, since they’ll produce unacceptably blurry results when applied to extremely low resolution art. Pixel art is designed so that every dot matters, and adding new pixels carelessly can cause problems, such as Mario flipping us the bird in the right-hand image below:

Mario vs MMarrioo:A possible result of bad upscaling.

Additionally, being done frequently in real-time emulation, scaling algorithms must be fast. Yet the fastest solution, called Nearest Neighbor, produces very blocky results, and also only really works well if images are scaled up to an integer multiple of the original in X and Y dimensions.

A good backgrounder of various issues is available from an old blog post here, but there’s been some interesting advancements in the field since then. RotSprite is a good contemporary solution that also can rotate pixel art images well.

The problem of rotation is made simpler by a nifty trick that’s used by many image editors and libraries. It turns out you can rotate an image by an arbitrary amount with three simple shear operations. (If you don’t know what shearing is, it’s just tilting an image by some amount in a direction. It’s pretty awesome that this works since shearing is easy to do.)

Example image borrowed from the above linked page. I’m amazed this works.

Video: Make Your Own Raycaster

A raycaster engine is a simple 3D engine that just draws lines from the player’s position to the nearest terrain wall for each horizontal pixel on the screen. It was what was used in one of the foundational 3D action games, id Software’s Wolfenstein 3D.

For those with a coding bent (the word bent seems so suitable when it comes to people who enjoy programming), Youtube account 3D sage demonstrates how to implement a raycaster in a series of three videos. The first one is embedded below:

Here are links to the whole series: Part 1 (17 minutes), Part 2 (14 minutes), and Part 3 (22 minutes)

Later he did another series on implementing the kind of engine that’s in DOOM, but we’ll look at that at a later date.