Older blog entries for pencechp (starting at number 1)

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!