Can't commit my changes to source code section

Coordinator
Oct 24, 2007 at 5:36 AM
Here is the less than helpful error I'm getting:

A database error occured (SQL error 18054) ---> Error 500021, severity 16, state 1 was raised, but no message with that error number was found in sys.messages. If error is larger than 50000, make sure the user-defined message is added using sp_addmessage.

Can't wait for XNA 2.0 releases with support for full VS8 and windows forms.
Oct 24, 2007 at 5:42 AM
What do you mean by Windows Forms?
Coordinator
Oct 24, 2007 at 5:50 AM
Like textboxes, buttons, support for putting xna games into a window with those things and having them interact. Perfect for creating a GUI editor.
Oct 24, 2007 at 6:15 AM
You mean something like this? http://www.youtube.com/watch?v=xgwmZ03vZbI
Coordinator
Oct 24, 2007 at 6:32 AM
Yes. Except without having to write thousands of lines of code to be able to use windows, and have to work around the xna framework to integrate your game into it. It will be fully supported and easily integratable.
Oct 24, 2007 at 6:39 AM
But that'll prevent from using Xbox, as Windows.Forms aren't available there. Also it does not integrate too well with the theme of any game, as windows controls aren't as easily skinned as a custom control would be. You wouldn't be able to show 3D content inside a control either.

Anyway there is still a need to create a HUD which might need input controls as well, and using windows controls might not be favorable here.

But if you are considering this approach have you been looking at the Vs2008 Shell package which might deliver another option (and also provide build in support for the language/projects) have a look here http://msdn2.microsoft.com/en-us/vstudio/bb510103.aspx
Coordinator
Oct 24, 2007 at 6:46 AM
Yes, well only the editor would be inside of forms. The engine's editor would create scenes and save them to file, once a game was loaded, the engine would create the scene without the use of any windows. Basically the editor will be the only part with 'windows only' code in it. I figure all editing of a real game needs to be done on a computer anyway, not with a 360 controller.

The current hud is really just a placeholder. If you'd like to re-design it you can. I designed a hud for an older xna game I made and was going to integrate those features in, but the gui is about 25th on my priority list right now.
Coordinator
Oct 24, 2007 at 6:46 AM
Oh, and I did manage to get the source code uploaded, finally!
Oct 24, 2007 at 6:54 AM
So you want to create an editor similar to Visual3D.Net's http://www.visual3d.net/VideoPlayer/tabid/93/VideoId/10/Default.aspx?
Coordinator
Oct 24, 2007 at 7:01 AM
Yes. The engine would be fun even without an editor, but would be difficult to use because users would have to code a lot of their own stuff in to get it up and running their game. We need a way to make it easy for them to load stuff in and run it.
Oct 24, 2007 at 7:29 AM
An editor is a must have for any engine, no doubt about that. There are some major items to consider creating an editor, some you already took by saying that it should be external. But this creates new:
  • Should it be a text only editor, i.e. create your script code and then launch the engine. Many work like this Unreal/HL/Torque etc.
  • Should it build on existing platforms like VS2k8
  • Should it be able to change anything runtime while viewing the scenen, similar to Visual3D.Net

As these can have a major impact on the design of the engine the decission should be taken soon.
Oct 24, 2007 at 6:38 PM
Since when has Epic's UnrealEd and Valve's Hammer been text only? They're feature-rich geometry editors, as well as just script editors.

I don't see much of a need to concentrate much on a script editor up front. I would just let the clients build a .NET assembly that references the QuickStart assemblies. Then, at run-time (or even at edit-time), the engine can pick up the assembly and use it for game logic.

Now the geometry editor will be very much tied to the scene manager in use. That's one of the reasons I was asking if the first stage of the engine will be optimized for vast terrains and not indoor scenes. The particulars of these two types of scenes make a single editor almost impossible.


Oct 24, 2007 at 7:23 PM
Sorry for that, Hammer and UnrealEd are of cause very nice tools (I was refering to pre those days, as that's when I used the tools, i.e. similar to TorqueDev etc.).

But integrating the script language after the initial engine design, isn't that asking for trouble? There are design issues that will affect the main core behavior, such as if the engine should pick up changes to a script at run time and automatically recompile it. This would allow changes to be instant in the engine (for good and for worse). This also raises a whole set of stability issues, and security is going to be a pain, you won't allow a scripter to access Reflection for one. Also File access should prob be denied as there is a huge difference between the PC and Xbox.
Oct 24, 2007 at 7:27 PM
I'm not talking about the scripting backend, I'm talking about a script editor. How scripting binds to the engine should be decided up front, but I wouldn't necessarily make much of an effort to make a nice GUI. Just use Visual Studio.

At run-time, you can apply security constraints to .NET assemblies, like what can be accessed.
Oct 24, 2007 at 7:38 PM
Ahh, so we are actually on the same page, I wouldn't write an editor at all, if we are using C# as the scripting language then VS seems like a perfect choice for a development platform. It provides SCC and all the other goodies we are used to. The engine can then "just" be a editor we show in the work area, similar to the forms editor.

Yes, you are totally that security is "simply" added at runtime, but CAS isn't something that's just added on at the end. As you write ourself we have to decide on a model up front :)

What would the requirements for an scripting system be? Would be support both writing a game in script and as compiled code?
Oct 24, 2007 at 7:51 PM
Edited Oct 24, 2007 at 7:51 PM
Yes, all I meant was that security is applied at run-time not compile-time.

I would say only allow compiled code. We can support dynamically binding/unbinding to modules, but I wouldn't allow taking in scripts as C# text and compiling at run-time, for two reasons:

  1. There is no System.Reflection.Emit on Xbox.
  2. Technically, client code could be written in any .NET language. They just provide as assembly that references the QuickStart assemblies, and we're good to go. We can take this a step further and say any language can be used as a scripting language, as long as the compiler can emit IL bytecode and reference custom .NET assemblies.
Oct 24, 2007 at 8:13 PM
While it's true that there is no runtime compile of the code for the xbox in the current version, I wouldn't expect that to hold true for future versions.

Yes it can be written in any language, but are we supposed to target CLS complaince, as this will affect the object model. I rather not as I realllllly looooove the power of templates. Also currently only C# is supported on the Xbox, but that might change (unsupported languanges might still work as it's all compiled to IL, but still only C# is supported)
Oct 25, 2007 at 2:25 AM
Edited Oct 25, 2007 at 2:26 AM
Why wouldn't we be able to use templates/generics?

Many unsupported languages do in fact work on the Xbox. I don't see why we should enforce staying away from "unofficial" (read, non-C#) languages. As long as you're comfortable at the IL level to fix any potential incompatibilities, who cares? Besides, most incompatibilities stem from missing parts of the System.* namespaces, as far as I know there is very little left out at the IL level.

On the subject of compilers, I have half a mind to write the physics module in C++ / CLI. The Xbox CLR is "supposed" to perform decent code optimization at run-time, but my own benchmarking and some of the threads on the XNA forums have led me to believe otherwise. Everybody seems to praise the power of runtime code generation being able to do all that compile-time optimization can and more, but its just not at that level yet. If I can manually unroll a loop just once and double my Xbox performance (for that loop), something is wrong in the compiler/run-time. I won't even get into the subject of function inlining, which the C++ compiler can do at the IL level with the "proper motivation."

The CLR just isn't at the level yet where we can just blindly allow it to do all of our low-level code optimizations. I realize the "optimal" case is when the CLR can produce the best possible code given the hardware platform without help from the compiler, since all of the code is supposed to be platform independent and "modular". But, when you're talking about high-performance software like games, scientific computing, etc., it's reasonable to sacrifice some direct portability (i.e. having to compile it separately for different platforms) in favor of higher performance.

Sorry, I'll stop now, this simple response turned into a rant against the current state of C# compilers/CLR. :)
Oct 25, 2007 at 6:49 AM
Templates are not CLS compliant, so using those in out interface would prevent other languages which do not support templates to use our code (Hence the CLSCompliant attribute). For one how are templates handled in VB/Boo/IronPython/COBOL?

I'm not going into where ever C# or C++ generates the best possible IL, or who does the best optimization. I do agree that games require the best possible performance and that they often push the hardware to the limit. That said there's also often also a tradeoff in regards writing the fastes possible code, and that's readability/maintanability. Often small changes in high performance code can degrate the performance by %'s (Somtimes tenfold). Also the one doing the change often isn't the one who wrote the original code, and therefore might not know the full impact of a change. Changes to the language might invalidate previous performance code. Is it faster to use foreach/or a for loop, are for loops faster running backward, is it more performant copying arrays using Int64 or bytewise? Also the language choosen also affects this as different languages do optimize differently, and mainly C/C++ often generated the faster code, compared with other languages.

In my experience it's often proven as the sound strategy to write the safe code first. Prove that it works first and foremost. Then write the performant code. There are even times where the safe code does have the performance needed in order to do the job. Adding another language into a project increases the complexity of the project, and requires more people being able to work in different languages. As you most certainly do not want only one person being responsible for all high performant code.

The real question here is if we want to introduce another language in this project at this time. An game engine evolves over years, and who is to say that the runtime and the C# optimizer won't improve over the coming years?
Oct 25, 2007 at 3:44 PM
In an ideal world, I would agree with you. I'm sure the Xbox CLR will get better over time, I just don't agree with .NET's methodology of eliminating code-level optimizations out of the compilers, in favor of doing everything at run-time with the CLR. The CLR is too time constrained and hence cannot do as much as it can. If the CLR were free to take as much time as it needed, it'd be different, but that's not possible without infuriating the user. Also, having the original parse trees around can help the optimizer decide context for code. A combination of compile-time and run-time optimizers would be ideal, but unfortunately that's not going to happen in any "official" sense.

Also, there really is no C# optimizer. It sometimes does in-place constant substitution, but that's about it.