I wans't able to update this user-jornal the last couple of weeks, sorry. Currently I am in educational holiday for three months and my daughter learned one thing at the beginning: moving. So I had to learn how to avoid bigger accidents like switching off the computer or destroy the house very vrey fast at first .
A first triangle will be rendered
I finished the basics of my Direct3D9-renderer. I was asked more than once why I started with D3D9, when D3D11 is the hot shit. The reason is pretty simple. I want to be able to try my demos on my devbox at my job as well and there I have to use a Windows-XP ^^. D3D11 is planned as well, but at first I want the basics running.
The Renderer runs in a separate render-task. To test the renderer itself I wrote a small render-test-app. This test runs in the main-thread. This makes debugging much simpler for me. I will add a screenshot-system to be able to automate the render-test if I have some time for it ( maybe the next decade ).The Task-Manager
To be able to separate tasks into separate threads I have implement a class called TaskManager. This manager handles several task-instances ( creation, starting, stop them ). Each task can work in the main-thread or in a separate thread, which will be spawned for the task.
If you want to do something in a task you can send him an event. Events will be handled by EventHandlers. The user can implement this handler and attach them to a task. The event-handlers should be the hook for any user-specific stuff. So if you want to implement a task to handle some work you can use the task-manager to create a new task-instance. After that you can attach you own EventHandler and send user-specifc events to the task.
A first prototype for the Resource-Loading-System
The resource load procedure works, too. At this moment you can import models using the AssImp-Library in a separate thread. The ideas behind the resource system is really simple: resources are assigned to a unique resource-group-id. You can register a resource-factory and a resource-loader to this group id. Factories will create the resources, the loader will import the data. The resource-server will cache created resources to avoid redundat loadings.
If you want to create a new resource instance and load data into it the procedure is quite simple:
- Get the Resource-Server instance.
- Get the Factory and the Loader, which are assigned to the unique resource-group -d of your resource type
- Create a new resource instance with the resource-factory. The factory gets the loader instance as a parameter. If you want to use a specific loader you can specify this here
- No you can call Resource::onLoad to signal, that the resource loading should be started by the loader-task.
- The resource-loading-request will be enqueued into the resource-loader-queue and handled as fast as possible.
This works and now I can test this for other resource types like shaders or textures as well.Next steps
Currently I am working on the render setup for the imported models. On issue I am thinking about is how to handle the ownership of the model-data. After finishing the loading the resource-data-ownership will be moved from the loader-task to the main task. The render-task will get this data by receiving an event and store it in vertex- and index-buffers. If you have some nices ideas feel free to share them with me ...The AssImp development
I made some progress at the assimp-deveopment as well. The M3-Importer grows and grows. At this moment I am able to import faces, normals and vertices. But I will need some more time to understand how to deal with the bone-system of the m3-format. Understanding such things is a much harder task if you child tries to switch off your computer again and again...
To be continued...