Josh

I am going to pull this out of 0.9.7 for two reasons: It blocks the event loop, which is okay for small projects but not so good for big ones. There is still a question of how the password can be stored securely in the executable. The first issue is not as serious, but the second could cause problems if people are not aware of it. The current version is uploaded in the first post (Update 3).

I could not reply before the meeting, but now I can give you some more details. If the World::Render method is called and the rendering thread has not performed at least one round trip yet, then the main thread will pause. The reason for this is that loading a new scene can cause a lot of objects to pile up, and the first render after that will be very slow, because a ton of new data is being passed into memory. This causes the rendering thread to run at a slow speed, that first frame. (At one point, I actually had some rendering calls being made in a callback while the scene was loading. It was funny to see the scene come into view piece-by-piece.) The rendering thread already performs interpolation, which is how it is able to rendering at a framerate independent from the game update rate. If the main thread did not pause when it detected the rendering thread was loading content, it would start piling up a lot of extra rendering commands. Let's say the rendering thread paused for one second because it was loading a lot of textures into memory. During the next render, there would be 60 frames of rendering commands piled up that would all have to be executed. This would slow make the next frame slow, and more extra commands would pile up. This could cause the rendering thread to be very slow for an extended period of time, or it could cause it to stop responding completely, if data was being sent faster than it could be processed. Now if the framerate drops below the screen refresh rate for some other reason, either due to some inefficiency that needs to be ironed out, or due to just hitting the limits of the hardware, that is a situation we don't currently have a good solution for. The best thing to do is avoid it, and Ultra usually does a good job of preventing that from happening, but I understand it cannot always be guaranteed and we should find a way of dealing with it without making things too complicated. Having multiple threads makes the engine very powerful because you have an amount of processing time for your game logic, which is almost impossible to max out. However, the problem of "overloading" the rendering thread is one issue that can arise, and it needs to be dealt with carefully.

Join us in 2 hours for a live chat session! This week we will review the new game packaging system, the launch of version 0.9.7, really good object-holding physics, optimization ideas, and a proof of concent for the UltraGL API! https://discord.gg/aRf4AveG?event=1274432337450635446

Are some of the icons not appearing on top of those transparent backgrounds? I can probably make it a little smarter. What else should I be testing? Just the game in general, or something more specific?

It's already frame-independent, but I added a World:GetSpeed() method which will return a weighting value for use when a frequency other than 60 is passed to World:Update.

I added the update that makes your GUI example much faster.

0.9.7 Disabled z-sorting in the GUI system. This will produce much faster rendering performance when icons are used, but it could cause rendering errors if you have multiple overlapping transparent widget blocks, or icons on top of transparent panels, for example. Please let me know if there are any problems. Added World::GetSpeed method.

The GUI example above is actually pretty impressive that it runs so well. It's rendering 440 unique objects, and half of them are alpha-blended. Widget blocks do not use any type of instancing, although the draw calls are batched. Each block is a unique mesh. I think that situation could probably be optimized more if I disabled z-sorting on the transparent blocks. Currently transparency and z-sorting are always tied together, but that is one situation where you would not want the extra overhead of z-sorting and the separate draw calls that entails. Let's see with a GEForce 1080: Nothing: 4200 With z-sorting: 1177 Z-sort disabled: 3800 I think this will be okay, because with GUIs you don't have transparency on top of transparency, normally. If you have something like an icon on a semi transparent panel, that will cause a problem if z-sorting is not active.

I don't know if differences like that are very meaningful. When you measure FPS, the difference between lower numbers is much more significant than the difference between high numbers. If you convert that to time elapsed it becomes more clear. The first number means 0.14 milliseconds per frame and the second means 0.5 milliseconds, so we are talking a different of 0.36 milliseconds. Besides the benchmarks I made, is there any specific code I should focus on testing?

@Dreikblack Now that we have solved the primary issue, I am interested in hearing your assessment of the situation now. Is there something in particular I should investigate?

0.9.7 Finished the packaging / encryption system. For C++ projects, a new password is generated and stored in both the project JSON file and the main.cpp source code file. For Lua projects, a Package:SetDefaultPassword method is used to set a secret password the Lua interpreter knows. Package::Restrict() (only available in C++) can be used to prevent Lua scripts from calling ReadFile or ExtractFile to directly read the contents of a password-protected file. Assets that are loaded from a password-protected zip file cannot be saved. This could be hacked in C++, but in order to read the file in the first place you would have to have the archive password, so it doesn't matter. New commands: Package::CountFiles Package::GetFileName Package::Get/SetComment Package::Get/SetFileComment GetMemoryUsage() now has an optional parameter to use the more precise method in debug builds. @Dreikblack LoadScene, LoadPrefab, and Scene::Save now accept an "extra" parameter that can pass any object to the component load or save method. Component::Save and Component::Load now have an extra parameter that must be added, or they will not get called when the scene is loaded: virtual bool Load(table& properties, shared_ptr<Stream> binstream, shared_ptr<Map> scene, const LoadFlags flags, shared_ptr<Object> extra); virtual bool Save(table& properties, shared_ptr<Stream> binstream, shared_ptr<Map> scene, const SaveFlags flags, shared_ptr<Object> extra);

This has been added to the installation.

0.9.7 Publishing system has been added and should work. Model files have to be resaved to output a list of used materials in the metadata. Password must be manually entered in both the interface and your main.cpp file. Project password is not saved between sessions. Encryption for Lua projects is not yet supported.

The updated version above actually scans scene files and finds materials, models, and textures, then scans material and glTF files and finds more textures (those formats are all JSON-based so it's pretty easy to step through them looking for file paths). Currently scanning of our native model file format is not performed because the model format is a bit complicated to step through. I need to think about the solution to this. You will want to add something like this in your main.cpp file: //Load packages const WString password = "xxxxxxxxxxx"; std::vector<std::shared_ptr<Package> > packages; auto dir = LoadDir(""); for (auto file : dir) { if (ExtractExt(file).Lower() == "zip") { auto pak = LoadPackage(file); if (pak) { pak->SetPassword(password); packages.push_back(pak); } } }

Yeah, that is the idea. It's a little tricky because Ultra can have extended support for new file formats the publishing system doesn't know how to handle. I am trying to implement the whole scanning system in Lua now so that it can be modified if needed...

First pass at this:

This extension adds a self-contained game publishing system. Currently the extension adds all project files into a zip archive named "data.zip", with optional encryption. It's not finished, but I wanted to get it out there as quickly as possible so people can see how it works and how they might want to customize it. Update 3: Publisher.lua Update 2: Publisher.lua Original: Publisher.lua Ultra 0.9.7 beta is required.

Hmmmm, which should it be called? We have WString::ToUtf8String().

Added these...

I think we probably need a flag or save command that saves the state of objects without resaving the brush and other data. It seems like saving a scene is not exactly like saving a scene...

In that case, the children should probably not be children. You can select another entity in the scene in a component field: { "component": { "properties": [ { "name": "entityvalue", "label": "Entity", "value": null } ] } } This will give you a dialog that can select any entity in the scene:

update is up now.

I don't understand why, but removing a small bit of code that was not needed anyways fixed the problem: if (mtl.textureHandle[TEXTURE_METALLICROUGHNESS] != uvec2(0)) { vec4 mrsamp = texture(sampler2D(mtl.textureHandle[TEXTURE_METALLICROUGHNESS]), decalcoords); materialInfo.perceptualRoughness = materialInfo.perceptualRoughness * (1.0f - color.a) + mrsamp.y * color.a; materialInfo.metallic = materialInfo.metallic * (1.0f - color.a) + mrsamp.z * color.a; }

I think there is probably an error in the shader that is causing a texture read from a sampler from an invalid bindless pointer handle. That's what it means if you see a shader that causes all rendering to stop responding...

I discovered that GetMemoryUsage is extremely slow in debug builds, taking almost 200 milliseconds sometimes. If you are using that command, please adjust as necessary.