New Patch 521

Dec 2, 2007 at 8:29 PM
Hi all,

I've uploaded a new patch with the baseline for the new QuickStart Engine code. Please see patch 521 (Which is build with ChangeSet 8015), and let me know if you have any issues.

DO NOT APPLY TO A CHANGED CHECKOUT !!!


There is a huge restructure so please create a new checkout and apply the patch to that.
Dec 2, 2007 at 9:28 PM
The new directory structure seems quite overcomplicated to me. Maybe its just me being simple.

For example, it took some hunting to find where the QuickStart.Core project actually is. I wasn't expecting it to be in the same folder as the old prototype code. Shouldn't the code/build from the template/prototype/new framework be completely seperated?

I'm also confused as to why there is seperate Windows and Xbox360 folders, as the code for each platform would (should) be the same, with only the .csproj and .sln files being different.
Dec 2, 2007 at 9:40 PM
I'm assuming the QuickStart.* folders under framework/code are relics of the original source tree and should really be deleted (cpc bug)? If so, are we dropping the multi-assembly approach and just going with one monolithic assembly? Or are there going to be folders for each assembly under the three folders Common/Windows/Xbox306 like you have for Common.Core? I think we need to establish the naming convention and how many assemblies we have. I know we discussed this, but I don't think we actually came to a decision. With the way this project is heading, I'm thinking we need to just scrap the multi-assembly approach.

Coordinator
Dec 2, 2007 at 10:01 PM
My feeling is that if the template will only be supported in bug fixes in the future, that there may not be much reason to keep it in the source code section. The way we'll only have the new prototype, and nothing else.
Dec 2, 2007 at 10:28 PM
Good comments guys.

Aphid:
No there will be much code which isn't the same on xbox and win (i.e. file access) and there are many optimizations to do on the xbox, so I do feel the need to have seperate projects.

The only reason I kept the prototype was because there are already some good thoughts in there I didn't want to loose, eventually both prototype and template folders will be deleted and the structure will become more clear.

Shaw:
The reason for the folders not being deleted is that the change hasn't been comitted yet. Once the change is in syncing up will also delete the folders. Though the folders should be empty, if not I forgot to delete some files.

I didn't drop the multi assembly, I just only created the core assembly. I made as little as I could in order to prepare the new engine code. So we need the create the input/graphics/etc assemblies as we get to them. Could you create a post for discussing the assembly structure?

LordIkon:
I wouldn't remove the source for the template, having it in the current tree shows those who use it that we are still supporting it.
Dec 3, 2007 at 2:33 PM
Looks good but the structures confusing. I dont like the way we have a project for the Windows common.core when it is only a link to the real files. This makes it difficualt as wont any links have to be mirrored for the xbox version? I think we should have on high level windows and one high level xbox project in the WIndows and Xbox folders respectively, and these contain a link to a single COmmon.Core project in its folder. That means only one link is needed in both windows and xbox to include the whole of common.core, rather than one for each file. Just my view though, its just a bit confusing.

I do like the fact youve seperated the two projects this earyl, as we can then make use of windows features efficiently without having to code them out for the xbox, eg mouse support
Dec 3, 2007 at 5:29 PM
Thinking more about it I can see where you are going. There should be a specific Core project which is included in both solutions. Having a bit more time, I can see that that makes more sense than having those included as specific project for each platform.

I will change that, so that we will have a core project, which is included in the two solutions. This gives an interesting dilemma when building as the same project file is used for different platforms, but I'm going to see if I can find a solution for this.
Dec 3, 2007 at 5:59 PM
From what I can tell on the XNA forums, multi-targeted projects are extremely painful and should be avoided. Also keep in mind that you can't compile an assembly for Windows and just use it in an Xbox project. The .NET assembly references will be wrong.

If we're sticking with the mono-assembly approach, I would have two projects, one for Xbox and one for Windows. There will further be three directories of source files, one for Windows-only, one for Xbox-only, and one for both. The Windows directory can hold the Windows project file, and the Xbox directory will hold the Xbox project file (though this is debatable). Then each project file will link to files in two of the three directories, depending on the build target (either Windows and Common, or Xbox and Common. A good 95% of the engine core (remember the editor and the content processors are a different beast) will be the same for Xbox and Windows. There's no way to get around the file linking problem, and I don't really see it as a problem.
Dec 3, 2007 at 6:10 PM
Correct me if im wrong, but wouldnt a sub project use the compilation settings of its parent? This means the core is adaptable. Also, we can still use 1 common project as there is a toll to convert pc to xbox projects and vice versa built in. It doesnt change code, only project settings, but if the code runs on both (as the common library should) this wont be a problem. This way you then link to the winodws common project and the xbox links to the translated xbox project. I just think it could get unwieldy linkin all the source files manually.
Dec 3, 2007 at 6:57 PM
Depends on the type of sub project. But that's not the issue here, as there aren't any sub projects (They are all under the same solution).

There are issues using a single project and including it in different solutions for different platforms. I was considering that there should only be one solution, which would include all 3 project types. This would remove the need for having linked files.

I might consider going back to that approach again. As this would ensure that a change in Core would compile on both targets. The reason for not having this is that while developing a feature you might not do both platforms at the time, which would produce compile errors which are simply releated to the fact that it's not implemented in one target platform. This can be very annoying while developing.
Dec 3, 2007 at 8:19 PM
So to prevent linking files you would just put all project files in the same place as the code files? No matter how it plays out, people need to be aware that adding files to the Windows project won't automatically add them to the Xbox project, and vice versa.

Also... why 3 projects? Aren't there just going to be one Windows and one Xbox project?
Dec 3, 2007 at 8:43 PM
Edited Dec 3, 2007 at 8:44 PM
I don't see what is to be gained by having the windows and xbox versions of the code seperate. There will be very little differences (a few missing classes and mouse methods), which would be simpler to just #ifdef out. The samples on the creators site do this, with just 2 .sln files in the root directory, one for windows and one for xbos360, and all the project files are shared by both solutions. A lot of those using the enigne will probably be used to this.

Having the 2 platforms code seperate would get annoying. e.g. while working on the input system, you would have to copy your changes onto both versions of the file.
Coordinator
Dec 3, 2007 at 8:54 PM
Having two versions would be more difficult I agree. I can't really say which is better because I don't have a 360 yet so I haven't tried it. But one thing to note is more the samples from the XNA team on the CC site have seperate projects for 360 and windows, it may be worth asking on the forums what made them choose to do it that way.
Dec 4, 2007 at 12:08 AM
It's because having multi-targeted project files is a pain in the ass. I can't vouch for XNA 2.0 since the Xbox integration isn't available yet, but Visual Studio doesn't play all that nicely with one project file and multiple build targets.

Aphid, I don't think anyone's saying keep the code separate. It'll look something like this:

framework/code/Common/<most of the source files>
 
framework/code/Windows/<Windows-only code>
framework/code/Windows/QuickStartWindows.csproj
 
framework/code/Xbox/<Xbox-only code>
framework/code/Xbox/QuickStartXbox.csproj

Alternatively, the project files could go in the Common directory. Either way works. If they're in the platform directories, then the project files will link to the source files in Common, and directly reference the platform source files. Vice versa if they're in the Common directory.

Dec 4, 2007 at 8:45 AM

Aphid wrote:
... There will be very little differences (a few missing classes and mouse methods), which would be simpler to just #ifdef out.
I can't stress how bad it is to use #ifdef (Yes there are special valid scenarios, but I haven't seen any of those in the code). You really do not want to add this amount of complexity to the source files. Most of thte #ifdef declarations in the current code are in the input system, which I reworked to having no #ifdef any more. The code is now much cleaner and a lot easier to test/debug.

Most #ifdef declarations can be designed out so that these become separate classes which are loaded when initialized. This does add a little overhead at load time, but the complexity is removed from the code.

Aphid wrote:
The samples on the creators site do this, with just 2 .sln files in the root directory

Well they are samples, and the complexity of the code isn't there as the same code can be executed on both targets. But it still add the same project linking issues as having the code in different directories, adding a file to the windows project does not automatically add the same file to the xbox project, you still have to do that manually.

shawmishrak wrote:
Also... why 3 projects? Aren't there just going to be one Windows and one Xbox project?

You wan't to be able to build the projects independently of each other (core/win/xbox). The reason for this is that an update to the core system shouldn't force a recompile of the plaform specific code, thereby you can keep the size of a patch/hotfix down to a minimum.

shawmishrak wrote:
I don't think anyone's saying keep the code separate

Actually I am, I'm thinking a structure linke this:

framework/code/Common/<most of the source files>
framework/code/Windows/QuickStart.Core.csproj
 
framework/code/Windows/<Windows-only code>
framework/code/Windows/QuickStart.Windows.csproj // Will reference QuickStart.dll
 
framework/code/Xbox/<Xbox-only code>
framework/code/Xbox/QuickStart.Xbox360.csproj // Will reference QuickStart.dll

I think this provides the most flexibility, without having to link files. Yes I'm aware that this might add a little more code to a platform than is actually needed, there might be code in Core that's simply not used by a platform. When build you will then just end up with 3 assemblies:

QuickStart.dll
QuickStart.Windows.dll
QuickStart.XBox360.dll

I think this is the cleanest solution.
Dec 4, 2007 at 10:17 AM
Edited Dec 4, 2007 at 10:45 AM
Perhaps I'm just missing something here... but how is the core library supposed to call into platform code? Have the client get an instance to whatever platform classes are needed then pass them along to the core library?

This is exactly one of the problems I ran into with the old approach. If A depends on B, then it's very difficult for B to have freedom to call into A.
Dec 4, 2007 at 12:15 PM
Cyclic references should never be needed, there should be no reason for the Core layer to access the platform layer. The references are always Paltform->Core.

Lets assume that there is a Storege class and that we can alwyas write
    this.Game.Storage.Save("NAME", MyData);
    object data = this.Game.Storage.Load("NAME");

The Storage class is defined as an abstract class in the Core assembly. Now both platforms need to inherint Storage and implement the Save and Load to fit the platform. Then when creating the custom game type, it would be needed to create a instance of the type and assign it, ,i.e.:
class CustomGame : QSGame
{
    ...
    protected void InitializeCore()
    {
        ...
        WindowsStorage storage = new WindowsStorage();            // Create the storage instance
        storage.InitializeFolder(GameConstants.SaveGameFolder);    // Invoke any custom initializing
 
        this.InitializeStorage(storage);                                             // Somehow set the storage to be the game storage
    }
}

Something like this. If you have any other examples or want to discuss this create a new thread (or hijack one of the design threads)
Coordinator
Dec 4, 2007 at 1:41 PM
If this is to be true then Core has to be very independant. I don't see something like our Game class being able to be inside of Core for instance. Game may need access to lots of things, like a SceneManager. So if there were no cyclic references from Core then everything Core accesses would need to be independant or inside of Core.

Really I don't see any issues on this matter, I've never had issues with cyclic "headers" in C#.
Dec 4, 2007 at 2:08 PM
I think this is very relevant to this thread.

So everything in the platform assemblies will be implementations of abstract classes or interfaces inside of QuickStart.dll, right? This is workable, but it doesn't avoid the conditional compilation problem, like using #ifdef's. They are just moved to client code. Your example would become:

class CustomGame : QSGame
{
    ...
    protected void InitializeCore()
    {
        ...
#if XENON
        XboxStorage storage = new XboxStorage();
#else
        WindowsStorage storage = new WindowsStorage();            // Create the storage instance
#endif
 
        storage.InitializeFolder(GameConstants.SaveGameFolder);    // Invoke any custom initializing
 
        this.InitializeStorage(storage);                                             // Somehow set the storage to be the game storage
    }
}

I was thinking more along the lines of having two Storage implementations, one in framework/code/Xbox, one in framework/code/Windows. Same class name, just different implementations. At compile-time, this is resolved by clients only referencing either the Windows QuickStart.dll or the Xbox QuickStart.dll. They cannot reference both in the same project. The client code just creates an instance of Storage, and the proper platform implementation is automatically used based on which assembly is included. We need separate QuickStart.dll files for each platform anyway (need two QuickStart.Core.csproj files), is there really a need to take it a step further and create additional platform-specific assemblies?

LorkIkon, the issue isn't with circular dependencies within a C# project, its with circular dependencies between assemblies. Like, A.dll is referenced by B.dll, which is referenced by A.dll. You cannot do that without dynamic assembly loading at run-time.
Dec 4, 2007 at 2:19 PM
I really like that idea. We need to think of the users first and ourselves second if we want this to be a sucess. The common interface between platforms would minimise any changes they have to make to support both.
Coordinator
Dec 4, 2007 at 3:26 PM
I think my porting class may come in handy on this project. Although there shouldn't be much porting going on as XNA has done most of that for us.

That example that Shaw gave above is the same way we could setup Networking for sockets and Live if we decided to do both. This way you refer to everything by the same name, but could refer to whatever is relevant. Something like #if LIVE.
Dec 4, 2007 at 4:34 PM
How about when the network is initilized you pass a flag into it telling of network type eg Sockets, Live, LiveSystemLink etc. This may be a simpler way of hiding the actual interface behind generic methods. Only problem is you would lose things like Gamercard support, but special Live methods could be added.
Coordinator
Dec 4, 2007 at 5:37 PM
Pretty much what I was thinking. The network system will likely be abstracted so any message passing is done the same no matter which system we're using. The only difference will be the way the network system handles it, which would be dependant on which method was chosen at runtime, or possibly in a menu, that is up to you, or up for debate I guess.
Dec 4, 2007 at 7:33 PM
At the end of the day, clients will be picking and choosing what they want to use, and the serious ones will most likely roll their own versions of some things. Our main goal here should be to make it as easy as possible for developers to pick and choose what they want, and at the same time provide as much direct cross-platform support as possible. I don't think it's necessarily our place to say, "Here's what we have, use it like this." We need to say, "Here's what we have, use it however you wish."
Dec 5, 2007 at 1:06 AM
Ups I certainly got my code wrong here ;)

I meant to do something like this:
class QSGame
{
    ...
    protected virtual void InitializeCore()
    {
        ...
        Type storageType = Configuration.GetStorageType(); // This gets the type of the storage based on config setting
 
        Storage storage = Activator.CreateInstance(storageType);
        storage.Initialize(this);    // Which invokes any custom initializing
 
        this.InitializeStorage(storage); // Somehow set the storage to be the game storage
    }
}

There shouldn't be any #ifdef in this or many other cases.
Dec 5, 2007 at 2:30 AM
So how is Configuration defined? Is it just a static class that contains get operations for each platform-specific type? If so, I'm not sure I see the advantage to this. It just introduces another class dependency and something else clients have to worry about. It also introduces the requirement that we need an interface for every platform-specific type and the master Configuration class needs to know about every platform-specific class. Maybe it's just my preference for compile-time binding over run-time binding when possible, but to me this is more readable, and gives the CLR a fighting chance of optimizing the calls:

class QSGame
{
    ...
    protected virtual void InitializeCore()
    {
        ...
        Storage storage = new Storage();  // Xbox and Windows projects will contain different implementations.
        storage.Initialize(this);    // Which invokes any custom initializing
 
        this.InitializeStorage(storage); // Somehow set the storage to be the game storage
    }
}

Think of it as compile-time polymorphism, if you will. Storage is a concrete class, not an interface. The Xbox source files will have an implementation, and the Windows source files will have an implementation. Behind the scenes you could use an interface to enforce what's actually implemented in both versions, but the client doesn't need to see the interface. No #ifdef's, not even any run-time polymorphism. Basically, I'm advocating the same design as the XNA Framework.


In summary, it seems like we have two possible approaches here:

1) Three assemblies: QuickStart.dll (two compiled versions, one for each platform, same code in both), QuickStart.Windows.dll, QuickStart.Xbox360.dll. Platform-specific code is accessed through interfaces. A global type manager is used to retrieve the strong type names of platform-specific classes, and these strong types are used to instantiate all platform-specific code. e.g.
class QSGame
{
    ...
    protected virtual void InitializeCore()
    {
        ...
        Type storageType = Configuration.GetStorageType(); // This gets the type of the storage based on config setting
 
        Storage storage = Activator.CreateInstance(storageType);
        storage.Initialize(this);    // Which invokes any custom initializing
 
        this.InitializeStorage(storage); // Somehow set the storage to be the game storage
    }
}

2) One assembly: QuickStart.dll. Platform-specific code is compiled into main assembly, resulting in two versions (just like in approach 1). Platform-specific code is accessed just like any other engine code. Interfaces may be used to enforce guidelines on the platform-specific code, but the client will only see the concrete types. e.g.
class QSGame
{
    ...
    protected virtual void InitializeCore()
    {
        ...
        Storage storage = new Storage();  // Xbox and Windows projects will contain different implementations.
        storage.Initialize(this);    // Which invokes any custom initializing
 
        this.InitializeStorage(storage); // Somehow set the storage to be the game storage
    }
}


Both approaches are equally valid, it comes down to a matter of preference. LordIkon, mikelid109, and others, post your vote on which approach you prefer (or voice a third option, if you please).
Coordinator
Dec 5, 2007 at 3:09 AM
I can't decide on only this. Not to say this isn't good stuff, it definitely is. I see the merits in both. I'm like how #1 uses generic types that can do both methods. If done right the user would never notice. However in #2 it seems cleaner, but I get the feeling we'd have to enforce platform specific rules at runtime, which could be more costly on performance. But again, these are just guesses without seeing more code.
Dec 5, 2007 at 4:56 AM
I understand. The only reason I'm pushing this so much is because it's such a fundamental part of how the engine will be constructed. Of course, this only really affects less than 5% of the core engine code. That's one of the reasons I question whether breaking the platform-specific code into separate assemblies is really worth the trouble of creating this binding logic as opposed to just linking a few files into the main QuickStart.dll project.

----
To me, the problem with this approach (approach 1) is that it draws a line between core code and platform-specific code. Core code is directly referenced through concrete classes, while platform-specific code goes through the Configuration class (or whatever the final name ends up being). So, the client needs to explicitly be aware of where the class resides (core or platform) when instantiating a class. I don't feel that its really the client's responsibility to know or care whether the class is internally implemented agnostic of platform or intimately related to the platform.
----

Storage isn't a great example, as that isn't platform-specific. The same API is used on both Windows and Xbox to get to the saved game/profile/configuration directory. A better candidate here would be the mouse driver. Mouse input only works on Xbox, so it would logically fall into the Windows-specific assembly. The keyboard and gamepad drivers would be in the core assembly. So, you'd end up with something like:

class QSGame
{
    ...
    protected virtual void InitializeCore()
    {
        ...
        Type[] inputTypes = Configuration.GetInputDrivers();
        foreach(Type t in inputTypes)
        {
            input.RegisterDriver(Activator.CreateInstance(t) as IInputDriver);
        }
    }
}

where Configuration.GetInputDrivers() returns all valid input drivers for the current platform. On Windows, this would be MouseDriver, KeyboardDriver, and GamePadDriver. On Xbox, it would simply be KeyboardDriver and GamePadDriver.


Honestly, besides the mouse driver, I can't think of anything off the top of my head that would fall into "platform-specific."
Coordinator
Dec 5, 2007 at 5:36 AM
Edited Dec 5, 2007 at 5:36 AM
Other than the mouse all I can think of off the top of my head is Networking with Sockets, which would be available in Windows but not Xbox. There are probably some minor issues as well, like certain resolutions, or the option for full screen or windowed mode.
Dec 5, 2007 at 5:45 AM

shawmishrak wrote:
So how is Configuration defined? Is it just a static class that contains get operations for each platform-specific type?

It could be static or could be a property on Game, that doesn't really matter. Static is prob the perfered here, as game might not be available everywhere. But I think you got it wrong here. There configuration isn't coded into the type, it's read from a configuration file i.e.:

<configuration target="Windows">
    <storage type="MyGame.MyCustomWindowsStorage" />
    <input>
        <handler type="QuickStart.KeyboardHandler" />
        <handler type="QuickStart.MouseHandler" />
        <handler type="QuickStart.GamePad" />
    </input>
</configuration>
 
or
 
<configuration target="XBox360">
    <storage type="QuickStart.XBox360.Storage" />
    <input>
        <handler type="QuickStart.GamePad" />
    </input>
</configuration>


shawmishrak wrote:
Think of it as compile-time polymorphism, if you will. Storage is a concrete class, not an interface. The Xbox source files will have an implementation, and the Windows source files will have an implementation.

This is a dangerous thing to do, as there isn't a contract it's prone to get misaligned, as a method could be changed on one platform without doing it on the other (think adding a new parameter to a call). When users now switch from one target to another their game might not compile anymore. Having the contract and using the base types will prevent this.


shawmishrak wrote:
In summary, it seems like we have two possible approaches here:

I have a hard time seing why there is this differention. I think that your are differentiating based on the assumption that Configuration is coded towards a specific platform, but since I just took that out the scenario isn't valid anymore, wouldn't you agree?

Also just because we have 3 assemblies there is no reason that suddenly everything has to be interfaces, it's perfectly legal to expose the types directly (As in your #2), they simply might just be abstract and the ConfigurationManager (or whatever) is used to retrieve the actual type.


shawmishrak wrote:
Storage isn't a great example, as that isn't platform-specific

How is this not platform specific? You won't have network drives or url connections on the xbox for one. I do agree that Storage is provided by Xna, but it's limited and users might consider having other means of getting files than just the connected drives. A game might even dl it's levels from a server on the net, which is a valid Windows scenario. The Xna storage mostly implies savegame (I know it's not limited to that).


shawmishrak wrote:
Honestly, besides the mouse driver, I can't think of anything off the top of my head that would fall into "platform-specific."

(And storage) I can't either, but I bet my old hat (If I had one) that there are going to be situations where we need different implementation on the XBox, most likely to do some optimization which will not make sence on a desktop machine (Just a hunch).
Dec 5, 2007 at 1:55 PM

Sturm wrote:

But I think you got it wrong here. There configuration isn't coded into the type, it's read from a configuration file


You're right, I was thinking about it programmatically. I see what you're getting at. You want to use this system for all pluggable components, not just platform-specific components, right? For instance, the keyboard and gamepad drivers are part of the core assembly, not the platform assemblies.


Sturm wrote:

Also just because we have 3 assemblies there is no reason that suddenly everything has to be interfaces, it's perfectly legal to expose the types directly (As in your #2), they simply might just be abstract and the ConfigurationManager (or whatever) is used to retrieve the actual type.


I wasn't saying everything needed to have interfaces, just the classes in the platform assembly. That's the only way to allow core code to have access to it. (Barring calling InvokeMethod on an 'object' instance).


Sturm wrote:

This is a dangerous thing to do, as there isn't a contract it's prone to get misaligned, as a method could be changed on one platform without doing it on the other (think adding a new parameter to a call). When users now switch from one target to another their game might not compile anymore. Having the contract and using the base types will prevent this.


That's why I said have an interface, but only to enforce consistency. Clients would access the types directly. (Actually, I think that comment was a couple posts up, sorry.)

The only loose end I see is what to do about platform-specific code optimizations (like math routines optimized for a certain architecture, read: "Help the CLR out by changing IL instruction order"). In a lot of these cases, the virtual overhead equals or outweights the benefit of these optimizations (like when you call a math routine a few hundred times a frame), so I'm thinking #ifdef's in the core assembly are the only way to go here.

Looking at it from the configuration XML perspective, it does seem like a good system. I want to start laying down some code today (mostly the QSGame class and some graphics library code), so for now I'll operate under the following assumptions regarding this issue:
  • For my stuff, everything goes in QuickStart.dll. Nothing platform-specific yet.
  • There will exist a Configuration type responsible for instantiating all pluggable types.
  • Any platform-specific math code optimizations will remain in the core assembly (for reasons mentioned above).

Sturm, has any of the messaging system been coded? Since I'm going to be working on this today, I was planning on using your new directory structure and just renaming the common assembly.



Dec 5, 2007 at 4:53 PM
I structured the code as follows:

framework/code/Common/QuickStart_Windows.csproj  // Builds QuickStart.dll with x86 XNA assembly references
framework/code/Common/QuickStart_Xbox360.csproj  // Builds QuickStart.dll with Xenon XNA assembly references
 
framework/code/Windows/QuickStart.Windows.csproj  // Builds QuickStart.Windows.dll
 
framework/code/Xbox360/QuickStart.Xbox360.csproj  // Builds QuickStart.Xbox360.dll

It's essentially Sturm's restructure, with the QuickStart.dll project files in Common instead of the platform folders. This way, each folder contains its own project (no cross-dependencies) and it's easier to just directly reference the source files in the Common project by enabling "Show All Files" in Visual Studio instead of having to link files as references in the projects. I'm not quite happy with the names of the Common project files, as they're only different by one character from the platform project files, so if anyone has a more creative name, let me know.

Like in Sturm's restructure, everything is built to $(ROOT)/target/$(PLATFORM)/$(BUILD).


Dec 6, 2007 at 5:33 AM

shawmishrak wrote:
You're right, I was thinking about it programmatically. I see what you're getting at. You want to use this system for all pluggable components, not just platform-specific components, right?


Absolutely right, and as we go along I can imagine even more elements going into the configuration.


shawmishrak wrote:
... so I'm thinking #ifdef's in the core assembly are the only way to go here.


I never said that #ifdef wouldn't have it's validity, this might be one of those cases.


shawmishrak wrote:
Looking at it from the configuration XML perspective, it does seem like a good system. I want to start laying down some code today (mostly the QSGame class and some graphics library code), so for now I'll operate under the following assumptions regarding this issue:
  • For my stuff, everything goes in QuickStart.dll. Nothing platform-specific yet.
  • There will exist a Configuration type responsible for instantiating all pluggable types.
  • Any platform-specific math code optimizations will remain in the core assembly (for reasons mentioned above).


It all sounds good, I can't wait to see the initial checkin :)


shawmishrak wrote:
Sturm, has any of the messaging system been coded? Since I'm going to be working on this today, I was planning on using your new directory structure and just renaming the common assembly.


Nothing of the extended version of the messaging system is in atm, as I was waiting on updates. But as we are reworking the OM I'm going to see if there are more optimizations I can do on the messages. As soon as the new model is in I'll try to get the message system in as well so everyone can start working.
Dec 6, 2007 at 5:48 AM
Understandable. I think we're in a weird kind of crunch here. We're all in one way or another depending on the work of another, so it's hard to really proceed. For me, it's hard to flesh out the game class when I don't know anything about how the messaging system will be set up. The first few commits are going to be very feature-incomplete concerning the game class. :)
Dec 6, 2007 at 6:23 AM
Thst ok, sometimes it more important to get a minimum skeletan interface checked in, than getting actual code checked in, so feel free to check in the code once you have the game type.

I was about to check in my structure, but since you have changed it I think you should just check in yours :)