For those not aware, there are other emulators out there for the Nintendo 64 apart from Project64, however nearly all of them have been left out in the dust. Over the years many other projects have gotten little attention. This isn’t a big tragedy apart from the fact that Project64 is closed-source, and win32-only (although it does run well in Wine).

The only F/OSS emulator for N64 had always been Mupen64, which was often criticized for being quite a bit less mature than Project64 and some others. In any case, it was in development so we all figured it would ‘get there’ eventually… Until 2005 shortly after the release of version 0.5.1 (win32), when the project just froze. Then 2006 came and went, then 2007… And seemingly no progress was being made. It was a sad state of affairs because Mupen64 was essentially the only hope for Linux users to have a native N64 emulator for their platform.

Now, finally. After a few years, a new team has come together to work on the Mupen64 codebase, they have dubbed their project “Mupen64Plus” (a little generic if you ask me), and they’re hard at work, hacking away. From the little research I’ve done, it would seem the leader (Richard42) of this new project was a long-time contributor to Mupen64, and the original head of the Mupen64 project (Hacktarux) was planning on adding some of Richard’s new work back to the original project. I’m not sure if this merge happened or not, but it seems that on the Mupen64 homepage, the last version is still 0.5.1 for Windows and 0.5 for Linux. So who knows what happened.

I’ve been hanging out in the IRC channel for the new project for a few days now, it’s more of a developer channel, so I’m a bit out of place, even so, I like hanging out, I figure maybe I’ll learn a thing or two from the masters. :)

It seems everything is well underway. Their homepage already has a release, version 1.3, which worked pretty well for me barring a few issues. This is obviously only an initial release, so don’t expect it to be light-years ahead of the original Mupen64, but with time it could evolve to be the best out there. If you have any problems with this release, make sure you file a bug report in the “Issues” section of that page (I filed one for Ogre Battle the other day), developers need info on problems to be able to fix them, and if you’re not a developer, this is the best way to help. Make sure your report is detailed, provide the md5 hash for the rom you’re using, and list which plugins you were using. Trying different settings on the plugins and seeing if there are different results, and adding this info to your bug report(s) can go a long way towards helping along with debugging.

So now we mere mortals can only wait and see how this unfolds, but it definitely looks very promising. A big thank you to all the individuals working on this fork, and keep up the good work. The N64 and Emu fans of the world are all rooting for you! (I’m such a ham…)

A note on closed-source emulators:

I must say I’ll never understand the concept behind the “closed-source emulator”. After all, the philosophy behind the emulation community at large is to make sure that old classic games do not become forgotten or die off just because a console is no longer in widespread use. After all you can only have so many game systems hooked up in your living room at once, and a lot of these old games can often be more fun then many newer titles. To me, a closed-source project is always more vulnerable for many reasons, not only does it not benefit from the open-source “with enough eyes, all bugs are shallow” philosophy, but I would imagine that a closed codebase is easier to attack if you’re a company. Think about UltraHLE and Bleem! back in the day, if they had been Open Source, it would’ve been impossible to stop the code from spreading and evolving. Neither Nintendo nor Sony would have any legal recourse to stop individuals from hacking on the code. If preserving the classics, and making sure they can run on modern platforms is your goal, then opening the code under an OSI-compliant license is the only realistic option to achieve that goal, otherwise companies do have the power to stop you if they choose.

I have to say, I really didn’t expect this kind of traffic for my humble little post about the Valve Source engine possibly coming to Linux, especially given that I reported on it a week or two after Phoronix! And seriously, 1500+ diggs, wow.

In any case, that aside, something has been bugging me, and as usual, I can’t just let it go.

Some individuals have been referencing my post, only to be shot down by people claiming my 3rd point is invalid because EA supposedly handled the PS3 port work. I have to say, nice detective work. I haven’t kept up with console release news recently, so I missed the story about EA having done the port.

However… This is completely irrelevant regarding my point. Sure, in the article I imply that Valve did it, ok, so substitute Valve for “EA”, the important point is that the code EXISTS. Somewhere, somehow, there is a version of the Source Engine out there that is powered by OpenGL. Furthermore, I would be willing to bet that the OpenGL work, at the very least, is all Valve’s, and that EA only did the PS3-specific bits.

Why do I say something so speculative? Because when the HL2 source code was leaked years ago, the engine used OpenGL as a backend. Now we all know that the HL1 engine was based on Quake1, and that the Source Engine was developed from scratch specifically for HL2, but it’s possible the general engine components were done first, and the rendering backend last, so maybe this OpenGL code from the leaked version was actually an evolution of the HL1 rendering backend, who knows?

Of course, when you factor in the Postal III port, everything more or less falls into place, and you start to get a picture of what’s going on, Valve has to have their own OpenGL somewhere, because I just can’t see a dev house like RWS or Akella writing an entire rendering backend on their own, if they were going to go through that trouble they would’ve been better off using an engine that fit their needs better.

Now I hope this settles the issue. Keep in mind that my post wasn’t designed to be authoritative on the issue, I am merely looking at the various clues, and drawing certain conclusions from them. If I am wrong, and there isn’t a Linux port, well, the points stand up on their own, in the end all it will mean is that Valve completely wasted some source code that they already had in their hands, for whatever reason.

Anyways, that’s it for me. Until next time, take care of yourselves, and each other. :)

A client had called me up this morning and stated that his Antivirus is out of date. Of course, he has Symantec and always has issues in this regard. I proceeded to block out a couple of hours since I figured it was a virus that caused the issue. When I tried to run live update, the following error message occurred.

Error: “LU1814: LiveUpdate could not retrieve the update list”

After reading this, I figured, hey, maybe it is not a virus after all! WOOHOOOO! I proceeded to google the message which brought me to the following symantec kb article regarding this.

After skimming through that article, I determined that all those steps were retarded, so decided to go for the last one which is reinstall live update. If nothing else, web 2.0 has brought on a new meaning of reinstalling software. All you need to do is go to that website and everything got updated automatically. The first time I ran through the install, it said I had live update running in the background and needed to terminate. I killed the service and ran it again. This time it prompted me to modify, repair, or uninstall. I chose repair and ran through the install successfully.

One the install was finished, I tried to update symantec. The first time live update opened, it said it had updates for live update (I thought I just installed the most recent version…oh symantec, you slay me!) I went through those updates and finished. I went to update symantec again and this time it worked! Excellent! I kicked off a virus scan (hey, you never know) and told the client to let that run but he should be set. We will see in the upcoming days if there was a virus causing this or just some corrupt file that liveupdate did.

A client called me up and said that his iTouch is malfunctioning. About a year ago, I would run to the hills with a call like this, since well, I hate ipods. The iPhone has given me a new light on the subject now. I took this call with both eyes open and actually read the error message.

this ipod cannot be used because the Apple Mobile Device service is not started

This struck me as odd and noticed that the service was indeed not started. I threw this message into google and was floored with the resolutions.

REINSTALL iTunes?!?!?!?!

I see no reason why I should reinstall iTunes so for giggles, I decided to check out the services and see if the service was indeed not started. Indeed the service was disabled. In the back of my mind, I wonder why this is but changed that to automatic and started the service. Immediately, the iTouch started to work.

If the issue is virus related, it will occur again and I will have to do more research, but, at this moment, it seems that the issue is resolved! If it is virus related, I will update.