So, the disassembly thing is basically not going to happen. Or at least, not by me. As it turns out, people want tons of money for this kind of software and the free alternatives that I'm willing to run on my computer are lacking in documentation and the features I need to get my foot in the door. Some are written in Python, which is annoying to deal with because everyone has their own pet version of Python that they never upgrade from and require you to install for all their stuff to work.
However, I can make my existing code better, and figure out more of the files.
I've already made the code better, by translating it to C#. It runs faster and is far simpler now. The reason for the simplicity is because my original PowerShell scripts were designed to work with paths containing wildcards and the PowerShell pipeline, so there had to be a bit of overhead in there to transition from one file to the next cleanly. Stuff that an end-user probably wouldn't think of, but would absolutely annoy them if I didn't do it. Namely, closing file handles properly so files don't stay marked as "in use" and become unable to be moved, renamed, or deleted.
But also in my typical fashion there was code in the PowerShell script for the UME files, for a use case I didn't need: some of the UME files are sort of grafted at the hip to System.ume, and being that the script was designed to be able to process an arbitrary number of input files, I put in code that would try to use System.ume from different directories, but if it's still in the same directory it'll keep the current System.ume open, and just seek back to the beginning of it. It's kinda dumb, but I wrote it off as being forward-thinking. After all, this code I'm working on could very well be the basis for modding the game, so maybe you have files for a few different mods you want to convert and they all have their own custom System.ume... While ostensibly there to avoid closing and reopening the same file repeatedly, it does have this other use case.
Yeah, like I said, it's a use case that I didn't actually need. It's technically preserved in the C# code, but the C# code also only handles one file at a time. If you want to process a whole directory, you get to call the method once per file, specifying the path to your desired System.ume with each call. Yeah, there's some overhead to that, constantly closing and re-opening the same System.ume, but the code's cleaner and easier to follow. I also got to re-examine what I was doing and remove some of the stupider bits, so the new code is just... more better.
Both the PCG code and the UME code now exist as C# static methods, along with a couple static methods I created to see what was going on with my transformation of the input path to the output path, that I decided to leave in there because why not. They could be useful. Yeah, the methods don't take an output path as a parameter, they just transform the input path and then bitch if that file already exists. That's kinda how I roll I guess. I did put in a lot of work transforming the file names to be useful, it's not just extension swapping. For example, Akr1b.ume will get transformed to Akira Stage 1 Background.bmp.
As for figuring out more of the files, honestly, without the ability to understand what's going on in the game's code, I can't do very much more. The interesting stuff, the PRT, ROT, SPR, and DMO files, will all take more work than I can realistically do right now. Running some quick commands to get file extension stats shows there's a couple other oddballs in there as well, Enemy.inf and Enemy.pnt. I've looked at those and have no clue where to start. This leaves two pieces of extremely low-hanging fruit: Option.dat and Destroy.sco. Option.dat holds the options, of which the game only has a handful, and aside from the difficulty setting they're all toggles. Destroy.sco holds your high scores. They're such low-hanging that I already have classes for both to allow creating, loading, and saving them.
Destroy.sco was interesting because it contains the same structure repeated 12 times. I chose to represent this in two ways: named properties on my class to allow accessing a specific stage's data by character name, and a custom indexer that puts the stages in the order they appear on the stage select screen from right to left. That's actually significant because the score data in Destroy.sco is not in the same order as the stage select screen. Figuring out the order was easy enough since it was simple to identify which values in the file were the scores. I just set each stage's score to a number from 1 to 12, so when I looked at it in-game I could see which score showed up where. Because I implemented an indexer, it didn't feel right without a Count property and an IEnumerable<T> implementation, so those are present as well. I didn't implement ICollection<T> because it's not actually a collection and doesn't need management methods.
Also, the scores are signed values, which is interesting because if you give it a negative score, it reads an incorrect graphics tile from System.ume when it tries to display the minus sign, despite the fact that there is a minus sign available. Also, if it has to display more than 7 characters for the score (7 digits, or 6 and a minus sign), it won't fit properly in the box on the stage select screen. My code range checks and sanitizes both the scores and the percentages to avoid causing display bugs.
The structure of Option.dat suggests to me that the difficulty setting was probably added later on in development. It appears at the very end of the file even though it shows up at the top of the options screen (everything else is in the order in which it appears on the options screen), Normal difficulty has a value of 0, Easy has a value of 1, and Hard has a value of 2.
Anyway, I've basically done all I can do in terms of figuring out file formats. I suppose that my next endeavor will be trying to tweak the game's graphics files to avoid the palette corruption. This will be annoying given that I can't get GIMP to load the palette from the files in its palette editor. Worst case scenario, I have to roll my own code to change a palette entry and update palette indices to point to the new color, because I'm not writing an image editor.
Friday, October 30, 2020
Friday, October 2, 2020
Sentimental Shooting Graphics Files
So at the end of my previous post, I left a juicy little nugget of information about me poking around the game's graphics files. I've "completed" a major milestone in doing so, and while there's still stuff left to do, I have enough to actually post about.
The game's graphics are in the PCG and UME files. Judging by file extension alone, you wouldn't expect them to be any kind of standard file format that's documented outside of a dark corner of the internet, but... you'd be wrong. Both are standard Windows BMP files, changed ever so slightly so that they don't appear to be proper files if you change their extensions and open them.
The PCG files are the omake pictures, and simply have 0x70 added to the first 0x03E8 bytes of the file. That's it.
The UME files are the stage backgrounds, clothing fragments, enemy and boss sprites, menus, and everything else. System.ume is actually a BMP that's just renamed, but the rest are very close to being proper BMP files. Some have extra bytes at the end that any viewer or editor can easily ignore, but the real kicker is that they have improper data for some of the header fields. You can make extremely minimal changes to allow an image editor to open them, but... for the stage backgrounds at least, we have the ability to make the game output the file directly. Making these minimal changes does not result in a file that matches the one generated by the game.
Thus began my journey for matching output. I discovered that the stage backgrounds saved by the game in the SNAPSHOT directory have various values pulled in from System.ume, including the color palette. Most of the UME files for stage backgrounds actually have a zeroed out section of their palette where the palette from System.ume should go, which made it easy to spot. Something about how the game handles the data zeroes out the padding in each row by the time it ends up in the SNAPSHOT directory, and any extra bytes at the end of the file get removed. Towards the end I identified two groups of files that needed different behavior, but couldn't pinpoint how to detect this from the file contents alone, so I gave in and implemented dirty hacks that check hardcoded filename lists. It's finally over, I have matching output for all 24 stage backgrounds, and no visible corruption in any of the other files, but... it doesn't feel right with the dirty hacks still in there. This is why I put the word "complete" in quotes in the first paragraph: It works, but I don't like it.
One issue is that some files exhibit... interesting changes if the System.ume palette is imported, even though they have the space for it. Some of these changes are easily identified to be incorrect, but others I'm not so sure. I have an idea how to proceed here, but it's low priority in the long run.
A major sticking point is that I have no idea if my code that generates matching output for the stage backgrounds also does so for any of the other files. I have no way to make the game output these files, and thus no way to see what needs to be done. Or, do I?
I have reached a point where all of my remaining logical steps involve disassembling the game to see how it loads the UME files, handles the color palettes, and outputs snapshots. This will be difficult for me for three reasons:
Still though, I now have PowerShell scripts that work for both the PCG and UME files, both of which produce output that matches what the game outputs on its own for every file I can possibly verify it with.
Fixing the palette corruption issues that the Windows compatibility modes mitigate by tweaking the corresponding UME files looks to be possible. Logo.ume defines a full 256-color grayscale palette but only uses a small portion of it. Enemy2.ume, which contains the sprites in which I'd noticed some palette corruption, has plenty of unused palette entries. I just need to figure out which palette entries get corrupted, and move them to areas of the palette that were previously unused. The disassembly can potentially help with that, if I can catch where the palette corruption happens and discover its true extent.
The pipe dream would be to fix whatever code is causing the corruption in the first place and just patch SGSTG.EXE.
I think I'll leave it there for now. I'm at the point where I can open a BMP file in HxD and identify all the fields without having to consult an external reference. If I don't post anything on this subject for a while, I've probably drowned myself in x86 assembly just to tweak a silly hentai game, or given up.
The game's graphics are in the PCG and UME files. Judging by file extension alone, you wouldn't expect them to be any kind of standard file format that's documented outside of a dark corner of the internet, but... you'd be wrong. Both are standard Windows BMP files, changed ever so slightly so that they don't appear to be proper files if you change their extensions and open them.
The PCG files are the omake pictures, and simply have 0x70 added to the first 0x03E8 bytes of the file. That's it.
The UME files are the stage backgrounds, clothing fragments, enemy and boss sprites, menus, and everything else. System.ume is actually a BMP that's just renamed, but the rest are very close to being proper BMP files. Some have extra bytes at the end that any viewer or editor can easily ignore, but the real kicker is that they have improper data for some of the header fields. You can make extremely minimal changes to allow an image editor to open them, but... for the stage backgrounds at least, we have the ability to make the game output the file directly. Making these minimal changes does not result in a file that matches the one generated by the game.
Thus began my journey for matching output. I discovered that the stage backgrounds saved by the game in the SNAPSHOT directory have various values pulled in from System.ume, including the color palette. Most of the UME files for stage backgrounds actually have a zeroed out section of their palette where the palette from System.ume should go, which made it easy to spot. Something about how the game handles the data zeroes out the padding in each row by the time it ends up in the SNAPSHOT directory, and any extra bytes at the end of the file get removed. Towards the end I identified two groups of files that needed different behavior, but couldn't pinpoint how to detect this from the file contents alone, so I gave in and implemented dirty hacks that check hardcoded filename lists. It's finally over, I have matching output for all 24 stage backgrounds, and no visible corruption in any of the other files, but... it doesn't feel right with the dirty hacks still in there. This is why I put the word "complete" in quotes in the first paragraph: It works, but I don't like it.
One issue is that some files exhibit... interesting changes if the System.ume palette is imported, even though they have the space for it. Some of these changes are easily identified to be incorrect, but others I'm not so sure. I have an idea how to proceed here, but it's low priority in the long run.
A major sticking point is that I have no idea if my code that generates matching output for the stage backgrounds also does so for any of the other files. I have no way to make the game output these files, and thus no way to see what needs to be done. Or, do I?
I have reached a point where all of my remaining logical steps involve disassembling the game to see how it loads the UME files, handles the color palettes, and outputs snapshots. This will be difficult for me for three reasons:
- I don't know x86 assembly
- x86 assembly is far more complex than the assembly languages I've learned so far (Z80 and 65816)
- I don't trust the NSA so I'm not installing Ghidra (so there goes its much-touted decompilation feature)
Still though, I now have PowerShell scripts that work for both the PCG and UME files, both of which produce output that matches what the game outputs on its own for every file I can possibly verify it with.
Fixing the palette corruption issues that the Windows compatibility modes mitigate by tweaking the corresponding UME files looks to be possible. Logo.ume defines a full 256-color grayscale palette but only uses a small portion of it. Enemy2.ume, which contains the sprites in which I'd noticed some palette corruption, has plenty of unused palette entries. I just need to figure out which palette entries get corrupted, and move them to areas of the palette that were previously unused. The disassembly can potentially help with that, if I can catch where the palette corruption happens and discover its true extent.
The pipe dream would be to fix whatever code is causing the corruption in the first place and just patch SGSTG.EXE.
I think I'll leave it there for now. I'm at the point where I can open a BMP file in HxD and identify all the fields without having to consult an external reference. If I don't post anything on this subject for a while, I've probably drowned myself in x86 assembly just to tweak a silly hentai game, or given up.
Monday, September 21, 2020
Sentimental Shooting Revisited
So a long time ago I posted about this game. In case you're unfamiliar and too lazy to click the link, it's an ero-danmaku game released in the late 1990s. I unironically enjoy it, not because of the nudity, but because of the gameplay.
In my post, I mentioned that having the music enabled causes the game to crash unless you're on Windows XP. The reason for this is now very clear to me after having done some basic research: Microsoft has been gradually degrading the MIDI support in Windows, and XP was the last version to have proper support.
This means that you can, in fact, have the music enabled without the game crashing. You just need to do some extra things first.
First up, if you're on Windows 8, 8.1, or 10, you'll need to install CoolSoft MIDIMapper. Full disclosure: I'm using Windows 7, so I'm unfamiliar with actually using this.
Next, on Windows Vista or newer, you'll need to install CoolSoft VirtualMIDISynth.
Now, in VirtualMIDISynth, there's some configuration that needs to be done.
However, enable the music cautiously, as the default volume was extremely loud for me. I had to crank it down to around 30% for it to not be louder than the game's sound effects. You can get back into VirtualMIDISynth's configuration using the system tray icon. From there, double-click on the soundfont you installed and the volume setting will be on the dialog box that appears.
Additionally, there's something I did that you may want to do. VirtualMIDISynth has two global keyboard shortcuts enabled by default, and I was worried about them clashing with other games. On the Shortcuts tab, just click in each key combination's text box and press Spacebar, that seems to have disabled them for me.
Edit (2020-11-11): There's now a better solution for fixing the color palette corruption. You should follow that post instead and ignore the suggested compatibility settings here.
There's still one remaining issue with the game, and to address that I need to contradict my earlier post. Specifically, the part where I said:
If you're unsure what the palette corruption looks like, well, the logo when you first start up the game isn't supposed to be red, or color-fringed. Also there's an enemy that sometimes appears outlined in white instead of black. Those are the only two instances of palette corruption I've noticed, at the very least.
I've been tinkering with the game's graphics files and may be able to provide patched files that don't experience the corruption, we'll have to see. More on this as events warrant.
In my post, I mentioned that having the music enabled causes the game to crash unless you're on Windows XP. The reason for this is now very clear to me after having done some basic research: Microsoft has been gradually degrading the MIDI support in Windows, and XP was the last version to have proper support.
This means that you can, in fact, have the music enabled without the game crashing. You just need to do some extra things first.
First up, if you're on Windows 8, 8.1, or 10, you'll need to install CoolSoft MIDIMapper. Full disclosure: I'm using Windows 7, so I'm unfamiliar with actually using this.
Next, on Windows Vista or newer, you'll need to install CoolSoft VirtualMIDISynth.
Now, in VirtualMIDISynth, there's some configuration that needs to be done.
- On the MIDI Mapper tab, set VirtualMIDISynth as the default MIDI out device.
- On the Soundfonts tab, you'll need to click the plus button and select a soundfont. You'll need to download one of these, and thankfully, the download page for VirtualMIDISynth has links to a good number of them. I downloaded the uncompressed version of FluidR3_GM, which so happens to be the first one in the list.
- Do the requisite clicking of Apply and/or OK.
However, enable the music cautiously, as the default volume was extremely loud for me. I had to crank it down to around 30% for it to not be louder than the game's sound effects. You can get back into VirtualMIDISynth's configuration using the system tray icon. From there, double-click on the soundfont you installed and the volume setting will be on the dialog box that appears.
Additionally, there's something I did that you may want to do. VirtualMIDISynth has two global keyboard shortcuts enabled by default, and I was worried about them clashing with other games. On the Shortcuts tab, just click in each key combination's text box and press Spacebar, that seems to have disabled them for me.
Edit (2020-11-11): There's now a better solution for fixing the color palette corruption. You should follow that post instead and ignore the suggested compatibility settings here.
There's still one remaining issue with the game, and to address that I need to contradict my earlier post. Specifically, the part where I said:
That's it, no compatibility modes, no running as administrator, and no extra settings.Without any compatibility options set on the game's executable (SGSTG.EXE), some of the game's graphics palettes are corrupted. The only combination of them that seemed to fix the corruption for me was the following:
- Run in 256 colors
- Run in 640x480 screen resolution
- Disable desktop composition
- Disable display scaling on high DPI settings
If you're unsure what the palette corruption looks like, well, the logo when you first start up the game isn't supposed to be red, or color-fringed. Also there's an enemy that sometimes appears outlined in white instead of black. Those are the only two instances of palette corruption I've noticed, at the very least.
I've been tinkering with the game's graphics files and may be able to provide patched files that don't experience the corruption, we'll have to see. More on this as events warrant.
Friday, July 24, 2020
Re-establishing habits is a struggle
So, sometime in May of 2019, I injured my ankle. I don't even remember how I did it, I was just on one of my walks and went "man, my ankle hurts". It hurt so bad I had to take a few weeks off to let it recover.
When I started being able to walk without pain again, I slowly ramped back up on my walks, always erring on the side of caution. I eventually got back to 100%, completely pain-free, and thought I was back to business as usual, but in reality, the damage to my established habit had already been done. What followed over the next several months was me gradually going out less and less, absolutely dreading the thought of it on most days, and forcing myself to go out anyway a lot of the time. In mid-February 2020, the burnout became clear and I stopped going out for my walk altogether.
It seems rather coincidentally-timed with the rise of the plague, but the months of prior experiences are solid evidence to the contrary. It took until a few weeks ago for me to feel like going out again. However, I decided to ramp back up even more slowly than I did after the injury. Several months of rather extreme inactivity had taken their toll on my legs (and probably my weight, but I don't know for sure; I also stopped weighing myself in February).
Fortunately, Nintendo to the rescue. They released Jump Rope Challenge on the Switch, which I started playing daily, just to work my legs through the inevitable soreness. Once I got to the point where my legs hadn't been sore for a couple weeks, I started going for a walk on every other weekday (that's Monday, Wednesday, and Friday, in case you live under a rock). It's not "The walk", it's just "a walk". One lap around my immediate neighborhood at a (comparatively) leisurely pace. My leisurely pace is probably a pace others would have to push to attain while walking, and the fact I can still do it is a good sign.
I don't really have any concrete plan for ramping back up further, but I need to approach it differently than I approached the walk when I originally started doing it. I'm honestly kind of surprised I was able to keep doing it nearly every day for three years. Leading up to the ankle injury I'd begun taking Saturdays off. The original reason for starting it is no longer the case; I'm still reasonably fit and just need to keep my weight in check. To do that, I need an approachable schedule that's easier to maintain than "every day". That's where the Monday/Wednesday/Friday thing came from, and so far it's working.
I think my next course of action is to increase the number of laps. This echoes how I did it originally. It's worked once before, I see no reason why it can't work again. The only difference is that back then, physical endurance was the limiting factor, and now the limiting factor is not wanting to immediately burn myself out again.
Things are looking up in this regard.
When I started being able to walk without pain again, I slowly ramped back up on my walks, always erring on the side of caution. I eventually got back to 100%, completely pain-free, and thought I was back to business as usual, but in reality, the damage to my established habit had already been done. What followed over the next several months was me gradually going out less and less, absolutely dreading the thought of it on most days, and forcing myself to go out anyway a lot of the time. In mid-February 2020, the burnout became clear and I stopped going out for my walk altogether.
It seems rather coincidentally-timed with the rise of the plague, but the months of prior experiences are solid evidence to the contrary. It took until a few weeks ago for me to feel like going out again. However, I decided to ramp back up even more slowly than I did after the injury. Several months of rather extreme inactivity had taken their toll on my legs (and probably my weight, but I don't know for sure; I also stopped weighing myself in February).
Fortunately, Nintendo to the rescue. They released Jump Rope Challenge on the Switch, which I started playing daily, just to work my legs through the inevitable soreness. Once I got to the point where my legs hadn't been sore for a couple weeks, I started going for a walk on every other weekday (that's Monday, Wednesday, and Friday, in case you live under a rock). It's not "The walk", it's just "a walk". One lap around my immediate neighborhood at a (comparatively) leisurely pace. My leisurely pace is probably a pace others would have to push to attain while walking, and the fact I can still do it is a good sign.
I don't really have any concrete plan for ramping back up further, but I need to approach it differently than I approached the walk when I originally started doing it. I'm honestly kind of surprised I was able to keep doing it nearly every day for three years. Leading up to the ankle injury I'd begun taking Saturdays off. The original reason for starting it is no longer the case; I'm still reasonably fit and just need to keep my weight in check. To do that, I need an approachable schedule that's easier to maintain than "every day". That's where the Monday/Wednesday/Friday thing came from, and so far it's working.
I think my next course of action is to increase the number of laps. This echoes how I did it originally. It's worked once before, I see no reason why it can't work again. The only difference is that back then, physical endurance was the limiting factor, and now the limiting factor is not wanting to immediately burn myself out again.
Things are looking up in this regard.
Sunday, January 5, 2020
MAGFest 18
Of course I went to MAGFest. Of course I still staff the console room. But you already knew that, right? Right.
Let's cut the pointless exposition and get on with it, shall we?
Wednesday
Like any good MAGFest trip for me, it starts on Wednesday. I leave in the evening, aiming to get there just after midnight. Well, that's precisely what happened. Arrived at 12:15 AM.
Thursday
Of course, the first thing to do is to go down to registration in good ol' Expo Hall E, which so happens to be as far away from the parking as possible, and pick up my badge. Interestingly, approximately everything physical tat-related was running behind schedule, so the staff lanyards weren't ready, neither were the staff shirts, and hell, neither were the freaking swadges. The swadges are neat, but ultimately conform to the definition of "physical tat". I have a pile of them in my room here, with very little reason to go find batteries for any one of them to power them up and play with them. The two most recent ones sorta solved this by also accepting USB power, but still.
The staff shirt thing was a very last minute "we don't have them" thing where they sent out an email far too late for anyone travelling from any significant distance away to be able to read in time to pack staff shirts from previous years. Just shows the futility of changing the damn staff shirt every fucking year. They're redundant for consoles anyway, we have the vests. I don't re-wear mine outside the event, I'm not a big fan of red t-shirts.
Anyway, Thursday is always the day I'm up for all 24 hours of, and this year was certainly no exception. I planned ahead and brought a travel mug full of coffee with me, which just barely lasted me until the coffee place in the atrium of the Gaylord opened and I could procure more. A move I should have repeated throughout the day, but more on that later.
Eventually, the hotel went from being fairly empty to being "attendees everywhere" and the time of MAGFest was upon us. Grabbed a spot in line for the dealers' room so I could get in when it opened, and made three purchases which ended up being my only purchases of the weekend: A Super Game Boy 2, a cartridge of Final Fantasy Adventure for the Game Boy, and an actual legit copy of Rogue Galaxy for the PS2.
The Super Game Boy 2 is almost identical to the original, but there are a number of reasons to seek one out:
If you sift through my archives, you'll find a whole series of posts where I was playing through Rogue Galaxy, offering my thoughts on the story and explaining anything going on in my gameplay, whether easy, difficult, or neat. Well, I kinda glossed over how I actually obtained the game, and that's because I just kinda downloaded the ISO of it and chucked it on my PS2's hard drive. Given how much I liked the game, I wanted to actually have a legit physical copy, so this takes care of that. Interestingly, when I was flipping through the manual in the case, a purchase receipt fell out. The game's previous owner apparently bought it for $15 in a GameStop in Brooklyn, NY, back in 2010. I could tell it was GameStop inventory at one point or another in its existence anyway because of the damn stickers all over it, which I managed to remove before taking the photo. What you can't see in the photo is that the case is slightly damaged, but hey, I can probably source another case if it becomes a problem. Just find some bargain bin PS2 game and do a swap. Also, the box art has some water damage, but it isn't really visible.
I made an attempt to test the SGB2 and Final Fantasy Adventure in the console room, but I forgot that the SGB2 is a Super Famicom cartridge and thus doesn't have the slots for the tabs in a US SNES' cartridge slot, and none of MAGFest's Super Nintendos have the tabs removed. Testing was postponed until I got home, where I popped the combo into my SNES and it booted right up first try, which was kinda unexpected.
Yeah, that's one of the SGB2-exclusive borders. The SGB2 ones are nice. Also, in looking up how to access the SGB1 borders, I uncovered a bit of trivia I didn't know: almost all the borders have an idle animation that plays after a while of you not pressing buttons. You can also input a button sequence to start it playing immediately. I immediately went through all the borders looking at their idle animations. Also uncovered is that you can input that same button combo on the default SGB2 border to change its color.
I've been dodging actually mentioning the button sequence and that's because there's a little more setup to it. To get the SGB1 borders you have to select the black border and exit the SGB menu, then enter the button sequence: . You'll hear a chime if done correctly. Go back into the SGB menu and you'll find the SGB1 borders available. If you input that button sequence with the default border selected, that's what changes its color. Finally, if you input that sequence with basically any other border selected, its idle animation will start.
Anyway, 4 PM rolled around and I was finally able to check into my room. I wasn't the first one, and actually, all four people showed up this year, so no room to myself again. I only got to talk to three of them, interestingly. The fourth was never awake when I was awake.
Fitness stuff still happened, I'll just mention that here and nowhere else.
Friday
So my first staff shift began promptly at midnight, and this is where the subject of my caffeination, or the lack thereof, comes into play. I was almost dead by the end of it. Anyway, dragged my ass upstairs and went to sleep.
After a good amount of sleep I went back down to Consoles and did some of the challenges, for which I never actually claimed the one reward I earned: a single M-point. I've got enough physical tat, and I never spend M-points anyway.
There isn't much I remember about Friday. It was really all just playing games and having fun. I figured out Pole Position on the Atari 2600 at some point. It's a surprisingly well-done game for the Atari 2600, somehow managing to cram all the necessary controls into a joystick and a single button. Like I said, fun was had.
Saturday
Another midnight, another staff shift. I was considerably less dead at the end of this one, on account of having actually gotten sleep. The consoles this year were (mostly) all in cages, locked with key-locks. Some didn't have key-locks and were instead zip-tied shut, which was annoying to encounter. This also meant that some consoles were a lot harder to do game swaps for than others. Basically any console with a front-loading disc tray, like the PS2 or Xbox 360. I still don't know what they were thinking with the placement of those, I had to turn so many cages sideways just to be able to open them far enough for the tray to fully eject. Also there was a GameCube whose lid latch had broken, which was fun to discover while attempting to do a game swap on said GameCube. It was working properly, I opened the lid and swapped the game, and then it just wouldn't close anymore. The "doing it live" solution got implemented: just tape it down.
Anyway, after that shift, sleep.
I had wanted to do another Pepper Palace run this MAGFest but had forgotten to go mid-day Thursday. Looked up their hours and discovered they were open until 10 PM, so I went after grabbing some dinner from staff suite. Tasted a bunch of stuff and ended up grabbing a salsa and a mustard. I got three bottles of hot sauce for Christmas, which influenced me to look at their non-hot-sauce products.
Messed around with some computers in the Museum for a bit before heading down to do my final shift of the event. Man, these things fly by.
Sunday
Last shift, and this one ended at 4 AM instead of 8 AM like the others. No incredibly unusual requests for games this year, certainly nothing like previous years where an attendee would ask for a game reccomendation or say "I'd like to play X genre of game on the SNES, surprise me" or anything like that. Smooth sailing through the weekend. Got off my shift and went upstairs to get whatever sleep I could before about 10 AM, just to give me enough time to get my shit together and get out of the hotel before the hotel's deadline, which MAGFest said was 11 AM but the hotel said was noon. I dunno about you, but I'll trust what the hotel says over what MAGFest says in this regard.
Anyway, the drive back was fairly uneventful, thankfully. Started to encounter a traffic jam due to an accident on I-95 southbound, but luckily the Dale City rest stop was right there. Stopped, took care of coffee-related business, and by the time I got back to the car, traffic was moving again. Some jerk tailgated me for a while on Route 20, but eventually found a cromulent passing zone and went about his way at 1.5x the speed limit or whatever those jerks think they're entitled to do.
Video games are fun.
Let's cut the pointless exposition and get on with it, shall we?
Wednesday
Like any good MAGFest trip for me, it starts on Wednesday. I leave in the evening, aiming to get there just after midnight. Well, that's precisely what happened. Arrived at 12:15 AM.
Thursday
Of course, the first thing to do is to go down to registration in good ol' Expo Hall E, which so happens to be as far away from the parking as possible, and pick up my badge. Interestingly, approximately everything physical tat-related was running behind schedule, so the staff lanyards weren't ready, neither were the staff shirts, and hell, neither were the freaking swadges. The swadges are neat, but ultimately conform to the definition of "physical tat". I have a pile of them in my room here, with very little reason to go find batteries for any one of them to power them up and play with them. The two most recent ones sorta solved this by also accepting USB power, but still.
The staff shirt thing was a very last minute "we don't have them" thing where they sent out an email far too late for anyone travelling from any significant distance away to be able to read in time to pack staff shirts from previous years. Just shows the futility of changing the damn staff shirt every fucking year. They're redundant for consoles anyway, we have the vests. I don't re-wear mine outside the event, I'm not a big fan of red t-shirts.
Anyway, Thursday is always the day I'm up for all 24 hours of, and this year was certainly no exception. I planned ahead and brought a travel mug full of coffee with me, which just barely lasted me until the coffee place in the atrium of the Gaylord opened and I could procure more. A move I should have repeated throughout the day, but more on that later.
Eventually, the hotel went from being fairly empty to being "attendees everywhere" and the time of MAGFest was upon us. Grabbed a spot in line for the dealers' room so I could get in when it opened, and made three purchases which ended up being my only purchases of the weekend: A Super Game Boy 2, a cartridge of Final Fantasy Adventure for the Game Boy, and an actual legit copy of Rogue Galaxy for the PS2.
 |
| It's at an angle to avoid getting my shadow in the picture lol |
- It actually runs the games at the correct speed. The original model runs them about 3% too fast, which perhaps matters more for some games than others, but it affects everything, including the music. This point is most relevant if you're going to be speedrunning Game Boy games.
- It has a link port. This coupled with having the correct clock speed makes linking to other Game Boy systems possible. They had to correct the clock rate issue and add the link port because of a little game called Pokemon. Ever heard of it? ;)
- It has an extra set of borders to place around the game you're playing, with the original model's set of borders available if you enter a button sequence. Of course, if a game has a custom border, it'll still show that by default.
- Also, some games have a different border if they detect that they're running on a Super Game Boy 2. One example I found while searching the internet for SGB2 stuff is Tetris DX.
If you sift through my archives, you'll find a whole series of posts where I was playing through Rogue Galaxy, offering my thoughts on the story and explaining anything going on in my gameplay, whether easy, difficult, or neat. Well, I kinda glossed over how I actually obtained the game, and that's because I just kinda downloaded the ISO of it and chucked it on my PS2's hard drive. Given how much I liked the game, I wanted to actually have a legit physical copy, so this takes care of that. Interestingly, when I was flipping through the manual in the case, a purchase receipt fell out. The game's previous owner apparently bought it for $15 in a GameStop in Brooklyn, NY, back in 2010. I could tell it was GameStop inventory at one point or another in its existence anyway because of the damn stickers all over it, which I managed to remove before taking the photo. What you can't see in the photo is that the case is slightly damaged, but hey, I can probably source another case if it becomes a problem. Just find some bargain bin PS2 game and do a swap. Also, the box art has some water damage, but it isn't really visible.
I made an attempt to test the SGB2 and Final Fantasy Adventure in the console room, but I forgot that the SGB2 is a Super Famicom cartridge and thus doesn't have the slots for the tabs in a US SNES' cartridge slot, and none of MAGFest's Super Nintendos have the tabs removed. Testing was postponed until I got home, where I popped the combo into my SNES and it booted right up first try, which was kinda unexpected.
 |
| I changed the palette from the SGB's weird default dark purple thing to the much more sensible grayscale palette before taking this photo. |
I've been dodging actually mentioning the button sequence and that's because there's a little more setup to it. To get the SGB1 borders you have to select the black border and exit the SGB menu, then enter the button sequence: . You'll hear a chime if done correctly. Go back into the SGB menu and you'll find the SGB1 borders available. If you input that button sequence with the default border selected, that's what changes its color. Finally, if you input that sequence with basically any other border selected, its idle animation will start.
Anyway, 4 PM rolled around and I was finally able to check into my room. I wasn't the first one, and actually, all four people showed up this year, so no room to myself again. I only got to talk to three of them, interestingly. The fourth was never awake when I was awake.
Fitness stuff still happened, I'll just mention that here and nowhere else.
Friday
So my first staff shift began promptly at midnight, and this is where the subject of my caffeination, or the lack thereof, comes into play. I was almost dead by the end of it. Anyway, dragged my ass upstairs and went to sleep.
After a good amount of sleep I went back down to Consoles and did some of the challenges, for which I never actually claimed the one reward I earned: a single M-point. I've got enough physical tat, and I never spend M-points anyway.
There isn't much I remember about Friday. It was really all just playing games and having fun. I figured out Pole Position on the Atari 2600 at some point. It's a surprisingly well-done game for the Atari 2600, somehow managing to cram all the necessary controls into a joystick and a single button. Like I said, fun was had.
Saturday
Another midnight, another staff shift. I was considerably less dead at the end of this one, on account of having actually gotten sleep. The consoles this year were (mostly) all in cages, locked with key-locks. Some didn't have key-locks and were instead zip-tied shut, which was annoying to encounter. This also meant that some consoles were a lot harder to do game swaps for than others. Basically any console with a front-loading disc tray, like the PS2 or Xbox 360. I still don't know what they were thinking with the placement of those, I had to turn so many cages sideways just to be able to open them far enough for the tray to fully eject. Also there was a GameCube whose lid latch had broken, which was fun to discover while attempting to do a game swap on said GameCube. It was working properly, I opened the lid and swapped the game, and then it just wouldn't close anymore. The "doing it live" solution got implemented: just tape it down.
Anyway, after that shift, sleep.
I had wanted to do another Pepper Palace run this MAGFest but had forgotten to go mid-day Thursday. Looked up their hours and discovered they were open until 10 PM, so I went after grabbing some dinner from staff suite. Tasted a bunch of stuff and ended up grabbing a salsa and a mustard. I got three bottles of hot sauce for Christmas, which influenced me to look at their non-hot-sauce products.
Messed around with some computers in the Museum for a bit before heading down to do my final shift of the event. Man, these things fly by.
Sunday
Last shift, and this one ended at 4 AM instead of 8 AM like the others. No incredibly unusual requests for games this year, certainly nothing like previous years where an attendee would ask for a game reccomendation or say "I'd like to play X genre of game on the SNES, surprise me" or anything like that. Smooth sailing through the weekend. Got off my shift and went upstairs to get whatever sleep I could before about 10 AM, just to give me enough time to get my shit together and get out of the hotel before the hotel's deadline, which MAGFest said was 11 AM but the hotel said was noon. I dunno about you, but I'll trust what the hotel says over what MAGFest says in this regard.
Anyway, the drive back was fairly uneventful, thankfully. Started to encounter a traffic jam due to an accident on I-95 southbound, but luckily the Dale City rest stop was right there. Stopped, took care of coffee-related business, and by the time I got back to the car, traffic was moving again. Some jerk tailgated me for a while on Route 20, but eventually found a cromulent passing zone and went about his way at 1.5x the speed limit or whatever those jerks think they're entitled to do.
Video games are fun.
Saturday, December 7, 2019
Revenge of the Bird King (Switch)
Like many others, I was intrigued when this retro-styled indie game popped up on the Nintendo Switch eShop, on sale for a measly 9 cents. I mean, I had more than 9 gold points, so whatever, I grabbed it. There's a limit to how bad a retro-styled platforming adventure game can be, right?
Well, sorta.
It takes influences from a lot of classic NES titles, namely Mega Man and The Legend of Zelda 2: Link's Adventure. In addition, there's a central hub area on the world map that serves as a save point and a shop, and you warp back there after completing a level. So far, so good.
The overworld is where the Zelda 2 influence shows itself. From the graphics tiles representing areas you can enter, to the black silhouetted enemies that pop up and pull you into a short level if you touch them. If you've played Zelda 2, it's very similar. Except that you can pause and select "exit to map" if you didn't want to actually get pulled into that short level by the black silhouetted enemies, which I'll leave as a plus.
The main stages are very much Mega Man-inspired, mostly consisting of a series of screens you navigate without a huge amount of screen scroll involved until you reach the edge of the screen. There are a few exceptions, though. There's a stage that takes place on a train that's just one long stage rather than being divided up into screens, as one might expect a train stage to be. Also, there's a stage where you're flying a vehicle that's an autoscroller. There are other examples on a smaller scale, but those are the notable ones.
The music is great. It's very NES-inspired, to go along with the graphics. It probably uses more sound channels than the NES had available, though. In the case that's true, they're not real chiptunes. Still enjoyable though. I'll take an NES orchestra.
Controls are fairly normal, but have their quirks that are tied to the overall design and premise of the game. You play as a bird that uses guns. He has a sword, but you can't really use it in combat too much, it's more for clearing obstructions and knocking armor off of certain enemies. The main quirk is the guns: they're plants. You can plant seeds that grow into guns, and as you play through the game, more guns get unlocked. You have to buy the vast majority of them, but the basic pistol is unlimited. Just pressing the button grows a gun that you can then pick up and use until it runs out of ammo, but if you hold the button, a turret grows instead.
If you were to go off of everything I've just said, you'd probably be 100% ready to plunk down your money for a neat indie retro-inspired platforming adventure game. However, there are a number of things that may make you reconsider, that I will now delve into.
Well, sorta.
It takes influences from a lot of classic NES titles, namely Mega Man and The Legend of Zelda 2: Link's Adventure. In addition, there's a central hub area on the world map that serves as a save point and a shop, and you warp back there after completing a level. So far, so good.
The overworld is where the Zelda 2 influence shows itself. From the graphics tiles representing areas you can enter, to the black silhouetted enemies that pop up and pull you into a short level if you touch them. If you've played Zelda 2, it's very similar. Except that you can pause and select "exit to map" if you didn't want to actually get pulled into that short level by the black silhouetted enemies, which I'll leave as a plus.
The main stages are very much Mega Man-inspired, mostly consisting of a series of screens you navigate without a huge amount of screen scroll involved until you reach the edge of the screen. There are a few exceptions, though. There's a stage that takes place on a train that's just one long stage rather than being divided up into screens, as one might expect a train stage to be. Also, there's a stage where you're flying a vehicle that's an autoscroller. There are other examples on a smaller scale, but those are the notable ones.
The music is great. It's very NES-inspired, to go along with the graphics. It probably uses more sound channels than the NES had available, though. In the case that's true, they're not real chiptunes. Still enjoyable though. I'll take an NES orchestra.
Controls are fairly normal, but have their quirks that are tied to the overall design and premise of the game. You play as a bird that uses guns. He has a sword, but you can't really use it in combat too much, it's more for clearing obstructions and knocking armor off of certain enemies. The main quirk is the guns: they're plants. You can plant seeds that grow into guns, and as you play through the game, more guns get unlocked. You have to buy the vast majority of them, but the basic pistol is unlimited. Just pressing the button grows a gun that you can then pick up and use until it runs out of ammo, but if you hold the button, a turret grows instead.
If you were to go off of everything I've just said, you'd probably be 100% ready to plunk down your money for a neat indie retro-inspired platforming adventure game. However, there are a number of things that may make you reconsider, that I will now delve into.
Wednesday, August 7, 2019
Thoughts with XT: Unhealthy Breakfast Pastries
Am I the only one who never really enjoyed Toaster Strudels?
Toaster Strudels must be kept frozen until you want to eat them, at which point they must be heated, making them vastly less convenient. Also, you have to apply the frosting/icing (is there a difference?) yourself, delaying breakfast even further. Heating of anything from frozen yields inconsistent results, so much so that Toaster Strudels actually have a second set of directions for when you bite in and discover that it's still cold. They also get crumbs everywhere while you eat them.
Pop-Tarts, on the other hand, can be stored at room temperature. They can be eaten that way too, if you just don't feel like toasting them. Underrated: eating a Pop-Tart straight out of the freezer, though this varies by variety. The Cookies 'n Creme ones yield the best results, from my extensive testing over the years. Pop-Tarts crumble way less while being eaten, and also come in way more varieties, from the sickeningly sweet Wildlicious and Gone Nutty ones that I wouldn't give to my worst enemy, to the clearly superior S'mores.
From an advertising standpoint, Pop-Tarts were always the very straightforward "Hey look, these are Pop-Tarts. Enjoy!". Toaster Strudel, on the other hand, were the far more edgy "We're better than Pop-Tarts. Our commercial is going to show several reasons why we aren't, but don't worry, we're going to spin those as positives. By the way, we're better than Pop-Tarts. Look at how this kid has to get black market Toaster Strudels because his evil parents won't serve them to him. Did you know we're better than Pop-Tarts?".
I'll take Pop-Tarts, kthx.
Toaster Strudels must be kept frozen until you want to eat them, at which point they must be heated, making them vastly less convenient. Also, you have to apply the frosting/icing (is there a difference?) yourself, delaying breakfast even further. Heating of anything from frozen yields inconsistent results, so much so that Toaster Strudels actually have a second set of directions for when you bite in and discover that it's still cold. They also get crumbs everywhere while you eat them.
Pop-Tarts, on the other hand, can be stored at room temperature. They can be eaten that way too, if you just don't feel like toasting them. Underrated: eating a Pop-Tart straight out of the freezer, though this varies by variety. The Cookies 'n Creme ones yield the best results, from my extensive testing over the years. Pop-Tarts crumble way less while being eaten, and also come in way more varieties, from the sickeningly sweet Wildlicious and Gone Nutty ones that I wouldn't give to my worst enemy, to the clearly superior S'mores.
From an advertising standpoint, Pop-Tarts were always the very straightforward "Hey look, these are Pop-Tarts. Enjoy!". Toaster Strudel, on the other hand, were the far more edgy "We're better than Pop-Tarts. Our commercial is going to show several reasons why we aren't, but don't worry, we're going to spin those as positives. By the way, we're better than Pop-Tarts. Look at how this kid has to get black market Toaster Strudels because his evil parents won't serve them to him. Did you know we're better than Pop-Tarts?".
I'll take Pop-Tarts, kthx.
Subscribe to:
Posts (Atom)