pencechp is currently certified at Journeyer level.

Name: Charles Pence
Member since: 2003-05-29 04:31:40
Last Login: 2013-11-08 00:32:16

FOAF RDF Share This

Homepage: http://charlespence.net/

Notes:

(Advogato profile no longer maintained. See my homepage.)

Projects

Recent blog entries by pencechp

Syndication: RSS 2.0

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!

9 older entries...

 

pencechp certified others as follows:

  • pencechp certified pencechp as Apprentice
  • pencechp certified leviramsey as Journeyer
  • pencechp certified lerdsuwa as Journeyer
  • pencechp certified JuxtaPositionYou as Apprentice
  • pencechp certified grey as Apprentice
  • pencechp certified MisterP as Apprentice
  • pencechp certified rcaden as Apprentice
  • pencechp certified blm as Apprentice
  • pencechp certified wspace as Apprentice
  • pencechp certified atai as Journeyer
  • pencechp certified bwtaylor as Journeyer
  • pencechp certified lkcl as Master
  • pencechp certified Nietzsche as Master
  • pencechp certified God as Apprentice
  • pencechp certified loic as Master
  • pencechp certified cbbrowne as Master
  • pencechp certified madhatter as Apprentice
  • pencechp certified Akira as Journeyer
  • pencechp certified johnnyb as Journeyer
  • pencechp certified notzed as Journeyer
  • pencechp certified nymia as Journeyer
  • pencechp certified mjg59 as Master
  • pencechp certified mrcsparker as Apprentice
  • pencechp certified murrayc as Master
  • pencechp certified zeevon as Apprentice
  • pencechp certified daniels as Master
  • pencechp certified chalst as Master
  • pencechp certified Stevey as Master
  • pencechp certified cerquide as Apprentice
  • pencechp certified badvogato as Journeyer
  • pencechp certified Penix as Apprentice
  • pencechp certified vivekv as Journeyer
  • pencechp certified pphaneuf as Journeyer
  • pencechp certified aristeu as Journeyer
  • pencechp certified auspex as Apprentice
  • pencechp certified jpablo as Apprentice
  • pencechp certified garym as Master
  • pencechp certified lukas as Master
  • pencechp certified deekayen as Master
  • pencechp certified ingvar as Journeyer
  • pencechp certified helcio as Apprentice
  • pencechp certified hadess as Master
  • pencechp certified miguel as Master
  • pencechp certified raph as Master
  • pencechp certified federico as Master
  • pencechp certified alan as Master

Others have certified pencechp as follows:

  • pencechp certified pencechp as Apprentice
  • leviramsey certified pencechp as Apprentice
  • lerdsuwa certified pencechp as Apprentice
  • Stevey certified pencechp as Apprentice
  • wspace certified pencechp as Journeyer
  • helcio certified pencechp as Apprentice
  • vivekv certified pencechp as Journeyer
  • domi certified pencechp as Journeyer
  • JuxtaPositionYou certified pencechp as Apprentice
  • keller certified pencechp as Journeyer

[ Certification disabled because you're not logged in. ]

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!

X
Share this page