Scourge of War Boards

Ahhhhhh, I've been in thread hell for a couple of weeks. Since most have multi core processors, it's foolish to not try and get at least one thread in there to speed things up.

It requires a bunch of rewrites and it's scary because our MP is working great and this is just going to mess stuff up again.

The initial work is fairly easy. Keep the drawing code on the main thread and move all the logic/updating code to a new thread. Lots of easy bugs and it works. Picked up around 10 frames. But I noticed something odd, every once in a while, on 1 frame a guy would be drawn in the sky, then immediately back to the ground. I ignored it for now and went to try MP. Basic crashes, basic fixes. Go it running, though there are still kinks to work out. Then I hit a snag, out of sync. Repeatable, a few minutes in every time. It was the height again. The same drawing error was now being used in the logic and causing an out of sync. I narrowed it down to the height function. I went through all my code and could not find an error. So I had to go into the powerrender code. Could not find a problem there either.

Looked closer, there was a define in there that led me to some assembler code. I don't really know assembler, but I found a class variable being used as a temporary holder (BAD IDEA IN THREADS).

In case you are still following me

PR:height()
{
int a;

PR:temp = a;

// some calcs

return a;
}

not the real function, but you can see what's not threadsafe. Because if two different threads enter this function at the same exact time, they are both trying to set the same variable, PR:temp and use it. So this is not threadsafe. The local variable (a) is ok because it's different for each instance of the function. But to save a temporary variable in a common location is not good. Not threadsafe.

So what was happening is that they both ran this function at the same exact time, so which ever function was last, got PR:temp set, then they both used that value. So for 1 frame you had a bad value for terrain height.

I know, it's techy, but thought I would share and document before I forget what I did. In order to work so many different pieces of code I have to learn a lot about unfamiliar areas. I'm pretty good at that, but the downside is that I braindump information just as fast, so I'll forget what I did. So I document a lot and put in comments to remind myself where I've been and what I've touched.

Norb wrote:

I'm pretty good at that, but the downside is that I braindump information just as fast, so I'll forget what I did. So I document a lot and put in comments to remind myself where I've been and what I've touched.

Years ago I had a friend who worked for the Social Security Administration and he said all the code for their programs was written in Fortran and so many programmers had modified things, some with little or no documentation, that it was going to be easier and cheaper to start over from scratch than to try to migrate the system. Basically nobody could figure out what had been done or how it worked. It just did.

B

Well despite all of the ups and downs, and the long hours that this is taking you, I’m glad that you are doing it!

Ten more frames-per-second is great, even if that drops down a little bit, seven more frames-per-second will benefit almost everyone.

I thought that the PR Program was written in C+ or C++ , are there still some sections of the code that is only written in Assembly Language?

I haven’t even heard no-one mention that word (Assembly Language) in twenty plus years.

davinci

I got introduced to threaded programming a couple of years back and I'm running the lab coursework on threaded Java programming at our university. It can be a real pain in the arse to try and make sure there are no variables or anything you access in an unsafe order. You have to employ locks but then the purpose of parallel computing kind of suffers.

Davinci wrote:

I haven’t even heard no-one mention that word (Assembly Language) in twenty plus years.

You are nekulturny. It's usually a good idea to write the parts of the code that run frequently in ASM. That way the coder can optimize it for the best possible speed.

Norb wrote:

Looked closer, there was a define in there that led me to some assembler code. I don't really know assembler, but I found a class variable being used as a temporary holder (BAD IDEA IN THREADS).

That should pop up as a warning in the visual c compiler. It always bashes me for doing that. On another note, the issue of synching the 3D view with the calcs has been a recurrent problem for HistWar too. Although JMM has gotten rid of most of the problems, there are still instances when the 3D view does not at all reflect what is actually happening. It occasionally results in some very bizarre views.

Davinci wrote:

I haven’t even heard no-one mention that word (Assembly Language) in twenty plus years.

You are nekulturny. .

Whoa – I had to google that word, now that would be considered an idiotic assessment on your part!

davinci

Yes, PR is written in C++, but there are a few parts in assembly for speed. Also the absolute fastest you can use is straight C. Some options available in C++ make things slower, but it results in cleaner code and good code design is easier to maintain.

Very thankful that I got the code to the engine, I've made a ton of modifications specific to our platform. It's fun to play with, but I still cannot do matrices (an absolute MUST for 3D graphic programmers)

Norb – are you planning on releasing this multi-core-fix for this engine, or is this going into the newer game?

Also, if this is applied to this engine, will this be the only fix in the patch except for minor tweaks pertaining to if this breaks anything?

Will this be available this year (i.e.….only two months left) or will this process take a while longer?

Thanks,

davinci

At this point, the plan is that the threading would be part of a major new game release. This affects both SP and it presents significant issues in getting this in without breaking MP. It will take a lot of testing before we are comfortable in releasing a change this significant.

We do have some plans for something else coming out this year, announcement is very close, stay tuned.

-Jim

At this point, the plan is that the threading would be part of a major new game release.

Well, that is not very good news at all for the current game, but I understand that this is a Command Decision that probably affects things that are beyond my understanding. So I can’t really complain about something that was never mentioned as part of this release.

This affects both SP and it presents significant issues in getting this in without breaking MP. It will take a lot of testing before we are comfortable in releasing a change this significant.

Understandable!

We do have some plans for something else coming out this year, announcement is very close, stay tuned.

I hope so; this forum really does need something new, there has not been too much of anything going on lately, as I’m sure everyone has noticed!

Thanks for the reply back Jim !

davinci