Ma-Shell

What does the code for differently coloured letters look like? Do you call CreateText once for every letter and then position them manually or is there a nicer way?

Is it possible to combine more than 2 worlds (possibly by daisy chaining them)?

I see two possible issues with filters: 1. I understand a filter as having some sort of "layer-id" on the objects and a camera only rendering objects with a given layer-id. Suppose, you have two objects A and B. If you want to first render A and B and then from a different camera only B (e.g. you have a vampire in front of a mirror. You would want the entire scenery to include the vampire but when rendering the mirror, you would want to render the scenery from that perspective without the vampire). This would not be easily possible with a layer-id. 2. Performance: You have to run through all objects and see, whether they match the filter in order to decide, whether to cull them or not. If you instead just walk the world's list of entities, this does not happen. Why not using something like this: camWorldA->SetClearMode(ColorBit | DepthBufferBit); camWorldB->SetClearMode(DepthBufferBit); camWorldC->SetClearMode(DepthBufferBit); context->ClearWorlds(); // nothing is being rendered context->AddWorld(worldA); // All cameras of world A are rendered context->AddWorld(worldB); // First all cameras of world A are rendered, then all of world B context->AddWorld(worldC); // First all cameras of world A are rendered, then all of world B, then all of world C This would give the user maximum flexibility and only require the context to hold a list of worlds, which are rendered one after another instead of having a single active world. For compatibility and comfortability reasons, you could additionally define void World::Render(Context* ctx) { ctx->ClearWorlds(); ctx->AddWorld(this); } This way, you could still use the system as before without ever knowing of being able to render multiple worlds. EDIT: I see, my vampire wouldn't work with this system, as well (unless you allow a mesh to be in multiple worlds) but I still think, this is quite a flexible and easy to use system without much of an overhead

Isn't that basically what a world is? Each camera renders only the objects that are in its world, so the world is basically a filter for the camera

Ah, I see... So the rendering always uses the last world, which called World::Render() and uses all cameras from that world in the specified order? Would it be possible to implement the same ordering as with cameras for worlds then? Like the following realWorld->setOrder(1); HUDWorld->setOrder(2); where it would first render all cameras from realWorld and after that all cameras from HUDWorld. This would probably mean, it is more intuitive to have the render-call on the context instead of the world, since all worlds would be rendered. By the way, is there any way to disable certain cameras, so they get skipped? Like setting a negative order or something like this. What happens if you set two cameras to the same order?

You mean, because unlike the previous version the user does not directly call Render() anymore, since it is run on a different thread and thus the user can not correctly orchestrate the rendering? This should not be a problem, since in CreateCamera you can specify the world. auto realCamera = CreateCamera(realWorld); auto HUDCamera = CreateCamera(HUDWorld); realCamera->setOrder(1); HUDCamera->setOrder(2); realCamera->SetClearMode(CLEAR_DEPTH | CLEAR_COLOR); HUDCamera->SetClearMode(CLEAR_DEPTH);

Would it be possible to use two different worlds for this? One "real" world and one for your HUD and then first rendering only the first world and after that rendering the HUD-world.

The model probably does not have a surface. You should get the number of surfaces first and then iterate over the surfaces. Something like the following (I don't know much about lua, so probably this code won't work without modification): for k,v in pairs (self.modelTable) do for i = 0, v:CountSurfaces(), 1 do surface = v:GetSurface(i) mat = surface:GetMaterial() mat:SetShader(shader) shader:SetVec4("ex_color",self.color) mat:SetColor(self.color) self.modelTable[k] = nil end end

As I said, you should take a look at the objects on your map and the scripts they have attached!

I am pretty sure, the problem is coming from a LUA script of an object in your map, not from C++. That script has probably a world render or update hook, where it tries to access that variable.

No, the comment "//lua" only means that this function is available in lua, as well, but that does not mean, that it is only executed in lua. As for your other problem, it seems like you might not be setting the variable "world" before calling the Update-function or you are probably setting a function-local variable in the Start-function and then accessing a global variable in the update function or something like that. It's hard to say without seeing your code.

Also, looking at https://www.gamedev.net/forums/topic/673534-instancing-and-the-various-ways-to-supply-per-instance-data/?do=findComment&comment=5264179, you can create the buffer much larger first, then copy all data and later repeatedly use glBindBufferRange instead of glBufferSubData, copying all data in one go and being much faster

ah, I see, so you're refering to GL_MAX_UNIFORM_BLOCK_SIZE (https://www.khronos.org/registry/OpenGL-Refpages/gl4/html/glGet.xhtml)? I think, it would make sense, to query that number in the beginning and use that instead of the fixed 256. Otherwise every system would suffer, only so that it can run on lower end systems. EDIT: Of course I mean use that number divided by 64

Doing a performance-test with LW 4.7, I wanted to draw an element ins tanced multiple thousands of times. Using RenderDoc I found out, that Leadwerks batches these into groups of 256 elements each, so instead of having one call to glDrawElementsInstanced, instead I have quite many (which in my eyes are not needed). Also looking at the shaders, I found that they usually have a line like #define MAX_INSTANCES 256 I believe that there is a lot of wasted potential because of this for rendering large groups of the same entity. Is there a reason for this limit? Can we increase it somehow? Will the same limitation be there in Turbo? I have attached the source code for my test. App.h App.cpp main.cpp

Unfortunately there is absolutely nothing you can do to 100% prevent the user from cheating. In the end, the application runs on the client's machine and they can modify the assembly code and by doing so patch these anti-cheat solutions. i.e. the hacker could precompute the file checksum of the original file (or keep a copy of the original file around and return that one's checksum, when the server asks for the file's checksum (When the server asks for the file hash, there is no guarantee, that the client actually computes any hash... it simply has to answer with the correct magic numbers, which a patched game could do.) All the developer can do is raise the barrier for the hacker (e.g. by obfuscating the compiled program code to make it harder to find the corresponding functions) but in the end, the hacker will always have a way to get to all the information, which is stored on the client for creating their own authentication codes or for displaying in-game-information, which is not supposed to be known to the user (wallhack, aimbot, ...). There is absolutely no way to make this impossible. The only way this could work would be by using game-streaming services ( 🤮 ) where the client does not actually get or calculate any state but only gets the rendered image and returns the keyboard and mouse-input to the streaming service.