I've passed my driving exam! yay!!! It went very well. We did the maneuvers very early on so i could relax a bit and just concentrate on driving around. Overall i only got 2 minors, i am very happy!
That's one thing that i don't have to worry about now and i can concentrate on starting uni.
Thursday, 25 September 2008
Wednesday, 24 September 2008
Nerves
I've got my driving exam tomorrow, part of me is looking forward to it being quietly confident that It'll be OK but the other part of me is nervous. The main reason being that you can't control what other drivers will do, it could only take one dodgy driver to cause me to fail. I'm pretty confident that i can drive to the required standard and perform the maneuvers well enough. I will just have to see how it goes.
This week has been fairly busy where i was at a wedding over the weekend which was good, the last few driving lessons and my exam tomorrow. I also have enrollment day at uni on Monday and i need to buy various things for when i start back.
Doesn't seem long ago that i had a whole four months off, now I'm down to a week...
This week has been fairly busy where i was at a wedding over the weekend which was good, the last few driving lessons and my exam tomorrow. I also have enrollment day at uni on Monday and i need to buy various things for when i start back.
Doesn't seem long ago that i had a whole four months off, now I'm down to a week...
Tuesday, 9 September 2008
System framework improvements
The System's code has had a lot of iterations to it which i do wish i could have gotten to quicker, but it's definitely worth it. It is now a lot slimmer, removing two classes (four source files) without losing any features.
When i first wrote the code it became large because i wanted to make it very flexible. I have now removed redundant code and cleaned it up a lot. The System's code needs to be fast and very solid as its the base for a lot of the engine and its plug-ins. These latest changes should be the last major ones made on these classes now (at last!!).
As it stands we now have:
We had a problem where we would get 50fps in the samples even though they were set to be ticked at 60fps (as well as any movements in the fps sample would causes large frame rate decreases). This problem has disappeared now due to these changes, getting a very stable frame rate even whilst moving around. It is also responsive to small changes in tick intervals.
Ticking the graphics system at 16.6666667 gives a frame rate of 60fps and a tick interval of 16 gives a frame rate of 62fps. Obviously this is what it should do, but it does suggest (i still need to profile to get proof) that there is a very low latency between the primary thread waking up and all of the Systems being ticked.
My next aims are to provide built-in debugging code/features to help with development (especially to track down threading and release mode issues) and possibly improve memory management, as there are a few places where we are allocating and freeing memory a lot.
When i first wrote the code it became large because i wanted to make it very flexible. I have now removed redundant code and cleaned it up a lot. The System's code needs to be fast and very solid as its the base for a lot of the engine and its plug-ins. These latest changes should be the last major ones made on these classes now (at last!!).
As it stands we now have:
- TaskThread - Wraps a thread and provides processing of tasks
- SystemGroup - Manages a group of System's and enforces a specific start up and tear down sequence for each System registered to it, as well as periodical updates (ticks).
- System - Allows a class to be managed by a SystemGroup and receives ticks.
We had a problem where we would get 50fps in the samples even though they were set to be ticked at 60fps (as well as any movements in the fps sample would causes large frame rate decreases). This problem has disappeared now due to these changes, getting a very stable frame rate even whilst moving around. It is also responsive to small changes in tick intervals.
Ticking the graphics system at 16.6666667 gives a frame rate of 60fps and a tick interval of 16 gives a frame rate of 62fps. Obviously this is what it should do, but it does suggest (i still need to profile to get proof) that there is a very low latency between the primary thread waking up and all of the Systems being ticked.
My next aims are to provide built-in debugging code/features to help with development (especially to track down threading and release mode issues) and possibly improve memory management, as there are a few places where we are allocating and freeing memory a lot.
Monday, 25 August 2008
Busy Busy...
Last week i had my driving theory test which i passed! I can't be fully happy until I've passed the practical though which is in a months time. My family, girlfriend and i went to my cousins wedding on the weekend as well, which was good.
Next month is going to be busy as i have another wedding to go to, my driving practical test and enrolment for my final year of uni. My holiday has gone so fast and i don't really feel like I've got much done at all. I had better make this last month count.
Next month is going to be busy as i have another wedding to go to, my driving practical test and enrolment for my final year of uni. My holiday has gone so fast and i don't really feel like I've got much done at all. I had better make this last month count.
Saturday, 16 August 2008
Engine initialisation and threading improvements
I haven't blogged in a while mainly because nothing major has really happened. I've mostly been learning to drive which is going very well. I have my theory test on Thursday which should be OK as I've been doing well on the practice CD i have.
I've just committed a fairly big update to the utilities and the core mainly aimed at threading as well as the engines initialisation sequence. One problem that existed was that for systems that are very slow to initialise (like OGRE) the engine would start running/ticking before it has completed.
There were many different possible solutions but the solution i went for is process every initial request (register/initialise/schedule) and only once every single one has completed, initialisation will finish. Ticking will not occur because the EngineTimingHandler has not been started yet, so game states etc cannot be ticked and cause the original problems.
A problem that existed before and probably emphasised with this solution is that all systems assumed the current time is 0 when they were created, and during initialisation they we're told it was 0. By the time everything has initialised, the time could be at least several seconds later, causing them to calculate very large time intervals which would result in incorrect calculations.
The solution now is that when a system is scheduled it is told the current time, which could be incorrect if the engine hasn't started running yet. The EngineTimingHandler solves this by telling every system that is scheduled the real current time before it starts running.
There are still many improvements to be made to OGE's threading but it has been fairly easy to make the necessary changes so i think our current approach is working well. The main improvement i want to make soon is to get OGE to work out how many threads to create at the start semi automatically. It will take various hints and requirements (from config) and retrieve details about the current CPU (such as number of packages, cores and logical processors) to work out how many threads to create.
On another note, i think its possible for us to get Intel's Threading Building Blocks working in OGE (the scheduler/algorithms part) because it allows you to specify the number of threads that the TBB scheduler can use/create. It would allow us to allocate all the threads we need and then let TBB create the remaining number of threads. On future CPU's with more cores than work that we can allocate from the various systems, we can put more workload onto the tbb scheduler.
I've just committed a fairly big update to the utilities and the core mainly aimed at threading as well as the engines initialisation sequence. One problem that existed was that for systems that are very slow to initialise (like OGRE) the engine would start running/ticking before it has completed.
There were many different possible solutions but the solution i went for is process every initial request (register/initialise/schedule) and only once every single one has completed, initialisation will finish. Ticking will not occur because the EngineTimingHandler has not been started yet, so game states etc cannot be ticked and cause the original problems.
A problem that existed before and probably emphasised with this solution is that all systems assumed the current time is 0 when they were created, and during initialisation they we're told it was 0. By the time everything has initialised, the time could be at least several seconds later, causing them to calculate very large time intervals which would result in incorrect calculations.
The solution now is that when a system is scheduled it is told the current time, which could be incorrect if the engine hasn't started running yet. The EngineTimingHandler solves this by telling every system that is scheduled the real current time before it starts running.
There are still many improvements to be made to OGE's threading but it has been fairly easy to make the necessary changes so i think our current approach is working well. The main improvement i want to make soon is to get OGE to work out how many threads to create at the start semi automatically. It will take various hints and requirements (from config) and retrieve details about the current CPU (such as number of packages, cores and logical processors) to work out how many threads to create.
On another note, i think its possible for us to get Intel's Threading Building Blocks working in OGE (the scheduler/algorithms part) because it allows you to specify the number of threads that the TBB scheduler can use/create. It would allow us to allocate all the threads we need and then let TBB create the remaining number of threads. On future CPU's with more cores than work that we can allocate from the various systems, we can put more workload onto the tbb scheduler.
Friday, 18 July 2008
First driving lesson!
I just had my first driving lesson today which went really well. Learnt some of the basics and got to drive around a car park a bit. I am at least happy i haven't stalled the car...yet. Bit of a squeeze getting into the car as its smallish and I'm not. My instructor seems good as well, i think I'll be able to learn at a good rate. I'm hoping the rest of my lessons go as well as (or better than) today's.
Monday, 14 July 2008
Framework for Features
We have been writing framework code for quite a long time now for OGE, a large amount being utilities and a fair amount for the core. We are now starting to add new projects/modules, currently graphics, input and audio. We are really close to being able to start adding loads of features to OGE which i can't wait to be able to do. Finally the fun part! Sadly though we still have some more framework to add, such as the basic initialisation/shutdown of each of the plug-ins and adding more to the core, but I'm hoping this won't take long.
Once we have the first few plug-ins up and running, it will be a lot quicker to add the remaining ones as we won't have to discuss how to name various files and classes.
Once we have the first few plug-ins up and running, it will be a lot quicker to add the remaining ones as we won't have to discuss how to name various files and classes.
Subscribe to:
Posts (Atom)