SVN r51/r52/r54: The Main (Joystick) Event

Okay. This one's sort of a doozy, so bear with me.

Up until r51, there was a functional difference between joystick and keyboard events. Joystick posted events to Player, which crafted Irrlicht events as necessary and made the system run. This would be all well and fine, if we wanted to use gamepads as keyboards. However, our goal is quite the opposite: We want the gamepads to be our main input devices, with the keyboard as a fallback and debugging tool.

So, here's the basics. Player should be a lightweight class. Joystick will generate events as necessary, using StateManager to determine when keyboard events should be synthesized in addition to joystick events. The struct JoystickEvent will be used to pass around joystick events. Joystick and JoystickManager will become smarter, and Player will become dumber. This is the plan.

r51 and r52 put down stubs and the initial code move from Player to Joystick. r54 simplifies the code, since being in Joystick means that less Joystick-specific information needs to be passed around.

TODO: Test this stuff. I haven't been able to test it yet. Also test OpenAL on Windows and get Irrlicht to use vsync on Linux.

~ C.

SVN r50/r53: VC2005 Support

r52: VC2005 finally works! It takes a load of work to setup, but I have written a readme that explains how to do all of it.

r50: Simple clean up.

SVN r49: No More Duplicates

In rev48 when you left the arena and re-entered the model form the previous arena was still being drawn, this revision fixes that problem thankfully. And all it took was a simple little line node->remove(), but of course I had to spend forever figuring that out. I also did some code clean up as well.

Anyway, small fix, but very worth while.

Keep an eye out, progress is being made,
Justin

SVN r48: Some Player maturity and bug fixes.

The player class is now creates and handles the models for itself rather than the Arena creating them. The arena is able to handle up to four players now, but since there are input limitations, only one is created for now. With the advancement in the Player class there is no reason now for the PlayerManager class and it's construction was removed from opensmash.cpp.

I also fixed a bug in the console that caused opensmash to crash when you backspaced too far. The bug was a string shrinking smaller than size 0.

Keep an eye out, progress is being made,
Justin

SVN r47: Cool new stuff.

R41 was my commit, but sadly, it was just code that I had slightly touched on and was too lazy to go back and try to remember everything about what I was doing.


Now there is r47. This is an excellent and much needed commit. I have fully obsoleted ArenaTest, made Arena work, but a major bug exists that is stumping me right now.

ArenaTest was the old way that the arena was loaded. There were many issues with it, mainly everything was hard coded; not very flexible or pretty.

Arena, oh Arena, thankfully it has come. I have been sitting on this idea for FAR too long. Arena now loads maps from an xml file. When we have more mature item and player classes the features of this new Arena class will extend heavily, look forward to that in the (hopefully) near future.

Sadly though, there currently exists a bug where the loaded player does not get deleted when you leave the Arena. When you leave and re-enter the Arena, the previous player(s) is still there and a new one is drawn.

Keep an eye out, progress is being made,
Justin

SVN r45/r46: Saturday Night Commit Fever

Hmm. I seem to be making a lot of broken-up, patch-style commits. Must be from working on git-based projects. At any rate, it's nice that the code is getting mature enough that variated commits aren't breaking the tree.

So, r45 brings Character Select up to feature parity with Menu. It's got FPS in the corner, and a Console hook, so the console displays properly. I'm considering making a global setting "show_fps" to control whether there's FPS in the corner for all states that support it, and also a global macro for making all drawing classes automagically have the Console included.

r46 makes the Console actually display in Character Select.

For some reason, Character Select both runs faster and is less responsive for me. I need to figure out why.

Talking about the future now. I need to find out why Irrlicht doesn't respect vsync, and also where the joystick mangling code in Player should go.

TODO: Settings-ify Character Select and Menu.

~ C.

r42/r43/r44: Potpourri

(Note: r41 is Justin's, so it's his problem to write it up.)

So, yesterday was busy. Justin and I sat down and talked extensively about code, and ended up writing a bunch of stuff. I'll go in order, trying to explain everything along the way.

r42 was mainly to commit a few changes to configure.in. I've been trying to move to a pure autotools framework, and part of that is moving all of the libraries that need to be linked from the Makefile.in stubs to configure.in. The final library, Xxf86vm, was finally moved in this commit, making us purely autotools now. (And of course, we may move to cmake or something similar in a while, but for now we're staying firmly put.)

I've mentioned OpenMP briefly, but I won't get into it here. It was enabled if your compiler (GCC 4.2 or newer, ICC) supported it, but for now I've disabled it. Passing --with-openmp to configure will enable it again. So far, the speed increases are negligible, and only occur in a few limited STL calls. We'll figure more of it out later.

There are also small fixes to Arena, CharacterManager, and a few headers. Also vsync is now enabled by default.

Next! r43 adds a 14pt monospace font for the Console and ArenaManager, which is like CharacterManager but for Arenas.

r44 was basically this:

$ optipng -v -o7 media/fonts/*.png
$ svn ci

For those not familiar with optipng, it is a cool utility that shrinks PNGs. (What? I was bored!)

TODO: Get the entire CharSelect path working. ArenaManager should be very easy to integrate. Also consider using XML files to lay out the character select and arena select screens.

Justin, Derrick, please write up your commits.

~ C.

SVN r40: MinGW/Win32 support

So, we now officially support MinGW building using the autoconf/automake system. (That's cross-compiling, for the new guys in the crowd.) It's not the biggest commit, but it's not anything minor, either; 300+ lines of changes total.

This is not Visual C++ support, although I see no reason why it won't build on VC. This is support for MinGW, which is a port of GCC to Win32. It runs natively, linking to Win32 core runtimes, and acts just like any other application. The catch is that this support is only for automake-based MinGW, which is pretty much limited to Linux cross-compiling. (At some point Derrick and Justin will make a VC-based version for building on Windows, I'm sure.)

In case you were wondering (and I know you weren't,) r38 belongs to Derrick and r39 was accidental and reverted by r40, so they don't get posts. (Well, Derrick was supposed to say something, but he's lazy.)

TODO: Win32: Fix bug where music does not play.

~ C.