Parallel Briefing and Mission Loading

[STiFU]

As I found these thoughts by Grayman very interesting, I would like to discuss this topic a little further, without ruining Bikerdude's thread.

 

For reference, here are the respective posts:

Hmmm. Thinking out loud here ...

 

I wonder if the map load and briefing text can be done in parallel?

 

The map's loaded twice: once to put together the difficulty/objectives and shop screens, and again after that to spawn everything and start. I wonder if spawning and placement et. al. can be done, regardless of difficulty level, then paused, awaiting the completion of the briefing text and difficulty/shop selections, then adjust everything based on selections made.

 

T'would cut down on the time between mission selection in the menu and mission start.

The order of events: briefing, shop, loading screen.

 

The player must see briefing before the shop, because the player needs to know what he is doing so he can buy the gear he needs. Briefing in the loading screen would only work if there is no shop in the mission.

Briefing, difficulty/objectives, shop, loading screen, map start.

 

When the player sees the difficulty/objective screen, it presents info he's already supposed to have gotten from the briefing.

 

To move the briefing into the loading screen, the sequence would have to be:

 

Loading screen (and briefing), difficulty/objectives, shop, map start.

 

Thus my pondering above whether the loading/briefing can be done in parallel. The player chews up time anyway reading the briefing or watching a movie; might as well use that time to load the mission. It would be nice if when they were finished with the shop, the map started up almost immediately.

Sounds good. But a question: if the loading briefing had some sort of animations, pictures, mouse movement for button controlled briefing, would they stutter because of the loading process in the background?

Maybe, but no more than they would stutter today because of non-TDM processes running in the background.

 

So, would something like that be possible to implement, considering D3 is still closed source? I guess Grayman himself can probably answer the question best, among those involved in the discussion, up until now. Hiding the levelloading time would be a huge improvement of course, which is why I am so interested in this.

[grayman]

The difficulty setting obtained from the Objectives Screen governs how the map data is parsed and entities are spawned. The gorilla in the room is whether the difficulty setting can be applied after parsing/spawning is complete. If it can, then it's possible that presentations to the player (briefing/movie/Objectives/Shop) can be done in parallel with parsing the map data and setting up the mission elements. Then, in theory, the only work remaining after the player is done with the optional Shop, is to adjust the mission elements that care about difficulty.

 

My only work in this area has been with the shop, but I can try a few experiments after 1.06 is released.

[Bikerdude]

Awesome work Gman.

[grayman]

Awesome work Gman.

 

We'll see. Could end up going nowhere.

[STiFU]

Seems like there's not as much to discuss after all. Just didn't want this topic to get under as I think it'd be a great improvement...

[grayman]

Good place to report what I discover, though.

[grayman]

I spent a couple days a week ago learning how the initial screens are handled, and their control over mission loading, objective screen, shop screen, etc.

 

To rearrange what's currently in place would be a massive undertaking. It's probably possible, but it doesn't seem worth the effort, because a lot of time is needed to set up a mission, regardless of the order in which it occurs, and there's no getting around that. To me, my time is better spent on smaller things with a bigger payback; things that enhance the user experience in the hours they spend with a mission after it starts.

[ungoliant]

tdm fm loading is still one of the biggest hangups of the mod for new players (and sometimes myself for larger FMs). getting this done seems like a giant leap forward for the mod.

Granted, everyones time is their own to spend, and beggars should not be choosers when team members are working for free, and players are receiving content at 0 cost. /2cents

[nbohr1more]

Loading lots of content will always take a long time.

 

That's why most engines stream it in.

 

The SEED system can grant some of that flexibility but it is not a cure-all because texture assets need to be loaded too.

 

Rather than conventional streams of tiled textures like everyone else, Id Software intended Megatextures to be how to address this problem.

 

They didn't finish that project till after Id Tech 4.

 

If you're looking for better load times, either keep an eye on Tels' SEED work, place your vote to add the limited (hacky) megatexture mod to TDM, or wait till GPL Id Tech 4.

 

IMHO, Grayman is rightly keeping his attention on the true meat and potatoes needs for fixing AI behavior.

Edited June 14, 2011 by nbohr1more

[Sotha]

IMHO, Grayman is rightly keeping his attention on the true meat and potatoes needs for fixing AI behavior.

 

Aye. He's doing a great job. Much appreciated!

 

But on the topic of loading times, I am under the impression that most (or at least some kind of contribution) of the delay comes from the compression of textures. It was discussed somewhere (can't remember where) that precompressing the textures would eliminate the need to compress them during map loading, but the reason why that is not done eluded me. Maybe some kind of arcane technical reason I'm not equipped to grasp.

 

But anyway instead of trying to get the briefing running with the loading, could the loading times be cut by precompressing the textures. Maybe there could be a mod setting, with which those who want can precompress all their textures in a single session and that way get rid of the need to always do it separately upon each map load.

[STiFU]

It was discussed somewhere (can't remember where) that precompressing the textures would eliminate the need to compress them during map loading, but the reason why that is not done eluded me. Maybe some kind of arcane technical reason I'm not equipped to grasp.

The reason is that dds compression apparently performs poorly on normal maps. So some people around (specifically Moroso Troll I think) have been investigating a little if some high quality normalmap compression standard can be adopted, namely DXT5nm. It did not work.

 

Also, you can't use the addnormals command on precompressed normalmaps I think. This should not be the reason to hold back on texture compression though, as the few materials that actually use addnormals could be converted to use dedicated normalmaps.

[Tels]

Speaking of loading times, a little known fact is that spawning an entity took quite some time hit somewhere after v1.00 (or possible a bit before that) and somewhere around v1.02 or v1.03 (I can't find the info on the wiki).

 

This means spawning an entity was suddenly much slower, and after fixing this problem, is now as fast as before. In praxis this meant that the loading times of heart went from somewhere around 90s to about 120s on my system, and then back to 90s again.

 

Most players probably don't notice these differences - after all, 90 seconds is ages

 

Anyway, I am confident that besides the texture and loading problem we have somewhere else reserves, f.i. in spawning/initializing entities (big missions can have over 4000 of these!), as well as in initialising other things. After all, a quickload only takes a second or two, but loading the map for the second time (even after all data is in the diskcache) still takes 90 seconds for Heart...

[Komag]

Well, after not playing any missions for a long time, then firing one up recently, I can say the long load times SUCK. I of course waited and then enjoyed playing, but my honest impression at first was that the mod is "broken", because only something broken could take so long compared to pretty much every other game nowadays.

[nbohr1more]

Tels and Stgatilov would probably need to be brought in for this as well as mission load does require SEED spawning (if present) and Stgatilov had a hand in the Save code so it makes sense that Load code would be similar territory.

 

So, it's probably a project for at least 3 or 4 members unless Grayman has a handle on the other scopes of this problem...