Archive for the Category: '
Games '

A lot of older games and software have received source ports over the years; furthermore, a lot of those older titles have had remakes or revisions that improve the underlying engine, adding features that were not available at the time the game was created. These capabilities tend to start with Source ports which add additional features, and sometimes a wild source port appears which is dedicated to introducing modern graphics features and/or high resolution textures. There tends to be two camps when it comes to the “best” way to replay these older games. There are those who argue that these modern source ports “aren’t the way the game was intended to be” and violate a sacrosanct code of ethics regarding playing games, and there are those who think if you can make something look or play better, why not. I fall largely into the latter camp. My logic is that if the capability had been there then the games were more likely to have the enhanced capabilities that we find in source ports, and the lack thereof isn’t a direct indicator of those aspects going directly against design intentions. Furthermore, I reason that if we go down that route about “intent” then we should be forcing many of these games to run in very low resolutions or to struggle with low framerates, in order to match the typical system capabilities of the era.

A few specific titles come to mind when it comes to these sorts of titles. There are plenty of source ports and configurability that allows players to be “pure” and entirely consistent with the original titles, as well as those which appeal to those who want to replay the game with a bit more flair.

Doom

Doom may not be the earliest game to receive this sort of treatment- as Wolfenstein 3D also has seen some similar things- but it was the first “big” one. Doom is one of the earliest examples of rather wide modifications of a game, partly because of how it was structured. This led to an endless supply of WAD files that you can download and play, particularly those constructed for

Doom running via the “Chocolate Doom” Source port.

Doom II. The original DOOM as well as Doom II was an MS-DOS game which ran on, unsurprisingly, MS-DOS. This meant that playing it on later systems, such as Windows 95, 98, and particularly 2000 or XP, meant that you had to deal with quirks from it being an MS-DOS game. Source ports changed this; by taking the original source and porting it to these newer platforms, the game could be run on any number of other platforms that were distinctly not MS-DOS. It wasn’t long before these source ports started to include additional features. For example, Doom Legacy was a source port which, among other things, could have the blood splats that flew off of enemies stick to walls and floors. Other source ports had similar features, extended the engine, or added their own capabilities. Nowadays, there are large modifications to the base game such as Brutal Doom or Project Brutality which significantly alter gameplay. You can use high resolution

Doom running via The GZDoom Source Port

textures and there are even Models that you can use to replace all sprites in the games. Traditionalists haven’t been left out; Chocolate Doom is a source port that runs on pretty much any platform- even MS-DOS itself- which seeks to keep the gameplay as original as possible.

One thing I’ve noticed in particular is that it seems to have it’s own OPL3 Based Music synthesizer built in, whereas other source ports use the system MIDI synth. I’m personally partial to Project Brutality via gzDoom, myself, as I feel it makes playthroughs more interesting and unpredictable because of new, unique enemies and weapons as well as enemy and pickup randomization. I also like to use a tweaked version of Oblige, ObHack, which is a WAD generator which I then modified (the LUA scripts) even further to increase enemy, ammo, and health amounts to ridiculous degrees, though that’s not really here or there.

Duke Nukem 3D

Duke Nukem 3D via eDuke32, using the “Classic” Renderer

Duke Nukem 3D was the 3D followup to, well, Duke Nukem 2. The Misogynist main character and his one liners was right at home in the late

90’s, and it received an expansion (in the form of the Atomic Edition, as well as a Plutonium Pak, which basically changed a normal install into

Duke nukem 3D, via eDuke32, using the Polymer Renderer and High resolution pack.

the Atomic Edition) and several unofficial add-ons such as “Duke it out in D.C”; Like Doom, it also had a vibrant community of level creators, kickstarted, somewhat, by the original CD including the Level Editor, BUILD. It has it’s own share of Source ports, but unlike Doom, there is one that stands head and shoulders about the rest- eDuke32. This port has pretty much any feature you could possibly want; including a brand new 3-D Renderer that allows for not only high resolution textures and models, but features like dynamic lighting, models, and various new image maps like normal and bump maps being supported.

Quake

Quake ended up being quite a different game when released then it was originally advertised in Commander Keen Episode 2:

The “Quake Preview”, then called “A Fight for Justice” found in Commander Keen, Episode 2.

Instead of what was presented here, by the time of it’s eventual release, the game was almost, one could say, a Doom clone; the gameplay was very much the same as Doom, with a slightly

Quake as seen via the relatively faithful Makaqu source port.

different story surrounding it- rather than a Space Marine fighting your way through Hell’s demons, you are fighting interdimensional demons. Of course Quake introduced a brand new, fully 3-D engine, which was one of the earliest implemented as well. At the time, it’s graphics

the same location in-game as seen in the enhanced Darkplaces Source Port.

capabilities were rather ground-breaking. While the DOS game normally used CPU-based Software rendering, paired with support for VESA standard resolution support, You could also get a version which used OpenGL, (or even a variant which internally converted OpenGL calls to Glide for those users with 3DFX Cards). Quake, Like Doom, was eventually Open Sourced. as a result of this, it, too, has seen innumerable “Source ports”; from egoboosting <name>quake.exe versions where people just slap their screenname or first name in front and add a few features, to full-fledged, complete reworks of the base engine. I’m particular to Darkplaces myself. This was actually part of what spawned this entire post, which is that when I posted a screenshot of Darkplaces with “all the trimmings” it was met with some lukewarm responses about how that “isn’t how it is intended”; Naturally, their recommendation for the “proper” way to play was another source port, which I think I’d most liken to Chocolate Doom, Makaqu.

Quake II

Quake, a game about fighting interdimensional demon hordes, naturally spawned a sequel where you play the role of a space marine in a retaliatory attack against an Alien race. Alright, so it wasn’t really a sequel in anything but name. Even so, the gameplay is very similar.

A scene from Quake 2’s original released product.

And, we see much the same “aftermarket” support appear long after the game had fell from the public eye. One can find enhanced source ports with dynamic lighting and even high resolution texture packs available for it, such as Quake2XP, r1q2, Berserkerq2.

One of the best parts about games where these sort of aftermarket additions and modifications exist is that you can generally play the game on

modern systems. A lot of older games that were held onto more closely by their manufacturers require very specific hardware configurations and setups, or have compatibility issues. This presents a problem for playing those titles today without actually procuring a system built specifically towards those title’s particular limitations. Open Sourced commercial games of “yesteryear” means that people who want to give the game a replay on their new PC can play it without major compatibility concerns as well as crank visuals to 11 if they so desire.

With a few decades behind it, Electronics how have an established “history”. This has resulted in a rather curious change in how “aftermarket” revisions to the hardware are regarded by some.

A good example would be the labels on Video game cartridges. If for example a label is torn or ripped, a person might decide to replace it. It is possible to make nearly perfect replicas of the original labels. The problem arises however in that there are people who find this behaviour unethical; in their opinion, these “reproduction” labels should be labelled as such, because it is not part of the original.

To me that argument makes far more sense when discussing things like reproduction ROMs, where the actual game “Card” and contents of the cartridge differ from the original. In particular, in that case the reproduction is effectively created afterwards, and typically those who make them and sell them aim to reproduce wildly popular and expensive titles in order to try to “cash in” on the rising demand for titles that have a limited supply.

But I do not think that extends to cosmetic considerations. If you have a copy of Bubble Bobble with a label that has ripped off, you aren’t “destroying history” by cleaning off the old label and affixing a freshly printed one. You are restoring your copy of the game. That such things could then be sold and mistaken for a good condition original is irrelevant, because the market that values good-condition labels was built entirely around conditions where the labels could not be fixed in this manner, and rather than deny or question those who create and affix reproduction labels to fix their games, collectors and those interested in purchasing these things should be aware of how good condition labels may not be original.

If I own a game with a damaged label, it is not my responsibility to adhere to some invented set of rules about what I’m “allowed” to do with it. I own the physical object, I can do anything I want with it, including replacing the damaged label however I see fit. The same applies to any piece of electronics, collectible or not. There is no unspoken responsibility for an owner of, say an Apple II, to keep it in factory condition; installing or using modern alternatives for things like Hard Drives (SD Card adapters, for example) does not magically make them a traitor against humanity or whatever wild accusations many people seem to often make against those who make aftermarket changes or restoration to their hardware.

The Industry is still relatively young but it appears we have reached a point where collectors – and speculators – take themselves as seriously as, say, collectors of old coins. There is a big difference between an original Spanish piece-of-eight from the 1500’s and a Video game cartridge from 20 years ago, both in terms of value as well as cultural and historical significance, and I think considering them equal heavily inflates the importance of Video games and the associated hardware. The people that made and were responsible for these are largely still alive. We may as well suggest that former presidents who are still alive be encased in plastic to preserve their historical significance.

Over time a lot of game franchises have appeared and many of them have many installments. Sometimes, you’ll try a much later release in the franchise and find you quite enjoy it, and decide to hop backwards- and see what you missed in previous ones.

As one might already guess, That’s effectively what I did and what I aim to discuss here. Specifically, a few years ago, for some reason, I wanted a new “thing” and decided to get an XBox One. Being that I was interested in a more complete racing game experience than Project CARS or Assetto Corsa seemed to provide- both of which still felt like Alpha-quality software particularly in terms of their menu interface, I decided to get the Forza Motorsport 6 Bundle/Edition. I actually hemmed and hawwed on the decision for a while because it was an awful lot to throw down on something I had difficulty actually justifying, particularly as I had never even heard of the series before; But I tossed my chips in anyway.

It comes as no surprise given what I’ve written here that I ended up quite liking the game. Which actually was a surprise to me since I’m not generally very car savvy or interested in cars. It’s worked out so far to about a dollar an hour of total playtime just with that one game.

Eventually the “6” got me thinking about the predecessor titles. So, following my typical style, I went overboard and got them all:

So far I don’t have any regrets; I’ve been playing through the first installment and I think it offers enough of it’s own uniqueness that it’s worth playing. In particular, having never owned the original XBox system before I was intrigued with the system as a whole and in particular the ability to have custom soundtracks. 2, 3, and 4 are for the XBox 360- which I’ve never owned either, so I once again went all in and have a new one on the way, for when I get through the first installment.

It is rather interesting how much variation there is between games that really were designed with the same intent. Ignoring for example graphical enhancements, you have to consider vehicle and even track licensing; As an example the Opel Speedster is available in the Original Forza Motorsport title but isn’t in Forza Motorsport 6; meanwhile settings like the New York Track and Tokyo tracks (among many others) simply are not available in the latest game, which themselves have tracks not available in earlier titles. My hope is that as I slowly make my way through each title each game provides a diverse enough experience that it isn’t too much of the same thing over and over.

For a while now Windows 10 has had a “Game Mode” feature. I’m rather mixed on the feature myself, but generally find it strange.

I’ve never been a fan of the “Game Booster” software phenotype; it seems like it is largely snake oil fakery, and where it does have an effect, it is really just a result of the same sort of adjustments that can be made manually via services or other configuration options. Game Mode does have an advantage, here; the first is that it sort of puts those applications “out of business”, and, being built into the OS, it is a much safer implementation, and it’s goals are less extreme. On the other hand, it does sort of legitimize the concept, which I’ve always found crazy, that such applications are in any way worth using.

I tend not to use the feature, however I can see it having benefits for some users and some systems. To me, overlay features such as the Game Bar that are used in this case feel like a sort of “chaff”; It is better than older approaches like the “Games for Windows Live” featureset, and better implemented as well, but I’ve found that- at least for now- it’s not really for me. This may be partly because I’m not a particularly heavy gamer, though- I seldom play games on my PC- nowhere near what I expected.

I also tend to enjoy older titles. Interestingly, I’ve found many older games- even going back to Win98 Games, run surprisingly well on Windows 10, most issues I’ve encountered with older titles tend to be a result of either lack of 16-bit compatibility (with much older titles) or are a result of the hardware being far in excess of what the game ever expected. A lot of older titles don’t have support for 2560×1440 for example because it is such a high resolution, requiring minor patches. Windows 10 is surprisingly backwards compatible in this regard. Even better than previous Post-Vista Windows releases, including Windows 7 which had an interesting explorer palette realization issue. that tended to cause problems with games that used 256-color modes.

As anybody knows, there can be a lot of incorrect information on the internet. Internet “Just so” stories can spread like wildfire if they are believable and explain something neatly. One of those “just so” stories involves older game consoles and computers; over time, we find that our once-white and gray plastics on old systems like Apple II’s, NES consoles, SNES consoles, and so on change colour; they change from white or gray to yellow, and over time that yellow darkens, sometimes even turning brown.

This phenomena is “explained” here. Or is it? Does what is stated there about the process reflect reality? Does it make chemical sense? To the layman or casual observer- hey, it makes sense. Bromine IS brown, after all, it’s added to the plastic. But is there a chemical basis and support for it? What reactions actually take place?

“RetroBright”- which is basically just Hydrogen peroxide – is commonly recommended to “reverse” the effects. The reason I care about the actual chemical properties is because the yellowing itself goin g away isn’t an indication that everything is back to how it was. Colour changes can be the result of all sorts of things. More importantly, if we learn the actual chemical processes involved, perhaps we can come up with alternative approaches.

Basically, the story put forth in the article is a rather commonly repeated myth- a Chemical “just-so” story of sorts- “Bromine is brown so that must be it” Is the extent of the intellectual discussion regarding chemistry, more or less. Generally though there isn’t much drive to look further into it- it all makes sense to the layman on the surface, or even one with rather standard chemistry knowledge. But when you look deeper than the surface of the concept- you see that the commonly held belief that Brominated Flame Retardants are responsible doesn’t seem to hold up.

First we can start with the first inaccuracy in that link- Bromine is not added as a flame retardant- that is flat out, categorically and completely wrong, and trivially easy to refute. Bromine compounds are added as flame retardants, But as they are compounds, the colour of elemental Bromine (brown) is irrelevant, because elemental Bromine is not added to the plastic. Specifically, chemicals like Tetrabromobisphenol A. (C15H12Br4O2).

The article also says that “The problem is that bromine undergoes a reaction when exposed to ultraviolet (UV) radiation” But Bromine doesn’t photo-oxidize. It doesn’t even react with anything in the air on it’s own; creating Bromine dioxide either involves exposing it to Ozone at very low temperatures alongside trichlorofluoromethane, alternatively, gaseous bromine can be made to react with oxygen by passing a current through it. Neither of these seem like they take place in a Super Nintendo. Not to mention elemental bromine is brown, so if it was in the plastic, oxidization would change it from the brown of elemental bromine to the yellow of bromine dioxide.

Back to what IS in the plastic, though- Tetrabromobisphenol A is not photosensitive; it won’t react with oxygen in the air due to UV light exposure, and the bromine cannot be “freed” from the compound and made elemental through some coincidence in a typical environment. It is simply not the cause of the yellowing; (it will yellow without BFR’s as well, which sort of indicates it’s probably not involved).

The Yellowing is inherent to ABS plastics, because it is the ABS plastic itself that is photo-oxidative. On exposure to UV light (or heat, which is why it can happen with systems stored in attics for example), the butadiene portion of the polymer chain will react with oxygen and form carbonyl-b. That compound is brown. There’s your culprit right there. Retrobright works because thsoe carbonyls react with hydrogen peroxide, and create another compound which is colourless. but the butadiene portion of the polymer remains weak- oxalic acid is thought to be one possible way to reverse the original reaction.

So why does it sometimes not affect certain parts of the plastic or certain systems? here the “just so” story is a bit closer to reality- the “story” is that the plastic formulae has different amounts of brominated flame retardants, This is probably true, but as that compound isn’t photo-reactive or involved in the chemical process, it’s not what matters here. What causes the difference is a variance in a different part of the formulae- the UV stabiliser.

UV Stabilisers are added to pretty much All ABS plastic intentionally to try to offset the butadiene reaction and the yellowing effect the resulting carbonyl has. They absorb UV light and dissipate it as infrared wavelength energy which doesn’t catalyze a reaction in the butadiene. Less UV Stabilizer means more UV gets to the Butadiene and causes a reaction and the plastic yellows more quickly. more UV stabilizer means less UV catalyzes reactions and the plastic takes longer to change colour.

As with anything related to this- the best way is to experiment. I’ve decided to pick up some supplies and test both approaches on a single piece of plastic. some standard “retrobright” mixture using hydrogen peroxide, and a variation using oxalic acid. I can apply both to the same piece of yellowed plastic, and observe the results. Are both effective at removing the yellowing color? what happens longer term? It should be an interesting experiment.

Occasionally, I like to fire up gzDoom and play through some of the old Doom and Doom II Games and megawads. I use a Random Level generator, Obhack, which I also hacked further to increase enemy and ammo. However, one alteration I like to make is to have higher Ammunition limits. As it happens, the way I had it set up, this information was in a DEHacked patch file within the WAD. As a result, to make changes, I had to use a tool called “Doom Wad Editor”.

Doom WAD Editor, or DWE for short, is about the most up to date tool I could find, and it is rather messy internally. It performs a lot of up-front processing to load the file and show previews and it doesn’t support a lot of modern capabilities. I recently came to a realization that the WAD Format is not some major secret- I could create my own tool.

So far, I’ve been able to construct the Format handler that is able to open and save the internal LUMP files. I’ll likely expand things to also use the KGROUP format (which is used by sole Build Engine games like Duke Nukem 3D) and create a Modern Application for current Windows versions for modifying those older file formats.

The WAD File Format

The WAD (For “Where’s All the Data?”) Format is a format used for Doom and Doom II as well as games using the same engine as well as modern source ports for those games to store game data; this includes maps, levels, textures, sprites, sounds, etc.

The Format itself is rather straightforward. As with most files, we have a Header. At the very start of the file, we find the characters IWAD or PWAD. These characters determine the “type” of the WAD file; a PWAD is a “Patch” Wad, which means it patches another WAD file’s data by replacing it’s contents. For example, a mod that changes all the sounds to be silly animal noises would be a PWAD which uses the same names for different data. an IWAD can be thought of as an “Initial” WAD. These are the “core” WAD files that are needed to play the games in question. The Header data is followed by a signed 32-bit integer indicating the number of Lumps in the file. (A Lump being effectively a piece of data). After that, is another 32-bit integer which is a file offset, from the beginning of the file, where the Lump Directory begins. The Lump Directory is a sequence of Lump Positions in the file, their size, and their 8-character name.

This is all, so far, relatively straightforward. So let’s get to it!. Now, this is just a code example of the basic implementation- my plan going forward with this tool is to flesh it out into a WPF Application that provides full editing and manipulation capabilities to WAD files. There is still an active Doom community creating Megawads and it may prove useful to somebody, and it’s unique enough that creating such an application should be interesting. I’ve been able to load and then resave the standard DOOM.WAD and have the newly saved version function correctly, so it would seem I did something correctly so far:

When it comes to playing older game consoles, there are a lot of varying opinions. One of the common ones I see is that the only way to play old game consoles like the NES/SNES/Genesis/etc. ‘authentically’ is to play them on a CRT. I’ve never bought into that, personally. The general claim seems to revolve around some very particular scenarios, which I will mention- which are used to support an idea that the games were designed specifically for CRT technology. Let’s look into the facts. Then, we can do some experiments.

First, we’ll start with a comparison image that I commonly see used to support this. The image is a screenshot of a portion of a screen in FF6 (FF3 for the US) from the SNES. First, we have the image which is called the “Emulator” image:

FF6, Alleged Image from an Emulator

This is held as an example of how ‘pure’ emulated game imagery is “gross and blocky”. Stemming from that, the claim is that this is not “authentic”- that in order to do so, the game imagery is supposed to be blurred; this is claimed to be a direct side effect of the CRT technology. Then this image is typically provided:

FF6, Alleged image from a CRT Television.

This is often claimed to be “what the game looks like on a CRT TV” and, typically, claimed as what it is designed to look like. However, there are a few issues with the claim. the first one is that this is taking a relatively small portion of the game screen, and blowing it up immensely. The fact is that you aren’t going to be seeing any of the pixel detail of the first image unless you press your face right into your monitor. Another, and perhaps more glaring issue- is that the second image is taken from an emulator as well. The effect can be achieved by merely turning on bilinear interpolation in an emulator such as SNES9X. So the image doesn’t actually tell us anything- it shows us an image without an emulator feature, and an image with it enabled. It asserts the latter image is “accurate to what it looks like on a CRT” But is it? The image itself is hardly proof of this.

Some short debates got me thinking about it. In particular, one common discussion is about Nintendo’s Wii U Virtual Console. For their NES library, I will often argue that for whatever reason it applies a rather gross blur filter over everything. I am told something along the lines of that this is intended to “mimic the original CRT TVs which were always blurry”. I find this difficult to believe. So the desire to properly experiment with an actual CRT TV, and the fact that my ViewHD upscaler doesn’t support the ideal S-Video for my SNES and N64 systems led me to ebay to buy a CRT TV. They were expensive, so I said “Nope” and decided not to. As it turns out, however, the previous tenants of my house who had sort of ran off a few years ago to avoid paying several months of back-rent had also left behind a CRT television. I had never noticed because I had never actually gone out to the shed the entire time I’ve been here. Mine now, I guess. So I brought it inside. Once the spiders decided to leave, I was initially disappointed as it refused to turn on- then an hour later seemed to work fine, but was blurry as heck. I was able to fix that as well by adjusting the focus knob on the rear, such that it now works quite well and has quite a sharp picture.

Before we get too far, though, let’s back up a bit. There are actually quite a few “claims” to look at, here. With the appropriate equipment it should be possible to do some high-level comparisons. But first, let’s get some of the technical gubbins out of the way here.

Send me a Signal

The first stumbling block, I feel, is input method. With older game consoles, the signal accepted by televisions- and thus generated by most systems- was Analog. Now, when we get right down into the guts, A CRT’s three electron guns- one for each color- are driven through independent signals. Some high-end Televisions and Monitors, particularly PVM Displays, have inputs that allow the signal to be passed pretty much straight through in this manner. This is the best signal possible with such a setup- the signal sent from the device get’s sent straight to the CRT electron guns. No time for screwing about.

However, Other video signal formats were used for both convenience as well as interoperability. Older Black and White televisions had one electron gun, and thus one signal, Luma, which was effectively luminousity. This allowed for Black and White images. When Color Television was introduced, one issue was backwards compatibility- it was intended that colour signals should be receivable and viewable on Black and White sets.

The trick was to expand the channel band slightly and add a new signal, the Chroma signal. This signal represented the colour properties of the image- a Black and White TV only saw the Luma, and Color TVs knew about the Chroma and used that. (Conveniently, a Color TV not receiving a Chroma Signal will still show Black and White, so it worked both ways). This worked fine as well.

Moving swiftly along, TV’s started to accept a Coaxial input. This provided a large number of “channels” of bandwidth. Each channel was a signal with the Chroma information lowpass-filtered onto the Luma signal.

Composite worked similarly, but abandoned the channel carrier, effectively just sending the combined Luma & Chroma signal without any channel adjustment.

S-Video Sent the Luma and Chroma signals entirely separately- with no low-pass filtering or modulation at all.

In terms of fidelity, the order going from least-desired to best of these, is RF, Composite, and then S-Video.

Now, this is North American-centric- Europe and the UK had a slightly different progression. Over there, a somewhat universal connector, the SCART connector, became effectively the de-facto standard. SCART could support a composite signal, separated Luma/Chroma (S-Video) signals, or an RGB Signal. and RGB signal as effectively three separate signals, one for each of the Red, Green, and Blue electron guns in the television. This is effectively the best possible signal- the signal goes straight to the electron guns with very minimal processing, as opposed to Chroma and Luma, which require some modulating and other actions to turn into an RGB signal to send to the electron guns. RGB was available in North America, but the equivalent connection method used- Component Video- wasn’t used until fairly late- around the time that CRT displays were being replaced with flat-panel LCD and Plasma displays.

So with that out of the way, one of the factors in how good an image looks is how much information is lost. In the case of older game consoles, the choices- without modding- tend to be RF, Composite, or S-Video.

For the NES, the ideal output, without modifying the system, was Composite:

CRT displaying an image from a Composite signal from an NES.

It is notable that we can still make out individual pixels, here; the dithered background doesn’t “mix” together. There is blurring, particularly along the horizontal scanlines, as well as dot skew along Megaman’s sprite, but those are not inherent properties of the CRT itself, but rather of the composite signal. As shown by running the same game via the Megaman Anniversary Collection on the Gamecube and using S-Video output:

A CRT Television displaying the S-Video output from a Gamecube.

This is a much clearer image. However, there is still some noticable blurring around Megaman. Could this be added by the Gamecube’s emulation? I don’t know. we’ll have to do more experiments to find out.

As I mentioned, Composite is inferior to S-Video; this is because Composite is the result of applying a low-pass filter to the Chroma signal, and “mixing” it with the Luma signal. The lowpass filter is so it doesn’t interfere with the Luma signal- but the effective result is that it doesn’t interfere with the Luma signal as much. The primary problem is that by having both signals as part of one signal, the demodulation will still pick up bits of the other signal due to crosstalk. Another possibility is that the signal being generated could be being generated in a less-than-optimal way- in the case of the NES for example it’s PPU generates a composite signal, but the composite signal is created from square waves, rather than

Now, since I have no immediate plans to try modding any sort of higher video output from my NES, the best solution for comparisons would be to actually use something that can be compared directly. I decided to go with Super Mario All Stars and the SMB3 World 1 Map screen. First, we can see it with Composite:

CRT displaying Mario All Stars via a Composite input.

Next, we can switch it over to S-Video:

CRT displaying SNES Mario All Stars SMB3 via S-Video

Just compare those two- The S-Video is much better. This difference is entirely because of the separation of the Luma and Chroma into two signals; one can see a bit of “noise” in the composite version, whereas the S-Video output is very well defined. It is almost night-and-day. However, these differences are not purely due to the use of a CRT. S-Video signals can be accepted by any number of devices.

Design Intention Declarations

One common statement made regarding older consoles is that their art and sprites and design are intended for a CRT; and therefore, a CRT is necessary to have an “authentic” experience. This seems reasonable in it’s surface. However, it really is not possible to design for a CRT in a general fashion. CRT Televisions accept varying signal inputs, they use widely different technologies- Aperture Grille, Shadow Mask, etc- have widely different convergence, moire, dot pitch, and other characteristics. While it would be possible to tailor or use the side-effects of a particular Television set to achieve a specific effect, that effect would be lost on pretty much any other set; and even on the same set if adjustments are made.

However, one thing that does have well-defined aspects and side effects that can be utilized is the signal. In particular, for systems that use a composite signal (either via composite itself or through a carrier-wave RF), the artifacts can result in certain image characteristics. These characteristics, however, have no relevance to CRT technology at all, and are not innate features that present themselves on CRT television sets.

The most common example is in Sonic the Hedgehog. The game has waterfalls in the foreground- in order to allow you to see your character, and because the Genesis hardware doesn’t support translucency, the game dithers the waterfall by having it drawn with vertical stripes. When this is paired with a composite signal, it looks sort of translucent:

Well, OK, it doesn’t work great, since you can still see the lines- but the characteristics of composite lend themselves to some horizontal blending, which helps make it look transclucent. At any rate, the argument is that the game is designed for a CRT and it is designed for composite, based on this- therefore, not using a CRT or not using Composite aren’t “playing it properly”.

I challenge this claim, however. First, the effect is irrelevant to CRT, as I stated, so we can throw that one right out. Second, the fact that this has a useful side-effect with the most common video signal format doesn’t mean it was designed that way. The problem arises that there realistically wasn’t any other way for it to be implemented. Dithering is a very common method of attempting to simulate semi-transparency, and had been for some time.

Another issue is that Composite was not the only signal format available. The system also output S-Video, and, in supported regions, full RGB signals. With an S-Video connection, that same waterfall effect looks like this:

If the system was designed for Composite- why does it support signal formats with higher fidelity? There is simply no merit to the claim that games were designed to exploit composite blending. The fact of the matter is that in all instances where it has an effect, there wasn’t any other option for implementing what they wanted to do. Dithering is the most common situation and it is merely a result of writing game software on a device that doesn’t support translucency. That the typical connection signal blended dithered portions of an image together a bit more wasn’t an intended result, it was, in the words of Bob Ross, a “Happy Accident”.

Moving forward from that, however- and taking a step back to the Wii U Virtual Console. We’ve already established that CRT displays do not have inherent blurring characteristics. Furthermore, the blurring effect of composite itself is relatively slight. The best way to compare is to simply compare the two images directly. For example, I have Kirby’s Adventure on the Wii U VC. I also have it on my Everdrive N8, allowing it to run on the NES as it would with the original cartridge. Let’s compare the two.

First, the composite image captured on a CRT, using the NES’s Composite connection:

Kirby’s Adventure, running on an NES and being displayed via Composite to a CRT Television.

There is a bit of a moire pattern from when I took the picture and how the phospor’s are lining up, but those aren’t normally visible. There is some slight blurring, but it is mostly in the horizontal direction. Now here is the image from the Wii U VC, running on an LCD:

Kirby’s Adventure, running on the Wii U Virtual Console and being displayed on an LCD Screen through HDMI.

Here we see that they have merely blurred the output. For what purpose, I don’t know. Perhaps they are scaling the emulator output and it is using the default bilinear scaling, when they intended nearest neighbour. In the closeups here it actually looks like a reasonable approximation, but even within the images the image on the CRT is still more clear (particularly vertically). The main problem is that the CRT output appears very clear and crisp from a distance; whereas at any distance the Wii U VC Output on an LCD looks blurry. Stranger still, the Virtual Console on the Nintendo 3DS doesn’t exhibit any of these visual effects.

To conclude, I think that a lot of the attachment to CRT displays is rooted in confirmation bias being supported primarily by nostalgia factors. While there are benefits to the Native analog capability of a CRT display- in particular, resolution switches are way faster – those benefits don’t really line up with a lot of the claimed advantages. And those that seem reasonable, such as CRT’s having less input latency- have only been measured in time delays that are otherwise inperceptible. The biggest concern is less that CRT is ideal, and more that LCD panels tend to use very poor digitizers to turn the analog signal into a digital one for use by the display panel itself. These issues can be eliminated by using a breakout box, such as a framemeister or a ViewHD, which accepts various inputs and outputs HDMI.

For some time I’ve been looking forward to a new “Game” that Nintendo announced some time ago- Mario Maker, which is now titled Super Mario Maker. I put “Game” in quotes because what it is is perhaps not that straightforward. Effectively, it allows you to create your own levels; but further, it allows you to share your levels via the online community and play levels created by others. One could think of it almost like a Mario game that you can change, while also having crowd-sources levels.

Opinions on the product are, of course, varied. Some consider it a “Little big planet” rip off. this is an odd descriptor since that game hardly trademarked the idea of having an online community for sharing levels. Others say it is nothing more than a glorified ROM hacking tool. That is an interesting argument, one that I rather disagree with.

What is ROM Hacking

For those unfamiliar, “ROM hacking” is effectively taking the ROM data of a Console video game and fiddling with the innards; this could involve changing graphics, code, or level information. In this context, most are comparing Super Mario Maker to Level editing tools such as Lunar Magic and Mario 3 Workshop; These programs provide something of a more graphical and easier approach to editing level information in Super Mario World and Super Mario Brothers 3 ROM files. I don’t think such comparisons are particularly valid; the primary issue is that neither of those tools is nearly as intuitive and obvious; both require some knowledge of the game engine, particularly how they deal with pointers and exits/entrances. Another consideration is that when it comes to ROM hacking, the typical distribution method is patches. the purpose being to circumvent/avoid copyright infringement. Effectively the person who creates a hack distributes a patch file, which describes the changes that are to be made to the ROM of the game in order to create their hacked version. this way the patch file being distributed only distributes the changes, and doesn’t distribute copyright content by Nintendo. This means that while there are communities and websites covering, reviewing, and featuring these hacked ROMs, in order to try such a hack one needs to download the patch file and apply the patch to the appropriate ROM file and load it in an emulator (or, run it on the original console using something like an Everdrive N8/Super Everdrive or an SD2SNES). The communities are also typically rather niche; while there is excellent help to be found in the community for creating, editing, and working with ROM hacking tools, these tools and the methods used are rather involved. It also requires that the user skirt the law; Unless you dump a ROM file from a cartridge yourself, you have to download it from the Internet which means breaking copyright law. of course, whether something is illegal and whether the laws prohibiting it will be enforced is another question, but it is still something that may scare many away

Super Mario Maker avoids all of these problems. That said, despite it allowing you to play/create levels that look similar to Super Mario Brothers, Super Mario Brothers 3, Super Mario World, and New Super Mario Brothers U, it is very much a different game. Many elements from the originals are changed; new things are added; features are revised, limitations are removed, new limitations are added; etc. I like to think of it as a new game that merely provides skins that approximate some of the original titles, myself. And I look forward to experimenting with many of the new capabilities that the revised engine allows. For example, in the original titles, enemies didn’t bounce off of note blocks or springboards. Only Mario could interact with them, and enemies just walked on them like normal blocks (or passed right through them); With Super Mario Maker enemies and various other entities will interact with Springboards and noteblocks; things like bob-omb’s will explode and damage the level, by destroying things like bricks; you can make large sized koopas and their shells can destroy otherwise indestructible blocks that are in the level; Koopa’s and other enemies and objects will interact with objects like platforms where previously they simply fell through them like they weren’t there. This provides a wealth of capabilities when it comes to designing unique levels which simply aren’t possible with ROM hacking tools, while providing the capabilities using an easy-to-use interface that requires no technical knowledge of pointers or object data or anything like that.

Super Mario Maker is going to be released next Friday (September 11th) a day chosen to approximate the 20th anniversary of the original Super Mario Bros. game, which, in Japan, was September 13th, 1985. Since in 2015 it falls on a Sunday, the date was selected as the Friday before it. Some have pointed out the unfortunate coincidence, and even referred to it as tasteless. However I’m of the mind that the world cannot simply stop on the Anniversary of such events, and any memoriam or sombre attitude associated with a date isn’t necessarily mutually exclusive with other activities, anyway. Who among us can claim to have never played a Video Game on November 11th, for example?

A bit of a shorter post. Sort of a “progress” report on some of the personal stuff I’ve worked on recently.

BASeBlock

I’ve come to form a love/hate relationship with BASeBlock. This is mostly because there are a lot of things I like about it’s design, and a lot of things I hate, and the things I dislike tend to be difficult to change. Some of the basic dislikes includes a lack of DPI support and how it won’t actually scale to larger sizes. On my monitor it is now tiny which is annoying and pretty much trash in the form of an action game. I’ve brainstormed a few solutions. The simplest would be to simply scale up the bitmap that get’s drawn to the screen. That is still a pain but is doable. Another would be to go a step further and actually scale everything in the game itself to larger sizes. That would be a rather large undertaking, to the point that I’m not even sure it would be worth the effort. I made a few minor revisions to try to get it to scale using the first method but ended up shelving that work for the moment. It’s rather disappointing to find such glaring problems with your old projects that you put so much time into, and almost painful to even consider just shelving the project entirely and just moving on. I certainly made a lot of mistakes with BASeBlock but I think it does well for a game using such basic capabilities (GDI+ drawing for a Game is rather unorthodox!).

Prehender

3-D programming is incredibly annoying and uses math that is far beyond my abilities to actually comprehend. Viewmatrices, rotation matrices, dot products. It’s basically a case of Googling to find out how to do things, then hoping I can figure out how to get the math to work with OpenTK. Nonetheless, I have managed to make a bit of progress.

As with BASeBlock and realistically any game I make going forward most likely, it’s primary purpose is for learning stuff. BASeBlock is at this point “learning” how to refactor an old codebase to improve it, whereas originally it was for learning C#. Prehender is going to be both applying the design techniques I learned since creating BASeBlock as well as being my first 3-D game. With that in mind, it is a rather simple concept.

Originally, I was going to just create some sort of 3-D Block breaker. I have a rather unhealthy fetish with them or something. But I decided to change it up a bit. I decided to “steal” a bit of the design of the 2-D Game, “Spring-up Harmony” which effectively uses a physics engine, and you shoot coloured balls at coloured blocks. If you hit a matching block it will “loosen” from the static background and will interact with other blocks. Then you can catch them with your “bucket” at the bottom of the screen. I haven’t worked out all the details but right now I have it so you shoot coloured balls at an arrangement of cubes, and when a coloured ball touches a coloured block, the block loosens and will fall. I haven’t actually figured out the gameplay specifics, though. That does bring me to the title, though- 3-D programming is quite difficult. I haven’t used Unity before, I may give it a go at some point, however my interest in creating games is typically in what I can learn about actually making them- Unity seems to be more for people interested in making games, as it abstracts some of the parts I find interesting. But in my case, I’m using C# and OpenTK. Unfortunately this means I get the fun of dealing with concepts such as Projection and View Matrices, Dot Products, cross products, and the like. My math also fails me as I’m not able to determine the Camera position from the projection and view matrix, which is a bit goofy when I want to shoot the balls from the position of the camera.

On the bright side, this does make it (IMO) a more useful learning experience. I find it rather strange that I’ve had to resort to third party libraries (OpenTK and BASS.NET) for providing 3-D display and compressed audio capabilities into my C# Program. XNA has been rather left behind (Though still works) and it has a few omissions that I found frustrating when I was working on BCDodger. I would hope that .NET is given first-party support for creating games in the future that makes the task much easier but allows us to use the full power of .NET and C#. Sort of an XNA successor allowing us to also publish to XBox One. (Heck if such a library was made available even at cost I think I could justify an XBox One.)

BCSearch .NET

BCSearch, my VB6 program works, but working on it is pretty much a non-starter these days. I am impressed with the patience I used to have working with Visual Basic 6 only 7 short years ago. Some features of the program will simply not be brought to completion.

Instead, I would like to create a modern WPF Windows Application that uses modern programming (and async await and such) for the same purpose. The effective goal is to create a rather straightforward on-demand search program. This differs from standard Start->Search and the search tool of Windows Explorer in that it is a full application oriented around searches and dealing with the results of those searches. I often find myself trying to find files based on rather specific criteria, and in that context I can see myself using an imagined BCSearch.NET that allows me to write a short C# method in a textbox for filtering each file. This would also allow me to rethink some of the weird architecture decisions I made with BCSearch, while also allowing me to work with WPF again (my work is almost exclusive Windows Forms, and the last time I really worked with WPF was with BCJobClock).

I’ve been out of the whole Bukkit Plugin business for some time, But I recently jumped back in because there was a tiny bit of demand for me to update “GP-EnderHoppers”. It got me thinking about possibly jumping back in more fully- Not to GriefPrevention, mind you- that has moved on, rolling back pretty much everything I did to the plugin, but rather with my own “protection” plugin of sorts.

My thought is that I could apply what I’ve learned through work to a Minecraft Plugin- that is, I work with software dealing primarily with Marina’s- Customers, Sites, sublets, reservations, Invoices, etc. And it might be interesting to try to architect- from scratch- a Minecraft plugin built to the same purpose. It’s only something I’ve been considering on and off for the last day or so in a passing whimsy.

Furthermore- what about a marina plugin? Something which fixes boats (makes them unbreakable, allows them to be named, etc) and brings real-world Marina terms and applications into a Minecraft Environment. Rather than a “general” protection plugin, it could be designed for instead managing harbours within the game, something which- at least as far as I can tell- doesn’t have any plugin built for the purpose. And being that I could bring real-world experience to the table in that context, it might be interesting.

That said the plugin landscape is pretty- goofy. Between the whole Bukkit DMCA debacle and the spigot workaround, it’s sort of like walking on eggshells. I’m not a big fan of the ecosystem, to be honest, I don’t even really like the sort of servers which would use plugins.

My main consideration is that I need a “hefty” side project of sorts, as currently I feel I’m not really doing as much as I could be in that regard, since almost everything I do is in some sense motivated by my work. To that end I did crack open “Prehender” (why did I call it that?) And even fixed some of the issues that had caused me to lose interest (HUD stuff). Once I work out some details about the camera I think I’ll be well on the way to having a basic, but playable, 3-D game.