Detis Engine load times... Blink and you'll miss it.

Apparently, there’s a real phenomenon where the modern average user associates long loading screens with "higher quality" software... Guess I'll have to add a fake progress bar to slow the startup down just to convince people it's actually good.

The actual potential of modern software

This speed should become mainstream for software

I was literally just thinking about that:

could you give a technical overview on how you made it so fast?

Planning a few deep-dive posts once the alpha is locked in. Basically, there's zero import pipeline. It reads raw data straight from .glb/.gltf files and a slightly customized .dds texture format.

@brockliddicoat interesting , how long does it take to load the Sponza Scene ? , right now im working on exactly this ( speeding up load time ) :

@brockliddicoat Took me a while to find, I had to recover the map from a previous build! But yeah, similar speed. Take a look at how the fastgltf library is doing it. Awesome UI you have there btw 👏

@brockliddicoat Just to clarify, the engine isn't preloading data on startup. Only loads the data it needs for each map on demand, so what you see is the true load time from scratch.

The startup speed is genuinely impressive. Does the engine currently have systems for dependency tracking, asset validation, automated optimization, hot reloading, and platform-specific preprocessing, or are those not implemented yet?

That’s a lot to break down! Let's see: First off, I should note that Detis is a hyper-focused toolset built specifically for fast iteration with solo and small-team devs in mind, targeting PC. Hot reloading is fully supported for everything except mesh files, which is planned for later. Then again, restarting takes a fraction of a second anyway. Dependency tracking and validation are handled lightweight at launch. If an asset is wrong or missing, the engine drops a clear visual placeholder (if required), prints the errors into a clean log for the user, and keeps running so your workflow doesn't freeze. It intentionally skips standard import pipelines entirely. It feeds on raw data directly from .glb files and textures in a slightly modified .dds format. This is both to aid speed and to make modding as accessible as possible for the end user. It is primarily a toolset I built for myself to speed up my own projects and escape the insanity of today's general-purpose engine bloat. So it isn't aiming at 100-person AAA studios, and it's not trying to be another general-purpose engine. Quite the contrary. Good questions btw!

If you eventually find a way to implement more of that production side tooling while keeping the startup and iteration speed this stable, I think it could give Detis a much stronger path toward becoming a genuinely high end engine one day, maybe even reaching AAA level capability in some areas. Finding a good engine as an indie developer is honestly pretty difficult right now, especially if you want something that isn't either extremely limited or overloaded with systems you don't need. And it feels like there's a lot of room for it to grow. I'd definitely like to see what it turns into as you keep developing it.

Thanks, appreciate it! But honestly, Godot, Unity, and UE are already doing that job. There's no need for another engine in that space. You'd also be surprised by how many AAA studios actually use much simpler in-house tech behind closed doors. But again, not this toolset's target audience.

Jesus christ

Σφαίρα πάει, ωραίος ρε Γιαννάρα...

It looks like crysis 2007 NGL, what graphics API does it use? OpenGL?

Impressive. What is the key? I assume you load pretty much everything as just data chunks and fix up offsets? Are these loose files are an archive so you block load large chunks?

Thank you! No wizardry going on to be honest. Intentionally keeping things stupid simple, and that pays back in speed. It's a small, hyper-focused engine, so not trying to be everything for everyone makes that easy. First off, I skipped standard import pipelines entirely. Always loved how old Gamebryo handled assets, keeping everything super open and accessible for end-user modding (can always pack if things get large later). Second, it's built for manually authored, non-streaming worlds. Maps just hold asset addresses, unique meshes are instanced, and the runtime feeds directly on raw .glb and pre-baked .dds files. Also core shaders are packed into a single file at startup. So yeah, just a strict contract on what its food must contain, no hand-holding complexity.

Thanks for the info. Keep posting updates, love seeing the progress.

That's really fast, nice one! A full recompile and launch of my engine + game is around 4 seconds currently. If I had planned a better pipeline around DDS I could make that ~2 seconds. It's in my todo list for my next engine iteration :)

We underestimate how fast computers are really these days because of very unperformant software everywhere

Unity: That's me in the dream

Is this better than Unreal? Should I switch?

And it looks nice and pretty as well. I think the main difference Devs and studios should make is keep toolsets away from game engine and door stuff animation/3D assets creations in it just use dedicated softwares.

Nice!

How long is the source compile?

Full engine compile from scratch is under 60s currently.

Thats very cool, what takes longest? C++, Vendor libs?

what about open the project with 17k files, 4k folders, and 4GB woth of assets ?

Haven't tested 17k loose files on a single map, but at that scale means you'd want to pack those into larger archives anyway. In that case 4Gb is chewed within a couple of seconds. Core shaders already load packed, and I can extend that to other assets down the line, if needed. That said, 17k assets per map is well outside current scope. The engine was built as a fast to use tool for small-to-medium indie productions, focusing on keeping things simple and manageable rather than fighting the big guys who already excel in bloat management.

would love it if you can share how did you achieve this