StOneDOes

When it comes to rendering and interacting with different menus, can I assume that the correct way to do this is to have multiple Interface classes, where each Interface would represent a different menu. I'm assuming that you would not want to have every single widget on the same interface, otherwise it is probably going to be inefficient such that every widget would need to be iterated over by its parent each frame to determine whether it needs to be rendered or not. Presumably, if you hide the parent widget (ideally the root widget in this case), the widget would essentially have nothing to do when checked by the engine, and all its child widgets would be implicitly hidden also. Is this an accurate analysis?

Can you please post your PC specs.

Just to be clear, are both of these items things that need to be done in the engine?

Sure, but I'm suggesting that perhaps camera zoom should be taken into account? If I'm 100 units away from an object, and my camera zoom is x2, I am hypothetically viewing from 50 units away? If this object has an LOD distance of 60 units, shouldn't the object appear in full detail? Because imagine if I then have a scope that is something like x16 zoom - its not going to look great is it? I can't actually recall if this is done in other games engines, I really just thought about this now.

Sounds good. Do you have any ideas about the model LOD level when zoomed? Am I still just not close enough?

I've found a couple of camera zoom issues. (AMD GPU) 1) After unzooming, I have some kind of shadow artifact that looks like it could be the back of one of the cascades. 2) After just having some fun with the new mesh reducer LOD tool, it appears that LOD distances are not respected while camera zoomed. Visible in video, many models have LOD variations, but just focus on the hedges. After taking the video, I thought that maybe I'm not zoomed enough or maybe still not close enough. Might need to double check this one. See video:

I mentioned BF4 just as an example of me saying, this is how much stuff is in that world/map and it doesn't take long, and its a very nonstatic / alive world. I don't think it would be a stretch to say that most modern game engines would use multiple threads for resource loading, or at least provide a means to do so. One other suggestion that I have is, something that would hopefully be rather easy; If you were to provide some kind of function eg. Entity::CreateModelUnmanaged(). It takes a path to the file on disk loads it, and simply returns the new model, and does not touch your system or resource manager whatsoever. Then I can run this on multiple threads, store a whole collection of models on my end, and then when I'm done, on the main thread, I use some other function like World::ManageMyModel() which takes the shared pointer that I received earlier, and basically copies it into your resource manager, just like the existing CreateModel() function would do. That way I handle all the thread safety, and the engine remains hypothetically untouched? Admittedly, the longest load times are caused by weapons that are not actually in the map (or at least not yet), rather given to the player, so something like this would be super useful to do say on game startup. As for how long release mode takes; I'll get back to you when I finish writing the release mode cmakelists ... I've been putting that off for a while

Right, so what would be the chances of you putting this on the to-do list? Because this is a big concern for me; Right now I have (I would say not a large amount) of different resources loaded just after the map has been loaded (I do have 2 high quality weapons), and it is taken almost 35 seconds in debug mode. I haven't written my cmakelists for release mode yet so I don't have a metric on that, but given that the map would be not even 10% done; it is a bit of a worry, and I haven't added any LODs to the existing models that I have (which could cause longer load times). In Battlefield 4, it takes me less than 20 seconds to join a full server on a large conquest map. Now I know its not fair to compare a work in progress engine to arguably one of (if not) the best game engines ever made, but I'm just trying to put loading time into perspective. And I don't think it would be difficult to do, although obviously I can't see your implementation. I am more than happy to provide an efficient thread pool for this, but I can't handle the thread saftey side. Just to note I have a AMD Ryzen 9 3900X processor, and wouldn't expect people to require something newer than this to play my game.

Can we please get some optional parameters or overloads for this? It would be ideal if I could provide say a 3D point and a distance to say; I want a random point that is within N distance to the given point. By trying to get what I need at the moment would be very inefficient to say use a while loop and see if the result was within the confines that I wanted.

Sorry my mistake I left a critical part out - hold the right mouse button down after the second click and it remains saying OUT for me, as though it doesn't think I'm still holding the button down.

So we could use this same logic, but instead of just using a single thread; a thread pool. While we know we are in loading state, we simply just do not do anything involving resources, otherwise we would probably expect issues. Is your under-the-hood resource manager thread safe? If it is I can test this myself.

After performing a double click, at not necessarily very fast intervals, the Window::MouseDown() function does no longer detect the mouse properly. I tested with 2 different mouses to be sure. Minimum required to reproduce: EDIT: I left a critical part out - hold the right mouse button down after the second click and it remains saying OUT for me, as though it doesn't think I'm still holding the button down. #include "UltraEngine.h" using namespace UltraEngine; int main(int argc, const char* argv[]) { //Get the displays auto displays = GetDisplays(); //Create a window auto window = CreateWindow("Ultra Engine", 0, 0, 1280 * displays[0]->scale, 720 * displays[0]->scale, displays[0], WINDOW_CENTER | WINDOW_TITLEBAR); //Main loop while (window->Closed() == false and window->KeyDown(KEY_ESCAPE) == false) { std::cout << ( window->MouseDown( MOUSE_RIGHT ) || window->MouseHit( MOUSE_RIGHT ) ? "IN" : "OUT" ) << std::endl; } return 0; }

Right, but if I were to click on the window while this loading was taking place, the window would go grey and say the program is unresponsive, wouldn't it?

Just FYI, I do not have this problem, I have a range of post effects and a UI camera showing just fine. However - when I built my game library into a DLL, which was responsible for creating the 3D camera, I did see this; but was unaware that this is the cause. When I instead began using a static library, interestingly enough it resolved the problem. EDIT: Sorry, I didn't realise this was Leadwerks. I'm referring to Ultra.

I'm not sure if I misunderstand what you mean "like that" - there's several resources that are needed to be loaded on startup that simply wouldn't do during gameplay or you would see clear hiccups in play, for example when a player picks up a weapon for the first time. And naturally, you load all resources for a map when you want to enter that map, but you don't want the main thread locked up, and game unresponsive during that time. The hard drive is not the bottleneck, its the fact that the main thread is loading everything. Ideally, the main thread will sit idly by, showing some kind of loading animation, while the thread pool is loading all required resources. You could provide a non-fool-proof mechanism under which the developer provides the start point and end point essentially for loading, in which time it's not safe to render/play those given resource, so you can avoid mutex locks all over the place in your resource wrapper classes.

Can we please have a way for multithreaded resource loading eg. models, textures, sounds. I think it will get quite slow when stacking up a lot of resources to be loaded on the main thread, not to mention that you can't render anything while this is occurring. Ideally, a thread pool class would be useful for this.

So would you suggest just calling World::Update() on each server frame, as you do on the game client loop?

Ok thanks for the repply, but how is it running in its own thread if I'm calling the Update() function? I guess this begs the question, of what happens if I do not call World::Update()? I'm not sure that this will be suitable for a game server, unless I don't understand correctly. I need to be able to simulate/update the world on command, and essentially pause simulation when I want, so that I can rewind play for things like lag compensation. If objects are still being moved around the world while I'm doing hit calculating then this would end badly. I hope I'm just misunderstanding here. Unless @Josh can you please provide a breakdown of how threads are handling things in the breakdown, thanks

I'm not sure I understand the documentation for this function World::Update(). The first param is: frequency number of updates per second I would have thought that this would not be necessary, rather you would just call this function on each game frame? Think of a game server where you are essentially simulating the world, and likely capping the FPS to a suitable amount - lets say 100 frames per second. Do I call world->Update( 100 ) in some arbitrary place, or do I just called world->Update() on each frame, which is already capped out at 100 frames per second by some thread sleeping code that already ran in the given iteration of the game loop? What happens if I call world->Update( 100 ) on each game loop iteration?

Will we also be able to customize the quality/size (and distance) of each cascade, at some point in time?

Ok I exported it as a JPEG by accident. Made it a PNG and it works. Awesome!

Josh, can you please provide some more info on how this can be done? I need this too. I did try doing this in GIMP with a alpha channel and mask, then played around with the material settings but couldn't get it to work.

I think it would be useful to allow users with a certain number of posts or rep to add notes to the bottom of pages in the documentation section, in an effort to help keep things up to date or to point out any quirks that are found. Just a thought.

You should also post the output from the debug window, assuming that it popped up? And perhaps be more specific about what project you built and run eg. was it a sample from the documentation page (and if not have you tried running something from there) ?

Have you got a navmesh with debugging turned on? I noticed that gives quite a hit to your performance.