Older blog entries for pencechp (starting at number 13)

Programming Update

Just spent a little of my down-time during breaks at the end of the semester to clean up my programming projects. I've shut down everything I'm not working on anymore, and condensed my two active projects on two Google Code sites: Arcus and Logos.

Logos is due for a release sometime soon; I'm about halfway done with the 2.0 release, which has been in the works for at least two years now.

Syndicated 2008-12-16 15:46:00 from Secondary Qualities

A quick note: if you're reading this Advogato blog, all the content below here is CRAZY OLD and doesn't have much anything to do with any projects I've done in the last several years. I used to be all about the game programming, an interest which has fallen off pretty substantially in recent days.

Well, a lot has changed since the last posting here. I'm now running and developing entirely on Linux, with OpenIL images, OpenAL sound, and SDL/GL video interface. I'm really loving the new development environment (Anjuta = beautiful), and I'm finally coming to accept the GNU autotools.

Aside from that, the other big change is the new use to which the engine has been tasked. The engine (codenamed Sparrow for the time being, connotations of "light" and "fast" intended) is going to be running game-theoretic evolutionary simulations, a project that I've been turned onto by Adadm Elga, a professor here at Princeton and a specialist in decision theory and the philosophy of science. More on how this all works will be written up here once I get around to implementing the simulation logic module.

Big changes, then:

  • Sound system is a class, loads OGGs, plays SFX and streams background music
  • Menus are (almost) totally redesigned and actually look tolerably decent now (these had been completely broken since the 16-px font-size change about 6 months ago)
  • More and more reliance on the event system, planning on introducing an EventHelpers namespace with inline functions for sending the more complicated events
  • Numerous, numerous cleanup changes and restriction of player movement and such pertaining to the fact that it isn't really a game anymore so much as a 3D visualization system
  • The QuakeC is becoming dangerously close to phased-out. Ideally, that's something I'd like to do (to get the sim-logic into C++) but it's not something I'd planned would happen just by not needing any of the QC code anymore.
  • More stuff to come in future entries...

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.

4 older entries...

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!