Older blog entries for pencechp (starting at number 6)

Complimentary Internet Access...

...at Hilton hotels is really cool. 1.5 mbits/sec, no work for me at all (plug it in and turn it on). Sweet. What will they think of next?

Rebuilding binary distributions...

...sucks. I'm having to prowl the entire internet for the data files I need. Moral of the story: release eary and release often.

C. Pence, signing off.

6 Jun 2003 (updated 7 Jun 2003 at 04:48 UTC) »

Case-Sensitivity Is Lame

I'm checking in a module to CVS today, and for some reason, WinCVS decides it's going to be named "Project" instead of "project." Case sensitive operating systems are lame, officially. If it just wouldn't care whether it was "Project", "project", or "PrOJeCt", then we'd be OK. Sometimes *nix is evil.

That is all.

C. Pence, signing off.

5 Jun 2003 (updated 5 Jun 2003 at 05:39 UTC) »

Introductory Note

A note of thanks to everyone who's certified me. Pretty cool that people would read this and think I know enough of what I'm talking about to act on it.

The Dell Support Saga

After several hours on the phone with Dell tech support today, they concluded simply that their hardware was incompatible with Windows 2000. Not that there aren't drivers, because there are, and I installed them. They simply don't work. At all. The only operating system my laptop will run is Windows XP. Period. Or probably a variant of Linux, but I'm not gonna go there (not enough hours in the day). Oh well. I'll strip XP back to its bare bones and maybe get used to it.

Must... Release... Alpha Version

I'm putting some pressure on myself to release an alpha version of Scoped. The primary reason right now, at least, is that I'm going to have to regenerate all the binary data files myself, as I didn't have any backups. It's not that I don't know how the binaries are laid out, it's just that I'll have to go through and unpack, run tools on, find, download, and otherwise process the dozens and dozens of files necessary for game function. Actually, I'm going to take the time now to implement proper error handling for each of the required files in the game - I'm going to start it up, and, file by file, add things, looking for crashes.

At any rate, I'd always set a goal for myself that I finish the object oriented conversion before releasing an alpha version. There's quite a few subsystems left to be converted over to OO:

  • Command parsing and execution (moderate)
  • Common utilities including filesystem stuff (easy)
  • Console (easy-moderate)
  • Cvar system (easy)
  • Draw system (easy)
  • Game system (really, really difficult)
  • Host system (moderate)
  • Key bindings (easy)
  • Math (easy)
  • Model loader (easy)
  • Progs (moderate-difficult)
  • Rendering framework (difficult)
  • Statusbar (easy)
  • System code (easy)
  • Video framework (easy)
So, as you can see, the only ones that I'm truly worried about are the rendering framework, and the progs/game combo. The problem with both is the problem of ownership and class dependencies (the classic OO dilemma). I may wind up having to attach the progs and various pieces of the game with friend dependencies, and pass around sets of references (or construct with references to global objects). Not quite sure how to hack it yet, but I'll make it work. I _think_ the best plan of attack is to bundle everything labelled as "easy", which should make my dependencies fairly clear. From there, I can start encapsulating into higher level groups like the rendering and game frameworks (the big two). We'll see how it goes.

C. Pence, signing off.

Development Machine Down
Troubles with Microsoft

Yes, it's everyone's favorite time of year... or month... or week... It's Microsoft OS reinstallation time! For reasons that are... you guessed it... Microsoft's fault! Installed a bad Windows Update download that effectively gutted my video driver. That's what I get for staying up to date. So I'm ditching my copy of XP (good riddance!) and reinstalling 2K Pro, which, to the best of my knowledge, is bulletproof. Thank god.

Thankfully, no code was harmed in the incident--CVS is a lifesaver. Unfortunately, I make it my personal goal not to commit VC++ project files to CVS (it's not code and it doesn't DIFF very well). So those will have to be rebuilt, and I'll have to redo all my cute little tricks, defines, project settings, and things like having the VC environment build and edit my QuakeC. Oh well. All good things must come to a... reinstall.

Brief Note

Brief note: phpBugTracker is really, really, really cool. That is all.

With a little more optimization, game load time is effectively gone now, and I've been focusing for the last several days on executable size lowering and faster binary loading time. I've got an entire, fully functional, object-oriented Quake engine in a 177K package. That, IMNSHO, is a piece of art.

There's still a few bugs to be ironed out, but I think I'll get 'em soon. Mostly, a few features had to be sacrificed - I had to give up on C++ exception handling (I'm not sure whether I'm glad it's gone or not, yet), and I had to give up on using common libc functions - memcpy becomes CopyMemory/FastCopyMemory, strcpy, strlen, strcmp, _stricmp become their odd Win32 variants lstrcpy, lstrlen, lstrcmp, lstrcmpi, and such things as that. But I'll live, in exchange for speed. Most of the things that were changed anyway (like the string functions) are replaced almost entirely by OO constructs anyway (like std::string).

With that done and committed to CVS, I'm not sure where I go next. I think I'm going to try to get used to working with the VC6 profiler (I've used Intel VTune in the past, but my 30-day trial ran out and I don't have _THAT_ much money to blow on a GPL'ed software project). Perhaps some area in need of massive optimization will present itself. It's happened before--the first profile I ran on loadtime optimization showed 30% program time spent in the console character drawing function. *cough* *hack* *sputter*.

C. Pence, signing off.

Haha... Certified myself to Apprentice. Lol.

This site looks like a cool concept, and I hope to use the developer diary on here somewhat like a .PLAN file, for those of you who are interested in more development information than the CVS log can give you and want to, in effect, "peer over my shoulder" as I work.

That being said, here's my first entry to that effect. I read a great article on FlipCode about the necessity of bringing down game load times, and I've been endeavouring to do just that over the last several weeks. It's taken me through several paths, namely, the removal of classic MDL model support, as MD2s load more quickly and don't require us to triangulate at runtime. This has also allowed me to remove the NVTriStrip library which was adding some significant code bloat.

In addition, much of the Quake loading code parsed all structures byte-for-byte doing endian swapping. Since everything we've done so far is non-portable anyway, I converted everything from endian swapping parsing to straight memcpy() out of the files. This is a most notable change in the BSP loading architecture. To that end, I also implemented MMX and SSE SIMD-enhanced memcpy() functions out of the xine codebase (http://xine.sourceforge.net). Thanks to them for making their project GPL as well!

In that manner, I've already shaved off about three seconds from inital game loadtime (as measured with a commandline containing +map e1m1). Changelevel loadtime is still about the same length as when I started, which may indicate there's significant overhead in deleteing all the data structures from one level and reallocating them for the next level. I'm not saying I'll go to static storage for all those objects, but it might be a consideration for further work. I'll commit all this stuff to CVS once I'm sure all this stuff isn't going to explode.

And one more note - the MMX/SSE code now requires that you have Visual Studio 6 Professional or Enterprise, with both Service Pack 5 and the Processor Pack installed, or the SSE will choke about the prefetchnta instruction being invalid. Don't say I didn't warn you.

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!