Rick

Test it out wayneg. Start an app and start putting tons of cubes around to see the fps hit. Even though I agree the graphics are horrible, the gameplay is interesting and many times that's all you need. Sometimes the gameplay is so interesting that you forget about the bad graphics. It's like watching a movie that they shot in black and white. If it's really good, you end up forgetting (and caring) that it's not in color.

Honestly, if the try/catch is out then the ctor usage talk doesn't really need to be had.

Seems like it should be. That's a ton of blocks though. I'm not sure how the FPS would be with all those blocks. You can try it with CreateCube()

Honestly conquering a "language" is the easy part. Getting to know all the libraries a language has takes more time and is never ending as new libraries come out. .NET is a good example of that. The language itself isn't hard, but there are tons of classes and frameworks in .NET, that will keep you busy for years and years. The language of C++ isn't all that hard, but there are endless amount of libraries for it and learning a bunch of those (and weeding through the bad ones) can take time. The best advice about learning the language and different features would be to read online, and ask questions here. The biggest drawback I find in this community is that most people don't want to talk about design. I don't know if they don't want anyone to steal their design or what, but talking about how you want to design some class or your entire game really helps get a wide range of views on it. Doing a design yourself can be rewarding but chances are you'll miss something that if you talked about it would have come out, and you could save yourself a ton of time later on in your development.

Does BMax have a try/catch? I mean out of all the languages LE wants to support is it just Lua that doesn't have a try/catch? There is probably a Lua extension that someone wrote to give try/catch functionality.

All I'd really care to much about is that it's event driven and not polling.

You would pass the graphicsdriver to the constructor of Shader(). You would need the graphicsdriver object above anyway in both situations, so instead of saying graphicsdriver->CreateShader() you would do Shader* shader = new Shader(graphicsdriver);

I believe it. Some people might say programming languages are all basically the same, but really C++ gives you lower access than most other languages. You can do some pretty funky things with it. I think you'll be more effective with C++.

The problem with .NET is that all objects are created as basically pointers. You don't have much of a choice. They are treated like pointers in C++ as far as where they are created in memory. C++ gives you the choice of where to create objects. Heap or Stack. It gives you more freedom, which is why it's slightly different. Trust me though, like any other language you get used to it, and even end up liking it

Lumooja, you're crazy man try/catch are very real and they are much more informational than a null check. Josh can make very detailed exceptions that actually tell you why (in string form) it failed. With a null check you don't get that. If you don't like -> operator then do something like (*params).MyFunction(), although I prefer -> over that. I guess you could make a macro to make that easier #define POINTER_VAR(p) (*p), then you can say POINTER_VAR(param).MyFunction(); Clearly you could shorten the name of that macro, just wanted to give it a descriptive name. It could be P(param).MyFunction() if you like. This also is something I wouldn't do, but if it makes you more comfortable you surely can. He would do it by having the classes throw exceptions that we can catch. That's how try/catch works. Your users use try/catch but the classes and functions throw the error for us to catch. Yeah, it would handle it by exiting gracefully. If you don't have a model file then there isn't much you can do about it. If anything try/catch lets you handle errors better, because if you throw more descriptive errors, we as the users can code for those specific errors and handle it better. Let's say we try to open a file but it's in use by another program and won't let us open it. With null checks we don't know why it return null. With try/catch you can throw a "file already in use" exception OR "file not found" exception. This tells us much more information than null.

try/catch is your friend. Throw an error. It's all the rage these days! It can be much better than plastering your code with if/null checks. If everything must work in a chunk of code, you surround it with 1 try/catch and boom, done.

Then overload the ctor for the Entity class to either specify an actual world class, or not (and make a SetWorld() also if we want to specify). If someone wanted the functionality you are talking about then I don't see anything wrong with giving it to them but it's going to come at a cost of passing that world around if they need it. For everyone else not doing that, don't make us worry about making worlds and managing them at all. The reasons you give above is valid, but it's most likely 5% of what anyone will really do. So don't cause issues for the other 95%, BUT still give the option to that 5% to be able to do it if they so choose. If LE3 is using layers (which I like), in the ctor to these entities we should specify which layer we want it in I think. Also (not related), is clipping going to be possible? I'm picturing something like in an RPG where you open up the character screen they normally have a model inside a window and that model is clipped inside that window. That would be cool if that was a little easier to do. I remember trying to do that and it being a pain without clipping areas.

OK, so here is what I'm thinking. Nested behaviors inside their respective outputs from other behaviors. When the behavior is finished running, it'll determine which output name should be used next. In the case of a behavior just having 1 output, it'll just say "out". In the case of the Compare Bool behavior, depending on what happens inside that behavior it'll return "true" or "false" indicating to the calling program what direction the program should go depending on what happened in that behavior. I hope that makes sense. It makes sense in my head So visually the below would have 2 actions (create_cube & compare_bool) and it would go from create_cube's output to calling compare_bool. Then depending on the result of compare_bool it would branch off to other actions defined. <behavior name="create_cube"> <parameter type="Entity" value="" /> <result type="Entity" type="variable" value="eCube" /> <output name="out"> </behavior name="compare_bool"> <parameter type="bool" value="bVar1" /> <parameter type="bool" value="bVar2" /> <result type="bool" type="variable" value="" /> <output name="true"> <!-- More nested behaviors if true --> </output> <output name="false"> <!-- More nested behaviors if false --> </output> </behavior> </output> </behavior>

You can look at that a few different ways. I would rather pass in the world to the contructor for the entities instead of having those functions part of the world. Here you say, create this entity in this world. The other way yo are saying create this entity, and place it in this world. World* world = new World(gfxDriver); Entity* box = new Box(world); The world shouldn't have CreateThis() or CreateThat(), they should just be added to a worlds collection of entities. The nice thing about that is we can now swap the same entity between worlds if a SetWorld() property was part of the Entity class. Not sure if that would cause issues though. If it doesn't, this would give us more control on things. For me the idea of a "world" kind of messes things up because you now would have to pass it anytime you want to create an LE entity. I personally don't care about worlds and wish we wouldn't have to deal with them at all. Why do worlds even exist? Is it because of the deferred renderer? If so, isn't there a set number of worlds realistically used? Main, Foreground, Background? Would there be any other reasons to have us manage worlds? Each of these constructors could have an enum to specify what predefined world they should be created in: Entity* box = new Box(WORLD_MAIN); That's just my personal view, but I don't know the whole story on worlds.

There is nothing wrong with -> and Roland will tell you the same thing. It's part of using pointers to objects in C++. Everyone who knows C++ knows this. No use in trying to get around it with weird designs. I don't like this approach either, but it's not the worst. That object won't exist outside of the scope it was defined in. So if that was created in a function, it'll be destroyed when that function is finished, but yeah I prefer creating objects as pointers so they stick around outside of the method they were defined in, and I have control of when to release them. About the camera you could do something like: Graphics* gfx = new OpenGLDrivers(); // polymorphism tells gfx to use the OpenGLDrivers::CreateCamera() method Camera* camera = gfx->CreateCamera(); Personally I would avoid normal C functions like CreateCamera() or CreateCube(). Seeing that seems like you really aren't in the OOP mindset yet. Should be: // Entity being the base class, Mesh deriving from Entity, //and Box deriving from Mesh Entity* box = new Box(); Mesh* box1 = new Box(); Box* box2 = new Box(); // GetPosition is shared by all Entity types so they all have access to it Vec3 v = box->GetPosition(); v = box1->GetPosition(); v = box2->GetPosition(); Entity* mat = new Material(); Material* mat1 = new Material();

The request isn't unreasonable, it's a matter of priorities. Having this isn't going to get the core of your game going. There are many other higher priorities that will aid in actually getting gameplay going in LE. This isn't a gameplay feature, but I agree it's a nice to have once all the other core stuff is competed first.

They are all still missing the `window` variable definition. What is it? I'm against any sort of global variable creation by the engine like it seems to be.

That helps. What I was doing was just calling things in the order they were in, in the xml file. Each "Action" is a class that overloads the () operator and passes in the parameters and return value (which isn't the flow control like the outputs are, it's just a way to return some values from the Action). The () operator currently wasn't returning anything. But it sounds like I should return what output was fired from said Action (maybe a string name that is an attribute in the xml element) so that the calling controller knows what node to look for next. Currently this all runs real-time from reading xml data (the file is loaded once at startup and the code just reads it to figure out what to do next). I might look into loading the xml and storing the entire flow in code and then running it, instead and if I do that, it would relate nicely with delegates as outputs like you suggested. I'll play around with that to see how it works. Thanks!

I have code that reads an xml file that will be generated by a flowgraph. It was working fine, however when I got into an action that has more than 1 input and/or more than 1 output my current design won't work. I was wondering if anyone wanted to brianstorm on how to do set some xml up for these. The thought (and code that I have working) is that each Action would be an LE API function. For those they would simply be an In & Out for the flow, and they would have parameters and results. All that works, but I'm looking at other nodes like "Compare Int" which has 1 in and 5 outs. The 5 outs changes the flow of the logic. Here is an example of what I currently have <behavior name="position_entity"> <parameter type="Entity" source="variable" value="cube1" /> <parameter type="float" source="constant" value="0" /> <parameter type="float" source="constant" value="1" /> <parameter type="float" source="constant" value="2" /> <parameter type="int" source="constant" value="1" /> </behavior> <behavior name="create_cube" > <result type="Entity" value="cube1" /> <!-- This will make a variable? --> </behavior> I was using just the order of the behavior tags to control the logic flow (the arrows in the flowgraph), but when you get something that has multiple outputs I can't really do that. Any ideas? I have this code working and it's pretty exciting, but I just need help with ideas. Here is a screenshot of UDK's Kismet and what I mean. My link

Overall I like it. Where did the variable `window` come from, or is that what you don't have worked out yet?

Got events working now. You would drag on the behavior "attach_entity_event" & the event you want to attach to, like "update_entity", and then link which entity you want to attach to that event. The out connector of that event is where you define the functionality inside that event. The xml would look like: <root> <behavior name="create_cube" > <result type="Entity" value="cube1" /> </behavior> <behavior name="attach_entity_event" > <parameter type="Entity" source="variable" value="cube1" /> <parameter type="xml" source="variable" value="event:on_update_1" /> </behavior> <event name="on_update_1" type="UpdateEntity" > <behavior name="test"> </behavior> </event>

nvm, got it with the Parse() function

Has anyone create a TiXmlElement object from xml data that is stored in a string? I can't seem to get it working and just wondering if anyone has experience in this. I was able to dump out the text xml from TiXmlElement but now wish to load it back into a TiXmlElement.

Added PositionEntity. This file will create a cube and position it. <?xml version="1.0" ?> <root> <behavior name="create_cube" > <result type="Entity" value="cube1" /> </behavior> <behavior name="position_entity"> <parameter type="Entity" source="variable" value="cube1" /> <parameter type="float" source="constant" value="0" /> <parameter type="float" source="constant" value="1" /> <parameter type="float" source="constant" value="2" /> <parameter type="int" source="constant" value="1" /> </behavior> </root> Now that I have these 2, I'll work on the UI so that one can make this file via a flowgraph UI.

<?xml version="1.0" ?> <root> <behavior name="create_cube" > <result type="Entity" value="cube1" /> </behavior> </root> These 6 lines are the start of a flowgraph system I'm working on. I've been playing with UDK's Kismet and enjoying what it can do. Now UDK's Kismet is pretty specific to UDK functionality for the most part. They have things like SpawnPlayer, which LE obviously doesn't have. LE gives you much lower level control than SpawnPlayer type stuff. So what I've decided to do is create every function LE has into an xml tag, that can be read in and executed. Then a flowgraph UI can be placed on top of that as the editor that lets you visually generate said xml. The user however, never needs to be concerned with the underlying xml. In UDK functionality is split into a few things. Namely Actions & Events. It also lets you create variables. My flowgraph will function the same way. Like in the above xml, you would have dragged the CreateCube action onto your canvas. Then created a variable object of type Entity, and linked it to the result node sticking out of the CreateCube action. Now when it's called, you have a variable that you can reference anywhere else. For example, you can then drag in a PositionEntity action and use the prior created variable as the entity parameter to this. So the result is just how a person would program LE, but it would be visual. If people will like this I don't know, but it's fun and interesting to get it working.