For sure, Sid's example is very helpful with that. And I think you're right that file_load is likely to be thread safe, but I'd like to be sure. Using file_load would do away with the mallocs, fopen, fread, fclose, rewind, and anything else that needs stdio, making an own implementation even more trivial

With "inspiration" from Sid's example, this is small enough that it's the kind of thing I'd like to write my own implementation for use in my own future projects.

I guess now that it's the weekend we won't hear more from jcl on this matter until Monday, if ever. My second request was never addressed, and I'd really like to know more about the thread-safety of GS functions -- this'd be very useful to have in the manual. Maybe it'd be even easier to just list the functions that aren't thread-safe, but I don't know.

Jibb

Most engine functions are not thread safe. As a rule of thumb, when an engine function modifies or accesses an engine or level object, it's not thread safe. Functions that play videos and handle file and memory access are thread safe.

Okay, thanks for the info. As it turns out, we can't get the background loading working. There are no errors or crashes, and the entity is created well after the function is first called (depending on how big it is), but there's still a very noticeable pause with large files -- seemingly no different than if we'd just called ent_create without any file loading and buffering first.

Is ent_create doing much behind-the-scenes stuff the first time an entity is created? Can we please have preloading functions so we can prepare an entity without interrupting the game, and then create it (perhaps in a similar way to my example in my first post)? This seems to be an area that A8 is really behind on.

And any comment on my request regarding session_ functions without requiring level_load?

Thanks,

Jibb

Preloading files will not magically remove all the ent_create time. The engine loads files very fast and buffers them in a cache anyway, so you won't gain this much time with a preload process.

Creating entities is a very different process than file loading. Much time is required for DirectX processes, such as building a mesh on the 3D card, building textures, creating the lighting, and creating a collision mesh. This can be sped up a lot by a clever concept that creates entities in several steps.

When you create entities first with INVISIBLE,NOLIGHT,and PASSABLE flags and have collision_mode at 0 at creation time, you'll see that creation is much faster. When you need the entity later, just reset the flags.

You can see such a concept in the infinite terrain demo that creates ten thousands of entities in a second.

Exactly. That's exactly why we can't do this ourselves, and why this discussion is still going on in the Future forum.Yes, because they're all very simple. The number of the same entity is almost inconsequential. In my tests I used a cube with an enormous texture -- in this specific case it's only the texture that causes the delay, and that'll often be the case as these days one entity will often have many skins. If I change my test to ent_create the same model again after the first one is created, there's no delay for the second entity.

It's this first-time-creating, behind-the-scenes stuff that we can't do anything about that could surely be done in the background with an engine function.

Even if "pre-loading" isn't going to do what we want, I thought the intention of this request was made very clear, if not from my first post then from subsequent responses from everyone else.

Jibb

What we're trying to explain to you is that there is no "behind the scenes stuff". All preload features you can have are already there. You're probably the 500th user who asks on the Future forum for a solution to overcome load delays, and over the years we implemented many functions and methods for that. Just look for "preload" in the manual.

Only thing you need to understand is that at some time, textures must be loaded and meshes must be created. You can not prevent this, you can only control when it happens.

Textures don't cause a delay when you create your cube. They only cause a delay when the cube either becomes visible in the level, or when it is preloaded. So it's totally up to you at which time you want this delay. The delay itself can not be charmed away by a 3D engine. Mesh creation and texture loading to the 3D card takes time and happens deep inside the DirectX driver and on your hardware.

One would think you'd be better at answering the question by now, then. One would also think a search for "ent_create" or "load" in the Future forum would yield examples.
This is obvious, and the least relevant piece of information in a thread that is breaking world records for number of mentions of "thread". No one cares how slow an algorithm or function is if it can be threaded. So it's about time you said it can't be.This is your first such mention. Seriously, whenever a request is made for something you can do nothing about, say so. Far out. How are we meant to take your answers seriously if you're generally vague, dismissive, or ignoring requests that still haven't been addressed (multiplayer). I understand that the difference between an engine programmer and an engine user means the intention of this discussion wasn't clear to you until a few posts back, but once you get that understanding it makes sense to address the question with "This is done in DirectX and cannot be threaded" instead of losing your cool. From the get go we've said we either want to thread this ourselves or for you to thread it.

Given that it can't be done, I'm sure we'll figure out for ourselves how so many games with huge assets load them without delay.

Jibb

EDIT: Since you edited your cool back into your post, please re-read mine with a at the end of every sentence, and ignore any suggestion that I might be frustrated.

EDIT2: By the way, that's not sarcastic. I really am all chill now having read version 2.0 of your post