Project Bolero Devlog 1

As threatened, here is my first real devlog post.

Work Since Last Devlog

I began a single-screen walking prototype in LÖVE. I’ve been procrastinating on this for a long, long time, so it feels good to actually start doing something productive on this front. Basic collision detection against a hardcoded tilemap of solid cells is implemented. Graphics are limited to rectangles generated with the love.draw library and debug printouts. Sound is not merged in yet. Input is hard-coded to the keyboard.

As little as it is, it’s still more than I had prior to this weekend.

I spent more time organizing notes and sketches that have piled up, and also playing with MilkyTracker and sample generation. Possibly I am using these as ways to procrastinate. I tried to separate my notes by topic, though I’ve yet to really go through them and prioritize what are good ideas and what should be thrown out.



In the fine tradition of the carriage leading the horse, here’s a quick and disorganized grab bag of things that are currently on my mind. I’d like to get more detailed in later devlogs.



This will be a platformer. I like these kinds of games, or at least a particular kind of them, a lot. My handle is an item from a game that lets you jump, in a genre and perspective that didn’t typically allow it at the time. Even though I’ve been more active with games lately, I haven’t made a platformer myself in ages.

Platformers don’t necessarily require the ability to jump, just that the player has some need to move across different platforms to achieve a goal, and the transition state between platforms typically puts the player at increased risk. Stairs, ladders, rope, grappling hooks, elevators, climbing, bouncing, teleporting, and moving the platforms themselves are all ways to get around, and they often appear as auxiliary travel methods alongside jumping.

Few platformers are built on platforming alone. Enemy characters, puzzles, and stage hazards are often thrown into the mix. Sometimes (or maybe oftentimes) being a platformer is the least notable thing about a game. Rigid definitions aren’t always helpful, and design and execution can be handled in many different ways.



I’m unsure about the best path to take here. My head says keep it light, but my gut wants to throw in some not-so-light themes. I need to hold off on this until I have more of the core game logic functioning.


Visually, austere pixel art with few special effects.

  • No parallax scrolling, no programmatic sprite rotation or scaling, no scanline interrupt-style effects, no zooming in or out of the scene.
  • No programmatic lighting effects, such as a circular radius of light around a torch, or shadows cast as polygons
  • Allow background animation so long as it helps ground the environment
  • Camera shaking should be used sparingly, if at all

No dialogue. No written text outside of the menu systems, title screen and credits.

Keep cutscenes to a minimum. When scripted events must occur, try as often as possible to have the player in control during those moments, even if they are forced down a specific path.

I want to play around with scene transitions. For example, slow dissolves between two versions of the same room to show passing of time as the player does something monotonous. But not all the time: it has to be used sparingly. Also, the ability for the camera to briefly follow auxiliary objects of interest, away from the player, without messing up the scene state. Looking forward to testing these thoughts.


I am woefully uninformed on this subject. Issues that spring to mind immediately are the need for captioning audio cues, and ensuring that visual cues are distinguishable for colorblind users. It’s a big and nuanced topic. Need to research.

Diversity of human characters

The human cast can’t be all white, and classes of character can’t all be typecast by gender. Need to think about the protagonist design, what that represents, and maybe include user customization. I’m not very good at this.

Copy Protection, Obfuscation

No. Nothing good comes of this.

Old Hardware Support

Supporting older hardware within a reasonable limit is important to me. LÖVE lists Windows Vista and higher as supported operating systems, and is able to run on some Raspberry Pi models. As long as the game doesn’t try to do too much all at once, it should run on practically any PC in decent shape from the past ten years.


For now, I’m just working with the expectation of a 60 Hz monitor, but I know that won’t cut it for a proper release. I’ll want to support variable framerates with delta time as well. The game should be mostly playable at 30 Hz, and partially playable at 15 Hz. Need to ensure that framerate fluctuations don’t break game logic, or desync things that are supposed to move predictably in lockstep.

Resolution and Aspect Ratio

I would normally default to a 4:3 ratio out of familiarity, but I feel the need to make the game in 16:9, as it’s the most common display these days.

I’m considering a couple of 16:9 resolutions that can scale up to 1920×1080: 320×180 and 384×216. The former feels a little too cramped, the latter a little too large. The core game engine needs more work before I can decide on this.

Sound and Music

I feel confident that I can make and record the necessary sounds for this game. For music, I am less confident, but willing to try making some tracker modules, and adapting some existing tracks that I’ve made in the past year for fun.


Plans For Next Week

  • Merge in sound and music functions from earlier test projects.
  • Add scrolling
  • Implement test objects: Randomly spawning fireballs, simple patrol enemy, and a moving platform

Project Bolero Devlog 0

I’ve been hashing out ideas for a sidescroller lately, and I think it’s time to start writing down my thoughts in a more organized diary or weblog. I might as well use this site, since it’s here.

I’ve written here about sidescroller ideas in the past. My life circumstances have changed since then, as time always marches on, but I’d still like to make something along those lines. It’s my hope that posting weekly will assist in moving this forward.

Once I’ve organized my notes, the first real devlog post will be this Sunday.

Maze Minders – Bitsy to ZZT

This post documents some work done to convert a Bitsy game to ZZT.

Bitsy is a game engine designed for making small browser-based games. Graphics are based on 16×16 rooms made of 8×8 tiles. It exports to HTML and is very accessible.


ZZT is a text-based action-adventure that enjoyed a very long after-market life, initially spurred by its built-in level editor. Boards are 60×25 in size, and are comprised of various terrain and objects that are represented by DOS text characters.


The game is Maze Minders, a short Bitsy adventure about various pixel-art stick figures wandering around an orthogonal labyrinth. This is not my best Bitsy effort — I was really just interested in drawing prancing 8×8 stick figures — but I went with it because the maps are almost entirely 8×8 solid blocks that would translate easily to ZZT’s DOS text mode.

I’m really happy to see Bitsy finding a community. It reminds me of ZZT’s following in a lot of ways, and I suppose that’s why I am doing this juxtaposition. Figuring out how to do certain things in these kinds of tools sort of becomes its own game.


Tools used

Bitsy 4.6 – 4.8 – By Adam Le Doux – Stock engine with no enhancements.
ZZT 3.2 — By Tim Sweeney – Stock engine with STK1 assets
KevEdit – By Kevin Vance and Ryan Phillips – The most common 3rd party ZZT world editor.

1 Tweaked ZZT game assets that cannot be invoked from the built-in editor.


The ZZT built-in editor and KevEdit have no undo feature at all, so it’s prudent to save your work often. Every saved copy of the ZZT game in-progress has been included in the final release — 192 saved files in all. In hindsight, I really wish that I had kept all of those in-progress snapshots of my old ZZT games.


Mapping From One To The Other

ZZT and Bitsy share similar territory, but the nuts-and-bolts behavior of both engines varies substantially. For example, Bitsy has no moving objects beyond the player avatar. All moving things are either faked by warping the avatar to different-looking rooms, or by modding the game engine.

These limitations are interesting, though. Hard limits with a low barrier to entry can lead to creative decisions.



Bitsy art is 8×8 2-color pixel tiles with a 128×128 display. Any tile can optionally be animated with two 8×8 frames, be it the player avatar, sprites, or background tiles.

ZZT is limited to MS-DOS text mode, which is typically 640×350 resolution comprised of 80×25 character cells that are 8×14 in size. 256 non-editable character symbols are available.


Bitsy supports just three on-screen colors by default: A color for the background, a color for terrain, and a color for the avatar and sprites. These colors can be anything that can be displayed in a web browser, and they can be adjusted on a per-room basis. ZZT is capable of fifteen simultaneous colors, plus black, not counting dithering. Most of those colors are highly saturated.

3rd Party MS-DOS utilities were available that could effect the following changes on a system running ZZT:

  • Apply custom fonts
  • Apply custom VGA colors
  • Disable text blinking in favor of more color combinations in text backgrounds

These utilities were rarely used.



Bitsy has no built-in audio capability, though it is possible to add with mods or by embedding an audio source into a webpage that hosts the game. ZZT provides basic control of the PC Speaker / Beeper. When run through DOSBox, this is sent to your system audio as loud square waves that occasionally crack and wobble.


Engine Limits

Being an MS-DOS game, ZZT has hard limits on what can fit into a single World file, and in many cases, no warning is provided to a developer that those limits have been breached. ZZT doesn’t seem to do much in the way of checking data integrity. This is both a blessing in terms of what is possible, and a curse when it corrupts world files. Bitsy’s limits, sky high in comparison, are less likely to be breached during typical development.


Gameplay Behavior

With no moving objects, Bitsy has no action elements. Puzzles, if present, are typically based around making the right choices, taking the right routes, or having the right items. The only built-in interface element is the dialogue box.

On the other hand, shooting and block puzzles are ZZT’s bread and butter. Although ZZT worlds certainly exist without those elements, there will always be ‘Health’, ‘Ammo’, ‘Keys’ and ‘Score’ indicators on the sidebar, along with instructions on how to shoot things.


Mapping 16×16 + 8×8 to 60×25 + 1×1

Bitsy rooms and ZZT boards are pretty different in terms of layout. What would be the best way to adapt one to the other? In hindsight, maybe this wasn’t a good project to convert.

Because of the tall dimensions of the text cells, a 16×16 map ends up being tall and distorted in ZZT. You could use multiple text cells to stand in for a given Bitsy tile (say, 2×1 ZZT cells for one 8×8 Bitsy tile), but even if you filled the entire 60×25 board with a good-looking recreation of the 16×16 original, ZZT player objects are always a single cell in size, and cannot be expanded to match the new scale.



Differences in Linking Areas Together

Travel to other areas is similar, but different enough to cause issues as well.

Let’s look at two kinds of linking: individual warp tiles that send the player to another area, and walking off the edge of the screen from one area to an adjacent location.

– Portals between areas

Bitsy allows the author to place single-tile exits that can transport the player to any room, at any possible coordinate. These exits cannot be modified during runtime, unless the game engine is modded.

ZZT has Passage cells that behave similarly to Bitsy exits. They can be destroyed, and tweaked ever-so-slightly during runtime, but placing new ones dynamically will only yield passages that point to the game’s title screen. (That’s right.) ZZT passages can be vulnerable to some esoteric problems, and they typically count towards a room’s limited tally of active objects.

Mutually-linked Passages in the first couple of screens of Town of ZZT.

The subject of ‘esoteric problems’ in ZZT is just too large for a single blog post, but consider this example. In Bitsy, you can place exit A and exit B next to each other just fine. No issues. If you put ZZT Passage A and B next to each other, you risk the possibility that a Passage may be erased from the board if the player simply walks a single cell’s distance from A to B. Best case scenario: this is a minor visual problem, if A and B both point to the same destination board. Worst case: A and B pointed to different boards, and now your player loses access to an area and needs to either load from a save file or restart.

(This effect could be used intentionally, but I’m getting way off topic at this point, so onto the next item.)


– Linking areas by their edges

ZZT provides built-in support for linking the edges of one board to another. Let’s say you have two areas that are supposed to be adjacent to each other, and you want the player to be able to travel between them by walking to the bordering edges of those areas. In ZZT, you just define board edge exits: set Board A’s Eastern edge to point to Board B, and Board B’s Western edge to point to Board A. ZZT checks to ensure that the destination cell on the other board is not occupied, so the player can’t get trapped in a wall.

To do the same in Bitsy (as of 4.8), you would need to define an exit for every cell on the edge of both rooms — either that, or just place a single exit and indicate it as such by blocking other parts of the edge, or pointing it out to the user in some way. The former is prone to manual error. The latter is valid, but sometimes you just want to have a wide open area to travel across.


An array of room exits in Bitsy, half-finished.


Board edge linking in ZZT’s Demonstration file.


In general, Bitsy exits are no-frills and instantanous — you can hide exits anywhere you want, and build up animations out of multiple rooms linked together. In contrast, ZZT board transitions are accompanied by a flashing purple screen transition.



I have not gotten too deep into Bitsy scripting, so I can’t make a call on this one. I will say that both Bitsy and ZZT have, at minimum, basic support for setting flags that can be used to tailor how NPCs respond to the user. Bitsy sprites don’t budge an inch from their designated coordinates, while ZZT objects have a small set of flow control and movement statements that can be used, abused and layered in various ways.



After trying a few ways of scaling up the Bitsy rooms to ZZT boards, I decided to just map one Bitsy tile to one ZZT text cell, and fill in the remaining board space with decorative wallpaper. This shortens the amount of time it takes to navigate through the maze, and prevents alignment issues when a sprite is supposed to block the player’s movement through a corridor.

I initially tried making the rooms fill a larger percentage of board space, and making the characters multi-cell text mode doodles, but I couldn’t really fit it into the space properly. The player also looked tiny compared to the NPCs.

Bitsy room for reference.


The room dimensions I ended up working with.


Using double-width blocks. It looks nicer, but takes longer to travel through, and introduces new issues wherever NPCs are supposed to block the player from the North or South.


An unflattering test of expanding the intro room to the whole board.


I briefly tested displaying the NPC sprite art in the corner of the screen using an array of objects, but getting this to work would require either a significant amount of typing labour, or some kind of preprocessing scripting that I didn’t have the time to work out. Also, when a dialogue box is open, there is not enough space around the edges of the screen to display the sprite in its entirety, even if it was moved to all the way into the corner.

This array of objects would have consumed about 20% of each board’s object capacity, which could cause problems when trying to fix other issues, so it definitely didn’t seem worth the effort.


Testing having a ‘Monitor’ in the corner of the screen to represent the NPC you are in contact with.


The monitor would not have been visible during dialogue scrolls, so I just embedded those graphics into the text scrolls themselves.


As mentioned earlier, DOS utilities can apply new fonts and colors at the BIOS level. Here is a quick mockup of what might be doable using additional DOS utilities:

A quick count suggests that there would be enough room to hold all of the in-game sprite art within unused symbols on the code page. However, the characters are  small and difficult to see, and all of their animation would have to be managed with ZZT scripting.

In any case, all NPCs in the final version are single #char 2 smileys. There is a visual indication when an NPC has nothing more to say — they will change over to a hollow #char 1 smiley.


Development Snippets

Converting dialogue.

@Maze Minder is the object’s name. This appears at the top of text boxes invoked by the object.
#cycle 1 makes the object process on every tick (about 10 frames per second).
#end halts program execution.
:touch is a built-in label. If the player walks into an object, the object will move execution to the topmost :touch label in its program, unless none exist.
#zap touch turns the topmost :touch label into a comment, so that you can talk to an object and get different behavior from them.


Left: Sometimes the ZZT player will damage floor graphics when exiting a passage.
Right: To make this less noticeable, you can place black empty cells around all passages on a given board, so that they at least look consistent.


In the Bitsy version, this area is entered from one of the four sides, and can only be exited by jumping down the hole in the center. In ZZT, I placed hidden objects to destroy the passages that the player uses to enter this board. These objects use #put <dir> blue normal to replace the passages with blue dithered walls. I’m not sure why, but the commands didn’t seem to work fully, only destroying 50% of the passages. I had to repeat the command a couple of times in all of these objects to fully get rid of them. I’m sure there’s some explanation for it that’s slipping my mind.


Using KevEdit’s selection highlight to show hidden terrain / objects necessary to prevent the player from wandering out into the background / wallpaper void area.


Here is the most complicated board in the ZZT version (though it’s really not too complicated by ZZT standards). The protagonist has been wandering the maze alone for a very long time, and seems to be going around in circles. In the Bitsy version, every rightmost walkable tile contains an exit that repositions the player on the next path along the top. This isn’t doable in ZZT with just passages, unless you make every path a separate identical-looking board2. However, a bug known as player cloning can be used to accomplish this kind of warping.

2 (A passage can send the player to a different part of the same board, but it only works when traveling from upper-left to lower-right, to a passage with a matching set of colors. This board needs to move the player in the other direction.)

Cloning is possible simply because ZZT includes “player” as one of the entity types that can be invoked through scripting, along with various items and monsters, even though it’s buggy and plainly unintentional.


Four sets of clone-generating objects are used, one for each teleport point. In each case, Object A waits for the player to come in contact with it. When this happens, it sends a message to Object B, which places an empty space to the South of itself,  then a clone of the player to the South. After doing this, it sends a message to Object C, which prompts that object to wait for one tick, shoot a bullet to the East, and then place a blue solid cell to the East as well.


Because of how ZZT behaves internally, this causes the Player to teleport to the East of the newly-minted clone at the top of the area. After one tick has passed, Object C shoots the clone, destroying it, the original player left unscathed.


To make this as seamless as possible (and it’s not really: you can see the cloned player for a fraction of a second before it is destroyed), each set of objects needs to be placed in the correct order, or else the commands will require additional ticks to process. If everything is in order, then each successive object can begin processing its script as soon as the engine will allow.

It’s very interesting that this bug functions as a consistent (though convoluted and potentially fragile) way of moving the player around. This article on Museum of ZZT contains more information if you’re interested in reading about player clone behavior.





KevEdit is a wonderful tool, but do take precautions in case it crashes.



The ending board mimics a Bitsy ending text box with objects. On every ZZT board except for the title screen, the player has to be present on-screen, somewhere. I ended up sticking the player in the lower-left, hoping it would be minimally intrusive if I included some objects around it to prevent movement.


An object to the North of the player always places a blue fake wall to the South, pushing the player downwards.

An object to the East is supposed to place blue fakes to the West, but I forgot that because of a programming error in ZZT, this never works when the destination coordinate is on the last row of the board. The player is free to wiggle around in the corner while the ending text rattles off.

Oh well.

The final conversion can be found on


Windows 10 Notes

Note: I’ve trimmed down this post for a couple of reasons:

  • I’ve migrated to Fedora as my main OS.
  • Microsoft seems to change and move options around between major updates of Windows 10, so anything I post could become outdated and misleading.

I’ve left what I think might be helpful below.


Local Account Mode

Here is an article on configuring local account mode if your installation is currently stuck with Microsoft Account authentication.


Uninstalling Groove Music

Windows 10 will not allow a straightforward uninstall of Groove Music. Doing this seems to require Windows PowerShell commands, or a power user utility like CCleaner.


Working with long filenames and/or paths

Windows sometimes has trouble with paths that are too long. The internet tells me that I should be able to make a registry edit to support long filenames, but this didn’t work for me. I followed this person’s solution and downloaded a 3rd party program to rename a file so that I could actually interact with it.

When I installed the Windows 10 Creators Update, some scripts that I had been using were no longer able to handle long paths. Others have noticed this as well. I was not able to find a solution to this other than not using long paths, and my overall patience with Windows 10 had run out at this point.


Other posts related to Windows 10

Windows 10: On lock screen, 2nd monitor does not recover from power-saving mode

Windows 10, NVidia GeForce GTX 750: OpenGL Programs Stutter Severely


(e 25/Mar/2017, 26/Mar/2017: Privacy: keyboard telemetry)
(e 6/Apr/2017: Long filename isssues: wording)
(e 16/Jul/2017: Creators Update notes)
(e 29/Jul/2017: File association grab)
(e 13/Aug/2017: Post trimmed down)


Rogue V5, as played on

Following are some scattered thoughts about the Roguelike genre, and a to-play list for myself as I explore the catalog.


Roguelikes are basically games that are like the 1980 Unix hack-and-slash Rogue. Originally played on text terminals connected to mainframes, your avatar is a little ‘@’ symbol, tasked with recovering the Amulet of Yendor from the 26th floor of the Dungeons of Doom. If (or rather, when) your character dies, it’s back to the very start with a fresh dungeon layout and new item definitions. Rogue maintains a high-score list, so that multiple users of the same system can compete for the highest amount of gold collected.


Rogue’s action is turn-based, and several aspects of the game are randomized — dungeon layouts, what potions and scrolls do depending on their description — to the point that they can’t be memorized from one game to the next. The chances of beating Rogue are very not in your favour. Luck is a large factor in determining your chances of survival, and on top of that, the difficulty curve soars during the final batch of floors.


The procedural generation systems and intense challenge make Rogue addictive and playable, and many developers have sought to emulate its appeal in the years since its release: from other terminal games, with increasingly complex underlying systems, to modern twitch-action games that have little resemblance outside of procedurally generated maps and permanent player death. I like both kinds.




Personal Roguelikes To-Play List

Will add thoughts as I play… This is going to take a while. Many interesting games are absent from the list, and I will try to flesh it out as I go along. The dates listed shouldn’t be taken too seriously, as I found them from random searches on the internet, and they don’t take subsequent work into account. I just wanted to sort the games along a general timeline.

Beneath Apple Manor | 1978
Superficially similar to Rogue, and released a couple of years earlier on home systems.

Rogue | 1980
My, what a yummy slime-mold.

Sword of Fargoal (Commodore 64) | 1982

Moria / Angband | 1983, 1990

Hack / NetHack | 1985, 1987

Larn | 1986

Omega | 198X

Fatal Labyrinth (Genesis) | 1990

Dragon Crystal (Master System, Game Gear) | 1990

Cave Noire (Game Boy) | 1991
Like a cross between Rogue and a puzzle game like Adventures of Lolo. I wrote a short post about the game here.

UnReal World | 1992

ADOM (Ancient Domains of Mystery) | 1994

Alphaman | 1995

Diablo | 1996

Linley’s Dungeon Crawl / Dungeon Crawl Stone Soup | 1997, 2006

IVAN | 2001

Doom, The Roguelike | 2002

POWDER | 2003

Frozen Depths | 2006

Brogue | 2009

Caves of Qud | 2015

Cogmind | 2015

Hauberk | In Development

 …AND MORE! Always more…


Roguelikes Reading List

John Harris wrote several “@Play” blog posts about Roguelikes, Roguelike design, and the genre’s history on GameSetWatch. His articles are collected on his blog,, and in his eBook @Play: Exploring Roguelike Games.

There are many insightful posts about development on the Roguelikedev Subreddit.

RogueBasin is a Roguelike community wiki.

Development Articles

Map Generation
Geometry, Line of Sight and Pathfinding


(e: 2017-Feb-13: Additional article links)

Android Cellular Data Minimalism Strategies

Following are some notes about getting by with a limited monthly 100MB data plan with an Android smartphone. To be expanded as I get more familiar with the platform.

Rough daily data metric is (monthlyData – emergencyData) * 12 / 365, or about 2.63MB per day in my situation.

Set up billing cycle and cap information in Data Usage panel: You can configure Android to shut off Cellular data entirely when a certain threshold is reached.

Blacklist bandwidth-hungry Apps from using Cellular data in the background: also available in the Data Usage panel. Watch for any anomalies day-to-day, and blacklist misbehaving apps.

Pre-filtered web browsing: Chrome and Opera Mini can be configured to minimize image sizes via intermediary proxy servers. Opera Mini can strip out images entirely. Probably not good for any sensitive information, but OK for a quick trivia search.

Google Docs syncing is an incredible hog: Watch out for cloud syncing. Docs uses significant bandwidth to download/upload even a simple todo list.

(e 2017/Feb/13: Emergency data)

Windows 10, NVidia GeForce GTX 750: OpenGL Programs Stutter Severely

OS: Windows 10 64-bit
GPU: GeForce GTX 750
GPU Driver:

Problem: OpenGL programs are stuttering to the point of being unusable.

Experienced with RPG Maker MV, and an old SDL+OpenGL test program that I made a while ago.

Workaround: Rolling back GPU drivers to resolved the issue. I reinstalled and set ‘Threaded Optimization’ in NVidia Control Panel to ‘Off’, and OpenGL applications seem to be working correctly now.

SNES Slap Bass

Don’t ask me why I did this, but some time ago I found the BRR sample for that silly slap bass instrument used in early SNES games (you know, the bwoo bwoo bwoo one), and did a pattern search on the entire archive for files containing a portion of it.

I remembered this sound as being kind of ubiquitous and inescapable on the system, but to my surprise, there weren’t as many matches as I thought there would be. 27 out of over 1500 SPC sets.

There were a few problems with my methodology:

  • The sample could be in an SPC file (in SNES sound RAM) but never actually be used by a track.
  • The sample could be modified slightly, still be recognizable as the bwoo bwoo bwoo we all love/hate, but still no direct match would be detected.
  • Any SNES soundtrack that is incompatible with the SPC dump format (ie any game that uploads new audio data mid-track) won’t be in the archive and therefore won’t be detected.

As an example: there is a slap bass sample in ActRaiser (Filmore) that sounds very similar, but didn’t count as a match. I’m not sure if it’s the same sample though. Paperboy 2 also seemed to dodge the list. Bwoo bwoo bwoo.

I could be missing significantly more, then. In any case, here is the list:

Darius Twin
Dungeon Master
Gan Gan Ganchan
Genjuu Ryodan
Hit the Ice
Hokuto no Ken 6
John Madden Football
Magic Johnson's Super Slam Dunk
Michael Jordan - Chaos in the Windy City
Might and Magic 2 (Japanese Version)
Mega Man X
PGA Tour Golf
Raiden Densetsu
Shinseiki Odysselya
Sonic Blastman
Soul Blazer
Spark World
Super E.D.F. - Earth Defense Force
Super Off Road
Super Soccer Champ
Vs. Collection
World Class Rugby

And here’s a list of matches for the individual SPC files.

(e 19/Mar/2017: Wording)

MIDI Masquerade

In 2015, someone posted a very large collection of MIDI files to Reddit, numbering at around 130,000 files total. I just downloaded and extracted it and I have now become this man.

Many of these files are transcriptions of pop, classical music, and video game soundtracks, dutifully sequenced by fans. Others are pretty awesome original works. Still others are just a single melody or set of chords.

It’s fun to pick a mid file at random, and if you like the track, to try and find out more about what it is, if it’s a cover of something, etc.

Some random picks:

  • ParadiseIsland.mid (Michael Walthius – Adventures on Paradise Island)
  • Streetlife-1.mid (The Crusaders – Street Life)
  • z2lapse.mid (LamSon Nguyen VanLam – Two Lapses)

But let me get to the main topic of this post. For whatever reason, some files that were not MIDI sequences were renamed .mid, and ended up in these internet collections. I guess people running MIDI repository sites weren’t very concerned about screening their files.

Here are some finds:

  • sou.mid – compressed archive containing what appears to be promotional content for a Japanese cop show.

  • how_do_i_live.mid – just an MP3 file. Spotted because it’s the largest file in the set.
  • horse03.mid WAV sample – Legend of Zelda: Ocarina of Time
  • hiatt.mid WAV sample – John Hiatt- Drive South
  • Amanda Wilson – Gotta Let You Go.mid – simply contains the ASCII text “file does not exist”
  • stereo.mid – WAV sample – “This is a journey into sound. A journey which along the way will bring to you new color, new dimension, new values.”
  • Somebody2.mid – dead hyperlink to an MP3 version of Somebody Help Me.

OK, so the only really intriguing one so far is the zip file with Japanese cop show stuff in it. Will add more to this post if I find anything worth highlighting.

1/5/2017 – Most standard MIDI files begin with either “MThd” or “RIFF” as a header identifier. Need to do some more culling, but a quick search for files that don’t match either header yielded around 1000 results.

19/Mar/2017 – Here are some more finds. I think I’ve satisfied my curiosity, and probably won’t come back to this. I just think it’s interesting how tiny bits and pieces of different things all over the world found their way into this collection.

  • andyl15.mid – Old 404 HTML page for the long-defunct web host

  • saluetg.mid – HTML page belonging to ‘The MIDI Farm’.
  • SUPPORT.MID – BBS listings for DMP / Dual Module Player, a module tracker program.
  • TwistAndShout2.mid – Someone’s HTML page about the Beatles’ Please Please Me, presumably a MIDI version of the album.
  • island2.mid – HTML page from “Miss Pita’s Domain”, a Geocities site circa 2000, now long gone. “Edited entirely by WebTv” is proudly displayed at the top. Here’s a mirror of the original site — though this one is a bit different.
  • hall_wee.mid – Multi-part MIME file with a couple of MIDIs based on the Halloween soundtrack (judith.mid and laurie.mid, already in the collection). Includes a promising warning at the top:
Content-Type: text/plain;
Content-Transfer-Encoding: quoted-printable

Do NOT listen to this music at midnight with all the lights off in the =
house. I did once and my friend came VERY fucking close to making me =
shit my pants.
  • F242.MID – This is a tracker module — a different sequencing format that includes instrument samples. F242 refers to German electronic group Front 242, which this module samples (per the internal notes).
  • bark.mid – NeXT Sound File of a dog barking.
  • swans.mid – NeXT Sound File, 19 second excerpt of a song I haven’t identified.
  • meg.mid – Shin Megami Tensei “BMS” music pack. Looping samples and a header file containing sequence data. My understanding is that this would be imported into a rhythm game.
  • bumble_b.mid – Seems to be a system component of an old version of Windows, maybe 3.0 or 3.1. References to EMS and various Windows file paths and fonts.
  • amc.mid – BMS package, similar to meg.mid above.
  • DAYSOF.MID – Sampled tracker module, like F242.MID above.
  • c04014.mid – Text file. Appears to be lyrics for a pop song by Taiwanese duo Ukulele – 《不知所措》 優客李林
  • JOYWRLD.mid – 
  • bluegrass.mid – 
  • absence_of_fear.mid – 
  • two_of_us.mid – 


And here’s a false positive: andshewas.mid is a valid MIDI file. Something prepended a text header to the top — it works if you delete that from the file.

(e:25/Mar/2017: wording)

Windows 10: On lock screen, 2nd monitor does not recover from power-saving mode

(Workaround is in place for this issue, but I want to leave some notes here in case I start looking at it again.)

OS: Windows 10 Pro 64-bit
GPU: NVidia GeForce GTX 750
GPU Driver:
Monitors: LG Flatron w1942TQ (primary), HP w1907 (secondary)

Setup: Windows 10 Desktop PC. Two monitors connected to video card in one of the following ways:

A) Video Card HDMI -> HDMI-to-DVI cable -> Monitor DVI
B) Video Card DVI -> DVI cable -> Monitor DVI
C) Video Card DVI -> DVI-to-VGA adapter, VGA cable -> Monitor VGA

I would prefer option A for contributing the least amount of physical bulk to the cabling of my system.

Problem: When locking the screen (Win+L), the monitors will go to sleep after some time has passed to save power. Upon hitting a key or moving the mouse, both monitors should wake up. When connected via DVI or HDMI-to-DVI, the second monitor will not recover until it is powered off and on again by hand.

When connected with a DVI-to-VGA converter, the second monitor recovers as expected.

Next Actions: Currently I’m using DVI-to-VGA for the secondary monitor. Another option might be to make a registry modification to disable monitor sleep on the lock screen entirely (which I haven’t tried, but someone wrote up the instructions here.)

I’m just curious why it doesn’t work with a digital signal… I haven’t done enough testing to pin down what’s at fault. I updated GPU drivers, but haven’t checked for new BIOS/UEFI versions, haven’t tested with another HDMI monitor, and haven’t swapped the primary/secondary designation for the two monitors. Had enough for today, and there are better things to do to prepare for the new year. Will update if I learn more about what’s going on.

11 Nov 2017 — Currently using Fedora 26, and the same behavior is present. I found an option in the HP w1907 which prevents the monitor from going to sleep while no signal is detected. (Management… -> Power Saver -> Off.) This prevents the issue, but leaves an annoying “Check Signal Cable” test message that ping-pongs across the display, until either the PC starts providing signal again, or you turn the monitor off. Using an analog VGA cable is still a better solution, since the PC is still able to wake this monitor back up following going to sleep.

Maybe analog VGA has some capacity to wake up a monitor that digital DVI/HDMI is lacking.

(e: 11/Nov/2017: updates)