LAN SMS

If you just want to download LAN SMS, check here: http://www.eonedgestudios.com/lansms.php

In early 2015, I was working on projects and kept getting annoyed with getting SMS on my phone.  Most of what I do is on a desktop, so always having to check the phone was pretty annoying.  Plus, I always had the sound off, so I never knew when I got messages.  Always love the "I SENT YOU A TEXT 6 HOURS AGO, WTF" scenario.  Of course, sometimes I had to text someone also for whatever, so the quest to find the phone was on regardless.

Initially, I thought, surely there has to be some way to get these text messages on to my computer.  Certainly, I found a couple apps and services out there that did that, but each one did things I definitely didn't like -- had to sign up with another account, had to get a different phone number, had to use Google Hangouts (bleh), or various other things, like use cloud services... I thought, man, why is this so freaking involved, I just want SMS to be forwarded from my freakin` phone to my computer and vice versa.  My phone is right here next to me, but I have to jump through all these hoops to make this happen...

Unhappy with the things out there, I decided to make apps that just did this in a way I wanted, well, with some bells and whistles to make this even more useful, of course.

Enter LAN SMS.  We began Alpha testing it in February of 2015 with some Beta action several months later.  Lots of ideas were implemented and some really great feedback happened, making the product much better than I initially designed it to be.

Below, you can find some of the screencaps over the course of development:

One of the earliest versions of LAN SMS

I insisted we had "tabbed" chats, like how web browsers have tabbed browsing

Our first major UI revamp looked like this.  Some of the connection options were explored, but subsequently dropped from the final product due to various circumstances.

Things started coming together by this point, settings and stuff on the left, major important stuff on the right.

More settings were being added, some tabbed chats were open, things were happening.  We were getting a lot of great feedback from Beta users at this point as well.

Some UI redesign happened and this is what the "final to be released" looked like.  Again, some of the options on the left were dropped before release and may make a come back in the future.

Using the night theme, showing off the settings screen.  What use to be packed on the left side of the screen now gets its own section due to the abundance of options and details.

LAN SMS was released to the public on August 13, 2015.

More information about the product, as well as links to downloads, can be found at: http://www.eonedgestudios.com/lansms.php

Tech Support and why Piracy websites are a Good Thing aka "When Tech People call Tech Support"

I hate calling Tech Support, and I get the feeling I am not alone.

This is coming from someone who was a "customer care" agent, tech support shill, and whatever else titles that deal with incoming, angry phone callers.

I just want to start here by saying, I sympathize with most customer service and tech support people, I've been there.  While many times hilarious stories come from this sort of job, most of the time, you go home incredibly frustrated.  Frustrated with customers, your boss, corporate policy, the inability to actually help people that really need or deserve it, the long hours, the insane call time quotas, all sorts of things.

This job usually isn't physically demanding, but you better like people and be ready for your chain of command to throw you out the door when you don't perform up to par as set by their overlords.  Never mind the people factor, we're all robots that read scripts and can't actually help anyone that doesn't fit the pre-fabricated script as presented!

I'd love to say #firstworldproblems here, but ironically, more and more of these jobs are now overseas in less-than-first-world areas... so yea.  Which of course only adds to the layers of fun we get to go through when calling these companies that deploy this "support" strategy.

Today's adventure was to Samsung.  I had high hopes here since I generally like their products... but oh boy.

The problem?

I'm an App Developer developing on the Android platform.  I have to download and install a driver to get my Windows desktop to correctly talk to my Smartphone.

The model in question?  The Samsung Galaxy Note 3 (SM-N900V)

What's the backstory?  Why do I need the driver?  Glad you asked.

As part of the fun with developing for Android, sometimes the drivers bug out and your device stops being able to talk to your desktop; it doesn't happen often, but when it does, it can be... unpleasant to get to work again.  Strangely, the USB connection still works to transfer files around, but the development abilities are crippled and non-functional... joy.

This is what happened, everything was working fine yesterday, then BOOM, my phone *refused* to talk to my computer and its development environment through ADB.  After a bit of troubleshooting myself, I figured the drivers themselves had to be uninstalled and reinstalled... which leads me to today's fun and festivities.

Before bothering going to any website, I have to do local troubleshooting, make sure I'm not an idiot and broke my own thing.  Normally, with Samsung devices, I had been using their Kies Software to manage my phone from my computer (including installing drivers for it a year ago or so).  Assuming this was the correct procedure again, I tried to do it again.  Kies3 claimed that reinstalling the driver was successful, but instead, it was unable to download the driver from Samsung's website, but failed to tell me that.  Instead, a NULL driver was installed for my phone.

I ended up going through Control Panel -> System, checking out the unknown devices and looking through the Event Log to see Windows complaining about invalid drivers.  Hurray.

Great, so Kies was broken and it didn't know it was loading bunk drivers.  Time to go to Samsung's website to manually get a driver (I hope).

As a tech guy, my own troubleshooting checklist for "fixing" something software-related usually goes like this:

* Google for answers for similar problems
* Try to fix everything myself first, or at least find the actual problem area
* Go to the manufacturer's website
* Look for my device/product model/software/issue in question
* Scour through their "easy to use" interface for their downloads/support section
* Look for whatever file/answer I need (the driver in this case)
* Download
* Install
* Yes/I Agree/I read the privacy whatever
* Ok
* No, I don't want ads for my convenience
* Yes do what I want
* Eventually things work

In theory, it sounds great.  But this time, things went a tad amiss.

It wasn't long before I came across Samsung's page for my phone, great, this shouldn't be too bad.

http://www.samsung.com/us/support/owners/product/SM-N900VZKEVZW

To make things better, there is a pretty clear way to snag the driver that I need, cake!

Clicking the download is where things started falling apart.

Naturally, the message of "Samsung has no responsibility blah blah blah" comes up -- Continue.

Well, this is when I was hoping to download a driver or something, but instead was greeted with:

Of course.

Well, my Internet connection seems to be fine, but I can't rule out my DNS settings are messed up or something, so let's check it.

downforeveryoneorjustme.com says:

Hmm, apparently, I may not be the only one completely unable to get to their download center.  I suppose this is why the Kies software manager thing couldn't get the driver either -- the website was unavailable to download from!  I certainly wish it told me this, rather than having to find this out the hard way, and then having to manually uninstall bogus drivers and all that jazz.

Some quick, frantic googling for my phone's driver didn't turn up much... plus downloading drivers from 3rd party websites really bothers me... so, I can wait this out and hope Samsung fixes their issue... take a risk with possibly getting virused with 3rd party sites... or... the worst option of all -- contacting tech support.

Strolling through their website already indicated I won't be talking to native English speakers.  Some broken English littered their website really didn't help my confidence.  I'm assuming I'll be talking to the Phillipines or Cambodia or something.

(In a major, surprising side note, the last time I called the Philippines to get support for TIME WARNER CABLE -- the phone support was actually pretty damn good; I was really shocked, mostly because the guy on the other end went off his script when he realized I knew what I was doing with networking tech, and actually listened to me and we actually worked together to resolve the problem, wow!).

Oh, the website also offers live chat on their website - great, anything but phone support.  Oh, that doesn't work either... of course, it must be hosted by their offline download center which is broken.

So, here we are, I have to be productive today and get some new App code loaded on my phone.  I seemingly have little choice but to bite the bullet and... call tech support.

I'll give Samsung some credit here, at least finding a way to Contact them wasn't too cryptic.  God knows this alone can be almost impossible for some companies.

So, I called the help line for Mobile Phones (I'm assuming this was the correct number, since I'm not sure if this is a website specific issue).  I certainly hate being stuck in a call queue for an hour, only to be transferred around in to phone support hell.  Thankfully, the phone I'm calling on is the phone I need support for and it has speakerphone.  So, we're prepared for the long battle ahead.

The standard litany of a dozen automated phone options comes up -- first, wait (for English), 1, 1, 1, 1, 1, 1, 3... uhh, don't know how to answer that, so I guess that one sounds good, I think that will get me to a person.

I hear the phone system click over and complete silence for a couple seconds... great, here we go.  Time to get snacks and some water, we're digging in for the... oh wait, someone answered the phone already?!  This can't be right.

So far, you're winning Samsung.  Though, as expected, we have someone with a heavy Asian accent.  I don't necessarily mind this, but they need to slow down when they talk and enunciate a tad better... and apparently listen better.

I explain to the guy that I need to download the USB driver for my phone to load Apps on to it from my computer, but the website is broken and it cannot be downloaded.

In good tech support fashion, he tried to verify my problem:

"Ok, you want to download USB Drive to your phone".

"No, I want to download the driver to MY COMPUTER so it can talk to my phone."

"Ok, so, you want to download USB Drive to your phone"

"No, I need to get the USB driver FROM YOUR WEBSITE, WHICH DOESN'T WORK".

"Ok, so you are having trouble downloading the drive?".

"YES". (well, the driver, but hey, whatever).

He verified my phone number, my name, it was my first time calling Samsung, etc.  Apparently, he claimed to "have checked to website, it was fine".  Well, that's nice that HE can get it, but the fact is, *I* certainly couldn't.

As tech support would go, he decided (probably by a script) to walk me through traversing Samsung's website to get to the driver.  Great, I don't think I had the heart to reiterate to him that I've already done this, hence why I'm calling him... but hell, who knows, maybe he has a different way of getting this.  Sure enough, he had me type in my model in to the search, which brought up my phone model eventually (I had a lost-in-translation error as he was spelling out what to type in, leading to garbage search results for a little while, so yea, I messed up too).

He had me click on things, etc, then told me "It should be downloading now!".  Well, it would have been if I didn't get the same error I already told you.  Of course, as a tech guy, we can't assume the customer actually knows what they are talking about, so we have to assume their internet might not be working or there are other issues (certainly it can't be the company's problem, that's absurd!).

At this point, I'm getting a tad annoyed, but hey, this guy is doing ok so far.  But THIS is where things went really south, really quick.  First, he claimed he could download it, and so it has to be my problem -- ok, fine, I get you don't trust me, that's fine... but then he insisted that he could remotely control my computer to fix things for me.  Wait, what the hell?!  He talked about how he can log in to my system, control everything and fix it.

Whoah buddy, I don't want you remote controlling my computer (especially when I know nothing is wrong with my system!).  Now, mind you, I do this EXACT thing for my friends and family for their tech support needs.  I certainly don't want a company in who-the-hell-knows-where to just jump on my system to fix "my problem".  Aside from the security standpoint, I'm not sure this guy knows that I have a fairly hardened network connection to the Internet, it wouldn't be completely trivial to allow him on my system to just fix a problem (that isn't even mine, from what I can tell).

I was a tad insulted, shocked, and I'll be honest, kind of angry that he would even suggest this.  I can understand that if you don't want to deal with customers and walking them through tripe things (click on the X in your window) it is much faster and easier to just do it for them -- fine, I get it.

BUT this is somebody I don't know, I don't know if they have to install some sort of remote control software or what -- in fact, this raises more questions than it answers in and of itself -- does some sort of software from Samsung need to be installed to allow this remote control access?? Is this already enabled in other software in my system?!  Now, I'm actually fairly curious.  Maybe I'll set up a virtual machine and feign another problem to call them back just to see what would happen here.  Maybe it was just windows remote assistance or something else; who knows.

I suggested that he download the driver and possibly email it to me instead?  He said he couldn't do that -- of course.

So, I told him I wasn't comfortable with him doing the remote control shenanigan, he said he understood and that it was possibly my Internet browser was at fault -- right, Chrome didn't like your download center's website; nevermind my ping tests or other things I've done to isolate the problem to Samsung's services.  So, while the guy was going on and on about things I should do, I saw that the URL from the [broken] download center's URL had the file name of the driver I was looking for -- finally, I could google for that directly and just find it somewhere else.

Boom, sure enough, file sharing/piracy sites have the file in question.  At this point, it was pretty clear Samsung would be unable to help me with their problem, much less even know about their own problem, or care to know, apparently.

I don't blame the tech guy, he was following his scripts, and he was probably quite frustrated with me, so I told him he couldn't  help me and that I will be going to 3rd party websites to get the file in question.  He verified that was to be our resolution and then bid farewell.  Thank god for piracy websites hosting this file somewhere else... now to hopefully not virus myself and this will be another fine tech support issue solved in clearly the most efficient way possible.

Samsung's final tech support experience tally?

Tech support guy: 6 / 10
He followed his scripts, was generally nice, spoke way too fast, didn't listen to what I had to say most of the time and probably wasn't super technical himself as he clearly didn't understand what I was telling him most of the time -- granted, I was probably unlike most people calling him, having problems with their apps or whatever, so I'll give him the benefit of the doubt.

Tech Support Policy: -10 / 10
You want to remotely control my computer to overcome issues of communication?  There's no other way to get your file?  Do you not care that your downloadcenter is broken to external customers?  I have to make assumptions that the internal support policy... needs work.

Website Design/Coder People: 9 / 10
Surprising I know, but overall, their site was laid out well enough to where I could get where I wanted to go fairly easily.  I wanted support, it was fairly straightforward to get there.  Oh, and the filename of the driver I needed being in the URL, excellent.  You saved me from having to deal with your own internal issues!

Information Systems Team: 1 / 10
A major portion of your website is possibly broken and nobody at Samsung apparently knows about it?  I guess it is like your Kies software, seemingly works well, but when a something goes wrong, it does you the favor of not letting you know about it!

Overall Tech Support Experience: 3 / 10
Not the worst I've experienced, but a far cry from where I would hope to be from a company like Samsung.

I have no idea if anyone at Samsung will ever find this blog, but if anyone needs the information:

As of 2/6/2015: org.downloadcenter.samsung.com was resolving to 112.106.5.11, using Google's DNS - which seems to be correct and be pointing to South Korea (where Samsung resides, right?)

I'm under the assumption a firewall rule was potentially blocking external traffic -- possibly specific to the United States, maybe everywhere else, Kim Jong Un under the hood?  Who knows... now let's hope I don't get virused and actually get back to work.

It is dangerous to go alone, take this!

While creating a game engine, or just programming in general, lots of things can go wrong! Certainly, tools can also prove some immensely useful aid in the task at hand as well.  That said, here is a listing of tools and software we're using while making our own game engine.  They won't get the job done for me, but they certainly alleviate problems and make things more productive in the long run.

[Programming IDE]
The defacto standard is seemingly Visual Studio for developers on Windows.  For my game engine, being cross-platform, I don't really have a luxury of sticking with any one specific IDE.  On Windows, I've found that Code::Blocks works just fine.  For OSX and iOS, XCode is the standard.  For Android, Eclipse seems to be the way to go (in combination with cygwin), and last, but certainly not least, for Linux, I generally use KATE, or whatever text editor is loaded on that flavor of XWindows that supports syntax highlighting... in a pinch I do use vim as well.

Compilers
Well, can't really get too far in programming without these.  On Windows I use MingGW, Android and Linux use GCC, and OSX/iOS are using Clang/LLVM.

CppCheck
Let's face it, even the best of us crazy programmer people make a mistake every now and again.  Probably more if you listen to other people, but why do we listen to other people anyways?!  So, this neat tool that helps find errors in logic and what not here is with CppCheck.  Using this in addition to the compiler's analysis and warnings should at least find a large portion of issues and bugs before they become too problematic.

XVI32
My hex editor of choice.  If you'll be doing data file editing, checking little or big endian, or doing any sort of binary things, looking at the raw bytes is immensely useful sooner or later, especially in files on the file system.  XVI32 is free and fantastic.  It might be useful for other things than programming, but I will leave that as an exercise for you to figure out.

Mercurial
Version control is a necessity with software development (and likely other things NOT software-related!).  I converted from subversion a while ago and I'm pretty happy with the switch.  I highly recommend checking hginit.com for help learning the commands to use this really neat version control system.  Mercurial is decentralized and robust.  Naturally, a more visual way of dealing with the tool could be useful...

SourceTree
In my personal quest to rule the world, this was one of the latter additions to my growing arsenal of tools to help with development.  I was doing things on the command line with Mercurial when finally I bit the bullet and tried this new GUI approach to things.  I was skeptical at first, but honestly, this thing really helps see things and speed things along with managing version control.  I'll still drop down to command line and use hg directly, but for the most part, SourceTree covers my day to day version control interfacing.

Notepad++
Editing text files happens.  This fantastic editor is my default editor on Windows.  It does syntax highlighting for tons of languages, it's zippy and responsive, supports massive files, and all sorts of good things.  I even use this to edit source code outside of IDEs when necessary.  Yea, it is that good.  Get Notepad++ and live a better life on a computer; well, at least when you're editing text.

Wireshark
The premiere tool to watch network traffic.  Wireshark is essential when figuring out what in the world is happening with your network and the software you may or may not be having issues with.  Ideally, you can troubleshoot your network code that is giving you guff.  I suppose it could be used for other interesting things as well, but hey, that's on you.

Putty
SSH shell on Windows?  Yes please.  Essential with a multiple system set up across multiple Operating Systems.  Putty has captured the hearts of many over the years.

WinSCP
It copies files over SSH, really convenient to transfer files to computers only listening for SSH traffic.  WinSCP is particularly nice sending/receiving files to/from linux hosts, especially if Samba is acting up or not working right for whatever reason.

Filezilla
Good `ole FTP.  Can't go wrong with either the client or server version of Filezilla.  I don't find myself using FTP too much anymore, but every now and again with webhosts this is still useful.  With cloud computing and what not, this is seemingly less popular these days, but hey, it is still kicking for now.

[Word Processor]
I'm using the excellent LibreOffice.  It replaces MS Office.  It can make PDF files.  It is free.  Get it.

[Web Browser]
Lots of choices here.  If you're a developer, and I hope you are if you've read this far, you won't go far without looking stuff up anymore on the internet... I'm generally a Chrome guy, but as a developer, get used to using all of them, especially if you do web dev at any point.  In order of personal preference, I choose:
Chrome, Firefox, SeaMonkey, Opera, Internet Explorer, Safari, everything else I didn't mention

Gimp
Hey, part of developing games incurs the necessity for graphics.  Gimp is the forefront winner in the free graphics category.  It can take a while to get used to, but it isn't so bad once you get over the learning curve.  It can be quite picky with drawing tablets (GTK+ fault most likely), so if/when you get that to work, it's a pretty well rounded raster art image editor.  The commercial alternative is, of course, Photoshop.

Trello
Not really a downloadable product, this web service is a great way to apply some sanity to organizing all sorts of complex tasks.  I don't think I can do it justice by explaining it, but it is a system where you put cards together in to lists, assign them to people, give them due dates, color code them, etc.  It is very visual.  Things can be dragged around and prioritized and stuff.  Trello is a nice way to keep yourself organized with what you have to do or facilitate communication with team members so everyone know what needs to be done!  Less forgetting the small stuff, give yourself todo notes!

There are probably more tools that I use, but those are the more frequently used ones in my quest to make software.

Remember, our game engine is a learning experience...

So, when I first started the adventure of making a game engine, I had some grandiose ideas of what it would do.  Quite a few of my initial goals have actually been met (almost suprisingly); but that isn't to say I had quite a few bumps in the road with some faulty goals.  Most of the time these misbegotten ideas were crafted up because I didn't understand something or know enough about the topic to begin with (like 3d data formats with animation!).

Here, I will showcase some of my mistakes and talk about my troubles.  For your time, I will offer my lessons learned and elaborate on why what I was doing was good/bad/indifferent.

So, here we go, some of the times where I really messed up.  For fun, I'm going to rate how bad I messed something up on a scale of 1-10, with 1 being a minor lapse in judgement to 10 being evidence for logical absurdity and possibly insanity.

Floating point precision (Score: 9 / 10, I will regret this later in life once I figured out what happened).

So, you're playing a game, and lo and behold we fall through the floor.  Sheesh, these programmers must be lousy, they can't even tell where the ground is!  As it turns out, figuring out where the ground is located is actually not a trivial task!

Other neat things include objects moving through each other, falling out of a game level through arbitrary walls, the game camera clips though walls, things get stuck in the floor, and of course falling through the floor.

I can't speak for all engines, but in all likelyness, floating point precision is a likely culprit of at least some of these problems.

Early in my engine code, I had things like:

void someFunction(float x, float y)
{
	if (x == y)
		doStuff();
	else
		doOtherStuff();
}

While this looks innocent enough, it is a very, very bad idea.  Not only is this a bad idea, it is a stupendously, compoundingly bad idea with cross-platform development and bad for your general sanity when you use this code and get unexpected results in ways you have no idea yet.

Bruce Dawson has two really good articles about floating point comparisons that you really need to read that will hopefully enlighten you enough to realize a couple things.  One, computers suck at math, just like us, and two, you need to know what they are doing to use fractional numbers correctly (like, just where is that floor in 3d space anyways).  Sort of summing up what Bruce talks about (you should read it all anyways)...

There is no 100% awesome way of solving the floating point issue, but you, the engine developer, need to figure out the "best" way forward with some strategy and stick with it.  If you want a 100% accurate way of always having 100% accurate real number representation, you may wish to look in to scientific computing as opposed to game engine development as you will need a decent set of math understanding (and raw CPU power) to figure all that out.

Some caveats to watch out for are constant Epsilons and always thinking straight equality comparisons of floats are bad.

Example of a straight equality that is a Good Thing (tm).

float x = 1.0f;
if (x == 1.0f)
	hurray();

or even

double x = 1.0;
if (x == 1.0)
	hurray();

With no math involved after the initial assignment, this conditional should be fine. However, notice that I use the character 'f' on my number in the first example.  This forces single point precision, as opposed to double representation.  Depending on the system this is running on, if you leave the 'f' off, this comparison may or may not be equivalent!!!!  Do NOT mix having an 'f' on a float constant and then comparing it to one without! Example of messing up:

float x = 1.0f;
if (x == 1.0)
	hurray();

What about Epsilon? This is a reasonable strategy, albeit not very accurate, sometimes.  Epsilon is some margin of error.  The trick is that this margin of error grows as each float gets further away from 0 and sadly shrinks as they get closer to true 0.

It is a tad tricky to pin down exactly how much Epsilon should be given as it depends on the magnitude of the float number in question.  There is seemingly no tried and true solution here - or at least a provable superior solution given program execution performance as a requirement. For our engine, we combined an absolute Epsilon (for numbers near 0) and relative Epsilons (for numbers not near 0).

If you're making your own engine, this is a topic worthy of extensive research and testing because all games made on top of the engine will suffer from your failings to deal with this issue "in the most correct way".
Oh, and if you think this is fun now, just wait, there are more woes to talk about with floating point issues with game engine development, not just precision, but we'll get to those soon enough!

How the cross-platform, custom game engine integrates in the big picture

 

While designing and developing the game engine, it became somewhat necessary to start drawing some pictures to help get a bit of visualization going on.  This picture here shows, hopefully, that the engine itself is merely a component in the "bigger picture" of how a bunch of code and logic fit together to finally and actually be able to make a real game product.

Because the engine is C (read here for the reasons why it is C), the source code should be written such that we can take the C files over to platform x, compile it, and it just works.  In theory that sounds great, but in practice it isn't quite that simple.  As long as I can separate out the cross-platform code from the platform specific code, then all will be [mostly] well.  Fortunately, this design also lends flexibility in how we go about implementing those platform specific things while allowing the vast majority of the engine to be compiled, more or less, as is across multiple platforms.

The top part of the this picture shows the various Operating Systems we plan to support.  Each, of course, has their own considerations that don't play well with other OS's though -- so we had to split those "platform specifics" away from the "core" of the game engine.  By decoupling them, we can make lots of upgrades, fixes, and what not to the core and have it be fixed instantly across all platforms.  We can also write the platform specific parts once and never really need to change it once it works.

The Platform Specifics are:

• compiled 3rd party libraries (static or dynamic, depending on the platform/license)
• windowing code (hey, they all speak differently with their host OS!)
• device data gathering about hardware capacities
• core input handling
• opengl setup
• utility things, like figuring out storage paths, how to talk to file system
• platform specific scripts, batch files for windows, bash for the others

The Game Engine then is:

• Lots of header files for 3rd party libraries
• Lots of loading data routines
• Lots of math, geometry, collision detection routines
• Random number generator
• Lots of graphics functions
• Lots of utility functions (think buffering files, writing strings in binary, delay functions, etc)
• Generalized/abstracted input handling
• Generalized/abstracted sound output handling
• Logging functions
• Networking code
• Physics
• Vector stuff
• Matrix stuff
• Time/Date handling
• String handling
• Memory handling
• Specialized data support for game data files
• Embedded Lua script engine
• Everything else not platform specific

The Game Core is:

• Art, sound, data loading/destroying
• Game objects
• Actors
• Artificial Intelligence
• Player input response
• Game networking
• Game physics (in addition or by compliment to the game engine's)
• Everything else that makes the game

Once all of these things are combined and compiled/linked together, the actual game can be spit out and run on any of the supported platforms!  It is quite exciting to see our Windows version work near flawlessly on iOS or OSX just by pulling down the game core code, compiling, and it works... yea, sometimes there are hitches, but these are usually quick to fix as they are general oversights.

It was also quite breath-taking to see a "windows game" work on Linux almost without a hitch also.

The supporting libraries of a custom game engine

While creating my own game engine, it became pretty apparent fairly quickly that I couldn't possibly do everything that would be required of me to reprogram "from scratch".  We are talking about stuff like opening PNG files and extracting the RGB data out of them!  (As a side note, I DID actually read the RFC  and realized very quickly this isn't something I wanted to do).

PNG files weren't the only thing I wasn't interested in figuring out myself.  There are perfectly good libraries out there that have weathered the long haul and perform very well.  Let's go ahead and admit we can use some help from others in our ambitious goals of writing a game engine from the ground up.

Oh, and a caveat, it had to be free.  I'm sure there are some great commercial libraries out there, but that's not my fancy.  Of all the years gaming technology has existed, there just HAS to be free solutions out there somewhere just for this adventure!

The libraries that I have thus settled for (at least for now!) are:

• libcurl - CURL is a useful library for dealing with network data transfer over various protocols.  This is useful for stuff like downloading things from HTTP, FTP, and many, many others.  For my intents and purposes, I found it useful that I could post, say, patch files on a webserver and have my game clients download those patches using features of this library.  Technically, my game engine has "enough" features to be able to talk HTTP with a server but I never got around to formalizing it to be as robust as libcurl.
• lua - Lua is a fantastic and powerful scripting language and feature to integrate in to a game engine.  What better way to extend games than allowing other people, or even the public, to create, modify, and execute their own scripts!  We integrated liblua in to the game engine and can now embed scripts directly (the engine incorporated the lua parser so it can run lua scripts in the engine!)
• OpenAL - Really, when it comes to sound, it becomes excessively problematic dealing with the tons of options out there; many of which are platform specific.  OpenAL was kind of the only sane way of dealing with audio output in a cross-platform setup.  I attempted to write my own audio mixer and all that, got pretty far, but then I realized I needed more than just mixing, I would need to somehow talk to the sound driver(s) on each target platform as well -- way over my head and just too much to learn and do well. 
• libpng - This one is a granddaddy library that fuels a surprising number of applications out there, may as well adopt it!  What can I say, it let's us load up PNG files and extract the much-needed RGB data from them.  It took a little while to learn how to interact with the API, but eventually I got it - perhaps I'll make an article just for this someday.  At the end of the day, this is a fantastic library to integrate with a game engine.
• zlib - Similar to libpng, zlib is almost everywhere on the planet.  It's in your smartphones, in your computer, and in almost every application and Operating System out there!  In fact, I'd be surprised if you haven't interacted with something zlib related, even today!  It deals with compression of data files and data streams.  As well, of course, with inflating data from compressed states -- something insanely useful.
• btrxml - An XML parser I wrote with a constrained memory footprint in mind while retaining cross-platform capabilities.  I open sourced it under the zlib license so other people can use it for whatever they want (permissable with the license, of course).  Originally this was going to be part of the game engine itself after I looked in to other XML parsers, but at the end of the day, I opened it up and generalized it in to its own project!

That's it!

Using the libraries mentioned above, combined with the other engine code, everything I can do is made possible.  There may be some additional libraries to consider in the future.  I've dabbled with a couple 3d data libraries like lib3ds and things like that to help with handling 3d data (models, animation, etc), but I haven't quite figured out how I want to handle many things yet with that aspect.  Plus, for now, my engine really only caters to 2d games.  It does have super basic support for 3d things, can even render cubes, spheres, etc, but anything beyond that is no go yet.

Speaking of new libraries to consider, I think the next library to incorporate is likely ffmpeg or some of its dependency libraries to help with audio/video playback in a cross-platform manner.

The dawn of a new game engine

After my [de]motivating blog post earlier about making your own game engine, this will be THE post talking about how I got started!

A long, long time ago, I set out to create my own engine.  I've always been one to need to figure everything out to understand how things work, and game engines were no exception.  In my moments of weakness, I did consider pre-made things (hey, I even used RPG Maker wayyy back in the day).  If you're curious, I even went on and on about Unity and why I didn't use it here.

It's been a while since I started the adventure of this engine, so I'm looking back on the commit history of that first legendary day of when my engine was first put in to version control (protip: use version control software when making your own engine - I MEAN IT).

According to my own notes, version 0.0.0 of my engine had the following capacities:

• Integrated libpng (for loading png files)
• Integrated zlib (for compression/decompression of data)
• Engine definitions (TRUE = 1, FALSE = 0, etc)
• Device capability reading (number of cores in the CPU, display resolution...)
• Engine init and deinit code, engine version numbers, etc
• Fixed math placeholders (float replacements)
• Real basic and rudimentary bitmap font loading
• A very, very broken, misguided, and naive set of game configuration routines
• A box structure, used to define a region for 2d interaction on the screen (think buttons)
• An actual button structure, the intention was to be able to just put clickable buttons anywhere
• OpenGL initialization stuff
• Life cycle logic (useful mainly for mobile platforms)
• Platform agnostic logging routines (to stdout, or to a file)
• Very, very basic network socket operations
• Very broken sound code that required extensive rework later
• Very broken storage routines (come to find out, this is much more complicated in cross-platform)
• Super basic time and date handling routines
• A generic "timer" structure to keep track of elapsed time (in milliseconds)
• Some engine utility functions (stuff like check if integer is even, get process id, check for file exist)
• Basic 2d vector structure

In theory, I could drop this v0.0.0 of my engine with some game logic and a real basic game could be made.  How wrong I was.

According to my version control, the notes I left for myself were mostly unhelpful at first, but it is quite apparent that I grew frustrated with myself with how broken a lot of stuff was; especially with my early cross-platform issues.  At first, this engine was to be used for Android development specifically to replace the very clunky Java solutions out there.  What I was finding out was that there is a crazy amount of problems to be solved here at these fundamental levels for a couple platforms, not just Android.

It looks like the first thing I did was make some test functions to specifically help with testing new engine code.  This way I could make an engine testing program that can test engine functionality in a sandbox-like environment -- definitely want a controlled system when testing engine logic; many times I've driven myself to the brink of insanity debugging engine code when I came to find out that it was a bug in a game's logic that actually was bugged, not the engine!  Then again, some of these sanity checks lead to more robust and fault tolerant code in the engine, so it wasn't ALL for naught.

I just realized I should back up a bit; hey there's a bit of history here and I'm getting old!

Let's go back to the design goals of the engine.

• It should have fantastic performance
• It must be cross-platform to the major platforms (windows, android, iOS, OSX, linux)
• It must cater to doing as little work across platforms as possible for games using it
• It should help me later when making games by doing a lot of the less... interesting things
• It should help me later when making games by doing a lot of the tedious things

To cater to the first two points, I settled on making the engine in C.  Yes, straight C programming.  Not even C++ (though one of my early iterations of an engine I did utilized C++, and I certainly miss some of those features).  C's performance has the potential to destroy the competition in the compiled languages sphere (well, short of FORTRAN, I suppose, though the race is close!).

Performance issues aside, C is also one of the few (maybe only?) languages that is supported by all the mentioned platforms.  The goal here is such that I need to be able to do as little rework as possible across all platforms.

I couldn't do Java, because iOS doesn't support it (a decision I agree with!).  Getting it to work on OSX can also be a bit finicky.  I certainly have a fair share of less-than pleasurable experiences with JVMs on Windows as well... and dalvik with Android... with its extensive device fragmentation issues is a whole other terribad experience I don't recommend to anyone.  Those things ruled Java out pretty quickly -- not to mention early versions of a Java engine I attempted were met with very bad performance metrics (especially on Android).  As a game engine, the fastest performance possible should be a high priority (I'll make an article about this later in much more elaborate detail).  Java was out.

C# was a candidate.  Unity uses it, it's not completely terrible.  The Mono framework supports it on non-windows solutions.  I dabbled with it briefly, but I found myself throwing features out that were suppose to be "pros" of C#.  Stuff like garbage collection, exceptions, reference counting, running unsafe code, etc... all these things were starting to add up against C#.  Though, unlike Java, C# at least seems to be deployable to the major platforms in some way... yet I found myself too often "going native" and making the hardcore components with C/C++ anyways.

So, to cater to this newfound information, I pretty much settled that the engine must be C/C++ flat out.  It's not all bad, I mean, every major Operating System in the world uses it.  Games on consoles use it.  How bad can it be?  Thankfully, these are my primary languages as well, so there's a comfort factor involved too.  Well, time will be a casualty with how complicated "going native" is for each supported platform... the tradeoff, though, is fantastic performance, and surprisingly little administrative overhead for "write code once, run anywhere"... which is a common advantage for Java/C# -- and here we are emulating that slogan with C/C++!  While this sounds good, there are platform intrinsics that we have to manually cater to, which is far from fun and anything but straight forward.

The other bullets mentioned I will be getting to as we go forward with these articles.

This was a lot of stuff.  I settled on straight C for maximum control, portability, and performance.  I dropped a couple of months on trivial things, setting things up for the engine (the first bullet list in this article reflects that effort).  There was already a bit of cross-platform support right from the get go as reading back certain information, like getting the current process id, were platform dependent.

Remember, each platform is fueled by different system capacities and standard libraries for their respecitve operating systems.  I will be taking full advantage of POSIX functions and things in the standard C libraries when possible, and I recommend doing the same for your own game engine for maximum performance, predictability, accuracy, and compliance with those standard behaviors.

Not sure what to cover next, I'd like to talk about big picture things and super technical things... so if anyone has a request for something, by all means leave a comment and I'll focus on that specifically.

So, you want to create a game engine?

Don't.

Ok, now that we have that out of the way, and I haven't convinced you not to, let's get this party started.

I'll be blogging a bit about my own experiences with making our own game engine.  It will be part technical, maybe part code, a bit of code architecture, motivating stories, demotivating stories, nuances, and all sorts of other things.  If anything, this will be used as a self-counseling and rambling type session, and if you want to follow along, feel free.

Usually you'll hear a sizable amount of pessimism from other people when you mention a desire to make a game engine. This is probably rightfully so.  As a solo developer myself, I will have to admit I didn't truly appreciate the sheer complex, massive task that this would encompass.  As of this writing, my own engine isn't "done", it isn't "feature complete", and has a substantial amount of things todo left.  However, my engine currently DOES fuel the backbone of a couple of cross-platform, published games - so it IS functional and even usable.

I suppose the first thing we need to focus on is just WHAT exactly IS a game engine.  I could probably list out a dozen or so references and copy pasta, but I generally like to rephrase things in my own words as I feel that once I believe I understand something, I should be able to reiterate it off the top of my head in somewhat plain English.

So, without further ado, a game engine is a large, complex collection of software that other software products (in this case games) utilize to deal with inconvenient and time consuming aspects of development.

When we save time, we save money.  An endeavor to make a game engine is a non-trivial obligation and decision to invest a substantial amount of time to save you time and money later.  Return on investment is the name of the game here.

Speaking of return on investment.  There are plenty of ready made engines out there.  You will likely see people advocating their use.  Things like Unity, Cocos2d, GameMaker, and various others exist.  If you are convinced you want to make an engine, you should STILL download some/all of them and look at them.  Look at the service they provide, look at the source code (where applicable), play with them a bit.  Get a feel for how they work and what they give you.  If you are to make your own engine, YOU will be making a comparable product, with similar interfaces, with similar needs and goals.  Think of this as competitive research.

If you look at the comparable engines out there, I hope you begin to look at how overwhelming the goal of making your own is.  "Look at all this stuff, I certainly won't need all this clutter!".  Trust me, I know what you're saying.  Chances are, you're right, you likely won't need a large portion of "all that stuff".  Sadly, there is a lot of it you will need, but you won't know that until you're well in to development (likely several months or even years).  So, look at these large projects and realize one thing.  There exists the potential that YOU will ultimately make something very similar in scope and complexity, you just don't know it yet!

"But all I really need is something to load up graphics and put them on the screen... my game code will handle the rest".  This is incredibly naive and very, very far from the truth.  I know, because I thought like this once.

The small laundry list of things you think you need will grow ever so slightly at first, but it grows at a consistent pace.  Oh, I need some abstract thing that handles generic box-like shaped regions (think clickable zones, usually useful for things like buttons)... yea, we'll need that... but what about font and text handling... don't really need TTF format support... or do I?  Should I want to load in custom bitmap fonts?  Oh, I need to be able to load bitmap formats (bmp, png, jpg?).  It will probably be good to be able to display those graphics too -- hmm, OpenGL, DirectX?  Is my engine going to be cross-platform?  If so, there are major implications for choices that I can make.

Surely, we COULD support DirectX with a cross-platform engine... but that technology would only be supported for the Windows versions of our games.  This sounds fairly straightforward, but it complicates things in your graphics code, build process, and even workflow when messing with your engine, and then ultimately building games using that engine - which of course is the actual goal when rolling your own engine.

I'm going to make more articles about specifics as I go, so don't worry.

For now, know this.  The game engine I'm currently working on, and actually using, is my 4th attempt at making an engine.  It is by far the most complex and furthest developed one I've ever made (none of the other ones actually fueled any games!).

I highly recommend you not grow too overly attached to any engine you make right away.  The first engine or two you make should really be seen as a learning experience because you will need a deep appreciation for the overarching goal and understanding of what it is you need to do and actually CAN do before you can make something actually usable.

Look in to version control software.  I'm using the very awesome mercurial to track changes in my engine code (and to keep my own general sanity).  According to my commits, my current engine was first submitted to version control on 17 August, 2012.  As of this writing, it will be hitting its 2nd birthday soon.  It is still not "complete".  We have a ways to go still; especially in 3d support and having support for playing back avi/mpg files in games.  There are plenty of other things left to do as well, some of which I probably don't even know yet, but we'll get there.

What I hope you take away from this article is several things.

One, making a game engine is not trivial.

Two, making a game engine is vastly time consuming, likely taking years of fairly hard work and lots of research.

Three, making a game engine is a lot more complicated than you realize.

Four, be ready to admit your ways are wrong, to incorporate new ideas, and be ready to gut things that aren't working in favor of newer, better ways of doing things.

Five, if you're weak of heart and don't have borderline OCD, this probably isn't for you.  If you're even somewhat on the fence about this whole thing, you will likely only find disappointment.

Oh, and lastly, you should consider using other game engines still... but if you're still not actually convinced and you still want to venture forth in to this crazy goal... then by all means, let us proceed!

Next article we'll talk about choice of technology and actually getting started making your own game engine through my ramblings about how I got started with my own.

It is not for the feint of heart, but here you go, the dawn of a new game engine!

When game projects die.

Welcome to another installment from one of those crazy indie game dev guys.  Today, I'd like to talk about when a project goes awry, and ends up being nixed.

About a year ago, around September of 2012, I began designing a tower defense game.  I figured it was going to be "easy enough" to design and develop.  Now remember, I'm basically working by myself and on top of the proposed game itself, I also make my own game engine, which is, of course, a never ending task.  Anyone with a decent amount of game industry experience (indie or otherwise) already knows that these are red flags, but hey, I'm stubborn and persistent.

The design seemingly went ok, the theme is to take control of plastic soldiers and defend human living spaces from pesky animals and things like that.  Once I sat down and wrote down everything about the game that I could think of; stuff like the player's pieces, the enemies, the general gameplay, etc, I decided I needed an artist to make the project come to life.  My lacklustre art talent was several years lacking to be "good enough" to do it myself.  So offloading the art would free me up to actively start programming the logic and game system, while still working on core game engine features in the background.  Now mind you, my game engine had already been in development for around 9 months at this time and had quite a bit of features "ready-made" (and published products using it), so I wasn't starting from scratch, but at the same time also put a technical limit as to what the game could be designed to handle.

Knowing that the budget is tight, the only real options I could consider was working with local college students that needed portfolio work, or outsource to Asia.  I generally like to try to keep things local and to support our own citizens, so I opted for the earlier option.  This turned out to be quite problematic, as with all things, apparently.

I may sound like a terrible person, but the people I met had some combination of no motivation to get anything done, couldn't follow directions, simply disappeared off the face of the planet, or just didn't have the required talent to make it happen.  The people I met and talked to just simply were not qualified.  Now, what did I expect, I was scalping college students.  Eventually I did meet up with 2 or 3 potentially qualified people.  After going over the plan, we drafted up a monetary agreement -- any "good" talent is worth money.  The amount of money offered, of course, couldn't be much, relatively speaking as compared to, say, established art houses, or even asian production companies, but hey, what do these guys expect, I'm an indie game dev with barely enough cash to survive with.  This conundrum is worthy of its own blog or even book so I'll leave it at this for now.

While there are other arrangements, like profit sharing, etc, that I have entertained in the past, I wasn't at that point with this project and tried to emphasize a cash payment, *on release of the product* to potential artists.  Some of the earlier failures with contracting ended up with some work being done and having the artist disappear, leaving me high and dry, so to protect myself, I insisted heavily on "no payment until release".  The game project wasn't something that could be done in a week or two, I understood that, so it definitely warranted some cash.

The amount of cash, of course, becomes the problem.  However, an agreement had been made between myself and an artist that seemed to have the right skillset.

The first couple of months went by with an acceptable amount of artwork production (definitely better than earlier contacts), and development proceeded in a fairly smooth manner -- but artwork production soon tapered off after about a month and a half.  I understand people have other commitments, but this was starting to get a little alarming.  I try to give people slack and not push *too* hard, but hey, things can only go so long, and plus, I'm not offering a huge cash payout, so I could see how and why my project would lose priority.

However, things got more complicated.  I had been in contact with Kongregate (a publisher) over the project.  This could have been the money infusion I'd been looking for, but this has its own ups and downs, dealing with publishers that is.  If we were to go this route, I'd have to increase game production, and art, several times over... something I don't think went over very well with the artist.

So, I ended up losing a bit of credibility here, and told Kongregate that we wouldn't be capable of producing something for them in any reasonable amount of time.  At the time, I was also pushing to release a demo of the product, or gameplay videos, but they told me not to as that could jeopardize our potential arrangement.

Time for alternative plans. An indie dev competition thing that was happening a couple months away came to my attention.  The dev builds of the game were going pretty well, but I'd need to get the game to an almost releaseable status to really be able to compete; the development was fine, but the art was slacking quite far behind.

I asked the artist for a status and estimate for how long it would be before I'd get "the rest of it".  He mentioned a time, but I almost laughed.  I had been tracking rough production time and my number was *vastly* different than his for artwork.  He mentioned something like a month, whereas my numbers suggested potentially 6 months.  Apparently, he didn't appreciate the discrepancy notice.

I think I got one additional piece of art from him since, and that was almost 6 months ago.  So, rewind the clock to that time, I pretty much knew his number was never going to happen.  Knowing that, I went ahead and did what any programmer would do, bury himself with more coding to "get it done".  I kept plowing away at the core game and the engine itself when a potential tech change occurred to me.

The entire game, at this point, is using 2d technology.  Yet, there was a lot of convoluted zooming in and out, with complex scaling, floating point stuff, strange math, things like this to produce a mock 3d-esque type player experience, using a core 2d tech system.  In the background, I was already toiling with 2.5d tech in the game engine and thought, hmm, this could be the perfect chance for me to incorporate this 2.5d stuff in to the game since I'm not going to be getting art anytime real soon anyways.

"It would be so much easier if I changed over everything to this new stuff".  This line alone could probably sink entire projects, and it certainly didn't do ours well either.   3 months later, most of the game had been transitioned over to the "new" 2.5d system, utilizing more of the game engine, which was also under heavy development, especially in this area.  There now exists a mostly broken game using new tech, old art, tattered nerves, little meaningful communication, and little funds.  I'd say time was short also, but there's never enough time, so that's a constant problem.

At this point, I had to sit down and ask myself where I was at with the project.  I had gotten so far to see over the peak of the mountain to realize I've gotten myself in to a bit of a pickle.  I had to reflect on myself where did things start going wrong.

Ultimately, failure rests on the project leadership, which lucky for me, was me.  The only way to grow was to reflect.

I personally believe that it all started back at the design of the project.  I described the game with words, not with concept art.  I didn't DRAW what the game would look like, I described it.  I used reference artwork, sure, but I didn't give explicit visual direction to what the artist was to create.  I didn't understand what the difference between what a game artist did versus what a game designer did.  I (wrongly) thought I could pass descriptions over to an artist and they would make the game come to life.  I was wrong.  When questions came up over intention and meaning of things, I'd answer with words, not drawings.  Visuals speak more clearly than words, especially in the media, and artists apparently are no different.

It wasn't really until I was working on other projects during this mess that I had realized that working with designers is what I was missing here right from the get go.  Two designers (unrelated to this project and each other) had sent me conceptual art for their own projects to develop and what they sent to me was visuals.  Artwork mock ups.  I could envision exactly what things would look like on a screen.  We had a hard, set, requirement for what displays and aspect ratios we would target.  I had basically no questions about what to do or how to go about doing it, and this, became quite apparent that this is where I was so sorely weak in my own project.

In fact, I don't even really blame the artist I was working with; sure, there might have been a bit of his own motivation issue at hand, but as a project lead, that's also my problem.  I think it probably didn't help that there wasn't a solid plan and design he could follow to find his own success, and again, this was my fault.  It would have been easy to just say "he sucks" and call it good, but it is more complicated than that, and there's no way I would grow from here if I did that anyways.

So, here we are about a year later from the very beginning with almost nothing to show for it. It is quite the sobering experience.  I'd like to get this project out the door one of these days, but I think I need to send it back to the drawing board and redesign it from essentially scratch, this time with a proper design.  It's hard to let something like this go; especially after "wasting" almost an entire year on it, but I guess this is one of those things that you have to love enough to let go when need be.

Game Programming and 2d Art, Part 3 (Texture Atlases)

Welcome to the final part of my series on game programming with 2d art assets!

The previous 2 entries are here:
Part 1
Part 2

If you don't know already, a texture atlas (also known as a spritesheet) helps game developers to display neat 2d graphics in to their games.  There is usually some sort of organization sanity happening with them as well, for example, all of the frames of animation for a player character would be in one atlas and its file name could be "herowalking.png" or something like that.

Of course, this isn't limited in any way, I've often used atlases that are just a collection of User Interface components usually in a file called "gui.png" -- it has all the buttons, graphs, meters, check marks, and all sorts of doodads, all conveniently packed in to one GUI atlas file.

At any rate, assembling a texture atlas can be extremely tedious.  You have to make sure nothing overlaps anything else, that all your texture objects can fit, you will even need to remember where you put each object so that a game engine can subsequently extract each object.  It is so much planning and tracking!

Thankfully, there is a program out there called Texture Packer.  It is a commercial product, but all in all, it's a nice, convenient tool to have in your tool belt.  I'll even go so far to say that if you make 2d games commercially, you probably shouldn't be without it!  It's reasonably priced as well for how much time and money it would save you.

Let's put it this way, I spent about 2 weeks making a command line program to extract texture sizes and coordinates and it was a pain to deal with.  On top of that, I was still relying on manually entering texture coordinates in to our games from that program's output.  If an artist changed any graphics, it would be a nightmare changing things all over the place.

This program keeps track of all that stuff, and allows you to output all that relevant information in to various game engine formats; or for us, even a generic XML data format!

Below is a screencap of what it looks like:





Honestly, it's pretty good.  There are a couple of features that would be nice to have; like manually being able to move texture objects around (or swap places with each other), but what the tool does is automatically find a place for your sprites in the empty atlas for you, so you don't have to sit around with a magnifying glass lining pixels up manually!

There are quite a few neat features as well about it, like automatically generating different scaled versions of your atlas (click AutoSD) for catering to different resolutions, being able to specify atlas geometry (like powers of two, max width/height, etc), and it can even import SVG files.

It takes a little while getting use to, but all in all, it's a pretty useful tool and saves us quite a bit of time dealing with artwork.

I have noticed that the windows and linux ports are a little behind the mac port, and again, it is missing a couple neat features, but all in all, it is useable and useful.

They offer a trial version of the program also, so you can check it out without having to buy it first.

Help, Windows Update is Missing in Control Panel!

Though our focus is on game development and things like this, I occasionally take on the role of IT support for friends and family.  After battling with a nasty collection of virii on a family members computer, I realized that Windows Update on their win7 system was gone from control panel!

Long story short, it, as well as the Background Intelligent Transfer Service (BITS) was just gone.

Naturally, I send systems home after a windows update to get the latest and greatest updates installed, so this had to be solved.

Googling around showed me a couple suggestions, some showing I needed to reinstall the operating system (or at least do a repair).  SFC /scannow didn't fix anything either.  I thought, that's dumb, why can't I manually add this stuff back in.

Well, we can!

Our happy command to do such is called "sc".

Before I get too far in to this, windows update DEPENDS on BITS to be running, and started to operate correctly (forcing an update while BITS is unavailable or not started will freeze your system pretty hard indefinitely).

For me, both "Windows Update" and "Background Intelligent Transfer Service" was missing from services.msc!  So, first order is to get BITS back and working.

The command on an admin command prompt (yes, those are SPACES AFTER THE EQUAL SIGNS):

sc create BITS type= share start= delayed-auto binPath= "C:\Windows\System32\svchost.exe -k netsvcs" tag= no DisplayName= "Background Intelligent Transfer Service"

Should create BITS in the services registry, but wait, we're not done yet.  BITS has some dependencies that should be added!

sc config BITS depend= RpcSs/EventSystem

This will add the dependencies for BITS.

Unfortunately for me, one of the viruses really messed up the registry settings for this service as well, so here is a "good" version of the part of the registry I had to import from a functioning WINDOWS 7 system as well.

bits.reg

Ok, with that done, I could get back to adding Windows Update again!

The same idea applied to this:

sc create wuauserv type= share start= delayed-auto binPath= "C:\Windows\System32\svchost.exe -k netsvcs" tag= no DisplayName= "Windows Update"

and again, to add the dependency...

sc config wuauserv depend= RpcSs

Both BITS and Windows Update should now be in the services window now and you SHOULD be able further configure them.

If you get access denied errors make sure you ran the command prompt as an administrator.

If you still get access denied, then you probably have malware and/or a bad virus problem.  You may have to resort to safe mode, run virus scans, possibly do recovery console stuff, etc.

Personally, I ran CCleaner, AVG anti-virus, then Malware Bytes Antimalware, mostly in safe mode, and that cleaned up the problems on this system.

Linux Mint, several hours in

Overall, the experience has been pretty positive.  I took a couple hours fiddling with the system settings, preferences, and all that jazz (of course!).  Of note, I'm now using the proprietary Nvidia graphics driver as opposed to the FOSS version (that was selected by default).  There was noticeable improvements to the rendering/responsiveness speed right away.

I snagged Steam and will be trying out one of my games (X3: Albion Prelude) as it is my *only* game that works on Steam Linux.

I also immediately grabbed some of Nehe's code for setting up opengl programs since I hadn't done windowing/graphics code on Linux in the last decade or so and I've completely forgotten what I was doing and I'm anxious to start porting game engine tech to the platform.

I did crash the window manager once trying to run "glxinfo | grep OpenGL".  To be fair, I think I did this command in a terminal while I was changing the graphics driver... so fair deal.

Firefox was noticeably glitchy and generally unpleasant, so I put Chrome on here, much better.

The only really annoying thing so far I've noticed is that I can't seem to middle/wheel click a webpage in Chrome and scroll around by moving the mouse (like you can in Windows)... so that's kind of annoying.

All in all, if it wasn't for several Windows-only games, I'd probably ditch Win7 completely.  I'm pretty impressed where Linux has come from in the last 15 years or so in terms of the general desktop (aside from the amazing tech fueling the OS itself of course).

Linux Mint - Installing from Live USB stick

Continuing from my last post...

I got tired of waiting around for this USB stick thing to do whatever it was suppose to do, so like always, I figured I did something wrong.

I put the USB stick back in to my main system and changed my options around a bit.  Instead of putting syslinux on the USB stick for the PBR, I changed it to NTLDR.  Then, I also changed my multi-partition set up, back to single partition using NTFS.

I don't plan on using this USB stick for much, other than just getting Mint installed on my resurrected system, so I didn't opt for any sort of persistent storage.
Well, fiddling with my BIOS' options, I realized I inadvertently turned off "Legacy USB storage"... which caused a foreseeable issue.  I turned that back on, and put everything back in the new old system... and bam, everything works!  I wrote this from the live loaded Linux Mint USB stick!
Let's see if this has gimp or anything else installed so that I can post a screenie.  Thankfully, firefox was already installed, so that went off without a hitch.

I ran a terminal, and did "gimp &" (to run gimp in the background), and bam, it's there, even the most up to do date version of it! (2.8.4 at the time of this writing!).

Now, how to remember to take a screenshot with it...

And there we have it.  Looks like I just need to install mint to the hard drive officially now and we'll be all set!

I will say this, Mint is pretty impressive.  If there ever comes a day and games take over the linux desktop (via Steam or whatever), then maybe this will catch on even more with the masses.  All I know is I'm not a fan of Windows 8.