Fun with threads

Published on August 19, 2005 By CariElf In GalCiv Journals

We've been pretty busy here getting ready for Beta 3. The game has come a long way since Beta 2, and we still have miles (or should I say, milestones) yet to go. For the last two weeks, my primary responsibility has been fixing and tweaking stuff. One of the bigger issues that we've been dealing with almost since we started working on GC2 has been the load time.

The way that the interface and other graphics are created in GC2 is radically different than it was in GC1. In GC1, a screen was essentially a bunch of bitmaps stored in one file with modified headers and all the position and size information was stored in the headers, and since the header was a specific size, the bytes could be copyed directly into a structure, so no parsing was needed. However, things like re-sizing the interface would have been a huge pain in the butt if not impossible because they were all 2D graphics. With GC2, we're using the DesktopX format to store the screen data and graphics, which gives us a lot more flexibility. However, it means that we have to do parsing on the file, load the textures, and do things like create vertex buffers. One screen doesn't take long by itself, but we have a lot of screens in GC2.

I discovered early on in the development of GC2 that you can't create graphics in a thread. You end up with weird graphical errors or crashes if you try to create two textures at the same time in two different threads, or even if you just create graphics in one background thread and try to render in the main thread. I might have to try putting critical sections in the main render function and in the functions where textures are loaded, or something, but I'm worried about creating deadlock situations: there will be 2-3 threads creating graphics and then the main thread trying to render existing graphics. Joe had suggested creating a secondary device and having it create all the textures, but the devices won't share textures even if they're created in managed memory (which means that they are backed up in system memory). So, today I tried making it so that it loads the dxpacks into memory and parses them, but defers the texture creation until the screen is actually unhidden. This works fairly well, although it's caused a few problems that I'm going to have to fix before committing my changes. It doesn't make a lot of difference in debug mode, but in release mode it cuts the loading time of a gigantic galaxy down to about 5 seconds. It also makes the screens pop up a lot faster the first time (even in debug mode) because they don't have to set up all their controls and load the textures.

Saturday has a 70% chance of rain here, but as long as the storms don't knock out my power (and therefore my AC) I'll be happy.

Have a good weekend, everyone!

--Cari

Comments

Civ3Fanatic

on Aug 19, 2005

most of that stuff went way over my head but i like the sound of the 5 second load time for a gigantic galaxy

primarycolorman

on Aug 20, 2005

Developer to American translation (based entirely on the previous post):

in galciv 1 the interface was just a bunch of images. No work was required to display them, just read and toss 'em out there. But, since images are static in size (they dont change dimensionally) it locked everything to a certain display resolution.

In galciv 2, they are rendering the menus real time (the images are created on the fly). Since they aren't static, they can change display resolution and add in extra eye candy at will, depending on your PC's ability.

The problem with building the images on the fly, is that it creates extra work. So how does one solve this? Easy, create more workers (threads). But then you have to manage them, and are stuck with Windows acting as a Vice President over you. This can cause not-so-funny problems which they are currently working through.

And that would be enough mangling of what someone else has said from me.

Lucky_Jack

on Aug 21, 2005

Primarycolorman - Exellent translation. Even a technophile like me can see how easy it will be for a technophobe to grasp the problems and the effort it takes to solve them.

CariElf

on Aug 22, 2005

, yep, that's actually a pretty good translation.

primarycolorman

on Aug 22, 2005

Thanks.

I've done enough graphics work (opengl) under windows to feel the pain. I think I'll stick with multiprocessing and genetic alg's for my occasional hobbies instead.... they seem saner.

stricken

on Sep 28, 2005

...until the screen is actually unhidden.

heheheh unhidden...you mean shown?

Welcome Guest! Please take the time to register with us.
There are many great features available to you once you register, including:

Richer content, access to many features that are disabled for guests like commenting on the forums.
Access to a great community, with a massive database of many, many areas of interest.
Access to contests & subscription offers like exclusive emails.
It's simple, and FREE!