reepblue

The MSAA and textureanisotropy setting doesn't apply correctly ether.

You also have camera->ClearPostEffects() only being called only if the posteffect array has a size greater than 0. This will allow the user to only set the effect on but turn it off. Change: // Post Effects auto peIt = videoSettings.find("posteffects"); if (videoSettings["posteffects"].is_array()) { auto& posteffects = videoSettings["posteffects"]; camera->ClearPostEffects(); for (int n = 0; n < posteffects.size(); ++n) { if (not posteffects[n].is_string()) continue; std::string path = posteffects[n]; auto fx = LoadPostEffect(path); if (fx) camera->AddPostEffect(fx); } } To: // Post Effects if (not videoSettings["posteffects"].is_null()) { camera->ClearPostEffects(); if (videoSettings["posteffects"].is_array()) { auto& posteffects = videoSettings["posteffects"]; for (int n = 0; n < posteffects.size(); ++n) { if (not posteffects[n].is_string()) continue; std::string path = posteffects[n]; auto fx = LoadPostEffect(path); if (fx) camera->AddPostEffect(fx); } } }

Actually, there also seems to be a mismatch with SetShadowQuality. The default setting is high, but the menu reports the medium setting. There's no GetShadowQuality to start as a base value for the menu.

I've been playing with the new Game.cpp / GameMenu.cpp code and I noticed some bugs with the code. First, this wrong, video isn't a boolean and there can be an error if window size vector is missing. On Line 33 of Game.cpp change: bool fullscreen = true; if (settings["video"].is_boolean() and settings["video"]["fullscreen"].is_boolean()) fullscreen = settings["video"]["fullscreen"]; if (settings["video"].is_boolean() and settings["video"]["windowsize"].size() >= 2) { w = settings["video"]["windowsize"][0]; h = settings["video"]["windowsize"][1]; } To: bool fullscreen = true; if (settings["video"].is_object() and settings["video"]["fullscreen"].is_boolean()) fullscreen = settings["video"]["fullscreen"]; if (settings["video"].is_object() and settings["video"]["windowsize"].is_array()) { if (settings["video"]["windowsize"].size() >= 2) { w = settings["video"]["windowsize"][0]; h = settings["video"]["windowsize"][1]; } } There's a bug with the window size values not carrying over from one save to another. This is because the window size values only get saved if a new window was created. Around Line 787 change: if (resolutionIndex > 0) { bool newFullscreenMode = (fullscreenbutton->GetState() == WIDGETSTATE_SELECTED); bool oldFullscreenMode = (Game::window->style & WINDOW_FULLSCREEN) != 0; auto& item = resolutionlist->items[resolutionIndex]; auto s = item.text; auto sarr = s.Split(" x "); auto w = std::stoi(sarr[0]); auto h = std::stoi(sarr[1]); if (w != Game::window->size.x || h != Game::window->size.y || newFullscreenMode != oldFullscreenMode) { auto style = WINDOW_CENTER | WINDOW_TITLEBAR; if (fullscreenbutton->GetState() == WIDGETSTATE_SELECTED) style |= WINDOW_FULLSCREEN; auto newWindow = CreateWindow(Game::window->text, Game::window->position.x, Game::window->position.y, w, h, Game::window->display, style); if (newWindow) { Game::window->SetHidden(true); Game::window = newWindow; Game::framebuffer = CreateFramebuffer(Game::window); ui->SetSize(Game::framebuffer->size); Game::settings["video"]["windowsize"] = {}; Game::settings["video"]["windowsize"][0] = Game::window->size.x; Game::settings["video"]["windowsize"][1] = Game::window->size.y; Game::settings["video"]["fullscreen"] = (Game::window->style & WINDOW_FULLSCREEN) != 0; } } } To: if (resolutionIndex > 0) { bool newFullscreenMode = (fullscreenbutton->GetState() == WIDGETSTATE_SELECTED); bool oldFullscreenMode = (Game::window->style & WINDOW_FULLSCREEN) != 0; auto& item = resolutionlist->items[resolutionIndex]; auto s = item.text; auto sarr = s.Split(" x "); auto w = std::stoi(sarr[0]); auto h = std::stoi(sarr[1]); if (w != Game::window->size.x || h != Game::window->size.y || newFullscreenMode != oldFullscreenMode) { auto style = WINDOW_CENTER | WINDOW_TITLEBAR; if (fullscreenbutton->GetState() == WIDGETSTATE_SELECTED) style |= WINDOW_FULLSCREEN; auto newWindow = CreateWindow(Game::window->text, Game::window->position.x, Game::window->position.y, w, h, Game::window->display, style); if (newWindow) { Game::window->SetHidden(true); Game::window = newWindow; Game::framebuffer = CreateFramebuffer(Game::window); ui->SetSize(Game::framebuffer->size); } } Game::settings["video"]["windowsize"] = {}; Game::settings["video"]["windowsize"][0] = Game::window->size.x; Game::settings["video"]["windowsize"][1] = Game::window->size.y; Game::settings["video"]["fullscreen"] = (Game::window->style & WINDOW_FULLSCREEN) != 0; } There's also a bug with Post Processing effects being applied when the map already has effects applied. Bonus: When the game un-pauses with the FPSPlayer, the camera will spin to where the mouse is currently is. This is because freelookstarted needs to be set back to false. I just added the function to have the listen to EVENT_WORLDPAUSE and added this to the ProcessEvent function case EVENT_WORLDPAUSE: freelookstarted = false; break;

I was looking at the new menu code for C++ and I noticed that the code is calling the menulogo texture that only exists in the Lua template. std::string logopath = "menulogo.dds"; Probably should be moved to the Common template.

On the latest beta, thumbnails don't seem to generate with new projects. This is a shader issue as it works fine with the older shaders. I only tested it with materials so far.

The current filter list is outdated and while it ignores cpp files, it doesn't ignore headers or the json files. My suggestion: start.map, $PROJECTNAME.props, $PROJECTNAME.sln, $PROJECTNAME.vcxproj, $PROJECTNAME.vcxproj.filters, *.cpp, *.h, *.lua, *.json, projecticon.svg, projecticon.ico

The code wasn't there on a new project. Maybe he forgot to change it or doesn't know the best all-around solution is..

I think all you have to do is look at Cyclone. There's a list of simple things that are glued together to make a simple game. Firing projectiles Volume detectors: Detecting points, lines, and full entities inside a volume without using physics detection. Collision Triggers, getting them to work with not only the player but props and NPCs. Pushing/Pulling physics. (Kind of the entire game) Spawning objects and removing them from the scene. (Box droppers and fizzlers) Joints wether that be doors, platforms or picking objects up. Timers, relays and gates. (Pedestal buttons, Making 2 buttons open one door, etc) Level Transitioning Killing the player and restarting reloading scene. (Or in Cyclone's case, I just respawned the player.) Showing Input Glyphs I know you expressed demonstrating view codes, but it would be great if you also went over how to find entities in a box or within a radius correctly without using collision. It would be also neat if you could visualize the math per function, per line this way the viewer actually has a better understanding of what TransformPoint or TransformVector actually does instead of "IDK, it worked in that example, so I'm gonna try it here." Recreating the Portal 2 laser cubes would also be a neat idea. It's a great demonstration of raycasts and you can go into reflecting the vector if it hits a shinny wall. Just some ideas I have at the moment.

This might be considered as "fragmentation of the user base" but why don't you keep the component system as a pro-feature? From these conversations and borderline arguments, what I'm seeing is that you want the scripting system to be simple to teach and explain, but most people defending the component system are C++ users who seemed to be doing fine with the examples and documentation (or lack thereof) for the past few years. These customers tend to do things their way anyway and don't like they are being told they are using the engine wrong. You seem to get a lot of push back on this thread due to the fact that the Pro version has been the popular choice over the standard edition. Even though I expect that to even out or change once the full release goes out, the Pro version is something special and the people who use it aren't afraid of burning themselves due to their own bad decisions.

Text shows a blurry mess. You can try this in the editor. font = LoadFont("Fonts/arial.ttf", 24) sprite = CreateSprite(program.world, font, "Hello", TEXT_LEFT | TEXT_TOP) o = CreateGameObject(sprite)

Well, if the goal is to have end users upload their own components so the download section we eventually have a library of them, some components would need to have open-ended parameters. I designed that to be as versatile as possible. If I wanted to make a teleport system, I would do it my way, with my models, and my sounds and baked it into the main player. It seems like your goal is shifting from people gluing things that already exist to actually getting them to program. Although I agree with your viewpoints since mono-components (Or just Actors) is how I coded Cyclone on Leadwerks 4. The only thing that that bothers me regarding this topic is that you're talking about removing options for developers. Right now, the engine supports multi-components, but if you want to cram everything into one, you can. If you want multiple components and have them reference each other, that's fine too. I also don't like that a core design of the engine is being reconsidered right before the final release and many people have active projects they have been working on. I know you wish to steer people way from overcomplicating things, but I believe that developers should have that freedom to design their game how they wish. I understand your perspective that "no decision is a bad decision", and supporting both can seen as a non-decision. But there's nothing wrong with what we have now. You can write your tutorials using the mono approach, I can use mono components, and people like Dreik and Alienhead can still code how they want.

I mean, I'm all for this. I can then make nice wrapper functions for my "components". std::shared<ScaryMonster> CreateScaryMonster(shared_ptr<World> world, const int intialstate = STATE_IDLE) { auto ent = LoadModel<ScaryMonster>(world, "Models/Characters/Monsters/ScaryMonster.mdl"); ent->state = intialstate; return ent; } Then in the flowgraph, you can pre-populate the nodes with entity functions so the end user always has access to those commands. Of course, that's another conversation. My only concern is you breaking people's existing projects unless you plan to have ECS as a legacy feature for a few versions.

I'm in favor of this! That would mean each component carries all functionality from the actual class itself. One thing I do notice is that Components tend to be used on fix amount of entities. For example, you're not going to apply the Monster's component to a sprite. If you can derive Monster from the model class, and change the mesh. This is what Quake and Source does. I'm all for this! The virtual nodes things would be interesting, but the flowgraph gets very cluttered. very fast. Adding imaginary nodes might just make it more confusing. I'm still a big fan of Hammer's I/O system. I actually think it's neater than messy nodes crossing over each other. I could set any entity's property the same and add delays to the output without a special component. Separation of functionality! Look how nice this is presented. This can be recreated with separators, but I like how I know this section is just for the teleport system. I will say this, if you're going to make a decision, do it now. I would not be a fan of the idea of you just cutting multiple components and leaving us hanging with planned features that multiple components can solve in the current build.

During the development of the engine, I've been experimenting with the best way to develop and create things using the current design decisions. I first tried the multiple components and having them check the entity for corresponding components and that ended up to be a confusing mess. How was I supposed to keep track of what components leveraged each other without some sort of internal documentation? I went back to mono components using inheritance as I normally use C++. However, there has been many opportunities where I have added multiple components to an entity. Here are the senerios when I find myself doing so: When an entity needs to do 2 separate actions (for example: Spin and change color) Instead of writing a special component that spins and changes it's color, I can reuse 2 components to do so. I don't feel like I'm recoding something because the functionality is a little different and the two components don't have to acknowledge each other. This is important in Lua since there's no inheritance. Logic components. Instead of having multiple Pivots with Relays and Timers, I can reduce the count by organizing functionality with less clutter in the map. VR. I made a VR player, and I have the teleportation code in a separate component. This is really nice because the Hmd can always be returned with GetHmd so each piece of functionality can be compartmentalized. Overall, I like adding multiple components to entities but I avoid coding any checks to see if another component is attached. I would leave this feature alone, but not advertise it or encourage it. If you believe that supporting multiple components may prevent you from adding new features to the flowgraph system or prevent support for prefabs supporting flowgraph information, then we'd need to really consider. And if we're keeping multiple components for now, it'll be a bad idea to drop it after the 5.0 release.