Ma-Shell

This is pretty cool. I have a small suggestion though: The first scenario you showcased, could leave you with objects, which are not part of the scene-tree, resulting in inconsistent behaviour, if you do not call CreateSceneObject. I would suggest to have a callback-system like a ObjectCreated-hook built into the engine, which the editor then could use to automatically call CreateSceneObject with the new object. It makes for one less gotcha you need to watch for when writing scripts and imho better reflects the intention of the scene-browser as a way to see ALL objects in the scene. Also I can imagine this hook to be beneficial for other use cases. Of course, there would need to be a way to retrieve the scene-object for a given object, as well, since the user is not generating the element themselves anymore and thus does not have a reference if they need it (e.g. for selecting the object as in the example).

Also when trying it with subfolders, I noticed, you may need to have the subfolders created automatically in your build-directory: OBJS = $(shell find . -type f -name "*.cpp" | sed s/.cpp/.o/) OBJS_DEBUG=$(foreach obj,$(OBJS),./.build/Debug/$(obj)) OBJS_RELEASE=$(foreach obj,$(OBJS),./.build/Release/$(obj)) CC = g++ FLAGS_DEBUG = -w -c -Wall -I/usr/include/freetype2 -I/usr/include/fontconfig -I./.build/Debug/ -D_ULTRA_APPKIT FLAGS_RELEASE = -w -c -Wall -I/usr/include/freetype2 -I/usr/include/fontconfig -I./.build/Release/ -D_ULTRA_APPKIT LFLAGS = -no-pie -lm -lX11 -lpthread -lXft -lXext -lXrender -lXcursor -lrt -ldl OUT = AppKit all: debug release debug: $(OBJS_DEBUG) $(CC) $(CONFIGFLAGS) $(OBJS_DEBUG) -o $(OUT) $(LFLAGS) release: $(OBJS_RELEASE) $(CC) $(CONFIGFLAGS) $(OBJS_RELEASE) -o $(OUT) $(LFLAGS) ./.build/Debug/%.o: %.cpp mkdir -p $(@D) $(CC) $(FLAGS_DEBUG) $(CONFIGFLAGS) $< -o $@ ./.build/Release/%.o: %.cpp mkdir -p $(@D) $(CC) $(FLAGS_RELEASE) $(CONFIGFLAGS) $< -o $@ clean: rm -f $(OBJS_DEBUG) $(OBJS_RELEASE) $(OUT) This should now make for a pretty low-maintenance Makefile for your purposes

And for the topping (as I just found out): If you have want to have .o-files for every .cpp file in your directory, you can even generate the list more easily: OBJS = $(shell find . -type f -name "*.cpp" | sed s/.cpp/.o/) OBJS_DEBUG=$(foreach obj,$(OBJS),./.build/Debug/$(obj)) OBJS_RELEASE=$(foreach obj,$(OBJS),./.build/Release/$(obj))

Actually it turns out, there is an easy way for modifying the list of objects, which means, you don't need to hardcode the OBJS_DEBUG and OBJS_RELEASE-list. Instead you can do the following: OBJS = ./AppKit.o ./Libraries/PluginSDK/GMFSDK.o ./Libraries/PluginSDK/MemReader.o ./Libraries/PluginSDK/MemWriter.o ./Libraries/PluginSDK/TextureInfo.o ./Libraries/PluginSDK/Utilities.o ./Libraries/PluginSDK/half/half.o ./Libraries/s3tc-dxt-decompressionr/s3tc.o ./Libraries/stb_dxt/stb_dxt.o ./Classes/Object.o ./Classes/Math/Math_.o ./Classes/Math/Vec2.o ./Classes/Math/Vec3.o ./Classes/Math/Vec4.o ./Classes/Math/iVec2.o ./Classes/Math/iVec3.o ./Classes/Math/iVec4.o ./Classes/String.o ./Classes/WString.o ./Classes/Display.o ./Classes/IDSystem.o ./Classes/JSON.o ./Functions.o ./Classes/GUI/Event.o ./Classes/GUI/EventQueue.o ./Classes/Language.o ./Classes/FileSystem/Stream.o ./Classes/FileSystem/BufferStream.o ./Classes/FileSystem/FileSystemWatcher.o ./Classes/GameEngine.o ./Classes/Clock.o ./Classes/Buffer.o ./Classes/GUI/Interface.o ./Classes/GUI/Widget.o ./Classes/GUI/Panel.o ./Classes/GUI/Slider.o ./Classes/GUI/Label.o ./Classes/GUI/Button.o ./Classes/GUI/TextField.o ./Classes/GUI/TreeView.o ./Classes/GUI/TextArea.o ./Classes/GUI/Tabber.o ./Classes/GUI/ListBox.o ./Classes/GUI/ProgressBar.o ./Classes/GUI/ComboBox.o ./Classes/GUI/Menu.o ./Classes/Window/LinuxWindow.o ./Classes/Timer.o ./Classes/Process.o ./Classes/FileSystem/StreamBuffer.o ./Classes/Multithreading/Thread.o ./Classes/Multithreading/Mutex.o ./Classes/Loaders/Loader.o ./Classes/Loaders/DDSTextureLoader.o ./Classes/Assets/Asset.o ./Classes/Plugin.o ./Classes/Assets/Font.o ./Classes/FileSystem/Package.o ./Classes/Graphics/Pixmap.o ./Classes/Graphics/Icon.o ./Libraries/CppTimer/CppTimer.o OBJS_DEBUG=$(foreach obj,$(OBJS),./.build/Debug/$(obj)) OBJS_RELEASE=$(foreach obj,$(OBJS),./.build/Release/$(obj))

You can just change the rule to say `.build/Debug/%.o: %.cpp` and unfortunately you have to add this path everywhere in the OBJS-list: OBJS = ./.build/Debug/AppKit.o ./.build/Debug/Libraries/PluginSDK/GMFSDK.o ./.build/Debug/Libraries/PluginSDK/MemReader.o ./.build/Debug/Libraries/PluginSDK/MemWriter.o ./.build/Debug/Libraries/PluginSDK/TextureInfo.o ./.build/Debug/Libraries/PluginSDK/Utilities.o ./.build/Debug/Libraries/PluginSDK/half/half.o ./.build/Debug/Libraries/s3tc-dxt-decompressionr/s3tc.o ./.build/Debug/Libraries/stb_dxt/stb_dxt.o ./.build/Debug/Classes/Object.o ./.build/Debug/Classes/Math/Math_.o ./.build/Debug/Classes/Math/Vec2.o ./.build/Debug/Classes/Math/Vec3.o ./.build/Debug/Classes/Math/Vec4.o ./.build/Debug/Classes/Math/iVec2.o ./.build/Debug/Classes/Math/iVec3.o ./.build/Debug/Classes/Math/iVec4.o ./.build/Debug/Classes/String.o ./.build/Debug/Classes/WString.o ./.build/Debug/Classes/Display.o ./.build/Debug/Classes/IDSystem.o ./.build/Debug/Classes/JSON.o ./.build/Debug/Functions.o ./.build/Debug/Classes/GUI/Event.o ./.build/Debug/Classes/GUI/EventQueue.o ./.build/Debug/Classes/Language.o ./.build/Debug/Classes/FileSystem/Stream.o ./.build/Debug/Classes/FileSystem/BufferStream.o ./.build/Debug/Classes/FileSystem/FileSystemWatcher.o ./.build/Debug/Classes/GameEngine.o ./.build/Debug/Classes/Clock.o ./.build/Debug/Classes/Buffer.o ./.build/Debug/Classes/GUI/Interface.o ./.build/Debug/Classes/GUI/Widget.o ./.build/Debug/Classes/GUI/Panel.o ./.build/Debug/Classes/GUI/Slider.o ./.build/Debug/Classes/GUI/Label.o ./.build/Debug/Classes/GUI/Button.o ./.build/Debug/Classes/GUI/TextField.o ./.build/Debug/Classes/GUI/TreeView.o ./.build/Debug/Classes/GUI/TextArea.o ./.build/Debug/Classes/GUI/Tabber.o ./.build/Debug/Classes/GUI/ListBox.o ./.build/Debug/Classes/GUI/ProgressBar.o ./.build/Debug/Classes/GUI/ComboBox.o ./.build/Debug/Classes/GUI/Menu.o ./.build/Debug/Classes/Window/LinuxWindow.o ./.build/Debug/Classes/Timer.o ./.build/Debug/Classes/Process.o ./.build/Debug/Classes/FileSystem/StreamBuffer.o ./.build/Debug/Classes/Multithreading/Thread.o ./.build/Debug/Classes/Multithreading/Mutex.o ./.build/Debug/Classes/Loaders/Loader.o ./.build/Debug/Classes/Loaders/DDSTextureLoader.o ./.build/Debug/Classes/Assets/Asset.o ./.build/Debug/Classes/Plugin.o ./.build/Debug/Classes/Assets/Font.o ./.build/Debug/Classes/FileSystem/Package.o ./.build/Debug/Classes/Graphics/Pixmap.o ./.build/Debug/Classes/Graphics/Icon.o ./.build/Debug/Libraries/CppTimer/CppTimer.o CC = g++ FLAGS = -w -c -Wall -I/usr/include/freetype2 -I/usr/include/fontconfig -I./.build/Debug/ -D_ULTRA_APPKIT LFLAGS = -no-pie -lm -lX11 -lpthread -lXft -lXext -lXrender -lXcursor -lrt -ldl OUT = AppKit all: $(OBJS) $(CC) $(CONFIGFLAGS) $(OBJS) -o $(OUT) $(LFLAGS) ./.build/Debug/%.o: %.cpp $(CC) $(FLAGS) $(CONFIGFLAGS) $< -o $@ clean: rm -f $(OBJS) $(OUT) There is probably also a way to add it automatically to every object in the OBJS-list but I don't know it. That later option is especially interesting, if you want separate debug and release builds: OBJS_DEBUG = ./.build/Debug/AppKit.o ./.build/Debug/Libraries/PluginSDK/GMFSDK.o ./.build/Debug/Libraries/PluginSDK/MemReader.o ./.build/Debug/Libraries/PluginSDK/MemWriter.o ./.build/Debug/Libraries/PluginSDK/TextureInfo.o ./.build/Debug/Libraries/PluginSDK/Utilities.o ./.build/Debug/Libraries/PluginSDK/half/half.o ./.build/Debug/Libraries/s3tc-dxt-decompressionr/s3tc.o ./.build/Debug/Libraries/stb_dxt/stb_dxt.o ./.build/Debug/Classes/Object.o ./.build/Debug/Classes/Math/Math_.o ./.build/Debug/Classes/Math/Vec2.o ./.build/Debug/Classes/Math/Vec3.o ./.build/Debug/Classes/Math/Vec4.o ./.build/Debug/Classes/Math/iVec2.o ./.build/Debug/Classes/Math/iVec3.o ./.build/Debug/Classes/Math/iVec4.o ./.build/Debug/Classes/String.o ./.build/Debug/Classes/WString.o ./.build/Debug/Classes/Display.o ./.build/Debug/Classes/IDSystem.o ./.build/Debug/Classes/JSON.o ./.build/Debug/Functions.o ./.build/Debug/Classes/GUI/Event.o ./.build/Debug/Classes/GUI/EventQueue.o ./.build/Debug/Classes/Language.o ./.build/Debug/Classes/FileSystem/Stream.o ./.build/Debug/Classes/FileSystem/BufferStream.o ./.build/Debug/Classes/FileSystem/FileSystemWatcher.o ./.build/Debug/Classes/GameEngine.o ./.build/Debug/Classes/Clock.o ./.build/Debug/Classes/Buffer.o ./.build/Debug/Classes/GUI/Interface.o ./.build/Debug/Classes/GUI/Widget.o ./.build/Debug/Classes/GUI/Panel.o ./.build/Debug/Classes/GUI/Slider.o ./.build/Debug/Classes/GUI/Label.o ./.build/Debug/Classes/GUI/Button.o ./.build/Debug/Classes/GUI/TextField.o ./.build/Debug/Classes/GUI/TreeView.o ./.build/Debug/Classes/GUI/TextArea.o ./.build/Debug/Classes/GUI/Tabber.o ./.build/Debug/Classes/GUI/ListBox.o ./.build/Debug/Classes/GUI/ProgressBar.o ./.build/Debug/Classes/GUI/ComboBox.o ./.build/Debug/Classes/GUI/Menu.o ./.build/Debug/Classes/Window/LinuxWindow.o ./.build/Debug/Classes/Timer.o ./.build/Debug/Classes/Process.o ./.build/Debug/Classes/FileSystem/StreamBuffer.o ./.build/Debug/Classes/Multithreading/Thread.o ./.build/Debug/Classes/Multithreading/Mutex.o ./.build/Debug/Classes/Loaders/Loader.o ./.build/Debug/Classes/Loaders/DDSTextureLoader.o ./.build/Debug/Classes/Assets/Asset.o ./.build/Debug/Classes/Plugin.o ./.build/Debug/Classes/Assets/Font.o ./.build/Debug/Classes/FileSystem/Package.o ./.build/Debug/Classes/Graphics/Pixmap.o ./.build/Debug/Classes/Graphics/Icon.o ./.build/Debug/Libraries/CppTimer/CppTimer.o OBJS_RELEASE = ./.build/Release/AppKit.o ./.build/Release/Libraries/PluginSDK/GMFSDK.o ./.build/Release/Libraries/PluginSDK/MemReader.o ./.build/Release/Libraries/PluginSDK/MemWriter.o ./.build/Release/Libraries/PluginSDK/TextureInfo.o ./.build/Release/Libraries/PluginSDK/Utilities.o ./.build/Release/Libraries/PluginSDK/half/half.o ./.build/Release/Libraries/s3tc-dxt-decompressionr/s3tc.o ./.build/Release/Libraries/stb_dxt/stb_dxt.o ./.build/Release/Classes/Object.o ./.build/Release/Classes/Math/Math_.o ./.build/Release/Classes/Math/Vec2.o ./.build/Release/Classes/Math/Vec3.o ./.build/Release/Classes/Math/Vec4.o ./.build/Release/Classes/Math/iVec2.o ./.build/Release/Classes/Math/iVec3.o ./.build/Release/Classes/Math/iVec4.o ./.build/Release/Classes/String.o ./.build/Release/Classes/WString.o ./.build/Release/Classes/Display.o ./.build/Release/Classes/IDSystem.o ./.build/Release/Classes/JSON.o ./.build/Release/Functions.o ./.build/Release/Classes/GUI/Event.o ./.build/Release/Classes/GUI/EventQueue.o ./.build/Release/Classes/Language.o ./.build/Release/Classes/FileSystem/Stream.o ./.build/Release/Classes/FileSystem/BufferStream.o ./.build/Release/Classes/FileSystem/FileSystemWatcher.o ./.build/Release/Classes/GameEngine.o ./.build/Release/Classes/Clock.o ./.build/Release/Classes/Buffer.o ./.build/Release/Classes/GUI/Interface.o ./.build/Release/Classes/GUI/Widget.o ./.build/Release/Classes/GUI/Panel.o ./.build/Release/Classes/GUI/Slider.o ./.build/Release/Classes/GUI/Label.o ./.build/Release/Classes/GUI/Button.o ./.build/Release/Classes/GUI/TextField.o ./.build/Release/Classes/GUI/TreeView.o ./.build/Release/Classes/GUI/TextArea.o ./.build/Release/Classes/GUI/Tabber.o ./.build/Release/Classes/GUI/ListBox.o ./.build/Release/Classes/GUI/ProgressBar.o ./.build/Release/Classes/GUI/ComboBox.o ./.build/Release/Classes/GUI/Menu.o ./.build/Release/Classes/Window/LinuxWindow.o ./.build/Release/Classes/Timer.o ./.build/Release/Classes/Process.o ./.build/Release/Classes/FileSystem/StreamBuffer.o ./.build/Release/Classes/Multithreading/Thread.o ./.build/Release/Classes/Multithreading/Mutex.o ./.build/Release/Classes/Loaders/Loader.o ./.build/Release/Classes/Loaders/DDSTextureLoader.o ./.build/Release/Classes/Assets/Asset.o ./.build/Release/Classes/Plugin.o ./.build/Release/Classes/Assets/Font.o ./.build/Release/Classes/FileSystem/Package.o ./.build/Release/Classes/Graphics/Pixmap.o ./.build/Release/Classes/Graphics/Icon.o ./.build/Release/Libraries/CppTimer/CppTimer.o CC = g++ FLAGS_DEBUG = -w -c -Wall -I/usr/include/freetype2 -I/usr/include/fontconfig -I./.build/Debug/ -D_ULTRA_APPKIT FLAGS_RELEASE = -w -c -Wall -I/usr/include/freetype2 -I/usr/include/fontconfig -I./.build/Release/ -D_ULTRA_APPKIT LFLAGS = -no-pie -lm -lX11 -lpthread -lXft -lXext -lXrender -lXcursor -lrt -ldl OUT = AppKit all: debug release debug: $(OBJS_DEBUG) $(CC) $(CONFIGFLAGS) $(OBJS_DEBUG) -o $(OUT) $(LFLAGS) release: $(OBJS_RELEASE) $(CC) $(CONFIGFLAGS) $(OBJS_RELEASE) -o $(OUT) $(LFLAGS) ./.build/Debug/%.o: %.cpp $(CC) $(FLAGS_DEBUG) $(CONFIGFLAGS) $< -o $@ ./.build/Release/%.o: %.cpp $(CC) $(FLAGS_RELEASE) $(CONFIGFLAGS) $< -o $@ clean: rm -f $(OBJS_DEBUG) $(OBJS_RELEASE) $(OUT) You can use this and then execute either `make debug` or `make release` (Whereas you will probably want to adjust the FLAGS_DEBUG and FLAGS_RELEASE variables). If you only execute `make`, it will create both, debug and release.

You could shorten that a lot: You don't need the definitions for SOURCE and HEADER at the top and you can replace most of your rules with a generic one: OBJS = ./AppKit.o ./Libraries/PluginSDK/GMFSDK.o ./Libraries/PluginSDK/MemReader.o ./Libraries/PluginSDK/MemWriter.o ./Libraries/PluginSDK/TextureInfo.o ./Libraries/PluginSDK/Utilities.o ./Libraries/PluginSDK/half/half.o ./Libraries/s3tc-dxt-decompressionr/s3tc.o ./Libraries/stb_dxt/stb_dxt.o ./Classes/Object.o ./Classes/Math/Math_.o ./Classes/Math/Vec2.o ./Classes/Math/Vec3.o ./Classes/Math/Vec4.o ./Classes/Math/iVec2.o ./Classes/Math/iVec3.o ./Classes/Math/iVec4.o ./Classes/String.o ./Classes/WString.o ./Classes/Display.o ./Classes/IDSystem.o ./Classes/JSON.o ./Functions.o ./Classes/GUI/Event.o ./Classes/GUI/EventQueue.o ./Classes/Language.o ./Classes/FileSystem/Stream.o ./Classes/FileSystem/BufferStream.o ./Classes/FileSystem/FileSystemWatcher.o ./Classes/GameEngine.o ./Classes/Clock.o ./Classes/Buffer.o ./Classes/GUI/Interface.o ./Classes/GUI/Widget.o ./Classes/GUI/Panel.o ./Classes/GUI/Slider.o ./Classes/GUI/Label.o ./Classes/GUI/Button.o ./Classes/GUI/TextField.o ./Classes/GUI/TreeView.o ./Classes/GUI/TextArea.o ./Classes/GUI/Tabber.o ./Classes/GUI/ListBox.o ./Classes/GUI/ProgressBar.o ./Classes/GUI/ComboBox.o ./Classes/GUI/Menu.o ./Classes/Window/LinuxWindow.o ./Classes/Timer.o ./Classes/Process.o ./Classes/FileSystem/StreamBuffer.o ./Classes/Multithreading/Thread.o ./Classes/Multithreading/Mutex.o ./Classes/Loaders/Loader.o ./Classes/Loaders/DDSTextureLoader.o ./Classes/Assets/Asset.o ./Classes/Plugin.o ./Classes/Assets/Font.o ./Classes/FileSystem/Package.o ./Classes/Graphics/Pixmap.o ./Classes/Graphics/Icon.o ./Libraries/CppTimer/CppTimer.o OUT = AppKit CC = g++ FLAGS = -g -c -Wall -I/usr/include/freetype2 -I/usr/include/fontconfig -I./ -D_DEBUG -D_ULTRA_APPKIT -lm -lX11 -lpthread -lXft -lXext -lXrender -lXcursor -lrt -ldl LFLAGS = -no-pie -lm -lX11 -lpthread -lXft -lXext -lXrender -lXcursor -lrt -ldl all: $(OBJS) $(CC) -g $(OBJS) -o $(OUT) $(LFLAGS) %.o: %.cpp $(CC) $(FLAGS) $< -o $@ clean: rm -f $(OBJS) $(OUT) This way, whenever you need to add a file, you just need to add it to the OBJS-list. The generic rule in the middle tells make, when it wants to create any file ending with .o to just search for the file ending with .cpp and in the command for that rule the placeholder $< will be replaced with the first prerequisite, whereas $@ will be replaced with the target (see https://www.gnu.org/software/make/manual/html_node/Automatic-Variables.html)

Please don't use Window::MoveMouse! You will have users constantly asking themselves, whether that's absolute (i.e. move mouse to x, y) or relative (i.e. move mouse by dx, dy). Even if you can easily look it up I think, it is more helpful when scrolling through the autocompletion-options to just see on the first look what the function does without ambiguities.

Pretty sure "appstores" is wrong, though^^

I don't even know what the f*** is going on with all the appstores?^^

This is looking great. I've always been bothered by the available options for a lightweight GUI. I also think that cross platform support for a GUI framework is quite a big deal and can only second the opinion that this is the most important bonus goal. From the material you have posted, there is one thing I am quite curious about: In your code example you are placing the button and panel using fixed coordinates and sizes. Moreover, the widget is only created once and does not run through a loop, where the user would constantly recalculate the coordinates. When looking at the video, however, the widgets resize, when you resize the window. Did you implement a resizing-handler for the GUI shown in the video or are you planning to have a sort of automatic layouting system (i.e. defining anchors and having horizontal/vertical/grid layouts, which automatically manage the sizes of their contents) (clearly such a layouting system internally needs to use such a resize-event-handler but the question is, whether the logic behind that is tucked away some place within the API or whether a user needs to implement the handler themself). Maybe you could extend the example code by the GUI which is shown in the video and if there is such a system leave some words about how you plan it to work.

You might want to look at the return code: in your batch-file add echo %errorlevel% directly after the game and before the pause

Is there a log in %LOCALAPPDATA%/Leadwerks ?

Have you tried temporarily turning off windows firewall?

I suppose, that would be the case. There might be some other optimizations for brushes (e.g. if you want to have a sphere, you can simply transfer the center and the radius to the GPU instead of multiple vertices and again save some bandwidth and RAM real estate) but I believe that these differences would be only minor. I should say though, that I have never done any comparison nor do I have any specific knowledge of how this is implemented. Everything I'm saying about that topic is just derived from things I gathered in different forum posts here over the years and using my own logic

The difference comes from the fact that the entire thing is collapsed to just a single model. This means that every piece of code, which iterates over all instances only walks over this object once instead of 1000 times. Also there is only one transformation matrix which is getting updated and pushed back and forth from CPU to GPU and which takes much less space (which can be used for caching again)

What happened to where you claimed 200 fps for 10000 characters? Was that all shared skeletons?

This is certainly a pretty cool feature! Whenever physics is involved, however, the programmer needs to keep in mind that there might be slower systems out there and things might break when executed on slower systems. The programmer might e.g. be tempted to give an option to reduce the particle effects on lower end hardware but then the entire physics might break.

I suppose, texcam will be rendered every frame, just like the normal camera. Would there be an option to render the camera only on demand? Like some sort of photograph? Or with a lower frequency for performance optimization?

Are you using some fancy new technology like MVR or one of its predecessors for the single pass point-lights? If so, have you also evaluated, what happens on older GPUs?

There is but that isn't trivial to implement: Basically you create a grid where each cell lists all the enemies within the region. This requires that when an enemy changes position, it also removes itself from the old cell's list and inserts itself into the new one. Then the player only has to search through the lists of the nearby cells. Of course the additional bookkeeping might have a different performance impact but especially, if the entities also sometimes react to one another or if you're checking the distance more often, this will certainly pay off.

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?