Josh

Besides the obvious driver update, it is also possible to enable Vulkan debugging by adding the validation layer in Ultra.json, but you don't need to do this unless you are just curious about it. I think I know what my next GPU will be.

Yeah, if I randomize the read position the delays go from 40 milliseconds to 4 seconds. The lesson here is that big data processing can only be done on an SSD, not because of the IO speed necessarily but because of the seek speed.

Okay, this simple test does not produce any strange results. Maybe this is happening because I am reading from one big file and writing to another big file, on a mechanical drive: #include "UltraEngine.h" using namespace UltraEngine; #define STEP 5 int main(int argc, const char* argv[]) { String path = "D:/test.tmp"; shared_ptr<Stream> stream; uint64_t tm; int count = 0; Print("----------\nWrite test\n----------"); stream = WriteFile(path); tm = Millisecs(); count = 0; while (true) { stream->WriteDouble(0); count++; if (count == 100000) { stream->Flush(); count = 0; auto now = Millisecs(); Print("W: " + String(now - tm)); tm = now; } if (stream->GetSize() > 1024ull * 1024ull * 1024ull * 6ull) break;// stop after 6.0 GB } stream->Close(); Print("----------\nRead test\n----------"); stream = ReadFile(path); tm = Millisecs(); count = 0; while (not stream->Eof()) { stream->ReadDouble(); count++; if (count == 100000) { stream->Flush(); count = 0; auto now = Millisecs(); Print("R: " + String(now - tm)); tm = now; } } stream->Close(); return 0; }

I'm already using _fseeki64 and _ftelli64 on Windows.

fwrite can correctly write very large files. I wrote a single 126 GB file with it. However, after a the first few seconds the calls to fssek start "hanging". Writing 1000 integers went from taking 40 milliseconds to 16 seconds. I'm just writing one integer at a time. I can't find any mention of this behavior online anywhere. Is this a know thing?

Updated 1.0.1 Fixed memory leak triggered by Texture::SetPixels and other GPU data transfers

Okay, the cause was I had a memory pool system, but I stopped allocating buffers from the mempool and just started creating them instead, but I was still recycling old buffers back into the pool, so the size grew and grew. I question whether a memory pool is really beneficial or needed on a modern OS, so I am just going to disable these completely.

Okay, here is my test program. Of course, you can also see the memory usage if you have the VS diagnostics interface open: #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, 720, displays[0], WINDOW_CENTER | WINDOW_TITLEBAR); //Create a world auto world = CreateWorld(); //Create a framebuffer auto framebuffer = CreateFramebuffer(window); //Create a camera auto camera = CreateCamera(world); camera->SetClearColor(0.125); camera->SetFov(70); camera->SetPosition(0, 0, -3); auto texture = CreateTexture(TEXTURE_2D, 512, 512); auto pixmap = CreatePixmap(512, 512); uint64_t mem = 0; //Main loop while (window->Closed() == false and window->KeyDown(KEY_ESCAPE) == false) { auto mem2 = GetMemoryUsage(); if (mem != mem2) { mem = mem2; Print(mem); } texture->SetPixels(pixmap); world->Update(); world->Render(framebuffer); } return 0; }

The stats on the free Ultra App Kit indicate something strange: Ultra App Kit, free licenses granted: 15046 First-time downloads: 171 This means that 98.8% of the activity is "fake".

Yes, that is correct.

It might not be, but I will check. I have seen memory rise steadily for about ten seconds before it levels off. I think the Vulkan memory allocator just creates new buffers until some threahold is reached and it levels off. But I will test this and find out for sure.

This plugin is now updated. You need to sync your project to get the new plugin file.

Updated 1.0.1 Fixed JP2 image saving Fixed KTX2 image saving Sync your project to get the new plugins.

You can renew before the expiration date and it will add that time to your existing days left. In other words, there is no penalty for renewing early or for pre-paying for a block of time. If you have a payment method stored (credit card or account credit) then that will be billed automatically at your selected renewal rate. You can also disable automatic renewals at any time and it won't effect your current time left.

Okay, it just needs this code in the plugin: void* SaveTexture(Context* context, wchar_t* extension, const int type, const int width, const int height, const int format, void** mipchain, int* sizechain, const int mipcount, const int layers, uint64_t& returnsize, int flags) { std::wstring ext = extension; if (ext != L"ktx2") return NULL; Although I still want to test and make sure KTX saving is working...

Oh, you are correct. 😱 I don't know why it would even be trying to save that...

I've also considered Clamp, Min, Max, MoveTowards, Mix, Ceil, and Floor, for Vec2, Vec3, and Vec4. That's the reason I haven't done any of them yet.

See section 3.1 about the file header: https://registry.khronos.org/KTX/specs/2.0/ktxspec.v2.html Does this code look right to you? void* LoadTexture(Context* context, void* data, uint64_t size, wchar_t* cpath, uint64_t& size_out) { //Check file header if (size < 12) return NULL; char FileIdentifier[12] = { '«', 'K', 'T', 'X', ' ', '2', '0', '»', '\r', '\n', '\x1A', '\n' }; if (strcmp((char*)data, &FileIdentifier[0]) != 0) return NULL;

Okay, it looks like the plugin doesn't do any pre-checking of the file and the KTX lib isn't set up to account for that: //Texture load function void* LoadTexture(Context* context, void* data, uint64_t size, wchar_t* cpath, uint64_t& size_out) { ktx_uint64_t offset = 0; ktx_uint8_t* image = NULL; ktx_uint32_t level, layer, faceSlice; KTX_error_code result = ktxTexture2_CreateFromMemory((const ktx_uint8_t*)data, size, KTX_TEXTURE_CREATE_LOAD_IMAGE_DATA_BIT, &context->ktx); if (result != KTX_error_code::KTX_SUCCESS) return NULL;

Updated 1.0.1 Added support for TIFF saving in FreeImage plugin Added support for save/load JPEG2000 (JP2) format in FreeImage plugin

It will work fine. The reason Leadwerks did not allow reading streams from zip files is because they were encrypted with a special algorithm. If I allowed the engine to read a stream from one of those archives, then it could load any game's contents. The system was never cracked. In Ultra since you assign the password yourself, it's fine to read streams from zips. I don't have a solution for how Lua scripts could encrypt zip files because the password would have to be stored in a script, which makes password protection pointless. I'm not going to worry about that too much right now though.

Okay, this is not implemented yet, and not documented, although you can clearly see what I had in mind. I've been hesitating on this because ZIP files don't actually store a folder hierarchy, they just store a flat list of file paths. So the folder structure would have to be calculated at the time the package is loaded. I wasn't 100% sure this is how I wanted it to work, but it's probably for the best to do it that way.

Without looking at it, I am guessing box2 has a node at the top of the hierarchy with no geometry, so it's just a point. You can get the recursive bounds and that will include all the children.

Yeah, that blue tint is probably the environment map. Make sure you are setting the diffuse and specular maps. Here are a few sets you can try: https://github.com/UltraEngine/Assets/tree/main/Materials/Environment

I would try to use the PBR approach because it looks good. Your environment maps or probes are very important for this.