Yes, And No
It is true that I went for another walk today, but this time I came straight back and did not go to sleep :) I gave myself one hour before dinner to finish off the prototype with communal textures which will allow me to populate a single texture with many quad texture renders. It's now two hours and I've just finished the quad texture regeneration system and not even started on the communal multi-render stuff. Just goes to show how even a simple developer task can be broken down into small unpredictable extra work that had no previous time estimate assigned.
Imagine, a task that I did not even think about, and did not have a time estimate for, taking twice as long as the task I started to do. Now multiply that few hours with those in week, and then an entire project and you will get a sense of how an estimate and reality can differ. I set myself an hour as I was famished, and as I write this I am doubly famished. Will stop now and eat, then return to do the task I set myself at 5PM :)
Signing Off
In the two hours of quad regeneration work however I tracked down some bugs in the engine which caused HIGH and MEDIUM LOD objects to render over each other which was rather redundant, and introduced the system which only renders the quad texture when it absolutely needed to be done. I also found that I needed to update the quad vertices each cycle in order to keep the quad polygons rendering to the screen smoothly. Whether this will effect overall performance when we start locking hundreds of buffers, we will see, but I wanted to achieve super-smooth AND speed. When we have some real world levels to throw at it, we can then decide to keep speed and have the quads stepping along, or keep smooth, and sacrifice some speed. One of the many thousands upon thousands of tiny decisions that do into making a games engine.
Also got an email with a prototype showing some rather nifty player hurt, directional damage and blood splatting effects. I am now resisting the urge to play with that integration (five minutes work which is actually five hours work) and remain focused on two objectives. Finish the prototype for engine integration and solve the object popping caused by occlusion. I can then prepare an installer for some internal testing before a planned release for the weekend. I think you will like this update, we have lots of tweaks in there!
At least your keeping healthy with a bit of exercise :) It sounds like you have the next update in hand, and I'm looking forward to the 20th!
ReplyDeleteIf you can find a way to combine all those memory allocations into one group, or if not, a few groups, you can lock/unlock groups instead of individual ones - it'll cut down on a lot of that overhead. I know that lots of individual system-memory allocations can slow things down considerably as the numbers get up there. Since DirectX is written by the same authors of that allocation manager....
ReplyDeleteThis comment has been removed by the author.
ReplyDeleteI realized groups would probably be better than grouping it all to one, b/c the rendering can be done with the others, in parallel to the CPU system's activities.
ReplyDeleteBut something else you can do if DirectX will let you, You said earlier you're modularizing your code. Thus you can send your unlock requests as early as possible, and then rather than waiting around for the various memories to become unlocked, just go on doing something else, and have DirectX trigger a software interrupt when one becomes available. Have DirectX tell your ISR which request it's responding to, then in your ISR, call whichever subroutine is appropriate to handle it (your reason for the unlock request). If you're already in a subroutine when you get another interrupt (I think there's a flag somewhere you can set in your ISR before it returns to allow that?), add it to a table and get back to the first ones first - so you can minimize the amount of time any memory needs to remain locked.
Hi Patrick (and thanks for the ideas). I do something similar in terms of 'do what you can then move on' to avoid ANY waiting. My alternative to interrupts is simply to return later and continue a task from a previous cycle, but I will be playing more with threads once the main Reloaded objectives have been met as I would very much like to get all the cores nice and warm when you run an FPSC game :)
ReplyDeleteNoticed in a lot of games at a GREAT distance some NPC's AI will wait until close enough before running where it left off. Though this is far when the player is so far away he can barely see the NPC's.
ReplyDeleteWill Reloaded feature security cameras and the ability to select what is shown to the player via the HUDs? That would be awesome!
ReplyDelete