One of the main attractions that lead me to buy Nintendo's Wii console was the Virtual Console games. Through the Shop Channel service, one can purchase and download games from older systems. Being interested in classic video games, it allowed me to obtain games that were difficult to find or otherwise troublesome to obtain.
There's one major problem I have with the service, however: the enormous stack of games I already have for these classic game systems. If I wanted to play them on the Wii, I would have to purchase them through the Shop Channel, and many of them are not even available.
The Wii console is equipped with two USB ports. This gave me an idea: the Gamecube had an add-on called the GameBoy Player. This device attached to the bottom of the Gamecube and allowed one to play GameBoy and GameBoy Advance games on the Gamecube. Why not have similar devices for the Wii? These would attach to the console via USB, and there would be one for each type of console the Wii could emulate (or perhaps just ones for their own consoles).
This would make for an excellent way for me to play my NES and SNES games. Right now I am playing them on a cheap knock-off console, for which Nintendo has seen no profit. Why not sell me devices that will cut down on clutter and allow me to put money in the pockets of the company that invented the original consoles?
I know that myself and thousands of others would love to have the opportunity to own such devices. But there are significant reasons that will prevent this, and I'm all too aware of these.
First of all, USB is a widely-used standard. Hackers (non-malicious ones, mostly) would find ways to hack the devices or create drivers that allow one to dump the contents of their game cartridges to their computer and play the games there. Nintendo would be way too afraid that these people would distribute these games over the Internet. This is quite foolish, however, considering that all of these games are already out there and fairly easy to obtain. The cat's already out of the bag.
The second reason is the engineering costs. These probably would not be offset by the small percentage of Wii owners who are interested in this prospect. I could be wrong, but I feel as though I am in a quite small group of individuals that would put down money on something like this. Sure, there are probably thousands, but there are millions of Wii owners, and I doubt (and I am sure Nintendo would agree) that they wouldn't have an easy time making their money back.
Third, they would much rather you bought the games on their Shop Channel instead. The engineering for that is already done and whatever they rake in now is almost pure profit.
Finally, there's no way they'd want to do tech support on something like that. If you are old enough to remember owning an NES, you probably remember spending more time trying to get your games running than you did playing them. This is less true with the SNES and N64, but with the cost of engineering and production, the last thing Nintendo would need is to tack on the cost of helping people get them working over the phone.
So, this idea is just a crazy pipe dream (Mario pun partially intended). But what about the WiiU?
The WiiU implements a new, touch-sensitive controller/tablet. Using that and the television, it is not out of the question that it is possible for the WiiU to emulate Nintendo DS games the same way the Game Boy Player was used. In my mind, it is possible to create a device that accepts a Nintendo DS or 3DS card and connects to the WiiU via USB.
While I'm sure such a project is well within the realm of possibility, I am really not sure that Nintendo would create such a device. The fear of making piracy easier and costs of creating the device will likely kill such a project before it even gets started. I must admit, however, that I would love to own one.
Saturday, September 17, 2011
Saturday, September 10, 2011
Windowing Toolkits: Why You No Meet My Requirements?
Recently, I had an epiphany. I had been searching for a programming project that could, simultaneously, be something I'm familiar with, something that forces me to learn new things, and be something I intend on finding a use for in the future.
Now that I have made some significant progress in this endeavor (and also because I have no readers of my blog), I have decided that I can safely announce here what I have been working on.
My idea is a hodgepodge of projects I have done in the past, integrated in such a way that they can all be used together easily and effectively. When playing Kalarsys (http://kalarsys.exofire.net) over the Internet, we typically use our computers to simulate dice rolling, store character sheets, and (Tale Spinners specifically) generate non-player characters (NPCs). For the dice rolling and NPC generation, I had created programs in the past. While lacking elegance, they were functional. We typically used word processors to handle our character sheets and a web browser to reference the various game materials.
This mess leaves at least four or five windows open simultaneously, ignoring any whiteboard and voice-over-IP (VoIP) software we are using. "Why not combine some of this shit into one program?" I pondered to myself, nearly wetting my pants in excitement over the prospect. I drew up some diagrams of what the program should look like. Then, I got to work selecting a toolkit to use for developing the graphical user interface (GUI) of the program.
I thought, foolishly, that my requirements were simple:
I decided on GTK+ almost immediately. Coding the interfaces without any sort of GUI editor was super-easy. The paradigm of packing boxes was easy to grasp and simple to code. I had about 80% of what I needed to know about it down in my first day at it, I'm sure. I had a basic UI done, three buttons at the top for "NPC Gen", "Book Reference", and "Character DB". In the middle, a simple and always-visible instance of a dice roller. Finally, a big area at the bottom for whatever was selected with the top buttons. I imported (and slightly modified) some code from my most recent KDice GUI program and got the dice roller working.
Then, I decided to try and get my development environment on Windows set up. Holy shit, if I knew it was going to be such a pain I wouldn't have bothered. I spent way too long finding a way to do this, but at long last, the official website was able to make me feel stupid when I figured it out. (At your own risk: http://www.gtk.org/download/win32.php, download the 2.22 full bundle and read the readme).
I told Code::Blocks to check in c:\opt\gtk and I was set to go. I got the program built and running and I was feeling pretty good about myself. I was living the high life, developing with an intuitive toolkit with a long UNIX/Linux history on Windows.
Then, I thought it would be great to get the book viewer up and working. I may as well have tried clipping my nails with a garbage disposal. One of my tenants listed above was that HTML rendering is required. Oh, no big deal. There's GTKHTML, right? Or WebkitGTK+. Or GtkMozEmbeded.
Well, here's the rub: GTKHTML hasn't been supported (in either iteration) for several years. WebkitGTK+ doesn't work on Windows. If I'm wrong, which I pray endlessly for, prove me wrong. Please. If there is some magical way to use it, then please direct me to a guide or tutorial showing how. GtkMozEmbeded suffers from a combination of the two previous problems: It's old and unsupported, and also doesn't work in Windows. (And by "doesn't work" in this context, I mean that they aren't compatible with mingw32-g++ (my C++ compiler in Code::Blocks) running on Windows.)
I think I spent a good two days Google-searching for some way to get any of these three solutions to work. And I found lots of help....for those programming in Python. Foolishly, I pressed on. I found some GTKHTML packages, but the only mingw32-g++ ones were some OpenSuSE packages. Suddenly, I knew what I had to do: create a Linux virtual machine, install OpenSuSE on it, install these packages and cross-compile for Windows.
I love programming (when it doesn't make me want to pull out my pubic hair one at a time as a means of exchanging my emotional pain for physical pain). I love using Linux (when I don't get the sudden urge to play Oblivion. Or any PC game for that matter.) Somehow, though, coding this program in Linux and compiling for Windows seemed like a suboptimal solution, especially considering I was already set up for compiling on Windows. GTKHTML was a picky bastard, though, and my code struggled to compile with it around and refused to link outright. (Compiling turns code that has been written into machine code, linking takes the compiled code I've written and combines it with the GTK+ code I'm using to make the final program.)
Somehow, I managed to get GTK+ programs to work in Linux without Code::Blocks working for me and even made a few friends along the way. Most notably, pkg-config, which I remember somewhat from my tangles with SDL. He's a little helper that'll grab all the options you need to include for compiling and linking code that uses external code, like GTK+ or SDL. A simple `pkg-config --cflags --libs gtk+-2.0` in my makefiles helped my code compile and run, but GTKHTML was still being a bitch.
Endless Googling (and even Bing-ing, in desperation) returned not useful results. UNTIL someone with my exact problem (I swear to God it was buried under four pages of nonsense results) was helped by an old C coder. (http://forums.freescale.com/t5/CodeWarrior-for-ColdFire-and/CW6-1-Undefined-Reference-Linker-Error/td-p/1397) Though it didn't immediately help, it sure put me on the right track. Putting my "#include <gtkhtml/gtkhtml.h>" preprocessor command inside my other new friend, an "extern "C" { }" block, fixed those linker errors right up. And made me feel like dumbass for wasting so much time.
So far, my disgusting solution of cross-compiling has been working decently well. Except for the 15MB of DLLs I have to ship with my program. Then I'll have to figure out what exactly the licenses are forcing me to include in addition to that. Oh, and the D-Bus errors I can't seem to fix, though the program still works fine. Mostly.
Then I decided it was time to include a chapter listing. Click a chapter, the HTML code of that chapter gets sent to the GTKHTML widget to be rendered. Great in theory, except despite how easy everything else in GTK+ is, list boxes don't exist. Instead, there are... um... Tree Views. They're amazingly powerful and extensible. But when you just want to display a God damn list of items in a box, it's overkill. They're ridiculously complicated and unintuitive. Somehow from copying the code of others I've managed to get a rudimentary list box going in just over 20 lines of code. Despite it's great power and flexibility, I'm used to doing such a feat in under five lines. Thankfully, someone has written a decent wrapper for them... in Python. (Python is evidently more popular than I thought, and startlingly so.)
For some reason I haven't given up on the project yet. I'm way too close to having a finished, usable product to give up now. And I can't imagine that the hard stuff isn't behind me, though I doubt I could be surprised after the list box incident.
There were points in time where I decided that maybe I'd be better of using WxWidgets or something other framework. I was greatly averse to such an idea when I started. WxWidgets requires a 2GB package to be installed for me to develop with it in Code::Blocks. Also, I don't remember much from my last foray with it, but I remember struggling with coding the interface design (there's a GUI for it, but I won't want to depend on that). At this point, however, it isn't out of the question that I'd start over and made a WxWidgets version once I finish. There's an easy-to-use HTML rendering widget and list boxes at least. Plus, installing a 2GB package to compile natively doesn't seem so bad compared to a 4GB virtual Linux machine for cross-compiling.
Now that I've gotten all that off of my chest, I think it's time to give my fingers a break. They've been doing a lot of coding and sandwich making lately, and blogging isn't doing much to stave off my imminent carpal tunnel syndrome. While it may seem crazy, I think what I may do is start over fresh and make some kind of guide on how to do this all in the future, partially for my own reference and partially to demonstrate how insane the process is. Hopefully some good comes out of the teeth my keyboard has claimed from me.
Now that I have made some significant progress in this endeavor (and also because I have no readers of my blog), I have decided that I can safely announce here what I have been working on.
My idea is a hodgepodge of projects I have done in the past, integrated in such a way that they can all be used together easily and effectively. When playing Kalarsys (http://kalarsys.exofire.net) over the Internet, we typically use our computers to simulate dice rolling, store character sheets, and (Tale Spinners specifically) generate non-player characters (NPCs). For the dice rolling and NPC generation, I had created programs in the past. While lacking elegance, they were functional. We typically used word processors to handle our character sheets and a web browser to reference the various game materials.
This mess leaves at least four or five windows open simultaneously, ignoring any whiteboard and voice-over-IP (VoIP) software we are using. "Why not combine some of this shit into one program?" I pondered to myself, nearly wetting my pants in excitement over the prospect. I drew up some diagrams of what the program should look like. Then, I got to work selecting a toolkit to use for developing the graphical user interface (GUI) of the program.
I thought, foolishly, that my requirements were simple:
- Must be cross-platform. I'm the only one that uses Linux on a nearly fulltime basis, but I want to be able to run a native copy.
- Must be "open". I avoided Microsoft's Visual Studio Express products because of license issues. While Mono provides a decent, open-source .NET implementation, I didn't want to use anything that was based on such a closed system.
- Must provide a means of rendering HTML. The rulebook(s) are in HTML, and by being able to separate the chapters the program would be able to render chapters without me having to change the book in any real way.
- Must be programmed using C/C++.
I decided on GTK+ almost immediately. Coding the interfaces without any sort of GUI editor was super-easy. The paradigm of packing boxes was easy to grasp and simple to code. I had about 80% of what I needed to know about it down in my first day at it, I'm sure. I had a basic UI done, three buttons at the top for "NPC Gen", "Book Reference", and "Character DB". In the middle, a simple and always-visible instance of a dice roller. Finally, a big area at the bottom for whatever was selected with the top buttons. I imported (and slightly modified) some code from my most recent KDice GUI program and got the dice roller working.
Then, I decided to try and get my development environment on Windows set up. Holy shit, if I knew it was going to be such a pain I wouldn't have bothered. I spent way too long finding a way to do this, but at long last, the official website was able to make me feel stupid when I figured it out. (At your own risk: http://www.gtk.org/download/win32.php, download the 2.22 full bundle and read the readme).
I told Code::Blocks to check in c:\opt\gtk and I was set to go. I got the program built and running and I was feeling pretty good about myself. I was living the high life, developing with an intuitive toolkit with a long UNIX/Linux history on Windows.
Then, I thought it would be great to get the book viewer up and working. I may as well have tried clipping my nails with a garbage disposal. One of my tenants listed above was that HTML rendering is required. Oh, no big deal. There's GTKHTML, right? Or WebkitGTK+. Or GtkMozEmbeded.
Well, here's the rub: GTKHTML hasn't been supported (in either iteration) for several years. WebkitGTK+ doesn't work on Windows. If I'm wrong, which I pray endlessly for, prove me wrong. Please. If there is some magical way to use it, then please direct me to a guide or tutorial showing how. GtkMozEmbeded suffers from a combination of the two previous problems: It's old and unsupported, and also doesn't work in Windows. (And by "doesn't work" in this context, I mean that they aren't compatible with mingw32-g++ (my C++ compiler in Code::Blocks) running on Windows.)
I think I spent a good two days Google-searching for some way to get any of these three solutions to work. And I found lots of help....for those programming in Python. Foolishly, I pressed on. I found some GTKHTML packages, but the only mingw32-g++ ones were some OpenSuSE packages. Suddenly, I knew what I had to do: create a Linux virtual machine, install OpenSuSE on it, install these packages and cross-compile for Windows.
I love programming (when it doesn't make me want to pull out my pubic hair one at a time as a means of exchanging my emotional pain for physical pain). I love using Linux (when I don't get the sudden urge to play Oblivion. Or any PC game for that matter.) Somehow, though, coding this program in Linux and compiling for Windows seemed like a suboptimal solution, especially considering I was already set up for compiling on Windows. GTKHTML was a picky bastard, though, and my code struggled to compile with it around and refused to link outright. (Compiling turns code that has been written into machine code, linking takes the compiled code I've written and combines it with the GTK+ code I'm using to make the final program.)
Somehow, I managed to get GTK+ programs to work in Linux without Code::Blocks working for me and even made a few friends along the way. Most notably, pkg-config, which I remember somewhat from my tangles with SDL. He's a little helper that'll grab all the options you need to include for compiling and linking code that uses external code, like GTK+ or SDL. A simple `pkg-config --cflags --libs gtk+-2.0` in my makefiles helped my code compile and run, but GTKHTML was still being a bitch.
Endless Googling (and even Bing-ing, in desperation) returned not useful results. UNTIL someone with my exact problem (I swear to God it was buried under four pages of nonsense results) was helped by an old C coder. (http://forums.freescale.com/t5/CodeWarrior-for-ColdFire-and/CW6-1-Undefined-Reference-Linker-Error/td-p/1397) Though it didn't immediately help, it sure put me on the right track. Putting my "#include <gtkhtml/gtkhtml.h>" preprocessor command inside my other new friend, an "extern "C" { }" block, fixed those linker errors right up. And made me feel like dumbass for wasting so much time.
So far, my disgusting solution of cross-compiling has been working decently well. Except for the 15MB of DLLs I have to ship with my program. Then I'll have to figure out what exactly the licenses are forcing me to include in addition to that. Oh, and the D-Bus errors I can't seem to fix, though the program still works fine. Mostly.
Then I decided it was time to include a chapter listing. Click a chapter, the HTML code of that chapter gets sent to the GTKHTML widget to be rendered. Great in theory, except despite how easy everything else in GTK+ is, list boxes don't exist. Instead, there are... um... Tree Views. They're amazingly powerful and extensible. But when you just want to display a God damn list of items in a box, it's overkill. They're ridiculously complicated and unintuitive. Somehow from copying the code of others I've managed to get a rudimentary list box going in just over 20 lines of code. Despite it's great power and flexibility, I'm used to doing such a feat in under five lines. Thankfully, someone has written a decent wrapper for them... in Python. (Python is evidently more popular than I thought, and startlingly so.)
For some reason I haven't given up on the project yet. I'm way too close to having a finished, usable product to give up now. And I can't imagine that the hard stuff isn't behind me, though I doubt I could be surprised after the list box incident.
There were points in time where I decided that maybe I'd be better of using WxWidgets or something other framework. I was greatly averse to such an idea when I started. WxWidgets requires a 2GB package to be installed for me to develop with it in Code::Blocks. Also, I don't remember much from my last foray with it, but I remember struggling with coding the interface design (there's a GUI for it, but I won't want to depend on that). At this point, however, it isn't out of the question that I'd start over and made a WxWidgets version once I finish. There's an easy-to-use HTML rendering widget and list boxes at least. Plus, installing a 2GB package to compile natively doesn't seem so bad compared to a 4GB virtual Linux machine for cross-compiling.
Now that I've gotten all that off of my chest, I think it's time to give my fingers a break. They've been doing a lot of coding and sandwich making lately, and blogging isn't doing much to stave off my imminent carpal tunnel syndrome. While it may seem crazy, I think what I may do is start over fresh and make some kind of guide on how to do this all in the future, partially for my own reference and partially to demonstrate how insane the process is. Hopefully some good comes out of the teeth my keyboard has claimed from me.
Subscribe to:
Posts (Atom)