Advanced scene loading

[Canardia]

The Scene::LoadMap method does first LoadScene which loads the vegetation layers, and gamelib's ProcessScene() after that just handles the entities more elegantly (for example not leaving annoying physics bodies of lights, etc... behind), and of course loads also additional entities, like playerstart, weapons, etc....

 

Loading screens with progress bars are done via POSIX compliant multithreading, which I will add to the next gamelib (I already published the source of that in the forum earlier).

[Marleys Ghost]

So gameLib actually loads the SBX twice?

[Canardia]

No, the initial ProcessSceneInfo() only scans for things which LoadScene doesn't load at all, like terrainresolution and terrainsize. ProcessScene() handles only in-memory entities after LoadScene.

[Marleys Ghost]

So what handles the terrain and veg layers?

[Canardia]

LoadScene().

[Marleys Ghost]

So you load the .sbx as per usual with Loadscene() and then you reprocess it with your own ProcessScene()?

[Canardia]

I already wrote it First ProcessSceneInfo(), then LoadScene(), then ProcessScene(). And the Scene::Update() has of course also the functionality to update the additional entitites, like nametags, mirrors (not yet implemented), etc...

 

I'm not sure if I should add rain (I have 2 types of rain: physics rain and raycast rain) also to Scene::Update(), because the new trend is to keep the classes of gamelib standalone. So you have to call rain.Update() yourself in your mainloop.

[Marleys Ghost]

Think I will stick with just Loadscene() .... faster

[Paul Thomas]

This all reminds me of my feature request on the old forum: http://leadwerks.com/forum/viewtopic.php?f=16&t=5807

[Pixel Perfect]

All the vegetation layer functions were exposed in 2.0 and were subsequently taken out. These should simply be restored in whatever form they currently take. This has been asked for on several occasions. It's just this sort of thing that prevents people from being innovative. Either that or provide some sort of call-back based on the LoadScene function so people can provide fairly accurate user feedback. Or even better ... BOTH!

 

Power to the people I say. (well the programmers actually )

[Rick]

It's just this sort of thing that prevents people from being innovative.

 

Oh, I thought I was being innovative with splitting the original sbx file into 2 files on the fly then using LoadScene() on the sbx file that has terrain and vege and a custom LoadScene() on the other sbx file that has all the entities. The splitting of the original sbx file should take less then a second and put in it's own thread so it doesn't cause any stopping. Then once both temp sbx files are loaded delete them.

[Mumbles]

(well the programmers actually )

 

Indeed, sod everyone else. In fact, let's extend that to everyone but the C programmers...

[Canardia]

Think I will stick with just Loadscene() .... faster

It's not really faster, since if you don't do a gamelib style ProcessScene() afterwards, you end up with lots of waste entities, which eat memory and slow down the FPS, not to mention about the collision bugs it might cause. And if you don't do the ProcessSceneInfo() before, you end up with missing features So, gamelib is perfect.

[Marleys Ghost]

Faster to load Mika ... has to be .. than doing the same thing 2 or 3 times over ...

 

 

 

No gamelibs like your claim about successful commercial linux apps ...

 

[Pixel Perfect]

Oh, I thought I was being innovative

That is being innovative Rick, I missed that when reading through the thread and that should work well but it is still only required because the SDK is not allowing access to functions that control a major feature of the Engine. I don't believe it's too much to ask for their inclusion and is better than having to do workarounds. In theory the inclusion of the call-back would be an even better solution but the commands should still be exposed non the less. Just my opinion, not saying you have to agree with me.

 

 

Indeed, sod everyone else. In fact, let's extend that to everyone but the C programmers...

Well who else apart from programmers are going to be using the vegetation layer functions in the SDK

[Mumbles]

Well who else apart from programmers are going to be using the vegetation layer functions in the SDK

 

...Apart from programmers, who else would use the Initialise command? Power to us, absolutely...

[Rick]

In theory the inclusion of the call-back would be an even better solution but the commands should still be exposed non the less. Just my opinion, not saying you have to agree with me.

 

What you are saying isn't an opinion it's a fact I 100% agree with you. Sadly I don't think these are considered to be bugs by Josh and will most likely never get done since he's doing LE 3 dev and I guess only bug fixes for LE 2.x?

[Canardia]

Faster to load Mika ... has to be ..

You need to stay realistic. If it loads 0.0001ms faster, but your whole game is 20 FPS slower, then the total speed loss matters. Besides the ProcessSceneInfo() is done in raw C, so it can handle 3GB of data per sec, and which SBX is even near to 3GB?

[Marleys Ghost]

You need to stay realistic. If it loads 0.0001ms faster, but your whole game is 20 FPS slower, then the total speed loss matters.

 

 

 

 

 

lmao I need to stay realistic?? if it only loaded 0.0001ms faster?? why do you never use realistic hypothetical scenarios?

 

Mika your doing the same thing 3x basically .. you make claims it fixes certain things .. that's the reality here.

[Canardia]

Actually it is faster than a normal LoadScene(), because gamelib disables some Lua scripts by default, and does them in C++ instead. Anyway, the speed difference is ridiculously small, and the most time wasting thing is still LoadScene(), and then specially loading of a large terrain. So if you really want to speed up the loading, you should rewrite LoadScene() completely and not use SBX at all, but some binary high optimized game map format, like gmf was made for. And you should not use terrains at all, but load each tile from a SQLite3 database, since there is no point to load things which the player doesn't see at that time.

[Marleys Ghost]

and the most time wasting thing is still LoadScene()

 

Which you STILL use!

[Canardia]

I use it, because it does a lot of things, and it is updated frequently. So if I would rewrite the whole LoadScene(), I would need to update it once in a while, and not really gain any speed benefit either, since the time taking step is to create the terrains on the GPU.

 

The only alternative to LoadScene() would be your own LoadModels() function, which stores the dynamically moved entities into a C++ STL map and also the modified terrainheightmap and then loads/saves them from disk. I've done that also and it's insanely fast, not sure why LoadScene() is slower there, but it might be because of garbage collection of BlitzMax, or some special logic which raw heightmap loading doesn't need (for example no loading of terrain textures).

[Mumbles]

Actually it is faster than a normal LoadScene(), because gamelib disables some Lua scripts by default, and does them in C++ instead. Anyway, the speed difference is ridiculously small, and the most time wasting thing is still LoadScene(), and then specially loading of a large terrain. So if you really want to speed up the loading, you should rewrite LoadScene() completely and not use SBX at all, but some binary high optimized game map format, like gmf was made for. And you should not use terrains at all, but load each tile from a SQLite3 database, since there is no point to load things which the player doesn't see at that time.

 

I don't see what's wrong with manually parsing the sbx file, it is just a plain text file after all. That and I'm (the only one maybe?) using a version where I don't to worry about any of this silly lua anyway. I don't use terrains because I don't see the point of them. And the sbx has most of the info you'll ever need, position, rotation, etc. The only sort of thing it won't hold is stuff like mission objectives (if you're building a game that has such things), and yes, your own text file will cut the difference easily.

 

All in all, it seems like a perfect file, I don't use the LoadScene command, which was intended to simplify loading such files. Indeed it does just that - but with larger scenes, you can be left waiting for ages, with no way of accurately knowing how much longer it will take. You could put a mac type spinner animation on, but that has the same problem.

 

That, and with Mafia II, I didn't like their world streaming. It had something my brothers call the "Black horse syndrome" Apparently oblivion players will understand what that means. But for those who don't, basically, you move across the world so quickly, every 10 seconds or so a different portion of the world is loaded, causing a huge drop in fps whilst it happens (it lasts about 2 - 3 seconds). Indeed on the highways in Mafia II, it felt the same. It's not a good way to demonstrate a streaming world, and they are the pros who are supposed to be good at what they do, and showcasing their technology. I think it needed to load more at a time, so the stutters weren't so close together, even if each stutter lasted for 5 seconds instead.

[Rick]

Moving across the world to fast really is the issue with streaming. That's why things like in WoW when you fly from one place to another it takes crazy long routes sometimes. It's to give the world streaming time to load things before you get there. In Mafia 2 when I'm going 100+ mph everything slows down and things are still loading when I get there. That was lame.

 

As for on topic, I wouldn't call the Lua stuff silly. It's actually very powerful and can help extend the editor with new functionality. It's just something you aren't interested in right now is all. It would be nice though if we (the community) could come up with a better LoadScene() method.

[Canardia]

Yeah, Mumbles should upgrade to 2.4 and get done with Lua