New Model Viewer

New version of the silly-little Egoboo Model Viewer. Now animating the models, allowing you to rotate them with the mouse, and sporting a readable font.

ModelViewer.zip

Egoboo 2.3.6 for Mac OS X

I don't know if there's anyone out there besides me who wants to play Egoboo on Mac OS X, but who cares? I want it, so I'm building it, and here it is. :)

If you have an existing Egoboo installation, you're going to want this file: egoboo-osx-r68.dmg. Just follow the directions in the included readme file.

If you want the new Egoboo 2.3.6 and you haven't already downloaded it yet, grab the full thing here: egoboo-osx-2.3.6.dmg. Just open up that package, copy the folder inside it onto your hard drive somewhere (it can't run within the package), and run Egoboo!<

Egoboo 2.3.6

Egoboo 2.3.6 has been released! I don't say it enough, but Zefz and the guys on the Egoboo Resurrection project are doing some great work. For the first time in years, there's honest new content to play. That's one of the big things that was missing in Zippy.

I'm also stoked as this release is using my Egoboo 2.x codebase. Brings a tear to my eye. :)

To get your copy, go here: http://home.no.net/egoboo

Universal Binary Egoboo

I found Universal Binary versions of SDL and SDL_ttf here: http://www.libsdl.org/cvs/. Yippee!

I needed to re-tool the Xcode project files to get it to build, and I finally got frustrated with egobootypedef.h and just re-wrote/re-factored it to make it much smaller/cleaner. Fixed up the rest of the codebase once those changes were in, and voila! It builds!

But of course there's a caveat. The endian-handling code was mucked up in the process, so certain images are loading with their red and blue channels swapped, and the game crashes once it starts loading models. Probably still works dandy on a Big Endian Mac, but I don't have time to try that now. So I'll be working on fixing that up tonight.

Intel Macs

Hey, my Work/University just got in a few MacBooks to start testing before we start deploying Intel Macs in the campus. I snagged one for a little testing of my own, and it runs Egoboo beautifully. And this is the version I posted a couple months ago; NOT a Universal Binary. So on a Dual-Core MacBook Pro, the Rosetta translator is fast enough to run Egoboo roundabout 350 frames a second. Noice.

I'm going to be going to a Red Hat training course the week of the 17th in Las Vegas, and since I don't gamble or drink, I'm going to bring the laptop along and see what I can accomplish Egoboo-wise on the lonely nights out there. With this thing, and Apple's BootCamp, I can be build and test on both Mac OS X and Windows. So here's hoping I'm productive enough to add some kind of new feature that week. :)

(later): Shoot, SDL doesn't quite work as a Universal Binary yet; at least not the release version. I'm not really in the mood to try and build it from source.

A Todo List

There is quite a lot of stuff I plan on doing to the Egoboo codebase, so when I get sit down to work on something, I occasionally get lost in what I wanted to work on. So I'm going to maintain this post as a Todo List of things that need to get done. It'll be edited from time to time.

Stuff to do:

• Implement proper timing code: gameplay & simulation should occur at fixed timesteps, while animation and rendering is allowed to run at whatever speed the computer can handle.
• Split game handling code into client & server portions, to make robust network play possible.
• Menus menus menus
• Re-work the input code, both to allow cleaner configuring of input sources and to allow for input playback for demos & the like.
• Adjust Egoboo's filesystem usage so that the game does not require write-access to it's own directory; this will make the distribution/installation of the game much cleaner on most OS's.
• Move from a per-module object store to a global one; commonly used objects should not have to be copied between different modules, and each saved character doesn't need it's own copy of a torch.
• Explore other possible inventory management schemes; Egoboo uses too many buttons for that right now. I want to be able to play on a controller with no more than 4 buttons.
• And along with the above few items, I want to be able to play the game on my Dreamcast. After the above issues are worked out, the main difficulty here is that all of Egoboo's level data is drawn as Triangle Fans, but the Dreamcast only supports Triangle strips. We'll see how performance is if I switch to straight Triangles on the DC.
• More to come

Beat!

I've been beaten to it: http://www.galaxymage.org/

Between that, and a request that I not drop the Egoboo stuff I've been working on, I guess I should keep at it.

So in that spirit, this is a test release that has new menus in place enough to run the single player game. There isn't any way to access the multiplayer stuff in this release, which is ok since it doesn't work all that well yet anyway.

Egoboo r39 - Win32
Egoboo r39 - Mac OS X

To run this release, extract one of the archives above into your Egoboo 2.22 directory. Windows users, you should probably make a backup of your egoboo.exe file first, as this will over-write it. Most Mac users don't have a working Egoboo anyway, so this serves as a way to let you play the game if you can't already. After you've extracted the archive, just go into your Egoboo directory and double-click on "Egoboo".

I haven't done much of anything with this since the last time I posted an update about it, so if you've played with the menu demo you're not going to see much new in this release. The 640x480 limit still applies as well; the menus have been designed to look nice in 640x480, they look kinda silly in anything higher. Cleaning that up is one of the many things on the todo list.

P.S. - Anonymous access to the Subversion repository is available at http://svn.csusm.edu/jfischer/egoboo/. The source code is located in http://svn.csusm.edu/jfischer/egoboo/trunk/src, so if that's what you're interested in I'd appreciate if you sync to that location, so that you don't download the whole game at once. =)

Menu Demo

Haven't had the time or drive to work on this in a couple weeks, so I thought I'd post up a demo of what I've got now so that people can play around with it.

Get the demo here:
Menu Demo for Windows
Menu Demo for Mac OS X

And the source is here:
Source Code

To run the demo, just extract the contents of whichever archive you're using into your Egoboo folder. You probably want to back-up your copy of the Egoboo executable first, 'cause this will overwrite it. Make sure that you extract the folders as well on Windows; Winzip should do that by default.

I made no attempt whatsoever to run this at anything but 640x480, so I suggest you do that too, else it will look stupid. :)

The interesting bits of code are in the Gui.* and Font.* files, and the bottom half of menu.c shows it in use.

Mac Eye Candy!

The Gui stuff worked fine on Mac OS X without having to change a thing. Yay!

Here's what the module select menu is looking at... I'm not totally happy with this yet though. I'm way less happy with the character select screen though, so I'm not showing that one until I am. :-)

Interestingly, you can't use the Mac OS X shortcut keys to grab a screenshot of an OpenGL window. You have to grab the whole desktop, and cut the window out of it. Didn't try using the Grab program though, that probably would've worked better.

More Eye Candy!

I put this together for the Zippy forums, so I should put it up here too:

Menu demo movie. (4.2 megabyte mpeg)

Eye Candy!

Here are those screenshots I promised. These are both in-game shots, not mockups. They look a lot better once you can interact with them and see the animation. Hopefully, I'll have enough menu-ing stuff by the end of the weekend that I can post a new executable for people to play with. Code too.

GUIs and Font Rendering

Timing update: I have the code in place to start converting things over to a proper time-stepped solution, but it isn't very exciting work, so I haven't dug into actually doing the converting yet.

I did find something else exciting though: a presentation by Casey Muratori about Immediate Mode GUIs. He put together a movie (found here, look in the sticky topic for the movie) in which he describes a different way of going about putting GUIs together. There's a lot of discussion about it on the site, and in general, it's a very neat idea. And it works beautifully for games.

So I'm building an IMGUI into Egoboo. So far it's very straightforward, easy to use, and easy to get robust behavior out of. It makes GUI programming a lot less tedious, and a bit more fun.

One thing that's annoying me about it though is that Egoboo's text rendering is rather... inaccurate, for lack of a better term. Where text appears on screen isn't where you would expect it to, given the coordinates you tell it to draw at. It's offset downwards by a bit. It's bugging me, and I'm iffy about trying to fix it and breaking text locations for most the game, so I'm quickly adding TrueType font support via SDL_ttf to use in the GUI system. Dunno if I'll keep it, but being that it supports Unicode text, it's probably a good idea to. Makes it easier to do translations somewhere down the road.

I'll post screenshots once I pretty this all up a bit.

This release adds networking back into Egoboo. (There was once a link here, but no longer).

When Egoboo was written back in 1998 (I think), Programmer X added support for playing over a LAN using DirectPlay. Since that's a Windows-only technology (that's going the way of the dodo, as I understand it), it was removed when the game was ported to SDL/OpenGL. No one has bothered to try porting it until now.

In 2001 (I think), Aardappel started working on a game engine called Cube, for which he put together a simple but robust networking library called ENet. That's the library I chose to port the DirectPlay stuff over to.

For the most part, it's been pretty straightforward. The functions used to put packets together really didn't change, except for adding code to make them endian safe. Sending packets was just pointing them through a different API, the concept was the same. The difficult part so far has been getting games started (with a host & client computers), and copying files across the network.

Egoboo stores saved players as complete copies of the object directories they were created from in the first place. Same thing with any inventory items a character might have. Because of this, players tend to be at least 600k big, and contain 60+ files each. As it stands now (and did back in '98), each remote/client/non-host computer copies each character & item that local players (of which there can be 2 or 4, I'm not sure) will be using up to the host/server computer. Once the host has collected all of the files from all of the clients, it sends them all back out again so that each client gets a copy of all the files necessary. So far, this has been preventing me playing over the internet. Too much stuff to send.

Getting it working was actually fairly easy, though it took me awhile to realize it. The original Egoboo code would split the files up into 2k chunks and send them across one at a time. I assumed I'd need to do the same thing with ENet. I spent days trying to get it working reliably until I took a look into the Cube engine's code (since that's where ENet came from) to see how it was done there.

Cube just shoves the whole file into one packet and lets ENet sort it out. That seemed way too easy. But it worked. Shove a file at a time into an ENet packet, send it across, and have the other computer send an OK packet back when it successfully receives the file. Easy.

It doesn't entirely work perfectly, but I am getting files across reliably a lot more often, and with a lot more speed, than I was by splitting them up into chunks myself. I still have more work to do to make it totally robust, but it's getting there.

Getting the game started hasn't been too difficult, by comparison. DirectPlay handled a lot of the work getting games started up before; it has built in lobbying support and whatnot. Cube doesn't handle that, so I had to rework things a bit so that you can specify a computer to connect to. That part really wasn't all that hard, I just had to cut out the menu parts that refer to the lobbying functionality and add a new one for connecting directly. It's kludgy right now; you have to specify the address of the host computer in setup.txt before you run the game, but it works.

And with those things in place, the game now connects and runs on 2 computers over a LAN. (I've left it deliberately at 2 players for now, I haven't felt like figuring out how I should space out sending files to up 8 players at once yet.) The game runs ok, but the speed at which network updates are sent & received is very dependant on the speed of the computers, so it tends to get out of sync really quickly at the moment. So next up, I'm going to look into standardizing the rate at which the game performs it's various updates. Tune in next time!