Vertical Scrolling Parallax Backgrounds in Godot

One of the fantastic things about game development is that there are a lot of resources available online. Video tutorials, blog posts, forum posts, etc.. Unfortunately the quality varies dramatically and they can end up out-of-date quickly as the game engine changes.

So it can be difficult to figure out how to do simple things because either what you find online uses APIs or techniques that no longer exist, or they don’t use an up-to-date technique that may be simpler. Often they don’t even include what version of the engine they used, so that adds an extra challenge.

There was a simple idea I wanted to play with in Godot that led me here…

Godot game engine icon

Godot Game Engine

Some old-school arcade games such as Raiden and 1942, are top-down, vertical scrollers. In these games, the player is generally restricted to moving left and right (possibly forward and back a little) and the background scrolls past them giving the illusion the player is moving forward. To recreate that style I needed to create a vertical, infinitely scrolling, parallax background.

Raiden (Arcade Game, 1990)

Raiden (Arcade Game, 1990)
Image from wikipedia

1942 (Arcade Game, 1984)

1942 (Arcade Game, 1984)
Image from wikipedia

Googling led to some video tutorials on side-scrolling parallax backgrounds (close!), some short answers in some forums (must be for an older version – didn’t work), and some things that were clearly hacks. After a fair amount of time looking around and watching videos, it turns out that it’s incredibly simple.

The following is a short tutorial will step through setting up a project with a simple player and an infinitely scrolling, parallax background. The complete project may be found on GitHub.

Continue reading

Notarizing Older Unity Games On macOS

Over the past couple of months I have been porting an existing Unity game to macOS. It is a shoot-em-up called Blue Rider developed by Ravegan from Córdoba, Argentina. It was originally released on PC (Steam), XBox, Playstation 4, and Switch.

Blue Rider Logo

I spent quite a lot of time getting it ported and running smoothly only to find that I couldn’t get past Apple’s notarization procedure because of the version of Unity I am using (5.6.7f1).

The binary uses an SDK older than the 10.9 SDK.

Notarization is required as of macOS 10.15 to distribute games in the Apple Store and it may become necessary on Steam. It may also be useful to notarize games for standalone distribution to avoid confusing warnings when users try to run your game.

(I am going to hold off a whole rant about Apple and their BS requirement to do this code signing/notarization at all. And I will try not to rant too much about their incredibly complicated process, documentation, and implementation.)

In this post I’ll describe the main problem I ran into and how I solved it. Hopefully it will help someone else.

Continue reading

Using Unity’s ShaderVariantCollection

Recently I have been working on porting an existing Unity game to macOS. It is a shoot-em-up called Blue Rider developed by Ravegan from Córdoba, Argentina. It was originally released on PC (Steam), XBox, Playstation 4, and Switch.

Blue Rider Logo

The main things I needed to work on to bring Blue Rider to macOS were the menu system, the resolution handling, the input handling, and some optimizations to achieve a smooth framerate.

(Note: I’m using Unity 5.6.7f1 since Blue Rider was written using a 5.x version. I’m not 100% sure, but based on the current documentation, I think what I’m doing here still applies with recent versions.)

The Problem

One such optimization had to do with shaders. The game was hitching sometimes when an enemy appeared and when it exploded. It only seemed to happen some times and with some enemies.

I’ll explain what I found when I broke out the profiler and then I’ll provide one possible solution using ShaderVariantCollection.

Continue reading

Torque Console Messages and Static Initialization

I figured I’d write this up for the one other person in the world that is going to run into this. Might save someone some time.

Several years ago I used to work at GarageGames on the Torque game engine. I worked on an internal version of the engine that was used for several of our games and by a few third-party games. While this version of the engine was never released, a whole bunch of our work ended up in TGEA at some point. So what I’m describing applies to at least some versions of Torque Game Engine Advanced (TGEA) as well [I have 1.8.2]. It may apply to the current iteration of the Torque engine – Torque 3D – but I don’t have it so I don’t know for sure.

Recently I was reviving a game that was written using an early version of this internal engine. I was updating the FMOD library and ran into a loading problem. While tracking it down, I found myself in sfx/fmod/SFXFMODProvider.cpp where the SFXFMODProvider constructor had a bunch of calls to Con::warnf(), but I wasn’t seeing anything in the console log. The problem was that the console log hadn’t been created yet because the SFXFMODProvider constructor is called during static initialization.

Taking a look at console/console.cpp, Con::printf(), Con::warnf(), and Con::errorf() ultimately call a static function _printf() which starts like this:

Guess that’s why I wasn’t seeing anything – we’re just throwing away all messages if we aren’t active yet!

So the obvious way to fix this is simply to save our messages instead of throwing them away and then to output them when we do become active. Easy as pie.

Now any messages that are sent using Con::printf(), Con::warnf(), or Con::errorf() during static initialization or before the console is active will show up at the top of console.log.

Hope the one guy who finds this useful in the future buys me a beer…