Rick

I would also add an activate that takes a camera parameter also. This would allow someone to not have to make a pointer to the class or require a camera when the class is created and activate it later. This is how I see I would use this because there wouldn't be anything to clean up when my class goes out of scope since it won't be a pointer. class My Class { private: Bloom myBloom public: void Update(window* window, Camera* camera) { if(window->KeyHit(Key::A)) { myBloom.SetParams(5, 3, 1); myBloom.Activate(camera); } } };

The other way is to loop over the world entities (world->entities I think) looking for the key "name" for the entity that you want, AFTER you've already loaded the map.

What is door->model? A 3D model I assume? Does it have a physics shape attached to it? With external models you have to assign a physics shape to it yourself (or csg). Probably best to make a prefab of the door where you give it a shape or attach csg with a script attached to it so the csg won't get collapsed.

I think the shader name should be inside the class itself since the shader is basically the reason for the class. Also more options for setting properties on their own instead of 1 since a person might want to alter just 1 property instead of all of them. Other than that, I think you just make copies (you could make a base class that has the camera & shader variable inside of it and inherit those since all effects would require those, but that's not that big of a deal. Someone might point out that you could just have set property with a string for key/value, but I'd point out the benefit here is that VS will tell you what properties are available per effect where using just string key names doesn't and you'd have to look them up which would be a pain. Also, when are you thinking of actually applying the effect to the camera? I may want to make an instance at startup but not actually apply it until later on when something happens to the player that should cause the effect. Something to think about. Getter for each parameter would be nice too so we can use it to add/subtract to.

I have more patience for bugs than I do scaling trial and error it seems because a bug is a mistake and I accept that. Scaling like this should be easier and real-time to make it more efficient. I could have probably set something up for that, but either I write 30+ mins of code to do that or I suffer 15 mins of rescale/restart to find the exact value. I picked the trial and error just to something.

I have pretty tame nightmares . Probably 15 mins of trial and error of scaling, test, get pissed, rinse and repeat. That rotate downward was a video posted here that some made with LE. It did look nice. It was in 3rd person but I'm sure it works in 1st too.

I did the same thing Josh did with scaling and it works. However, it was a nightmare of trial and error trying to get the right scale and position.

I guess the nice thing about Leadwerks is the models and textures get converted to mdl/tex. Not that someone couldn't write a loader for them but that's still effort like cracking a zip file. So really it's music that doesn't get converted to a format that requires some kind of work to get at.

Might be best to show your work on github or bitbucket to allow others to see what it's all about and participate if they want. You could make task lists of what's needed and people could help where they can. Like I could add the RakNet stuff if you did this.

I 100% with you catch22. The issue is the license of purchased models say you have to make an attempt at some kind of password protection of their models so to be compliant we need this, even though we all know it's pretty much worthless. Tell that to the artists that sell these models

@tkunze You are correct. I guess I was thinking in terms of engine features vs supported platforms but I can see where platforms can be considered features too.

I swear I did this in LE 3.0. I just swear it. It was part of the App template in C++.

Those are commands for outputting to the console window. Those are part of the C/C++ library not the Leadwerks library. Leadwerks has it's own functions for drawing to the Leadwerks window. It's been to long for me to exactly remember the LE 2.x commands. Maybe DrawText()?

inventory = { sword = { cost = 150, dps = 15 }, dagger = { cost = 200, dps = 10 } } print(inventory["sword"].dps) So you can make a lua file like the above to init your inventory. Notice how this isn't that different than if you made a text file to hold this information. The good thing with the above is that once you include it in your other lua files it gets evaluated and is lua and ready to use. Prefabs aren't there to prevent players from altering. Prefabs just link multiple things together. That's it. This may come as a surprise but if you are using Lua the player can see your code and alter it if they wanted. If this is a single player game then it really doesn't matter. If they want to play it that way then there isn't much you can do really and they'll only be ruining it for themselves.

Nope. It's a good way to test and get your lua table format solid. Then ideally you'd use a text file or sqlite or some kind of external file to describe the data, which when you look at it really isn't that different than a lua file really. If you have an external text file look at the IO commands LE has to open the files and reading/writing to them.

self.inventory = {} self.inventory["sword"] = {} self.inventory["sword"].dps = 15 self.inventory["sword"].cost = 150 self.inventory["sword"].icon = Texture::Load("") Each element in your inventory table can have a table as well that stores all your stats for that item. Ideally you'll have some kind of master inventory that loads 1 of everything possible in your game and however you give items to the player is where you copy what to give to the player inventory. That way you are just pointing to 1 loaded texture of an item so if you have 5 of those it's just pointing to the 1 texture/icon. You can have sub-tables of sub-tables etc.

What we are talking about sound the same, but one is Lua and the other is C++. Really the only difference I see in this design is the ability to pass parameters to the effect so it can be passed to the shader to allow for even more customization within each effect. Also, perhaps the ability to alter the effect at run-time by the means of these variables? Shadmar could probably list other limitations he's seeing for the reason he asked for this.

@tkunze The reason for some 2.x features not being in 3.x is because 3.x was a total rewrite of the engine. It used to be in BMax in 2.x and earlier, but now it's C++ so the rewrite caused some features to be removed and to be added later. C++ has been around for so long that I can't see anymore rewrites of the engine to any other language so going forward I think we're all safe from losing features and only gaining features.

Josh has said before that he generally plans for yearly paid updates. I want to say the updates are generally around $99 (possibly $199? can't 100% recall). Leadwerks does get updates throughout the year also though for free as well.

I am. I coded some menu stuff and now that they have finished the first scene and finishing up on the monster and another character I'll start adding some gameplay logic.

@Josh I think the main question here is the requirement for multiple worlds/buffers. Shadmar is saying that it's possibly more efficient to have multiple worlds/buffers and the current 3.1 system seems to use just 1? My understanding is that we can use Lua scripts as a post-processor (which allows us to create more worlds/buffers if we need) which is great, but that's only Lua and not C++. The C++ crowd could still use something that helps with this. What we are proposing here seems a lot like Lua post processor scripts but just C++ classes for the the C++ people. Same idea but for C++.

I get no love for Phobia? This proves people only care about art

Ah ok, so the idea being the creator of the shaders can make a collection class that combines effects and adds them in the "right" order and then users can make an instance of this class and they get a predefined look. I like that idea as it still allows for users to create their own order of effects or just use a predefined order via a collection class predefined by someone. They are just like helper classes to get a predefined look. I like that as a helper class. I don't think getting the order of something is overly complicated, but this can help for sure.

I like the idea of an effect collection. How do you see it working though? How do you know what effect you're adding? We would need some kind of identifier on each effect. This requires knowing all effects. I think this works for the base stuff we know today, but would have to be updated when new effects come out. How do you see this working? Update RenderFramework with delete and clear effects. My C++ is a little rusty but I think I have the idea. Just doing this in notepadd++ so not checking for compiling. class RenderFramework { private: World* bgWorld; World* fgWorld; Buffer* bgBuffer; Buffer* fgBuffer; list<IEffect*> effects; public: void RenderFramework() { // create the worlds and buffers } IEffect* AddEffect(IEffect* effect) { effect->SetBGWorld(bgWorld); // etc. set the effects worlds/buffers // add this effect effects.push_back(effect); } void RemoveEffect(IEffect* effect) { list<IEffect*>::iterator iter; for(iter = effects.begin(); iter != effects.end(); ++iter) { if(effect == (*iter)) { // store off our effect so we can delete it IEffect* e = (*iter); // remove this entry in the list effects.erase(iter); // delete our effect delete e; return; } } } void ClearAllEffects() { list<IEffect*>::iterator iter; for(iter = effects.begin(); iter != effects.end(); ++iter) { delete (*iter); } effects.clear(); } void Update() { // loop over effects and call Update() } void Render() { // loop over effects and call Render() } };

That's a good question. I'd be more inclined to leave that up to the user because it might allow them to make funky looking effects for whatever they want it to be used for. Maybe they want it to not look right for some strange alien effect It gives the user more freedom and I'm all for that. Even if that freedom seems strange Also, we don't know of every single effect that will ever exist so it's easier to let users have that control than to have to update the framework when totally new effects come out and have to be ordered a certain way. The only thing I didn't cover in my example is removing effects. We'd have to have a way to remove a given effect. Maybe AddEffect() returns the IEffect object and we can use that to remove and alter the effect later during run-time. Could probably have a ClearAllEffects() also.