Map Loading, Materials, Shaders, and other Details
Entry posted by Josh ·
2,740 views
I have map loading working now. The LoadMap() function has three overloads you can use::
shared_ptr<Map> LoadMap(shared_ptr<World> world, const std::string filename); shared_ptr<Map> LoadMap(shared_ptr<World> world, const std::wstring filename); shared_ptr<Map> LoadMap(shared_ptr<World> world, shared_ptr<Stream> stream);
Instead of returning a boolean to indicate success or failure, the LoadMap() function returns a Map object. The Map object gives you a handle to hang onto all the loaded entities so they don't get instantly deleted. When you want to clear the map, you can just set this variable to nullptr/NULL:
auto map = LoadMap(world,"Maps/start.map"); map = nullptr; //BOOM!!!
The "entities" member of the map object gives you a list of all entities loaded in the map:
auto map = LoadMap(world,"Maps/start.map"); for (auto entity : map->entities) { //do something to entity }
If you want to clear a map but retain one of the loaded entities, you just set it to a new variable like this. Notice we grab the camera, clear the map, but we still can use the camera:
auto map = LoadMap(world,"Maps/start.map"); shared_ptr<Camera> cam; for (auto entity : map->entities) { cam = dynamic_pointer_cast<Camera>(entity); if (cam) break; } map = nullptr; //BOOM!!! cam->SetPosition(1,2,3); //everything is fine
Materials and shader assignment has gotten simpler. If no material is assigned, a blank one will be auto-generated in the rendering thread. If a material has no shader assigned, the rendering thread will choose one automatically based on what textures are present. For example, if texture slots one and two are filled then the rendering thread will choose a shader with diffuse and normal maps. In most cases, you don't even need to bother assigning a shader to materials. I might even add separate animation and static shader slots, in which case materials could work for animated or non-animated models, and you wouldn't normally even need to specify the shader.
Shaders now support include directives. By using a pragma statement we can indicate to the engine which file to load in, and the syntax won't trigger an error in Visual Studio Code's syntax highlighter:
#pragma include Lighting.glsl
Shader includes allow us to create many different shaders, while only storing the complicated lighting code in one file that all other shaders include. The #line directive is automatically inserted into the shader source at every line, so that the engine can correctly detect which file and line number any errors originated from.
With this all working, I can now load maps side by side in Leadwerks 4 and in the new renderer and get actual performance benchmarks. Here's the first one, showing the example map "02-FPS Controller.map" from the First-Person Shooter game template. In Leadwerks 4, with Intel HD 4000 graphics, we get 71 FPS. (Yes, vertical sync is disabled).
And with the new forward renderer we get a massive 400%+ increase in performance:
I expect the results will vary a little bit across different hardware, but we can see already that on the low-end hardware the new renderer is a massive improvement.
I plan to get a new build of the beta up soon so that you can try your own maps out and test the difference. Physics and scripts are presently disabled, as these systems need additional work to be usable.
Oh, and look how much cleaner those shadow edges are!
-
5
-
2
6 Comments
Recommended Comments