First video tutorial.

http://www.youtube.com/watch?v=9OSFt0FfwfQ

Adventures in homebrew -- wii part 1

I work on a lot of different things, all the time.

Tonight I finally got devkitpro working for doing wii development.

My environment is the following

VirtualBox image of debian 6
DevkitPPC
codelite IDE
and a softmodded nintendo wii


My initial goal was to port Mono to the wii, but that seems like quite the daunting task. Mono is a big platform, and I certainly don't know my way around auto-tools, but getting it ported could certainly be worth it.

For now though, it might be worth trying to port a smaller platform over to the wii.

Python is certainly a candidate. Javascript and lua certainly have their appeal.

V8 looks interesting, if I can figure out how to force scons to use the devkitpro ppc compiler.

That will be the next avenue of attack, I think. For now, sleep!


edit:

Found this until I can figure how to make v8 do my bidding!

http://code.google.com/p/tiny-js/

viper - next steps

So I've made some decent progress on viper. I think now would be a great time to justify yet another game development library, seeing as there is already xna, openTK, Tao.NET, Unity, SFML, and several others.

Maybe the biggest one is that they aren't all that friendly to use. I'm not saying that they are difficult. DirectX is difficult, OpenGL + Extensions under win32 is difficult. I'm just saying that they aren't friendly. 

OpenTK and XNA both require that the gut class of your program inherit from a class in their assembly. I'm not saying that inheritance is a bad thing, it's actually quite useful, but it forces you to adopt their way of thinking, and at least in the case of XNA, for a beginner, it's not always clear what to override.

Viper provides a more explicit interface. In viper, you create the window, not inherit from an abstract window or game class. You explicitly define it.

Another thing that viper provides is thread safety. Most of the time, you aren't going to want your rendering code in a secondary thread anyways, but you might want your resource loading to happen in the background. With OpenGL, and much of Direct3D, all the calls are required to be made on the same thread in which the context was created.

When the pitviper window is initialized, the first thing it does is create it's own UI Thread. That thread creates the output window and does message processing from two message queues; the windows system message queue, and an internal message queue.

The internal message queue is a queue of Action<> delegates. When you call a method like myGameWindow.Clear(255,255,255) what it's really doing is queuing up a new action delegate containing the command, and placing it into the private queue. The UI Thread will then dequeue the call, and execute it. This is how thread safety is achieved.

This also has the unintended side effect of potentially making your code faster. If you are in the habit of doing a lot of calculations in your rendering code, on the same thread, you are doing that math, then the rendering, then more logic, then more rendering. By offloading the rendering to a dedicated thread you can go from this

logic  |  render   |   logic   | render  |

to this

logic 1 |   logic 2  | logic 3  | logic 4  |  logic 5  |

        |  render 1  | render 2 | render 3 |  render 4 | render 5

Granted, you do have the overhead of a context switch, and you won't see a huge boost on hardware with only a single thread, but the goal here is not ultimate performance, but rather simplicity. If we can get a small performance boost out of it at the same time in some scenarios, then awesome!

***

Another thing that sets viper apart is that it's primarily 2D, and I don't see that changing. There are constraints with what you can realistically do in a 2D environment. When you go 3D, you can either do far too little, or far too much. The first thing that comes to mind is vertex formats. Position? Position + color? Position + color + texture + normal? Position + color + texture + normal + extra info for the shader? I feel that by going 3d, it would break away from the concept of simplicity that I'm aiming for.

***

Currently, I'm relying on OpenGL 1.2, and I don't know if that will ever change. Having support for shaders would definitely be nifty but GLSL is far from being simplistic, and at this point I'm not sure the benefits out weigh the obstacles. If somebody wanted to help me enable them in a sane fashion, that would be amazing.

*** 

I suppose the next big huge step is going to be finishing up the input sub system. Keyboard and mouse should be fairly straight forward. Right now, the keyboard uses get async key state to poll the keyboard directly, but I'm going to investigate using raw input instead.

***

I'm working on tutorials and documentation for the time being in hopes of attracting more attention to the project, and oh yeah, I should probably host it somewhere. A game showing it off would be nice too.

Pit-viper initiation

==Win32 OpenGL gaming API (tentatively called pit viper)==

* Opengl 1.1 2D rendering

** Need to work on screen sampling

* Opengl 2.1 2D rendering

** Fragment and vertex shaders load, compile, and execute. Look like complete garbage.

** All my model-view transforms are done via a custom matrix class. Could do final transformation in software or move to a vertex shader

** Might have a library of predefined shaders. (sepia, warp, blur, resample, etc)

** Support for rendering to an image

** Support for Texture rectangles, not just POW2 textures.

** Need to find a way to do some font rendering

* Sound

** Have been playing with the win32 waveOut functions.

** Sound is a very complicated beast.

** Will have support for creating samples

** Will have native support for playing back wav audio.

** Support for sound streaming.

* 3D drawing

** Much of the 3D code is already available via ManaGum and Unicorn21 projects. Should be easy to import.

** Consider using modified original quake .MAP format for worlds. Brush collision detection is super easy.

** Consider using original quake MDL format for models, in addition to an XML interpretation of said format http://tfc.duke.free.fr/coding/mdl-specs-en.html

** Geometry streaming engine, for working with really large levels.

** Block terrain generation (See pyboxel for more info.

** Batch rendering similar to existing 2D components.

** Point sprites as well

** Lighting To Be Determined

* Input handling

** Will be done using the raw-input API.

** Will expose keyboard, mouse, and game controllers

** Will automatically provide support for 2 button joysticks. 

* Physics to be determined, or separate project.

* Networking to be determined

* Entity framework to be determined

Thoughts on a lazy Sunday afternoon

So I've been sitting here, thinking, about some of the projects I've been working on. I'm really enjoying working on my PyBoxel project, things are actually starting to come together on it. I've got a firm grasp on how I want the project to proceed, and I'm actually spending time working on it almost every day. I think it will be a pretty big hit when I roll it out and really start getting feedback on it.

I've also been thinking about some of my other projects, and I think if I can get them out of my head on paper here, that I can leave them alone for now to keep working on PyBoxel.

Building a game console in Linux has always been a long term goal of mine. There isn't a whole lot to really do with it, other than make a gamepad friendly window manager. Everything else is already practically written. Aptitude with package signing provides secure content distribution method, wireless drivers, display drivers, etc, it's all there. The Devkit would basically be SDL, and a hand full of other small libraries.

Now that I have the spare PC guts, it might be worthwhile to start building a prototype. The D525 isn't much, but it's more than enough for most games.


Another thing that I've been thinking about is that processing game input sucks. I think a modular input server would be a fantastic idea using raw input, allowing the client to handle interpreting the byte strings would be just the thing. It's a very scary sandbox to be playing in, but I think with the cross platform libusb, it might be just the ticket for raw-reading pesky usb game controllers that might not otherwise have drivers.


I've also been thinking greatly about how to make programming in python more accessible. Thinking back to the elder computers such as the C64 and the TRS, instead of spending hours playing games in-front of a TV screen, you could handily make your own in some dialect of basic. I think a portable everything-but-the-screen setup would be a lot of fun to work with.

I can start putting together the right Debian spin or whatever, but finding the cheap hardware, Ideally something around $100, with like an atom or a geode CPU would be idea. Bundling it with a book would be a good idea too.

http://www.commodoreusa.net/CUSA_VicSlim.aspx

something like this, but with a cheap ARM cpu. I think the raspberry PI would make a great foundational component for something like this. until that comes out, the beagle bone is only 89.

So, back on track with the pyboxel project then!

On Linux

It's been a while since I've posted. My thinking was to post an update every time I finished something cool, but by the time I get to a point where I want to stop, it's 3AM and I have to be up for work by 7. Hopefully I will at least make one update a week.

So I was thinking about Linux lately. Mostly because of the post by the blogger at Red Hat sounding the alarm about potential vendor lock in with UEFI secure boot. Microsoft then offered an explanation and a rebuttal regarding it, then said blogger went off the deep end in part two of his post saying that Microsoft can't be trusted, and all the other silly rhetoric we've been hearing from those who have taken an unhealthy interest in free software.

That got me thinking about Linux in more general terms, about the different distributions, the community, etc. And there seems to be a contradiction. The community wants Linux everywhere, but they don't really want it simple enough for the average user to use it.

A favorite phrase of mine is: 20XX is the year of Linux on the Desktop. My response to that is, not until it can play MP3s, Mpeg 4 video, Flash. Not until it comes bundled with restricted drivers, and definitely not until you can operate the system completely without having to touch the command line. In short, there's going to have to be a commercial distribution.

My guess is in the next 5 years or so, there will be a commercial spin of Ubuntu, that will either come on you PC, or you can buy from their site online. If it doesn't require an activation system, it will at-least require you to sign on with your Ubuntu one account. (This is all just rampant speculation though)

Some of you reading this are probably cringing right now. Charging for free software? That's against our philosophy!

The problem is that you can have universal adaptation, or you can have a completely free environment (cost and liberty), but you can't have both.

Eventually, there will be good free codecs for media, there will be good free drivers, and there will be a good desktop, but who will encode with them? Who is going to convert their massive libraries of music or videos to free formats?

Linux is winning in the mobile realm because Google's Android has made these concessions. You can watch Netflix, you can play flash, you can listen to your MP3s, you can even make phone calls. But it's because they compromised on non-free software.

---

So, I guess, if you are a Linux supporter, do you support broader adaptation or do you support freedom of choice? At this moment, it's really hard to have both.

Little update - rewrote chin music in C

http://dl.dropbox.com/u/2126236/formatted_contort_c.html

A rewrite of chin music in straight C. A lot nicer looking than the C# version in some ways, a lot more portable too. One file, the executable is only 14 KB!