Rick

So maybe something similar to the below? Thoughts/ideas/concerns? // part of the framework class IEffect { protected: // protected so our derived classes can use them // these get filled in from the framework World* bgWorld; World* fgWorld; Buffer* bgBuffer; Buffer* fgBuffer; public: virtual void Update()=0; virtual void Render()=0; void SetBGWorld(World* world) { bgWorld = world; } // etc. for worlds and buffers }; // my take on the Bloom effect namespace Rick { class Bloom : public IEffect { public: Bloom() { } virtual void Update() { } virtual void Render() { } } }; namespace Shadmar { class Bloom : public IEffect { public: Bloom() { } virtual void Update() { } virtual void Render() { } }; }; class RenderFramework { private: World* bgWorld; World* fgWorld; Buffer* bgBuffer; Buffer* fgBuffer; list<IEffect*> effects; public: void RenderFramework() { // create the worlds and buffers } void AddEffect(Effect* effect) { effect->SetBGWorld(bgWorld); // etc. set the effects worlds/buffers // add this effect effects.push_back(effect); } void Update() { // loop over effects and call Update() } void Render() { // loop over effects and call Render() } }; // usage RenderFramework fw; fw.AddEffect(new Shadmar::Bloom()); fw.Update(); fw.Render();

My thought is because with it being open source we would want others to contribute at any point in time their effects, which might be different takes on existing effects. Right now we basically just have Shadmar doing these, but tomorrow we could have another person who comes along and says they have a different take on the Bloom effect so they make their own Bloom shader that requires different parameters than Shadmars. So now we have 2 takes on a Bloom effect that take different parameters created by 2 different people. Maybe at some point in our games we want to use both. How to account for that? Namespaces would be the proper way in C++. The question becomes is this an open framework that allows people to add to it for everyone to use and if so how to allow this without colliding with existing effects, which would make more work for the user as they piece together the code and if there is a collision with effect name or whatever they have to work out themselves. That's my line of thinking anyway. I don't think adding a namespace would cause that much more work for both the creator or the user. These effects classes are pretty basic I'm thinking as they pretty much transport parameters to the shader and so some camera/world switching.

All the styles I listed above are 1 liners for usage though I personally like: fw.AddEffect(new Shadmar::Bloom(15, 2, 5)); Is that flexible enough? As a content creator that means you make a class class Bloom that derives from some kind of IEffect class inside a namespace you called Shadmar (in case someone else makes a Bloom class this is how we tell them apart). Your Bloom class would hardcode where the shader is located. Being able to modify it for my own usage is one benefit but also being able to add to it for others to use is (the biggest benefit IMO) another and that means making sure what a person adds doesn't collide with what another person adds.

I think what we have to think about is what is an effect. It's basically a shader with settings that need to be set in the shader from the program. Person A can make a bloom shader that has x variables that need to get to the his shader, and person B can make a different bloom shader that needs different variables. So an Effect class basically combines a specific shader to specific parameters to get to that shader. So this would mean a person would have to make their own class name for their effects or use namespaces. So either: fw.AddEffect(new ShadmarBloom()); or fw.AddEffect(new Shadmar::Bloom()); Going this route I don't think one would have to pass a shader in as it would be hardcoded in that persons class. We would just pass other parameters that get passed onto the shader to control it's look/feel. If we go the route of passing in a shader, then it gets so much more generic because it could be any shader along with any pieces of data to pass to that shader. If this was javascript it would look like: fw.AddEffect(Shader::Load("bloom"), { low = 5, middle = 2, cutoff = 1, strength = 6}); Translating something like that to C++ is a little more difficult as there is no type information and I think we'd need that to send the parameters to the shader, but you see how an effect seems to simply be a shader and parameters for that shader. I like the namespace method as it's probably the "proper" way to do things, but I know some people don't like namespaces.

I like the RenderFramework folder idea. The default shaders would need to be in a certain spot to use an overload that doesn't specifically load a shader. So maybe something like: class IEffect { public: virtual void Update(); virtual void Render(); }; class Bloom : public IEffect { public: Bloom(); Bloom(string shaderFilePath, float low, flow middle, float cutoff, float strength); }; RenderFramework render; render.AddEffect(new Bloom()); render.Update(); render.Render();

A design to think about with having these SetXXX(). A more flexible approach seems like having an Effect class and an fw->AddEffect(Effect*) function. That way people can just add new effect classes without directly effecting the main framework class.

I think we need more customization allowed. For instance what shader does SetBloom() use? I think a default bloom shader file is nice, but maybe have an optional param that let's us pick the shader file to use as others may have new bloom shaders they want to use instead of a default one. All effects could be like that. I vote source since it'll always work on all compilers and we wouldn't have to maintain libs. We have to think about mac/linux so source handles that also.

try printf(cname.c_str()); printf() is old school and doesn't know about the string class so it's function c_str() converts it to plain old char*

std::string cname; instead of just string cname, will fix the first one. Your second error is saying the function Delay() doesn't exist.

What error are you getting?

I think it's a good idea as long as it allows for custom shaders to be used. I think the original basically only allowed 1 shader file for each effect (probably hardcoded in the framework). I think testing with multiple worlds to see if it's a lot faster would be needed first though as that remains one of the biggest benefits of the framework and if it's not required it would diminish the purpose of it some. Lua might be a little more awkward I think as it's main attraction is using the editor to do a lot of stuff vs the person coding things like the creation of worlds and cameras vs using the camera entity in the editor and attaching shaders via the editor. If multiple worlds makes things so much faster then perhaps the editor should have some things altered to help with that without coding.

I always felt one of the main benefits of the 2.x framework was not having to deal with multiple worlds. It had some other nice helpers in it like FOG, DOF but not having to mess around with handling multiple worlds ourselves was the winner for me. I seem to recall the main reason for multiple worlds was transparency issues that a deferred renderer caused. I thought that was all worked out with only 1 world now in 3.x though? 3.x seems so much more shader based that I wonder if a generic framework would work as it would most likely rely on shaders existing already in the project where I can't recall if 2.x needing those external shader's to exist for SSAI, GodRays, HDR, Bloom etc.

Hello, You can view and schedule appointments at: https://acuityscheduling.com/schedule.php?owner=11246158 It seems people would like a more 1 on 1 training experience instead of a group setting so I'm going to offer 1 on 1 training by the hour. My rate will be $10 hour. I'm pretty sure a person flipping burgers makes more than that but since this is all new and an indie friendly engine I thought I'd pick an indie friendly price. I can't promise the price won't go up at some point pending the demand but for now this is what it will be. I've made available the times I can provide training. M-F is later in the evening for me, and Sat/Sun I offer morning hours as well as evening hours. All you have to do is schedule a time and we'll be on our way. I'll send out an invoice via Pay Pal to the email address you use to sign up and that'll need to be paid 15 mins before the training. Thanks and I look forward to providing some personal help! Rick

Sounds like 1 on 1 is what most people are interested in so I'll switch to that. I'll send you a PM with details Papa.

Does anyone feel like private 1 on 1 lessons would work better for them? I get the sense that we have such a diverse community that finding the right time for a group is difficult and possibly people are more timid in a group setting. Maybe it's better to switch to a more private 1 on 1 training class. I'll give this a few more days to see who is interested and if I can't get the full 5 I'll do 1 on 1 classes. I could do videos but I really want to give a more personal touch to the training. There are already videos out there but I know a lot of times I have questions even with the videos that I'm not able to ask a real person at that time of having the question. That's the gap I'm trying to really fill here.

If there is enough demand for this I'll be offering more of these and at different times to accommodate others.

Thanks Roland. We'll see what the demand is like 1/5 people so far. 4 slots remaining.

The LE stuff is different but the RakNet stuff is the same. You just might have to translate the new LE stuff vs what the tutorial uses.

Yes. Passing variables to functions does not change it's scope. However in the case you had you didn't have local in front of PlayerEnt. So unless above in that function you had: local PlayerEnt, and just didn't show us that code, PlayerEnt would have been global because you just had: PlayerEnt = entity

Hello all, My name is Rick and I will be offering Beginning Lua for Leadwerks training on Saturday May 10th at 10 AM CST. I have been using Leadwerks for about 5+ years and professionally I've been programming for 13 years. Beginning Lua For Leadwerks will touch on the basics of Lua and how Leadwerks uses Lua. It's meant for people who are a little newer to programming in general or if you want a quick overview of how Lua is used in Leadwerks. The training will last 1 hour and I'll take questions at the end so it might go longer (30 mins of questions max though). Question are welcome throughout the training as well. The cost is $10 and will be invoiced from Pay Pal (because I'll invoice I don't think you need a Pay Pal account but most likely some kind of credit/debit card). I am going to host via https://www.meetingburner.com/. I believe this works on all LE platforms (Windows, Mac, Linux). Because I'm using the free version (for now as I don't know what kind of demand there is for this) it only allows 5 participants so I'll only be taking the first 5 people who respond here asking to join the training. This will also help keep the training class small so people feel more comfortable asking questions. If there is enough demand I'll continue doing these sessions along with different topics. This is something new I'm trying so if anyone has ideas/thoughts/concerns I'm open to hearing about them. Please send me a PM if you would like to join. Thanks, Rick

You are returning the player entity from the collision script? The engine calls this collision function so the question is why would you think returning it would do anything? Not being mean just trying to get your thought process so I can understand and help you understand. Also what I'm seeing from your code is that you maybe think there is a relationship between script variables and function parameter variables (since you have them named the same)? There isn't. Just because your PlayerPosition parameter is named the same as the variable you seem to set in the collision function doesn't mean they are the same. In fact they are not. You don't need to set the entity to anything in your collision. You said you want to pass the player to your function. So pass it as a parameter (this is the normal way to handle it). if entity:GetKeyValue("name") == "Player" then System:Print("Found Player") self:PlayerPosition(entity) end So you will notice in the above example that should be in your collision function, if the entities name is "Player" you print out a message and you pass that entity to the PlayerPosition function. You use self: because that function is part of that script (self refers to the script itself and since that scrip that function self:PlayerPosition() means the PlayerPosition() function in that script). Note that script variables uses a dot and not a colon. That's just how Lua works (functions can use dot as well but colon is easier for use that as you have to do something else to use dot for functions. colon is a shortcut that you should use). Now you may have thought that PlayerEnt was global and if it's global why wouldn't it work in your PlayerPosition() function. Well 2 things. Since you named the parameter to that function the same I'm thinking Lua gets confused when inside that function (reality is it's probably not confused and it's probably using that parameter which is probably nil when the function is called). When is this function called? These are reasons to avoid globals. Even without the parameter to that function the order of when that function gets called has a requirement of setting the PlayerEnt variable, so if that function gets called at any point before PlayerEnt isn't set to something then it'll be nil. But you'll notice how much easier things are without globals in this case. Just call the function from the collision passing in the entity when it's the player. There is no need for the global and in fact having the global caused more typing and more things that can go wrong.

I didn't say stop 100% but just be careful with the advice you give and know that you are still new to programming and you might be giving less optimal ways of doing something. It would be the same as if I started giving less optimal advice on art related stuff. Some may have you believe that as long as something works then that's all that matters (which for small apps may be true) but how you structure your game matters when things start getting larger. How you do things in programming do matter for maintaining and being able to read and follow it 6 months from when you write it. The same holds true for doing things in the art world.

Make a bug report with an example. In the meantime you can take the 2 points and find the distance via one of the helper functions to Vec3 I believe.

"name" actually does get set by the engine so that should be fine. Tell us the exact error you are getting and on what line. I'll leave this site open all day so send me an IM on it and if I'm on I'd be more than happy to help you in real-time. @YouGroove Your examples doesn't make any sense according to the issue he's having and only confuses matters. For instance you aren't doing any checks to see if the entity passed into the collision is actually the player, which is fundamental to his issue. Be careful with the help you give in programming (since you are newer) as it might just cause more confusion.

It's not really the network library that is hard. It's the hoops you have to jump through to get networking to be decent. There are so many tricks that you have to do to make it playable. RakNet is C++. I created a C++ DLL that exposed RakNet to Lua about a year ago. It was a learning curve but you can do it.