Bay 12 Games Forum

Thanks for the compliment Tack

Alas, it's a crazy ass time at work. Averaging about 65 hours a week, with super-extra overtime on weekends. Deadlines are deadlines, but at least things will quiet down just before we ship. Just a few more weeks...

Just to reassure - I haven't forgotten about Obsidian. I have, however, been struggling with the weirdest Lua error lately. Anyone familiar with Lua and binding to C, can you maybe cogitate over the following and offer some suggestions as to what might be the culprit?

<technical>
I'm generating Lua bindings where I start by registering metatables for each C++ class. I generate a C-function for __index, which contains a generated switch statement that compare a hash of the incoming string key with all of the members and methods defined in the class. It will return either the value of a member, or a C-function wrapper for a method. A similar C-function is generated for __tostring (prints the C++ class name) and __newindex (to assign values to members). These class metatables are added to the registry by using luaL_newmetatable with the fully qualified class name. Whenever I need to push such a C++ object into Lua, I create a light userdata set to the object pointer, get the registered metatable using luaL_getmetatable, and set it on the lightuserdata.

So far, so good - all according to examples from the Programming In Lua online book. Except... for some reason most lightuserdata will act as if the most recently retrieved metatable is set on them. So, given class Fortress, class Map and class Cell, each with a __tostring that prints the class type, I get the following:
> fortress = ReadFromDF()
> print(fortress)
Cell::Fortress
> map = fortress.Map
> print(map, fortress)
Cell::Map Cell::Fortress

Here comes the funky part:
> cell = map.Get(0, 0, 0)
> print(cell, map, fortress)
Cell::Cell Cell::Cell Cell::Fortress

See? The root object stays the same (it is actually a full userdata), but the light userdata references (cell and map) are set to the latest metatable retrieved.

Trying to debug this with commandline gdb in Windows is not helping. I've been wholly spoilt by Visual Studio's commercial debugger these last few years, and my brain is just too tired to learn gdb properly at this point. Anyone know of any good free mingw32-friendly debuggers (or good GUI frontend for gdb) on Windows, or do I need to whip out the Archlinux and try out KGdb etc?
</technical>

P.S. Don't even mention Visual C++ Express - yes, its free, but the free debugger smokes crundle butt-lint and the compiler can easily be curb-stomped by a furry wambler suffering from gastrointestinal stress.

Progress Update

Alas, I have little progress to update today. I'm finalling at work for the next 8 weeks (we release in mid October), so I'm looking at 10-14 hour days. I only get about an hour each day to spend on Obsidian, and it is hard to get flowing in such a short time.

So during the week I'll be tweaking and cleaning up existing code, and on weekends I'll be tackling big stuff, like the terrain generator, etc.

That doesn't mean I haven't made any progress - in fact, I've got the Cell engine to properly load and save from DF 31.0.08 to XML using the latest DFHack library.

I've uploaded a cell file for my current Nurembourg-style castle project: http://dffd.wimbli.com/file.php?id=2573

I'm currently packaging the cell engine as a stand-alone Lua module, for anyone that wants to play with it whilst I continue to work on Obsidian.

To those worried about polycount, remember that there are maaany ways to work around it.

Firstly, you use LOD models - the LOD stands for Level Of Detail. Simply put, you take a model of a barrel with high detail (6k polys) and create successively lower detail versions, up to a certain point (say, 100 polys). The engine then chooses which model to use, based on camera distance. So if you are zoomed up close an personal to a food stockpile, the high-detail versions will be used for graphicy goodness, and in an outside scenery shot the very low count barrels will be used.

Secondly, modern GPU's provide the ability to do instancing - that is where you load a set of meshes and textures (i.e. a model) into the graphics card's memory, and then you load up a list of positions, scales and orientations. The GPU will then use the same model, but just render it X number of times using hardware. This cuts the time spent transferring data between main memory and graphics card, which is often the speed limiting factor.

Lastly, there is a technique called imposters - where you render the model to an offscreen surface to get a 2D sprite (a transparent thumbnail picture), which you then 'stamp' wherever the model appears far in the distance. So the cost of rendering the model then becomes drawing a single quad (two squares). That is the technique VF uses for the tree models - you can see that after a certain distance the trees' appearance change somewhat, looking more 'flat' than usual. The Total War series of games relied heavily on the imposter system as well - otherwise it would be impossible to render 5k+ troops. It explains the spritey look of the soldiers in the early games from that series.

AFAIK OSG supports all three techniques mentioned above, so I am really not worried about performance at this point.

Remember that a big part of Obsidian is its planned ability to export to common raytracing renderers (like Povray, Blender etc.). So we'll eventually need a high-detail raytrace and lower-detail real-time version of each module (and texture?).

I chose the Git because it is a VCS I haven't tried yet, and it was next on my list of things-to-learn (being my first distributed VCS) . I've whipped Subversion already, but Mercurial is even less well known then Git at this point, at least to me.

Hrmm. Can we use github to store the source art, as well as the art assets then? Even if they get large? What are the file size and bandwidth limits for a project on GitHub?

If that is workable, what would you need from me to setup a repository for Obsidian on github?

I'm using Git locally (I'm fairly newb with it - been using Perforce for a while so the learning curve is interesting).
Eventually I can push the source with history to github once I'm ready to release it. Until then we can use it to push binary releases and models, textures, logos, etc.

Any help is more than welcome, Crunch!

Obsidian's philosophy is that absolutely anyone can contribute anything.

To that end I've chosen to use OpenSceneGraph to render the geometry and models. That means there is a decent composer called OSGEdit(http://osgedit.sourceforge.net/) that you can use to import models and play around with. If you can make it in OSGEdit, Obsidian will render it.

Currently, opsneakie and Djohaal are our modellers/render experts, and GFXiNXS our artist. Contact them (cc me) and lets organize what models and textures we'll need for starting out.

My portrait image is the actual icon for Obsidian, kindly provided by Janus.

Reducing the magma disk down to 64 and less will lose too much detail, I think.

Currently, Obsidian consists of a terminal console, a rendering window and a loading splash screen.

What we could do is use GFXiNS' submissions as the splash screen and credits background, and then use the others as the background for the rendering window and terminal console.

That depends on how colored text will look superimposed on the disk or sphere...

This will all be user configurable through the config.lua file, of course