Could not load file or assembly … HRESULT: 0x80070057 (E_INVALIDARG)

Wow, this error just cost me 40 minutes of my life. I was forced to hard-reset my computer and when it rebooted, trying to load my primary IIS dev site gave this error. It names a specific DLL, but that’s a red-herring. The specific DLL is irrelevant. In my case, it was a 3rd party DLL that worked fine when I switched IIS to a different site, so I knew it wasn’t the problem.

Searching reveals this thread on the MSDN social site. It says to delete the contents of “Temporary ASP.NET Files” folders. There are several locations if you want to be really thorough. Note that the last one is the one I had missed and was causing me grief:

C:\Users\<UserName>\AppData\Local\Temp\Temporary ASP.NET Files
C:\Windows\Microsoft.NET\Framework\v2.0.50727
C:\Windows\Microsoft.NET\Framework\v4.0.30319
C:\Windows\Microsoft.NET\Framework64\v2.0.50727
C:\Windows\Microsoft.NET\Framework64\v4.0.30319

The Framework64 v4 directory is where my culprit files were located. I’m running Windows 8.1 64 bit and Visual Studio 2012.

tl;dr: delete your .NET temp file directories, and don’t forget Framework64!

GitExtensions Date Column Setting

By default, Git Extensions for Windows will display the commit timestamp as just the number of hours or days prior to now. If you’re like me, you find this sort of information worthless. Telling me something happened 37 days ago is not useful information. Telling me it happened September 15, 2013 at 2:37 pm is much more my style.

To change this setting, select “GitEx Browse” from the Windows Explorer right-click context menu, then Settings -> Settings. Finally, navigate to and uncheck this box:

Git Extensions relative date setting
Git Extensions relative date setting

Ahhh, so much better now!

PSA: XBox 360 Wireless Controllers on PC

PSA: connecting a wireless XBox 360 controller to your PC with the USB cable does not in fact make it a wired controller. That cable is called a “play & charge” cable. All it does is provide power to the controller but does not transmit any data. Therefore, a wireless receiver is still required.

Illogical, but it’s the truth. When you plug it into your PC, Windows will complain that it doesn’t recognize the device and that it may be damaged, but nothing is amiss. Just a stupid decision on Microsoft’s part.

Yes, I really did waste too much time on that.

Deleting SecuROM (and other tricky) Files

When I rebuilt my computer recently, I copied over my old users directory, including AppData. Inside there was a directory for SecuROM that included 2 files that won’t delete via the Recycle Bin. This is because SecuROM is anti-consumer and thinks that punishing customers is the way to gain their loyalty. However, because this is a computer, anything that can be done can be undone with the proper tools.

You’ll need your trusty command prompt for this. Once you have one open, the magic command to delete undeletable SecuROM (or other) files is:

del /S /Q /F “C:\Users\<your_username>\AppData\Roaming\SecuROM\”

Ensure the path is enclosed in quotes if it contains any spaces. That should do it! You can then delete the directory normally.

Plantronics GameCom 780 Drivers

This took way too long to find. If you have the Plantronics GameCom 780 USB headset like I do and you reinstall your OS, you may have trouble finding the driver download for the Dolby surround. They work just fine in Windows 8 via plug and play, but the Dolby surround doesn’t work. Here is the link to download the drivers:

http://www.plantronics.com/us/support/myheadset/control-pc-audio.jsp

For some reason, Plantronics has hidden that download extremely well.

Then, in Windows 8, after it has extracted itself (which it does into Program Files (x86) without any warning), you have to right-click the Setup.exe, click the Compatibility tab, and tell it to run in Windows 7 compatibility mode and as administrator.

The setup will take 30-60 seconds. When it’s done, everything will work (even without rebooting). The tray icon should show up and clicking the button on your headset will switch on Dolby Surround mode.

1GAM: February is Different

Well, February’s 1GAM is not really what I expected. A few things happened in January/Feb:

One, it’s official that MS is killing XNA. We’ve all known this, but it’s really really true now. Announced true.

Two, MonoGame is the new hotness for XNA developers. I’m waiting a release or two for the DirectX templates to be made current, but I think this is the way to go. Keep everything the same (it’s event namespace equivalent!) while using an OSS framework that can run on Win, Mac, and mobile devices. XNA dying and developers moving to MonoGame may actually be a win for the community, though losing MS’s brains and backing is not a small matter.

Three, I realized I had been letting a lot of weaknesses in the IceCream engine slide for awhile that I shouldn’t. They became more obvious when I tried to make even a tiny game from start to finish for January. Little things, like sprite-sheet management, positioning being wrong in an annoyingly subtle way, and the code-base being quite large and bloated with large unused portions hanging around. So I scraped it to go custom. I hate writing engines because I think it’s a waste of time, but this way I can do things right and know where to go when I need to dig in. Besides, it won’t be nearly as big as IceCream.

Four, I found the Gearset library for XNA games. This is amazing. I don’t understand why this tool set isn’t mentioned in every XNA article ever written. It’s $35 for Pro and worth every penny. It’s like having better-than-debugger functionality in real-time. Bolded to make sure you read it. It’s a steal and I hope they recompile for MonoGame. It replaces hundreds of man-hours of coding real-time editing and debugging tools. What a find.

Five (wow really?), I installed analytics on my blog and discovered that my article on using the lidgren network framework to build a P2P app is by-far my most read piece (nearly 50% of all my traffic). How and why are still a mystery. It makes me think I should revisit the article, update the app, and post about it again.

Ok, I’m giving up on the list thing. Instead I will accept that this is simply a stream of consciousness and deal with it.

My February game was going to be a top-down zombie killer. I started using tIDE to build levels because it’s a great tool with a great XNA library (though it needs a way to bulk-edit tile properties). Then I put a little player sprite, a zombie spawner and zombies with horrible AI, wired up twin-stick-shooter controls, gave him a pistol, and wanted to kill myself when I tried the result. I stopped all game dev for 4 days afterward. It was terrible. I’m considering trying to salvage it into a Link to the Past like thing (think single environment, not entire world-map) but am having a hard time even opening the code base after seeing the abomination my own hands created. On the up side, I really like the progress I made on the engine. It works, is super-simple, and integrates with TexturePacker well. Next up: PhysicsEditor, then Spriter.

Additionally, failing is good for me. I should get used to it. Better to fail after a week of development in my spare time than after months of betting the farm on it. So really, this is a win.

But seriously, Gearset. I wholeheartedly endorse this library, and get nothing in return if you click any of the links or buy it. I’ve tried a lot of tools in my time, big and small, Windows/Mac/Linux, and this is a cut above. It’s simply a great tool, and you can try before you buy to ensure it’s compat with your kit.

1GAM: Tactical Space Release

Woohoo! First game is done! Download it here:

Tactical Space Release, 5.8 MB 7z

Yes, I shrunk the size from last time by deleting a bunch of textures I wasn’t using. Here are a few screenshots from this latest version to entice you to download it:

TacticalSpace_Release_SS1
Title Screen
TacticalSpace_Release_SS2
Press F1 and F2 for debug info.
TacticalSpace_Release_SS3
Winning!
TacticalSpace_Release_SS4
Level 3 (the last)

 

I’m mostly happy with how it turned out. I still like the concept, but the mechanics need a lot of tuning to be more fun. Mostly it consists of: shoot randomly and… watch the puzzle solve itself. It’s interesting from a programming and conceptual point of view, but I think much less fun for the gamer. It’s also not nearly as tactical as I was hoping. When the planets don’t move, it’s incredibly easy. When they do move, they move so fast that getting hits through is random and it becomes extremely difficult aside from spraying the field. If ammo were limited, this would be incredibly frustrating. With unlimited ammo, being tactical is pointless when you can just spray and pray.

I once read that when making games, there are three types of fun:

  1. Fun for the gamer.
  2. Fun for the programmer.
  3. Fun for the computer.

I feel like Tactical Space falls too much into buckets 2 and 3, and not enough of bucket 1. Lesson learned for next time!

Additional lessons learned:

  1. I need a tool to start handling my sprite sheets. The Milkshake editor doesn’t cut it when sprite sheets are changing with assets. Assets I don’t end up using that I want to remove are a bit of a pain. I was able to do it easily manually this time, but only because this is a very small project. I’m going to try to integrate TexturePacker into my process.
  2. IrfanView is a cool concept but handles PNG transparency like the ’90’s. Disappointed.
  3. With many bullets on the screen, performance comes to a crawl. I think because Farseer Physics is way overkill for this game (radius distance collision would have been perfect) and because I think I’m supposed to scale the world to non-real-size (0.1 maybe) and I’m not currently doing that. I may even switch over to polygon collision soon.
  4. I need a re-useable library of my common stuff. I’ve now made so many quick hack games that I’m starting to see what’s reusable across games.

I don’t currently have the source uploaded anywhere but am willing to get it posted (or emailed) if people want it.

Until next time!

(Tech notes: written in .NET 4, XNA, Visual Studio 2012, IceCream engine, Indie Graphics Builder sprites.)

OneGameAMonth: January: Tactical Space

Welcome back!

I’ve started the OneGameAMonth (#1GAM) challenge for 2013! I just wasn’t making much progress on my “big idea”, so I thought it would be best to take smaller but more complete bites. With #1GAM, the idea is to build a very small but complete game each month, and I think that’s exactly what I need to get better.

For January I’ve started a game named, terribly, “Tactical Space”. It came to me while playing the demo of Angry Birds Space. The idea is that you, the player, have a planet on one side of a 2d map and the “enemy” has one on the other side. The goal is to destroy the enemy planet with various weapons, ranging from regular shelling to missiles. Between the two planets are a number of other planets and space debris that block and exert gravitational forces on your projectiles as they fly through space. A screenshot might help:

TacticalSpace20130114
Click to enlarge (twice, even!)

Let’s pick-apart this hideous excuse for entertainment:

  1. The player is the planet on the left, while the “enemy” is on the far right.
  2. The planets are obvious, but what isn’t obvious is the very lightly faded moon-looking outline on all of them. The texture is poor, but the idea is that it’s showing the field of influence of each of the planets. For example, the two bottom planets have very large fields of effect, and it’s easy to see because of the giant halo around them.
  3. The glowing dots are the projectiles that the player is currently shooting. There are many in this shot.
  4. The salmon-colored lines are for debugging and are drawn between planets and projectiles they’re affecting. On the right you can see a few that are under the influence of two planetary forces.

That’s about it for now, but I’m pretty excited. My next goal is to swap out some of the graphics with images from Indie Graphics Builder (I was part of the Kickstarter), which will help me establish a few more game-dev tools in my toolbox (Irfanview and Texture Packer). Though I think I’m going to go overboard and bloat the game several megabytes just so I can have a few cooler looking sprites. Then I want to add a few weapon options, maybe change the way the enemy planet is destructed, and a few more things I’m sure I won’t have time for in January.

The main tech behind the game is IceCream (modified by me), with Farseer Physics Engine handling hit detection when a sprite hits a planet. I’m not using realistic gravity simulation from Farseer, though I should be! Let me know if you have a great algorithm for handling gravity already written in C#. I just made mine up.

Download the game so far (9.1 MB 7z)