ChangeSet 8329

Dec 9, 2007 at 2:42 AM
I've uploaded the initial messaging and object pool changes.

The object pool does not recycle released items and just keeps them alive. This has to be revorked, and I'll do that later.

The messaging system isn't complete as I'm trying to get a better om for it in place. The functionallity is going to use the object pool once it's ready. Feel free to comment.
Coordinator
Dec 9, 2007 at 5:04 AM
Edited Dec 9, 2007 at 5:18 AM
Although we pass a template data type in our message, will we be able to pass as many pieces of data as we'd like? If I wanted to send two ints, a float, and an object reference in a single message, would I be able to?

Is there an example of a message in use? I'd like to see that if possible.

That is all I have for now, good start so far.
Dec 9, 2007 at 7:13 AM
Yes, DebugData does excatly that, you can createa any kind of data to transfer, so just create your own type and pass that. There is already an example in the example game (I think I did initialize and Load Content).
Coordinator
Dec 9, 2007 at 7:20 AM
Sweet, I'll see if I can put that to use. I was going to use it for camera input, but we still need an input system.
Dec 9, 2007 at 10:40 AM
Yes we need input but not for testing camera. It will be submitted during the week.
Dec 9, 2007 at 5:19 PM
Nice work! I'm anxious to see how a lot of this plays out.

Few comments/questions:

  • Why are the graphics settings (resolution, MSAA settings, etc.) now in QSConstants? These will be user-configurable, perhaps even in-game, not just game-configurable.
  • Why the switch to single-line comments in the source preamble? This isn't a big deal, but it probably helps to be consistent.

I'm especially looking forward to getting a preliminary working scene manager.
Dec 9, 2007 at 5:32 PM

shawmishrak wrote:
  • Why the switch to single-line comments in the source preamble? This isn't a big deal, but it probably helps to be consistent.

Firstly, coding guidelines. Secondly, it simply plays better with VS build in C# commenting feature (Keeps comment consistency)
Coordinator
Dec 9, 2007 at 5:54 PM


shawmishrak wrote:

  • Why are the graphics settings (resolution, MSAA settings, etc.) now in QSConstants? These will be user-configurable, perhaps even in-game, not just game-configurable.


I think it would be a good idea to have each user have a .cfg file that holds their settings. Just like any game where you can change your configuration options and come back a week later and they hold true. Having a constant value gives you a fallback.

What if we:
  • Load everything up to the QSConstants value
  • Read in the config file settings and use those

You may think, "Well we even use the constants then?". Well what if the values in the config file are changed improperly, or corrupted, or the file is deleted? The constants give us a default fallback value. This is just how I see it Shaw. You're the graphics guy on this one, if you would like it done differently, then I leave that up to you.
Dec 9, 2007 at 8:10 PM

LordIkon wrote:
You may think, "Well we even use the constants then?". Well what if the values in the config file are changed improperly, or corrupted, or the file is deleted? The constants give us a default fallback value. This is just how I see it Shaw. You're the graphics guy on this one, if you would like it done differently, then I leave that up to you.

if reading the configuration fails, abort. There is no telling what could be wrong, don't even try to guess the possible values. If you still wish to use fall backs, fallback to the absolute lowest values. (ie. 80060016 or even 8bit). But I would prefer a message telling me that the configuration was incorrect and that I should reinstall.
Coordinator
Dec 9, 2007 at 8:15 PM
Edited Dec 9, 2007 at 8:17 PM
That is fine, I would just prefer the engine not crash due to it. If the config file is corrupt or incorrect we could allow the default values to correct it. Or at least give the option for it. We could overwrite the config with default settings and notify the user somehow that it was done, while creating a backup of the corrupted one.

I see the config file as a way for the artists or designers to tweak the engine without having to get into the code. And if they're messing around with it there is a good chance they could break something. I'd rather give them the ability to make tweaks, at their own risk, and then simply have a check on our end in case they muck something up.
Dec 9, 2007 at 8:31 PM
It's always good to tell users what went wrong. Just don't try to fix it. Maybe the reason for the file being currupt is that there isn't any disk space, if you try to backup you will just fail as well. Bailing out directly is the safe way to go.
Coordinator
Dec 9, 2007 at 9:29 PM
Edited Dec 9, 2007 at 9:31 PM
If that is the case, then why aren't we using Exception throws when values aren't correct? If we're going to close the program on a single error, we might as well be throwing exceptions.

The "corrupted" file, as I see it, isn't because of a disk error, but more because someone mucked with it and put a float where an int should've been, or a string where a char should've been, etc.
Dec 10, 2007 at 4:30 AM
Edited Dec 10, 2007 at 4:30 AM
I'm just saying that we can anticipate all the possible error scenarios, so do it the safe way:
  • Validate the configuration file, preferably using a schema
  • If validate fails show error on screen, as a nice window
  • Terminate
Showing exceptions isn't a nice user experience as most casual users do not understand the information provided.
Dec 10, 2007 at 3:29 PM
I agree with exceptions not being nice. How about instead of carshing we provide some means for a user to enter values? Most games provide a seperate config program that allows a user to choose. The engine could boot this if the settings are wrong. Should only take 10 minutes with Winforms, and could be included with the engine
Dec 10, 2007 at 5:23 PM

mikelid109 wrote:
Should only take 10 minutes with Winforms, and could be included with the engine

I would quite take it that easy. There are other concerns. The tool should then also support custom settings. also the tool should be able to valiate the entries, which might be difficult.
Dec 10, 2007 at 6:07 PM
Rather than text box or whatever, how about a combi-box? That would limit it to standard resolutions we which we know work, and provides validation (unless ive misunderstood what you meant)
Dec 10, 2007 at 7:09 PM
That wasn't what I meant. Imagine that there is someone using our engine and that he wishes to add 10 new properties to the configutation, how would those be propergated to the configuration form?
Dec 10, 2007 at 7:58 PM

Sturm wrote:
That wasn't what I meant. Imagine that there is someone using our engine and that he wishes to add 10 new properties to the configutation, how would those be propergated to the configuration form?


Sorry, my fault. Its a very good point. We could have a generic application, but if the user wants a custom one (with their own options, banners, icons etc) wouldnt they be better of implementing it themselves? I dont see how we can offer that degree of customisation. We could do a bit of a kludge with a banner.gif he should replace, or xml documents listing options, but this is ciruclar. If these get corrupted then we're back to square one. I dont really have a valid answer at the moment sorry.
Coordinator
Dec 11, 2007 at 4:19 AM
I've got an easy solution.

Have default engine settings to fallback on.

Then check the types in the config and the ranges.

Example config.ini:
nearplane:0.1
farplane:1000.0
fov:"I like cheese"

We check that the nearplane is within acceptable ranges (which we're already doing in the accessor. We pass it in as a float, which is valid for 0.1, and it is within range. Next....
We check farplane, also valid float, and within acceptable range, Next...
We check fov, which is supposed to be a float between 1 and 180, so "I like cheese" is not valid, we send an error message telling them this, and we use the fallback value in QSConstants.

As long as they know which line in the config has causes the error, and why it has caused an error, I don't see the problem.
Dec 11, 2007 at 4:41 AM
First of all, XML is god so:
<configuration>
    <graphics>
        <nearplane value="0.1" />
        <farplane value="10000" />
        <fov value="I like cheese" />
    </graphics>
</configuration>
Now here fov might seem like the only illigal value. But actually all of them are. The reason is that on my local settings the "." should have been a "," so actually most of the configuration file is incorrect. Bu loading default values you might obscure this. It gets even worse when:
<configuration>
    <graphics>
        <nearplane value="0.1" />
        <farplane value="10000"         <fov value="I like cheese" />
    </graphics>
</configuration>
Here the xml itself is illigal, and no value should ever be loaded from it. Of cause this is validated against the schema so there isn't any problems with loading it. But now loading using all default values will prob not be a good solution.

The problem with default values, is that we can only load our stack. Any customization might still fail.
Dec 11, 2007 at 4:54 AM
I don't see why we can't have a baseline of default values, and if any games define more configuration values, have them define default values and ranges accordingly. Just failing to run the game and forcing end users to manually edit XML is in my opinion unacceptable. What happens in this scenario?

  • I setup a game for 1900x1200@60Hz on my 24" monitor.
  • I move the computer somewhere or replace the monitor, and now 1900x1200@60Hz is no longer a valid resolution.

Am I now forced to hand-edit the configuration XML file?
Coordinator
Dec 11, 2007 at 5:42 AM
If we use XML I would rather have a drop down menu, or any kind of nice menu with selectable settings. Then when you hit Save it would write the XML. This way we could certainly read from an XML file, which allows people to save their configs. And they can hand edit them at their own risk. If we can't parse the file properly we would be able to use engine defaults.

We should also consider that some methods we're writing might require us to set some boundaries. For example, last time I played with shadowing I realized it only worked when my near/far planes were in ranges that weren't rediculous, like near:10 and far:1000000. I also noticed that if I set the near plane to certain values my zoom methods acted strange. I'm not saying we couldn't find a way around those two scenarios, but its concievable that we want to set default limits for the engine, and if someone wants to change those limits then they do so at their own risk. Setting those limits allow us to develop the engine within ranges we find both robust but acceptable for any game we think people can make with the engine.
Dec 11, 2007 at 5:47 AM
Hopefully whoever created the game also created a configuration form, or set the defaults for the game. The point here is that we will never (at least not very often) be able to guess which setting are legal for the type of game currently running. A view of 10000 might be valid or it might mean that you will see nothing when starting.

If you meant that this should be implemented in the demo game, by all means go ahead and do it. I just don't think that there is enough knowledge to do it in the engine code, without setting some restritions to the expected game types.
Coordinator
Dec 11, 2007 at 5:58 AM
There will be some restriction on game types. We won't be supporting 2D games, at least not unless someone creates some crazy workaround in their version. For the most part though I agree, we aren't limiting the game types, and we won't be able to predict everything they will do. Having 10,000 as a default max still doesn't hurt anything, they can change it if the need arises. If we require them to hand edit it, then they're still changing the value manually, either way. Once we have a scene/level editor we could simply let them set the engine max to a new value. Really I'm not sure if it matters this early along, so I'm just throwing out my thoughts on the matter.
Dec 11, 2007 at 6:14 AM
I'm not going to fight this anymore, though I still think that this is going to be way too much work for something most gamedevs are going to redo.

So who is going to be responsible for creating the configuration dialog/program?
Dec 11, 2007 at 12:50 PM
Isn't there a way to pull valid settings for any given computer from the device and give those as an option? And then set the defaults based on the lowest of that computers options. If the user wants higher settings they should be able to set them in a config menu or something like that. But there should be no reason to have defaults in the engine. If the user dosn't have the basic requirements to run, it shouldn't even try(shader model 2.0 for instance) and should tell the user.
Dec 11, 2007 at 2:42 PM
Yeah would work with graphics, but graphics is only a small part of the overall configuration system.
Dec 11, 2007 at 3:19 PM
Can you detect cpu's and/or graphics with managed code? I like it when games I play detect my hardware and adjust accordingly. This is something many devs would like, so we should add it if possible. Obviously this discusion is mostly mott for the 360, as the only variable is TV size and aspect ratios.

Sturm, whys XML god? Im not being funny, I can see some benefits in large files, but for a few simple lines isnt plain text just simpler?
Coordinator
Dec 11, 2007 at 3:24 PM
I think there are some things we can detect, like IP address. I've never tried, but I think we can detect current resolution on PC.

Really, there aren't a whole lot of things we care to detect. The fact that they can run XNA means they meet around 90% of the requirements. Things I would like to check:

- Current resolution
- Shader model version supported
- Check for 32-bit index buffer support.
- Free memory (possibly)
Dec 11, 2007 at 3:33 PM
Can i also add dual core? If the engine has threaded parts these should be optional, to cater for single core users. Also though, we can tie default settings like LOD into the graphics card.
Dec 11, 2007 at 3:53 PM

LordIkon wrote:
Things I would like to check:

- Current resolution
- Shader model version supported
- Check for 32-bit index buffer support.
- Free memory (possibly)


1 & 2 are easy, 3 I'm not sure about, a quick glance over the device capabilities structure didn't make this obvious, and 4 is possible but I don't see how it helps. Total memory might be useful.

As for multi-core chips, I'd think .NET would have some means of exposing that.
Dec 11, 2007 at 3:59 PM
The closest I can find for index buffer support is MaxVertexIndex, which is documented to define the maximum index value of a vertex. I'm assume that if this number is greater than 65535 then 32-bit indices are supported.
Coordinator
Dec 11, 2007 at 4:35 PM
Does multi-core matter? Whether we're running single or multi-core we'll still be multithreading right? Shouldn't the OS take care of thread processing for us? I haven't done a whole lot of multi-threading though, and none in C#, so I could be way off on this assumtion.
Dec 11, 2007 at 4:38 PM
I was under the impression some cores cant handle threading very well, so best to only use threads if two cores are present. Also, if the core doesnt have hyper threading we are adding an (albeit small overhead) even thinking about threads, as it has to switch and manage the threads. We need to squeeze every iota out of this engine, surely?
Dec 11, 2007 at 4:48 PM
Correct, there is thread switching overhead. On a single processor machine, you will get somewhat better performance out of a single-threaded engine than a multi-threaded engine.
Coordinator
Dec 11, 2007 at 4:57 PM
Edited Dec 11, 2007 at 5:17 PM
I think it would be beneficial for everyone to look over Steam's hardware surveys, they will tell us a lot about what kind of hardware to expect.

http://www.steampowered.com/status/survey.html

For instance, you'll notice ~35% of games have multiple cores. This indicates we should probably setup the engine to support single threads. If it were 1/3rd of people had single cores, instead of 2/3, I'd say we should've just done multi-threaded, as the number of single cores are rapidly diminishing.
Dec 11, 2007 at 5:01 PM
What's important is to limit the number of threads in the cases of single-core processors. We need to go multi-threaded, there's no other option going forward. We need to multi-thread on Xbox, and the future is multi-core, not faster processors.
Dec 11, 2007 at 6:14 PM
Not in GHz perhaps, but definitely in instruction sets. I agree though that we need to limit the threads, as clients may have their own on top. What absolutely must be threaded?
Dec 11, 2007 at 6:25 PM
Physics has to run in it's own thread. Server operations might have to as well, but I'm not sure about that, as I don't know too much about the live networking.