Come gather ’round people, and listen to two tales of programming lore…

The time between the last post and this one was longer than I expected.  I wanted to make a post earlier, but then I started on something neat and decided to hold off posting until I gathered my thoughts about it.  The result is a very long post about two topics: old display simulation and an audio engine update, complete with anecdotes of projects I did in the days of yore.  Brace yourself.  At least there are lots of pictures to look at.

Old Display Simulation

I’ve experimented with a few graphical overlays that will make the game window of Gonna Catcha look like an old CRT display.  As with the audio capabilities of Gonna Catcha, this is something new to me, so it will require some research.  I’ve already found some blog posts that talk about it, but the methods shown used pixel shaders, which GameMaker: Studio doesn’t support (well, at least not yet).

To get technical, you could code up your own pixel shader functionality into a GameMaker application using the draw and get pixel functions, but it will be very, very computationally expensive (i.e. it will make the game run very slowly).  I’ve done something similar with GameMaker before…

*flashback*

I’ve created a raytracer that renders several spheres on the screen in real-time without using GameMaker‘s 3D functions, just the 2D functions and mighty 3D geometry and trigonometry powers.  It could render at low resolutions fine (like less than 50×50), but once it goes beyond that point, it slows to a crawl:

This 50×50 scene runs at 8 frames per second…

…and this full-resolution frame takes about 18 seconds to render.
Yeeeah, I think I’ll stick with the built-in 3D functions for now.

*flash forward*

As interesting and colourful as my raytracer is, we should be going back to Gonna Catcha now.  Since I currently can’t use shaders, I’ll just have to make due with using foreground overlays and GameMaker‘s blending modes.  Below are some screenshots of the game with and without the various experimental overlays.  Click to magnify the screenshots, as the effects can’t be seen in the thumbnails.

Baseline (no overlay)
Scanlines only 
“LED billboard???” (Scanlines +   High contrast RGB dots)
“LCD???” (Scanlines + Low contrast RGB dots)
And here are some close-ups:
Baseline (no overlay)
Scanlines only 
“LED billboard???” (Scanlines +   High contrast RGB dots)
“LCD???” (Scanlines + Low contrast RGB dots)
So far, I like “LCD???” the best, followed by having scanlines only, but both are still not quite the CRT look I’m looking for.  Nevertheless, I’ll continue to soldier on.

Audio Engine Update

In other news, BASS, the audio library I’m using for both Gonna Catcha and That Which Binds Us, has been updated to version 2.4.10, and I’m three and a half months late to the party.  This meant that I needed to update BASSGMS, my wrapper library that makes BASS and GameMaker understand each other, as well.  Oh, and I know very well the troubles that can occur with incompatible libraries due to version differences.  Yes… very well.

*flashback*

When I was doing my Master’s at UOIT, I used BASS and a precursor version of BASSGMS for one of my projects.  One day, my project kept crashing on my lab machine, yet it ran perfectly fine on my home computer.  I spent a long time looking over my code and even inserted test and debug functions into it to make sure the outputs were correct, but no matter what I did, the program still kept crashing in the lab but not at home.  I forgot what gave me the idea, but after several hours I decided to look at the version numbers on the BASS DLL on both the lab and home computers.  It turned out that the DLL on the lab machine was a few revisions behind, so I downloaded the latest version of it and, lo and behold, the program stopped crashing.  And then I was enlightened.

*flash forward*

So anyway, I fired up Visual C++ and recompiled BASSGMS, no problem here.  I also took the opportunity to give GameMaker more control over BASS by add more functionality to BASSGMS.  In the end, I created a GameMaker:Studio application to test out the new and improved BASSGMS 0.3, which does things that are probably not even needed in my current game projects, like tempo control and monitoring CPU usage, but it’s still nice to have them there for future projects.

Not captured in picture:  animated, cycling rainbow effect.
Most likely not need in either project.
Copyright © Quadolor Games. All rights reserved.

A Race to Bottom… of Sound Chip Specs [Updated]

Update 3/18/2013 (6:21 PM):

EVERYTHING IS SUPER

HAVE A NICE DAY!

Well, it didn’t take long for things to go back to normal.  Maybe I should’ve held off posting this just for a little while longer.  Oh well.

As a bonus, here’s the coloured image of Pohena I meant to show earlier:

“I’m not a prize, you idiot.”

W-well, I didn’t mean it like that.   Uh… awk-ward.

TECHNICAL DIFFICULTIES

PLEASE STAND BY

Well, it seems that in my attempt to reorganize the files on my “website”, I did something that caused all the images on this blog to break (Dammit, I’m a computer scientist, not a web administrator!).  I’m in the process of getting that fixed.

In the meantime, let talk about something that doesn’t involve anything hosted on my site.

In my introductory post of Gonna Catcha, I posted this music sample from the project:

It was my attempt at emulating the style of music from 80s arcade games, without actually knowing how it was actually done.  Being someone who spent 3 years working on a master’s thesis on computer-generated sound,  this just simply wouldn’t do.  Nope, nope, nope.avi.

As with the graphics, I turned to Pac-Man  for inspiration:


The game used a chip called the Namco WSG to generate sound.  It had 3 channels, each could play one of the 8 waveforms stored in 256 bytes of external memory (PROM).  These waveforms could be customized to the sound guy’s heart’s content, which resulted in the highly-memorable audio of games such as Pac-Man.

This also stands in contrast to early PCs and early home consoles that came around the same time as or after it.  Although some of them did allow custom waveforms either intentionally or via programming exploits, they mainly relied on programmable sound generators (PSG) that only played preset waveforms to generate sound.  Some examples are (off the top of my head):

  • AY-3-9810 – found on earlier models of MSX computers
  • MOS Technology 6581/8580 (SID) – found on the Commodore 64
  • Ricoh 2A03/2A07 – found the NES
For comparison, listen to the NES port of Pac-Man:
Even though the sound generation of these chips weren’t as sophisticated (well, the SID was sophisticated in other ways), it didn’t stop them from being popular even to this day, even more than these old arcade chips.
Enough digression, time for the main event.  After applying the knowledge above, I have created the following early-80s-style arcade-type music:

Track list:  Donum Start ~ Donum Level ~ Donum Defeat ~ Pohena Start ~ Pohena Level ~ Pohena Defeat

I couldn’t find a way to generate 4-bit samples; everything I had to work with had a minimum bit resolution of 8 bits and the bitcrushers (a digital audio effect that reduces the number of bits used in an audio signal) I tried didn’t produce the desired results.  So essentially, I doubled the amount of pretend PROM on my pretend arcade board and used 8-bit samples.  Otherwise, I’m satisfied with the result, at least for now.  Personally, I find both “Defeat” tracks to be quite funny.

Copyright © Quadolor Games. All rights reserved.

My name is BASSGMS, I’ll be your interpreter for today

I’ve for a long time found GameMaker‘s audio engine to be too limiting. particularly in the background music department.  That’s why I choose to use an external audio library to handle the background music.

Long story short, GameMaker only allows you to use MP3s for background music, and the only flexibility you have for it is whether you want it to loop back to the beginning or not when it reaches the end.  That’s why I prefer to use MO3 modules for my background music.  MO3s are tracker modules with MP3- or OGG-compressed samples rather than straight PCM samples.  In simpler terms, MO3s combine MP3- or OGG-compressed samples with data on how to play those samples.  Looping is internal to the MO3 itself and is seamless,  allowing you to theoretically have an infinite-length MP3/OGG quality music in a few megabytes, or even less.


The only library I know of is BASS, whose developer, Ian Luck, also created the MO3 module format.  Getting BASS to work with GameMaker isn’t as easy as just importing the DLL into the project.  They can’t communicate with each other due to incompatible data types used in their functions.

I’m sorry, I don’t understand your funny accent.

(For those coders playing at home, GameMaker‘s only two types, real and string, are equivalent to the C types double and char* respectively.)

The solution was to create my own wrapper library, which I dubbed BASSGMS, that translates the functions in BASS in a way that GameMaker can work with.  In the heart of BASSGMS (and any wrapper DLL I may create in the future) lies these magic words that make everything possible:

What is this sorcery?!

To this day, I still only have a vague understanding of how to code DLLs.  All I know is it works like voodoo magic.

Copyright © Quadolor Games. All rights reserved.