Project V: Progress Report (Jan 11)
Friday, 29. December 2006, 05:27:44
Progress Report. I'll be updating this so you can see where I'm at.
After the last TODO list, I've learned a few things. Nothing that would change the world or anything. I'm fairly certain that predicting the work needed more than 2 weeks in the future gets more and more vague from there. Obvious, no?
I think reassessing where you are every two weeks is good. You should plan out two week work agendas and stick with that. Further than that you need to make assumptions. And you can't be precise. The possibility of error in timing is greater the further ahead in time you try to predict. So this makes determination of how long a project will take quite difficult. If at the end you're predicting a certain task to be one month plus or minus two months, then you have possibilities of compound errors.
Here's what I mean. And I'll use the example of what I'm working on now, alpha channels. I don't have to be precise with this because I retain the original graphics. So every time I use them, any error in the algorithm that merges two images will only be present once. However, if I use the result of that image on a third image, errors will be more pronounced. After a while, the produced images will look nothing like what we want. It'll be either too dark, too bright or the image will look like garbage. Every iteration brings its own set of errors. Using too many iterations will lead to absolute errors.
I think the same is true of predicting long term projects. For every task you try to predict, you introduce yet another set of errors in your timeline. If there are many tasks to be done, you'll get extreme compound errors. Being right on all counts is something we all strive for, but it's not very realistic.
What's more boggling is that programming has been around for ages. We should have already done everything that can be done. So our timelines should be easy to create. For example, driving to another city is easy to calculate. It doesn't matter how many stops we make. We can calculate with some accuracy how long it will take to get there. This is because many people have done it before and we have data we can use from these past voyages. Programming should be the same. We should have timelines of all sorts of different tasks. If you use C++ and want to write an alpha blending routine, it should take under 1 hour. If you assembler, it should take between 2 hours and 4 hours with testing. It gets worse. If someone has already written it, why are we writing it over again? Because everyone does things their own way or it's doesn't have a full set of features. In a way, it's like most projects are straw bridges. It's just good enough for you to get across the river. But screw everyone else. If this bridge isn't good enough, they can build their own.
Ok, so enough on that. I'm working on two week schedules now. For this part, I'm just going to lay out what I want done. One per day is all I'm doing right now.
Paste32 386 MMX SSE SSE2 SSE3 Normal 2 Normal LPaste32 MMXPaste32 ISSEPaste32 Normal 2 Static LPastePA32 MMXPastePA32 ISSEPastePA32 Normal 2 Precom LPasteP32 MMXPasteP32 ISSEPasteP32 Static 2 Normal LPasteA32 MMXPasteA32 ISSEPasteA32 Static 2 Static LPasteA32 MMXPasteA32 ISSEPasteA32 Static 2 Precom LPasteZA32 MMXPasteZA32 ISSEPasteZA32 Precom 2 Normal LPasteU32 SSEPasteU32 Precom 2 Static LPasteA32 MMXPasteA32 ISSEPasteA32 Precom 2 Precom LPaste32 MMXPaste32 ISSEPaste32 Paste32Alpha Normal 2 Normal LPaste32Alpha SSEPaste32Alpha Normal 2 Static LPastePA32Alpha MMXPastePA32Alpha ISSEPastePA32Alpha Normal 2 Precom LPasteP32Alpha MMXPasteP32Alpha ISSEPasteP32Alpha Static 2 Normal LPasteA32 MMXPasteA32 ISSEPasteA32 Static 2 Static LPasteA32 MMXPasteA32 ISSEPasteA32 Static 2 Precom LPasteZA32 MMXPasteZA32 ISSEPasteZA32 Precom 2 Normal LPastePPN32Alpha SSEPastePPN32Alpha Precom 2 Static LPastePPA32Alpha MMXPastePPA32Alpha ISSEPastePPA32Alpha Precom 2 Precom LPastePP32Alpha MMXPastePP32Alpha ISSEPastePP32Alpha Clear32 Normal 2 Normal ASMClear32 MMXClear32 ISSEClear32 Static 2 Static ASMClear32 MMXClear32 ISSEClear32 Precom 2 Precom ASMClear32 MMXClear32 ISSEClear32 Clear32Alpha Normal 2 Normal LClearNN32Alpha SSEClearNN32Alpha Precom 2 Normal LClearPN32Alpha SSEClearPN32Alpha Normal 2 Static LClearNS32Alpha MMXClearNS32Alpha ISSEClearNS32Alpha Precom 2 Static LClearPS32Alpha MMXClearPS32Alpha ISSEClearPS32Alpha Normal 2 Precom LClearNP32Alpha MMXClearNP32Alpha ISSEClearNP32Alpha Precom 2 Precom LClearPP32Alpha MMXClearPP32Alpha ISSEClearPP32Alpha Convert32 (In place conversion) Normal 2 Static LConvertNS32 MMXConvertNS32 ISSEConvertNS32 Normal 2 Precom LConvertNP32 MMXConvertNP32 ISSEConvertNP32 Static 2 Normal LConvertSN32 MMXConvertSN32 ISSEConvertSN32 Static 2 Precom LConvertSP32 MMXConvertSP32 ISSEConvertSP32 Precom 2 Normal LConvertPN32 SSEConvertPN32 Precom 2 Static LConvertSN32 MMXConvertSN32 ISSEConvertSN32
So I have to write a routine for each of these. Where there's a function name, those are done already. I'll do SSE2 and SSE3 some other time. (My bridge is good enough for now.) I have 42 routines left to write. At one a day, that puts me at Feb 20th. That's too long. Many of these are similar, so I'm cutting it down that I need to write all three routines for each type of operation on the same day. That gives 14 days. Perfect. That's two weeks. Friday, Jan 13th is the expected completion date. Wonder if it's a full moon too?
I wish I could use the extra eight registers on 64bit CPU's, but you have to be in 64bit mode. That sucks. Oh well. Maybe I'll write SSE2 routines later on. Operating on 4 pixels at a time is nice, but I'm already using SSE registers for division in some algorithms. So I don't know if I can get any speedup from that.
After all this is done, I have to update my code for compound type creation. I think I have this figured out. Once that's done, I'll write up a few components and release an alpha version.
Oh, the reason for the update of my graphics library yet again is because there are many different ways to store images. I want to have a fully functional library before going further. This way, I don't have to deal with it anymore. The old one is ok, but lacks the ability to not do clipping when not necessary. I've introduced complex clipping areas and this basically screwed up everything. I'm now building very primitive drawing routines that higher level methods can mix and match in order to produce the best and fastest results. Like I said, encapsulation is rarely a good thing in my book. I also like that I'm using data flow organisation techniques in my regular programming work.
When the above chart is completely filled with function names, my library will be mostly done. I'll have to write clipping rountines too, but most of it is already written so it'll take a couple days work max.
Jan 31st is the worst case release date for an alpha version. This blog will shut down after that date until I release something.
Update Jan 2nd, 2007: Well, it's only the 2nd and I only have 7 routines left to do. Precom 2 Normal is annoying. There's are plenty of special cases. I may resort to just using a plain C++ routine. I may not use normal graphics at all and only use precomputed and static images. Funny that normal images are actually the worst way to store them.
Update Jan 9th, 2007: All that's left is ClearAlpha routines. This should take a day or two.
Update Jan 11th, 2007: I'm done the basic routines. The ASM, MMX and SSE routines aren't optimized. I just want them to work for now. After I've tested them, I can reorder some of the instructions. Now, I can finish off the higher functions.
I guess I'm not done. I want to include in-place conversion.
