Older blog entries for pencechp (starting at number 10)

Well, I'm going to dust this thing off because people have complained that my main blog has become entirely too tech-heavy, and I'm moderately inclined to agree with them. After a long hiatus, I actually _am_ working on the Scoped project again, believe it or not, and things are coming along quite nicely--farther than they did the last time I worked on it.

The network layer at this point is entirely gone, which means the code is very light and fast--at this point, we're well under 200k for the compiled Release executable, and there's plenty of room to go. Much of the work thusfar has been unifying the CL_ and SV_ systems and their competing data structures. I've combined both the edict_t and the entity_t into a new super-entity_t, and the sv, svs, cl, and cls structures have been rolled into two structures, a game_state_t for game-wide information, and a player_t for player-specific information (things that need to be wiped across level changes and such). The entire engine also dynamically allocates memory through malloc(), free(), new, and delete, getting rid of that clunky Hunk_ system. Since no memory allocation happens in any speed-critical sections of the Quake source, I'm not sure why this Hunk system was written in the first place--it may have something to do with systems design in the days of DOS, something I know admittedly nothing about. I've only just started touching the rendering system, and the most substantial addition there is the first full-on C++ class to hit the engine, an OpenIL texture loading class, which has already brought in high-resolution status bar, console, and text, with more on the way.

As you might have gathered by the OpenIL move, the next round of big code changes will be taking the platform layer out of the code entirely and abstracting it off into OpenAL for sound, OpenIL for images, and SDL for OpenGL framework, input, windowing, etc. The only things it looks like I'll have to totally code up from scratch are the event pump (I need both the ability to add events to a queue to be popped off later and the ability to push an event through to its listeners immediately, something that the SDL event system doesn't give you) and a high-resolution timer (which I'll have to figure out how to implement on Linux, for the time being I can fall back on the SDL 1ms timer).

Anyway, the main point of this post was to get down some ideas I'd been having about how to abstract the entity interfaces a little bit. I think the first thing to do is split out the parts of the entity structure that the renderer needs to know about into a separate structure, which will provide some level of entity-API-independence to the renderer, by which I can add fields to the entity structures without introducing any changes in the renderer module. The entity class can expose a GetRenderParams() accessor that will drop out a RenderParameters structure containing everything the renderer needs to know about drawing the entity. The renderer draws lists of these instead of entities (i.e. gs.visedicts (the old cl_visedicts) becomes a std::vector of RenderParameters structures). Of course, I need to be careful about how I work that--that's speed-critical code inside the PVS-checking algorithms, and I don't want to call a thousand copy constructors per frame on RenderParameters structures, which wouldn't make any sense at all. There might be a way to do that with a vector of references, if you were allowed to construct such a thing in C++. Given that you aren't, maybe some old-fashioned pointers would make the most sense, even though they do make me cringe. I guess since this is a static data member inside a class that shouldn't go anywhere between the time it's added to a PVS list and that list is drawn, it should be safe enough.

My TODO for the renderer is about nineteen pages long, but the first thing to be done is dynamic video mode switching inside the program. It's less easy than it sounds, given that every texture has to be reloaded and rebound once GL is reset. The proper way to do this is through a TextureManager class, but I haven't had the guts to go retrofit one through the entire renderer yet. Then, though, it's as easy as switching video modes, calling some sort of TextureManager::Rebind(), and you're back in business. Some issues will come up, though, given that some of the paletted skin/texture data that's stored inside the models/BSPs is kept around in a really sketchy manner after the models are loaded (variable sized structures and such squirreling away of data). But that's a problem for well after we've converted to SDL/AL, so it's down the road a little bit.

Okay, I've both procrastinated long enough and written more than enough here, so I'm out to do some actual work (curse having to work on holiday).

Wow. An update here. Argh. I'd always intended to make more use of this, but I never got around to it. Been spending the last few weeks getting Gentoo up and running on my laptop--works just like a charm. The 2.6 kernels are absolutely a thing of beauty.

At any rate, development on Scoped as slowed somewhat, the website's currently b0rked, and I'm working on getting it revamped. At some point, I'll fix it, and when I do, development will resume, although the code base is in a pretty sloppy state right now: I'm about halfway through the very, very large migration of all of the 2d rendering code (console, fonts, etc) to their own class, which is covered with hidden dependencies. I'm not quite sure how I'm going to finish it yet. And, not to mention, since Linux is my primary platform now, I'll need to make it cross-platform... *grins* SDL here we come!

Mmmmm... Streeeeams...

Until I started using C++ stream syntax, I always said that using the bit-shift operators for input and output was one of the worst ideas I'd ever heard. Now that I'm used to it: it's incredible. I don't know what I did without it. I converted the Quake console to a stream that is almost (but not quite) transparent to std::ostream. I probably could have derived from std::ostringstream, but I didn't want to fight with it. I like my results, however, and it runs more quickly than a vsprintf() implementation. Score.

C. Pence, signing off.

Time Management 101

Wow. Juggling a 9 to 5 job with coding, romance, social life, food, and sleep is a serious, serious skill. Development on Scoped has virtually come to a standstill. I'm not sure whether I want to sacrifice sleep or some social time to start coding again.

But, it is science...

I can't complain, though. Having a blast at my job - research associate at the M.D. Anderson Cancer Center Science Park Research Division here in Smithville, TX. Working full-time on something that I would probably do for free is a true, true luxury. Even the grunt work (counting cells under the microscope... shudder) is still somehow interesting. I guess I'm rather excited by the prospect of working my way from research to initial idea to data to results. The scientific process is really quite exciting.

C. Pence, signing off.

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.

1 older entry...

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!