Opines from Beta

The 1.31 Open Beta has been steadily rocking along. Few little wobbles at the start there, and I’m not sure if Ramp has fixed the gargoyles yet (infantry “statues” that appear when a trooper dies out of your line of sight but inside your vis range; the trooper animation system surrenders the body to the ragdoll system, which promptly disowns it because he’s not in LOS; leaving a death-throws statue).

Started out rough: In short, the debug build of the servers I was building couldn’t handle 20 people simultaneously, the world-update loop was frantically dialing back its capacity and then treating everyone to the “wow, long time no hear” treatment.

I’ll explain the technical issues in a little more detail after the bump, but this post is primarily going to be about the gameplay feedback we’ve gotten…

Specifically, regarding the feel of the new capture system; picking up a discussion I fired up a little while back.

SSD: Nice, RAMDisk: Niiiiice

http://memory.dataram.com/products-and-services/software/ramdisk

Course, my RAM is overclocked DDR3 :) And I’m using an i7 based system so I see some real thruput from RAM disk.

Trouble is I only have 6Gb. I might have to put another 6 in.

OpenMP

Don’t try to learn it while you have this cold that’s going around. It’s bad enough that half the documentation is in Fortran, and the other half assumes you already know how OpenMP works. *Sigh*

Diagnosing header pollution?

Host builds under Linux/GCC have gotten a tad slow. I threw in a couple of #pragma warnings and it seems to be spending most of its time munching on headers.

Anyone any experience on diagnosing compiler slow down with GCC? Usually it’s header pollution, and I’m trying to figure out non-retarded ways to get talk CMake into generating per-target precompiled headers automatically, but in the meantime… I could really use figuring out where mah slowdown is.

“dba” 0.3.0

http://www.kfs.org/~oliver/dba/

Found a problem with the way I was testing logical statements (rs[0] != NULL) which lead to finding that some of the tests weren’t being, well, tested. After fixing that, I found the SQLite interface was reading one too many rows.

Also turned on -Wall and -Werror for the non-MSVC builds, to catch any errors I was missing – I found a few minor casting problems which I also fixed. This version is the first “healthy” version. It also seems to compile and work quite happily under MSVC.

- Oliver

“dba” 0.2.1

Nothing special, added “install” targets to the CMake-generated Makefiles.

http://www.kfs.org/~oliver/dba/

Intel: Milking the cow at both ends

When you buy your fancy top-end CPU, you expect stuff to run faster. Only it hasn’t been that simple since before the 386. Your new CPU isn’t really going to kick into gear until you get software that uses the shiny new features of your CPU.

In the case of Intel, they are very guarded about how their new features work. Probably because – as it happens – Intel also sells compilers: the software that programmers use to turn their text into machine instructions.

So your Intel CPU isn’t going to run anything at top whack until software companies have forked out for Intel’s compiler. Now, that’s a pretty nice deal for Intel, isn’t it? They sell the hardware that runs your software, which makes your user think your software isn’t running very well, because it doesn’t run very fast on the guys new hardware, unless you buy the software that Intel sells to make the hardware run the software properly. Ugh.

Their compilers are really good at optimizing code. We got a sizeable FPS increase in WWII Online just from switching to the Intel compiler.

But in just about every other aspect it’s a real pile of crap…

HTMLized source

Well, harumph, I figured one of you would have taken a look at my code and poked glaring holes in it – or the concept :) For those of you who don’t like bz2 files, I also put a zip up and I also put the source up along with htlmified versions of each source file (http://www.kfs.org/~oliver/dba/source/).

Not going to get chance to do anything else with it this week, somewhere between 1.30 and here one of the hosts in 1.31 has gotten badly out of shape, so I’m going to have to look at memory organization and instruction ordering in some rather ancient code. *Sigh*. I did just find 100Mb of memory that was being allocated for defunct legacy reasons…

“dba” v0.2

http://www.kfs.org/~oliver/dba/

Version 0.2  2010/03/01 [ Status:: MySQL: working; SQLite: working ]

1. Completed a number of incomplete functions.
2. Brought the SQLite interface up to working status.
3. Some convenience functions (variadic constructors).
4. Fixed numerous bugs.
5. Significantly bolstered “main.cpp”

“DBA” v0.1

http://www.kfs.org/~oliver/dba/

The MySQL interface is working, I wouldn’t call it complete. The SQLite interface is what I was going to work on tonight, I’ll see if I can get it working tomorrow.

Todo List:

1. Get SQLite interface functioning,
2. Unit tests,
3. Windows and Mac,
4. Auto-documentation,
5. Convenience constructors,
6. Source control,
7. Add a Postgres interface,
8. Features (such as parameter binding, column metadata retrieval),
9. .NET API

That list will definitely grow :)

Notes on the development below: