News

2007 June 26 - Resolutions

A few graphics bugs have been fixed. The display surface was only flipping in 640x480, which is fixed, and the interpolation modes should now work.

Not all of the display options like the fancy interpolation modes have been built right into the game's own configuration UI yet, so for now, you'll have to play around in the u3_config.xml file. Specifically, in the "ultima3 > screen" section:

• width and height control the game resolution.
• fullscreen is 0 for windowed and 1 for fullscreen.
• tileset is an index value for the tileset you'd like to see, but it's easier just to hit F11 in game to cycle between all the supported tilesets.
• flat_gems is 1 to show flat squares in the gem view or 0 to see tiny map tiles.
• surface_3d and dungeon_3d indicate whether to show the surface or dungeons in overhead or first-person view. Normally, you want 0 for surface and 1 for dungeons. Note that how the movement works can get bugged if you're using F11 to manually select view modes, and you can end up being unable to rotate the camera in the dungeons.
• scaler indicates which full-screen scaler to use to enhance the graphics.
  • 0 - No scaling
  • 1 - 2x Bilinear scaling (blurry!)
  • 2 - 2xSaI scaling
  • 3 - Scale2x scaling (from xu4)
  • 10 - 2x Scaling with no interpolation, useful only for testing

And speaking of configuring the game, it's probably worth discussing how to get it to run at all since I haven't put out any kind of public release and may not for a while.

• Get the source code. Sourceforge allows for anonymous access and anyone can grab the tree out of Subversionby pointing their SVN client -- TortoiseSVN is a good one -- to https://svn.sourceforge.net/svnroot/u3project. The repository is also viewable in your browser, so go ahead and click that if you're curious.
• Get it to build if you can. You'll need at least Visual Studio 2005 (I'm using the Express Edition, which is free). You'll also need the Windows SDK (also free), SDL, and SDL_Mixer. ZLib, LibXML, and Iconv are also used by the project, but they're already in the repository and the project doesn't need additional configuration to find them.
• Under the U3Project directory, you'll see a new directory created that is not under revision control called U3Project. Depending on whether you build debug or release, you'll see either ultima3d.exe or ultima3r.exe there.
• Copy everything from conf, graphics, and mid to the same directory as the EXE.
• Add all the files from the original game. Not all of these are used by U3Project, but most are.
• Configure the xml file, or not, and run.

2007 June 25 - This place is a mess

Most developers can appreciate the experience of going back and reading code from a few days or weeks past and finding it unfamiliar. Many times you notice things that don't quite look right. What were you thinking? Who wrote this, anyway?

Well, it's been three years for me this time. While a lot of the code is still familiar, I'm fortunately not the same developer I was three years ago, so I would have done many things differently now. It's almost a little embarrassing knowing that anyone might have been browsing through my code out there on SourceForge for the last three years. "This guy," you must be thinking, "is an idiot," and you'd be right. A lot of the code looks way overwrought.

This is especially obvious when you start looking at the original source for the game. Now of course there's no high-level-language source, since Lord British (Long May He Reign) wrote the original game in Apple II assembly and not in C. A few kind souls have pointed me in the direction of some decompiled assembly versions of the game code from the Apple II and the Commodore 64, and of course compared to my object-oriented and thread-synchronized monstrosity with its third-party libraries and its swaths of never-called code and its too many ways to do the same thing, the original game source is elegant and to the point.

So while I lightly clean up the code -- and GameWnd.cpp was a monolithic mess -- I'm sort of also going through these old sources and trying to figure out how the original combat worked. Much of the semantics of the code has been provided to me by the people who have done the decompiling, for which I am grateful. Really appreciating what's going on it going to require me to learn 6502 assembly, which isn't so bad, and putting together some kind of map of how the game looks in memory. Fortunately, I won't have to do this for much of the game, since almost all of the game is already figured out and done.

So that's what's going on. If I don't emerge from my underground lair anytime soon, send a party of adventurers down to fetch me.

2007 June 23 - One big happy window again

The app's main window and the key event handling are now moved over to SDL, making everything just a little bit more portable. A few other key things like threading and MIDI playback can be moved over later without much trouble.

With everything up and running again in just one window, it's time to turn attention to the gameplay. Most of the issues I still have to get through involve the combat mechanics. How much HP does a monster have? How do the players attributes influence how likely they are to hit or how much damage they do? And most perplexing of all, what do all of these pesky spells do? This is the wall I hit before that caused me to lose interest in the project. It's time to overcome that and do some research into the mechanics of the original game.

2007 June 22 - I can see the title screen from here

The video wrapper is now converted over to SDL and is working pretty well. Even the hacked-up stretch blitting works. The font engine is still Windows-based, but that hardly matters from a portability standpoint, since U3Project doesn't use the font rendering at all and ports can just take that code out. In fact, I should probably take it out now myself.

U3Project is up and running as far as the title screen and main menu, and I'm assuming that I could even form a party and start playing but because the event processing is still Windows-based, you have to give control focus to the blank window that pops up in the background behind the game. That's the next thing to go.

2007 June 20 - Porting RGraphics

First of all, MSVCRT should only be ignored in debug mode. That is the first lesson.

With the sound working again without the DirectX SDK and all of the WAV playback moved to SDL (MIDI is still pending, and will be done much later), a unit test for graphics has been added, though it is only going through some of the bare basics for now. Bitmaps load, they blit, and stuff like that.

There is quite a lot to go through just in the graphics engine. A lot of things like routines to draw circles and Bresenham lines aren't used in the project, but one thing that SDL lacks that is used on both the title screen and in the 3D view is a good stretch blit. SDL's preferred way to do this is with OpenGL and I'm not keen on using OpenGL anywhere in this project, so I'm looking at just rolling my own stretch blit in software, which is straightforward but not as optimized as what the video hardware can do.

2007 June 19 - Audio is now SDL

Now that I am working without the DirectX SDK, the project now gives me all kinds of problems when I try to compile it. For this reason, the first item of business is to replace all of the old homebrew DirectX libraries with good old SDL (though I had so much fun writing those). Eventually, this will also get rid of all the Windows dependence, but just compiling without DirectX is goal number one.

The compiler itself decided for me that my first problem was the audio subsystem, so at least the WAV playback portion is now based on SDL. A few notes:

• SDL and SDL_Mixer are now required to build the project.
• Visual C++ 2005 Express Edition creates new projects to use Unicode by default. "Configuration Properties > General > Character Set" is the setting to change.
• To avoid runtime library conflicts, add MSVCRT to "Configuration Properties > Linker > Input > Ignore Specific Library."
• RLib, the wrappers for audio and video and other system stuff, is no longer split into Win32 and SDL versions. It is to become platform-independent.

The graphics wrapper is next. It compiles now but does not link because of the absence of ddraw.lib.

2007 June 18 - Online again, for now

Where did everyone go?

It's been a while. Inevitably, hobby projects are prone to hiatus and delay unless there's a large team working on them, and in the case of U3Project, it's just me. Real life, changing jobs, children, medical nonsense and of course other games have all caused this project to go off the map for quite a while, and I apologize to anyone who really wanted to play this game but couldn't. It turns out that all that idealistic talk about cancelled projects means nothing in the face of Real Life's power to change your plans.

I'm not going to make any false promises that this project will be done in six months or any reasonable timeframe, but I have picked it up again and plan to tinker with it, and hopefully bring it up to where it ought to be. A few things I'd like to do first include:

• Convert the project to VC++ 2005. I'm using the Express Edition, which is free. Though there are more open tools out there, I'm used to Microsoft.
• SDL instead of my homebrew DirectX wrapper.
• Finishing up the combat mechanics, even if they're fake mechanics and not the ones from the original game.
• Refactoring of a lot of the state-based command handlers.
• Bugs, including the problem with only being able to play U3Project after starting out in the original Ultima III.
• Get U3Project.com to point back to here. I still own the domain name, but it's pointing at null space.
• If the site gets updated, maybe I'll convert it to WordPress. Currently, it's all still hand-tooled.

Enhancements to the original game can all come much, much later. I feel like these are the most pressing issues at the moment, apart from just my picking up the code again and looking at it.

To kick this off, I can announce that the SourceForge CVS repository for this project is now considered dead and will no longer be updated, and all further development will be in SourceForge's SVN respository. Having to generate PGP keys to update code that is in the public domain just seemed pointless, and I use SVN at work anyway.

So here we go again, sporadically as always.

Older News >>>