Change Set 8284/8285

Coordinator
Dec 7, 2007 at 7:03 AM
I've uploaded a new change set with the beginnings of a camera framework. I left it an intermediate state as I'm blocked at this point. I will be needing at least the following soon to continue and test the camera system:

1.) Input system for moving the camera.
2.) Messaging system. All camera movement will be done through messages.
3.) Entity hierarchy started. Camera's will derive from Entity. Models will be attached to Entities as well, and we need Models to render.
4.) Basic light system. We cannot render a model without a light to hit it. We could probably use BasicEffect default lighting to begin with.
Dec 7, 2007 at 7:40 AM
I uploaded today's work on my end. Since the two of our commits are so close together, we might as well combine the discussion into one thread.

New in 8285:
  • Beginnings of the graphics library
    • Custom model processor for static models (no animation, all geometry baked into one vertex-buffer/index-buffer for efficiency).
    • Render queue not implemented yet, but the IGeometryProvider will be the interface point for all geometry containers (static models, skinned models, etc.) along with another interface for materials.
    • For those interested, the new model processor demonstrates the new property functionality of the XNA 2.0 content pipeline. The coordinate system transform is setup as a property for each model.
    • User-rendering mixed with graphics library rendering.
  • LordIkon's FreeCamera
  • ConfigurationManager still untouched for now (sorry Sturm!)

Dec 7, 2007 at 10:38 AM
Edited Dec 7, 2007 at 10:39 AM
Nice code shaw (thought I did some code cleanup, like adding this prefix for instance members). I started integrating my stuff.

LordIkon, I think you should consider rereading the coding guidelines, either we need to revise the guideline or you should revise your code.


LordIkon wrote:
1.) Input system for moving the camera.

I do agree that this is a must have but this does not hinder the building of the camera class


LordIkon wrote:
2.) Messaging system. All camera movement will be done through messages.

I do hope that you mean that FreeCamera has this dependency, other types of camera surely don't. Initially you could create a camera which as able to follow a fixed path, either always having a fixed distance to the terrain or being able to change this depending on speed, or something else.


LordIkon wrote:
3.) Entity hierarchy started. Camera's will derive from Entity. Models will be attached to Entities as well, and we need Models to render.

You can just create a basic entity class, simply containing position/rotation etc. I think that we should use single noun for folders, similar to what you would have used for a namespace. Also move camera one level up otherwise you will just end up with a very big entities (Entity) folder.


LordIkon wrote:
4.) Basic light system. We cannot render a model without a light to hit it. We could probably use BasicEffect default lighting to begin with.

You can start on that as well, as soon as you got the basic entity in place, you can always just render your entities directly in the demo game, until a SceneManager has been checked in (Which I'll do once I get the messages checked in)


shawmishrak wrote:
ConfigurationManager still untouched for now (sorry Sturm!)

No problem I'll start filling in on that once I start the work with input.

Good work all, it's starting to make progress :)
Coordinator
Dec 7, 2007 at 2:10 PM
Edited Dec 7, 2007 at 2:15 PM

Sturm wrote:LordIkon, I think you should consider rereading the coding guidelines, either we need to revise the guideline or you should revise your code.


I stated in the changeset description that I needed a code review and that I wasn't finished with commenting. It was late so I may have missed some things. Although I have changed my coding practices already as you may have noticed. No regions, camel case member variables and local variables, pascal case functions. If there are things you have noticed it would be easier if you just let me know right now, because I did read the guidelines recently.

There are some things that are confusing. You state that members should be PascalCase, but then you show below that:

 
Wrong:
private bool Initialize = false;
Right:
private bool initialize = false;

I'm not sure if I just don't understand or if this is wrong.

The only thing I can think of offhand that I might have missed was
- Using braces on one-line statements.
Coordinator
Dec 7, 2007 at 2:25 PM
Edited Dec 7, 2007 at 2:25 PM


Sturm wrote:
I do agree that this is a must have but this does not hinder the building of the camera class

How am I to test the movement of the camera without input? How will I know zoom is working, or the rotation speeds, or the rotation and zoom smoothing? Will my camera move in the right direction according to its vectors? Maybe, but I won't know until I have input.


Sturm wrote:
I do hope that you mean that FreeCamera has this dependency, other types of camera surely don't. Initially you could create a camera which as able to follow a fixed path, either always having a fixed distance to the terrain or being able to change this depending on speed, or something else.

That is of course exactly what I meant. The camera isn't going to need to send itself messages to respond to its own interactions with its target or collisions.


Sturm wrote:
Also move camera one level up otherwise you will just end up with a very big entities (Entity) folder.

How else are users to know at a glance which classes are derived from Entity? Will they be required to open every class? The entity folder might be huge, as will the code folder, as will the content folder, as will the root C:\ folder on any PC. Why is that a bad thing? In fact, placing entity types in an Entity folder will keep the root code folder of our project from having all entities folders within it. I'd prefer having the entity clutter within folders inside of an entity folder rather than the root folder.


Sturm wrote:
You can start on that as well, as soon as you got the basic entity in place, you can always just render your entities directly in the demo game, until a SceneManager has been checked in (Which I'll do once I get the messages checked in)

I could start it, if I want it deleted later. I'm assuming Shaw is going to be doing this soon, as he is working on Models and graphics. He won't get too far without a lighting system. I'd rather not overlap our work.
Dec 7, 2007 at 3:26 PM

LordIkon wrote:
If there are things you have noticed it would be easier if you just let me know right now, because I did read the guidelines recently.

I will do a review later when I get the time,


LordIkon wrote:
There are some things that are confusing. You state that members should be PascalCase, but then you show below that:
 
Wrong:
private bool Initialize = false;
Right:
private bool initialize = false;
I'm not sure if I just don't understand or if this is wrong.

I guess what might confuse you are the terms, members should be PascalCase, but what is shown is a field. Maybe we should make it more clear in the guidelines.
Dec 7, 2007 at 3:56 PM

LordIkon wrote:
How am I to test the movement of the camera without input? How will I know zoom is working, or the rotation speeds, or the rotation and zoom smoothing? Will my camera move in the right direction according to its vectors? Maybe, but I won't know until I have input.

You have to be able to test the class, and most code, without any user interaction, so there should be a way to fake the interaction and get the results. The easiest thing as I see it is to create a PathCamera initially and then check on a couple of updates if the state is correct. Sometimes though, the only way to test things, out of band, is to use reflection.


LordIkon wrote:
How else are users to know at a glance which classes are derived from Entity? Will they be required to open every class? The entity folder might be huge, as will the code folder, as will the content folder, as will the root C:\ folder on any PC. Why is that a bad thing? In fact, placing entity types in an Entity folder will keep the root code folder of our project from having all entities folders within it. I'd prefer having the entity clutter within folders inside of an entity folder rather than the root folder.

Well I hope that most users will use our framework and extend it, not actually the source code. I think that's a success criterial for the engine. But I have no problem keeping the current folder structure.


LordIkon wrote:
I could start it, if I want it deleted later. I'm assuming Shaw is going to be doing this soon, as he is working on Models and graphics. He won't get too far without a lighting system. I'd rather not overlap our work.

You should be able to implement a simple ambient light, It's just another entity :)
Coordinator
Dec 7, 2007 at 3:59 PM
I guess I am confused on the difference between members and fields. To me, in the sample above initialize is a member of its class.
Dec 7, 2007 at 4:34 PM
By moving the camera one level up, do you mean moving it into the Entity folder (opposed to Entity/Camera), or into the project root? I agree with the move to Entity (to match the namespace), but I don't see why it should be in the root.
Coordinator
Dec 7, 2007 at 4:37 PM


shawmishrak wrote:
By moving the camera one level up, do you mean moving it into the Entity folder (opposed to Entity/Camera), or into the project root? I agree with the move to Entity (to match the namespace), but I don't see why it should be in the root.


If we put camera into simply the entities folder, what happens when there are 4 different types of camera? Or people want to add their own camera? Wouldn't we end up with a single entity folder with a bunch of files?
Dec 7, 2007 at 4:48 PM
There will be a decent amount of files in the folder, yes, but not that many. Remember that everything in the Entity folder will be generic. There will be no game-specific entities, and any entities that exist as part of a certain scene manager will most likely exist with the scene manager.

If people add their own camera, it would fall in one of two places:
  1. If its part of a game project, it would go with the game code, not in QuickStart.dll.
  2. If its an engine enhancement, it would go in the Entity folder.
Coordinator
Dec 7, 2007 at 5:32 PM
I guess I'm curious as to why we're purposely removing organization from the project. Having a camera folder lets me find all camera files. If I don't have that it may be more annoying. Here's an example of some random file names.

Code/Entities folder:
- ArcBallCamera.cs
- BEntityClass.cs
- BlahEntityClass.cs
- Camera.cs
- DEntityClass.cs
- FixedCamera.cs
- FourItemsClass.cs
- FreeCamera.cs
- LEntityClass.cs
- NotACameraClass.cs
- RandEntityClass.cs
- WoWStyleCamera.cs
- ZCameraClass.cs

Given 2 seconds, tell me how many cameras there are. The answer is 6. Now lets try one more time:

Code/Entities/Camera folder:
- ArcBallCamera.cs
- Camera.cs
- FixedCamera.cs
- FreeCamera.cs
- WoWStyleCamera.cs
- ZCameraClass.cs

Not only can I figure out how many cameras there are, but I know which files are cameras without even looking at their names. I also know while files in entity aren't cameras without looking at their names. In fact, this example was still too simplistic, I had only 2 types, cameras and others. What if we had about 6 types, each with 3 derived classes. We now have 18 files, and of those I have to sift through for the cameras.

I guess I don't understand what is so difficult about having a folder to keep things clean? Why have folders for PCs when we can put everything on the C:\ root directory? Because it just makes no sense at all.

Using our current logic why even have an entities directory? All the entities are objects, we could just have an objects directory and place every class in the code in that. See where I'm going with this?
Dec 7, 2007 at 5:45 PM
My concern is where do you draw the line with what gets its own folder? Camera is a well-defined example. I'm worried that we'd end up with as many folders as we have source files. When you get close to that point, its actually harder to find what you need. Having a few high-level categories is fine, I just don't want to get in a habit of creating a folder for every possible type of entity.
Coordinator
Dec 7, 2007 at 5:53 PM
I'd would say anything abstract, and then all the classes derived from it. Or set a limit, say, only classes that have more than 3 things derive from it. Not only does a folder let me know which things are cameras, but it lets me know that everything in that folder should be of that type, or derived from a type. Using the folder system you can plainly see what things are entities, and by extension we'll know all camera's are entities.
Dec 7, 2007 at 5:59 PM
As long as there's a set criteria for what should be a folder, that's fine. Just be aware that you're always going to have fringe cases, where a new entity could logically fit into two or more current entity folders.
Coordinator
Dec 7, 2007 at 7:01 PM
As long as it is an entity it should be in the entity folder right?

I agree though, there should be some basic guidelines so we don't get people making folders 4 levels deep and having a folder with only a single file.
Coordinator
Dec 7, 2007 at 9:50 PM
I should add that I included exceptions in the code as a temporary measure until we setup an event logging/console system of some kind which we can pass errors in a cleaner way. I'm willing to set that system up once the messaging system is in place. I'm not sure if I'd use the same setup as the template's event logger or not. I'd have to have a couple of you review that system first as I want this engine to be 'top notch', nothing half-assed.
Coordinator
Dec 7, 2007 at 9:53 PM
Edited Dec 7, 2007 at 10:00 PM
Oh and by the way, nice job on the latest changeset Shaw, I like having the logo in the corner. Reminds me of the Ogre engine. I'd also like to say that I know there is always a little tension between people trying to communicate effectively and design an engine using only the internet, and I like the critical feedback that we're not afraid to give each other. As long as we always consider that our idea could be the wrong one, or that we're always open to criticism then I think we can only learn from this experience to become better programmers and hopefully create a decent engine at the same time. Good job so far guys.

Edit: Thanks for adding the descriptions headers in my camera as well Shaw.
Dec 8, 2007 at 12:11 AM
It's always nice to have some level of disagreement, because it forces everyone to reconsider their own styles. Coming from a strong C++ background, I've had to learn a lot of stylistic things that are common in the C# world.
Dec 8, 2007 at 11:35 AM
If you want to become more C#ish have a look at the C# Coding Standard from IDesign, Phillips, and Microsoft. They are very good in providing a unified programming style. They are maybe a little more restrictive than I would enforce, but it's up to the individual project lead (or yourself) to take that decission.