QuickStart Editor Patch

Dec 19, 2007 at 2:16 AM
My first patch, I am sure I did things wrong. Let me know what you think and be brutal.
Coordinator
Dec 19, 2007 at 2:24 AM
If you want brutal we'd better let Sturm do it.
Dec 19, 2007 at 2:46 AM
And don't worry, we've set up an "Sturm Brutality" support club. :)
Dec 19, 2007 at 4:27 AM
I tried to take a quick look at it, but it seems as though the project file doesn't work in VS Pro, and from the solution file, the project is incorrectly linked with an absolute path instead of relative to the solution file. Unfortunately, I'm going to have to put it off until we get the other patches squared away.
Dec 19, 2007 at 5:45 AM
Well, considering that I only use VS Express it is very possible that I did something wrong which makes it incompatible with VS Pro. I will try and figure out the linking problem, though I am not sure why that would be.
Dec 19, 2007 at 5:23 PM
What is it, bash Sturm day? :)

I dont see why express would cause the errors. All my work is done in express, with no problems (yet), and arent they meant to be compatible anyway?
Dec 19, 2007 at 6:02 PM
It's possible that I deleted the solution file...it's back now, let me re-upload the patch.
Dec 19, 2007 at 7:57 PM
Its possible that only the XNA projects are compatible, and WinForms projects are not, for whatever reason.
Dec 20, 2007 at 6:17 AM
(I couldn't build so I just reviewed the code)

Move the QuickStartEditor code under framework/code

Generally:
  • Remember to use this prefix for instance members
  • Method names should use PascalCase
  • Remember to add xml comments

In Scene.cs
  • Couldn't name be a attribute on the class instead of a property, I guess it's only used in the editor?
  • SWind/SGravity should be removed, promote the fields to properties instead

In SceneManager.cs
  • Couldn't name be a attribute on the class instead of a property, I guess it's only used in the editor?

In UserControlMenu.cs
  • Consider having one method (ie. SetVisibility(bool visible) instead of having duplicated code.

In MainWindow.cs
  • Do not expose fields, use properties
  • Do not omit brackets on single line if statements
Dec 20, 2007 at 4:03 PM
Move the QuickStartEditor code under framework/code


Can Do!

Generally:

* Remember to use this prefix for instance members
* Method names should use PascalCase
* Remember to add xml comments



I try and remember these things but I don't always get it. Also I am not sure what the Windows code generation uses so it is possible I will have to change all of those by hand.


In Scene.cs

* Couldn't name be a attribute on the class instead of a property, I guess it's only used in the editor?
* SWind/SGravity should be removed, promote the fields to properties instead


It is possible that it could be an attribue, but I use the property for the property grid form so that you can change the name from the property grid. I am not sure if you can do that using an attribute. And yes it is only used in the editor right now.

SWing and SGravity I did because Wind and Gravity were already capitalized, although I don't think they should be. I can however make them both properties.



In UserControlMenu.cs

* Consider having one method (ie. SetVisibility(bool visible) instead of having duplicated code.

That code wasn't put in there by me, it came in the base code that I used and it worked so I didn't even look at it again. I will however and see if I can cut out some unnecessary code.


In MainWindow.cs

* Do not expose fields, use properties
* Do not omit brackets on single line if statements


Rawger that, will use properties from now on. I would imagine that code was there also since I always use brackets on if statements, I think it looks ugly otherwise. But like I said much of the base code I didn't review for standards I will go back and do that.


On a side note, any idea why it won't compile? Something that I am doing wrong? Also, I believe that me and xnasorcerer are going to be working on the editor together starting with what he already has so what I uploaded here would be obselete and worthless anyways, I will make more of a point in the future of checking for coding correctness. Me and sorcerer have already laid out what we want to have implemented in the first release of the editor, so we probably will not upload anything until those things are in place, I can say that it shouldn't take too long with us both working on it since they are not that many things and many of them he has already implemented to some extent. Anyways we'll see how it goes.
Thanks for the review.
Coordinator
Dec 20, 2007 at 4:15 PM
It'll be exciting to see something working. I also would like to request a feature (doesn't need to be right away), that we can have the editor running concurrently with the game. It doesn't have to interact back and forth with the game, but what I would like to be able to do is make changes the scene and then start the engine without shutting down the editor, and have my scene load up in the engine. This way I can shut down the engine, make changes in the editor that is running in the background, and then start the engine back up. This will keep me from having to shut down the editor each time I need to start the engine.

I believe XNA lets you run two games at a time separately anyhow, so this may not be very difficult.
Dec 20, 2007 at 4:23 PM
That shouldn't be too dificult, we can put a walkthrough feature in which stick in a player at a spawn point and lets you walk through the scene, obviously this requires that there be some sort of terrain/room to walk on and a spawn point. I can't imagine what else you might want to test in the engine from a scene anyways. And in the end if you just want to test different lights and stuff it would be easy to put a flat piece of geometry and a spawn point and then play with the lights and shaders. This probably won't be in the first release but I will talk with sorcerer and see, he might already have something like that implemented, in fact in the video he made I know that he was able to view the scene playing so I am pretty sure he does.
Coordinator
Dec 20, 2007 at 5:18 PM
His editor showed a lot of shader changes, skydome changes, postprocess effects, and such, but I didn't see specifically any point lights, or change of lighting color, altering model position or rotation. I'm sure he has more than is shown in the video, but it is difficult to get a full scope of what has been done already from the video.
Coordinator
Dec 20, 2007 at 5:23 PM
I retract some of what I just said, I just saw the newest video he made, a lot of cool things I hadn't seen before.
Coordinator
Dec 20, 2007 at 5:26 PM
Interesting link and some ideas:
http://www.youtube.com/watch?v=LVXs_paf99U&NR=1
Dec 20, 2007 at 9:25 PM


LordIkon wrote:
Interesting link and some ideas:
http://www.youtube.com/watch?v=LVXs_paf99U&NR=1


LordIkon, I already have the code for a terrain editor working. I just have to implement it inside the editor.
Did you read the message I sent to you?
Coordinator
Dec 20, 2007 at 9:50 PM
Just read it. Done.

Does your terrain editor work for the type of terrain we're using?
Coordinator
Dec 20, 2007 at 9:55 PM
I should elaborate on that I guess.

The vertices must be laid out in an axis aligned grid.
The width of the terrain must be (n^2 + 1), i.e. 257x257, 513x513. However the heightmap image itself must be power-of-two.

Vertices must have position and a normal.
Vertices must be put into a list, which the quad-tree system can use to create the leaves.

I have this system in place, the editor would simply need to modify the vertices and run the algorithms already in place.