Josh

Okay, I found that GetMemoryUsage() in debug builds is extremely slow, taking almost 200 milliseconds. I found this just by hitting pause on the debugger and seeing which function is stopped on, since if something takes a long time it is statistically more likely to be hit. That's your primary problem.

@Dreikblack I am running your game now and there is definitely something wrong. The framerate is very inconsistent and often very low, but I don't know why yet. Is there any built-in way to display the rendering statistics?

Easy fix, thanks for reporting this.

I am running the default start.ultra map and it looks like what I would expect. The culling time is in the titlebar. (Culling is asynchronous and does not have to be performed each frame, so 17 milliseconds does not mean 60 FPS.) Do you have a scene I can test that shows the problem more clearly?

I updated the editor with a fix that will relieve a lot of overhead. Instead of doing a full world update it just updates particles.

I did not make any major changes to these systems, so the solution is probably very simple.

The only part that really needs to be done in C++ (for speed) is the file scanning. In Leadwerks, this starts with scene files, then checks scene files and find materials and models, then checks those models and finds more material files, then checks the material files and finds texture files. A function could be added in the editor API, something like ScanProjectFiles(), and that could return an array of file names. CreatePackage, Package:AddFile, and Package:Close are exposed right now in the Lua API, although I have not tested these commands extensively.

Thank you everyone and especially @Yue for your help tracking this one down. That was a tricky one and I am glad to mark this solved.

What about C++?

@Yue The whole engine is updated now. Please let me know the results.

0.9.7 Full build is uploaded, no longer using a static lib for libzip.

I think the safest way around this would be to put files in multiple zip archives with a fixed size limit, like data1.zip, data2.xip, etc., with a user-adjustable size limit. If we make a spanned archive, it would probably have the same problem as a single archive, where all the bytes change and the whole thing has to be uploaded.

Okay, I will do a full build this way now.

This is the interface for the standalone publishing option for Leadwerks: We have not talked in much detail about what features the Ultra publishing system should support. I plan to use encrypted zip files, and some people have requested splitting the zip archives up into multiple segments, or zipping each folder up separately. What are your ideas?

So is the editor working correctly? Can you browse through the contents of the zip file and load files from inside it?

In the current build, libzip was compiled into the engine from source, not as a static lib. @Yue Please let me know the result when you use the editor with a project that contains a zip file.

0.9.7 Libzip is source is now compiled into engine instead of using an external static lib. Only the editor is updated at this time.

Okay, those two functions are the exact same code. I suspect there is some preprocessor define that doesn't match in the main project and in the static lib. I will try compiling libzip straight into the Ultra source code instead of as a separate static lib.

Please try this: #include "UltraEngine.h" using namespace UltraEngine; ZIP_EXTERN zip_int64_t zip_source_make_command_bitmap2(zip_source_cmd_t cmd0, ...) { zip_int64_t bitmap; va_list ap; bitmap = ZIP_SOURCE_MAKE_COMMAND_BITMASK(cmd0); va_start(ap, cmd0); for (;;) { int cmd = va_arg(ap, int); if (cmd < 0) { break; } bitmap |= ZIP_SOURCE_MAKE_COMMAND_BITMASK(cmd); } va_end(ap); return bitmap; } int main(int argc, const char* argv[]) { /*WString path = GetPath(PATH_DESKTOP) + "/ultra.zip"; int errorp = 0; auto zipper = zip_open(path.c_str(), ZIP_RDONLY, &errorp); if (not zipper) { Print("Error: Failed to load zip file. Error " + String(errorp)); } else { Print("OK"); }*/ Print("1"); zip_source_make_command_bitmap2(ZIP_SOURCE_SUPPORTS, ZIP_SOURCE_TELL, ZIP_SOURCE_SUPPORTS_REOPEN, -1); Print("2"); zip_source_make_command_bitmap(ZIP_SOURCE_SUPPORTS, ZIP_SOURCE_TELL, ZIP_SOURCE_SUPPORTS_REOPEN, -1); Print("3"); return 0; }

Let's get lower level with this. Please copy your ultra.zip file to your desktop and run this code: #include "UltraEngine.h" using namespace UltraEngine; int main(int argc, const char* argv[]) { WString path = GetPath(PATH_DESKTOP) + "/ultra.zip"; int errorp = 0; auto zipper = zip_open(path.c_str(), ZIP_RDONLY, &errorp); if (not zipper) { Print("Error: Failed to load zip file. Error " + String(errorp)); } else { Print("OK"); } return 0; }

Strange. I just uploaded a new update that removes the folder part of the path and uses ChangeDir() before loading the package. Only the editor is updated.

What is the full file path to the project you are testing this in?

You should try first without encryption, otherwise you are testing multiple things at the same time.

0.9.7 Added "velocity" particle view mode, good for sparks and ricochets. Added adjustable width and height for particles.