I realise I'm one of few that considers Windows an acceptable platform (at least here on/.) but personally I dislike Lynux.
I don't consider the extreme tweakability of Lynux beneficial to me. If I absolutely cannot tweek whatever I don't like in a given Windows app there is usually a plethora of alternative app choices available just a download away.
In my experience Lynux crashes as regularly as Windows - you may vividly disagree with this statement, but consider that any Lynux user is very likely to be quite clued-up with all matters concerning Lynux; as a consequence system stability in Lynux is augmented by these users. Similarily, I know my Windows environment quite well, and hardly ever experience system ceisures.
On the other hand, my occasional foray into Lynux is occasionally coupled with frustration as things dont necessarily just work (for me). And I do experience Lynux crashes.
Regarding security on Windows and PCs being hijacked for spamming... - if I were to write a virus, worm or sparm-app I would most certainly target the Windows OS, not because of security holes - but to take advantage of the vast selection of PCs out there were my payload could hit. I may be wrong, but I find it hard to believe that Lynux is impervious to security attacks. Also I think that the average Lynux user is more savvy then the average Windows user, which acts as a deterrent to virus programming.
The extensive scripting capabilities in Lynux are quite useful, but anything that I really have difficulties with (and cannot in some way automate) in Windows I can easily write a quick app for.
Lastly, I do not agree with some of MicroSoft's business practises, I'm against DRM, against software patents, and in favour of open source. I do however think that Bill Gates does do tremendous good with the considerable financial resources that he commands due to MicroSoft; he and his wife truly go above and beyond the call of duty to use both their wealth and intellect to aid those with lesser privileges around the world.
I'm the author of the article. So I guess I can explain a few things.
Originally the article was written 3 years ago as a technical report for a small course I needed to do. DevMaster found this work and asked me whether they could make it available.
The course took place over 8 weeks, covering each algorithm in a week - and 2 weeks for the report at the end. The actual course work is still accessable at
http://www.cs.sun.ac.za/~henri/advgfx.html
And includes pictures and sources to keep everybody happy.;)
To those that are uncertain who the intended target audience is - well, originally my supervisor...;) - hence the somewhat formal and academic style; however, in its current form as an article on DevMaster it is intended for intermediate readers. Those that look for some additional insight into (spatial) graphics algorithms. The article isn't a tutorial and (given its history) is not bothered with technical details, however, it does make reference to useful starting places for those that wish to explore the matter some more.
Although I agree - pretty pics would've been nice.;) Those that really need them should go to the website.
The choice of algorithms reflects not the state-of-the-art, nor the best approaches to solving graphics issues. The algorithms were, however, easily accessable to me at the time - and hence featured in my one-algorithm-a-week plan.
Somebody mentioned that BSPs are outdated, this isn't true - though they have been around for ages, they are still the work-horse for most indoor engines around. Sure, BSPs are rarely used for the actual rendering process (as mentioned in the article), but in terms of processability of spatial organization they are hard to beat.
I stand to be corrected but I'm rather sure Doom3 makes use of some form of BSPs as well. That should be good enough for anybody.
Slashdot Mirror
I realise I'm one of few that considers Windows an acceptable platform (at least here on /.) but personally I dislike Lynux.
I don't consider the extreme tweakability of Lynux beneficial to me. If I absolutely cannot tweek whatever I don't like in a given Windows app there is usually a plethora of alternative app choices available just a download away.
In my experience Lynux crashes as regularly as Windows - you may vividly disagree with this statement, but consider that any Lynux user is very likely to be quite clued-up with all matters concerning Lynux; as a consequence system stability in Lynux is augmented by these users. Similarily, I know my Windows environment quite well, and hardly ever experience system ceisures.
On the other hand, my occasional foray into Lynux is occasionally coupled with frustration as things dont necessarily just work (for me). And I do experience Lynux crashes.
Regarding security on Windows and PCs being hijacked for spamming... - if I were to write a virus, worm or sparm-app I would most certainly target the Windows OS, not because of security holes - but to take advantage of the vast selection of PCs out there were my payload could hit. I may be wrong, but I find it hard to believe that Lynux is impervious to security attacks. Also I think that the average Lynux user is more savvy then the average Windows user, which acts as a deterrent to virus programming.
The extensive scripting capabilities in Lynux are quite useful, but anything that I really have difficulties with (and cannot in some way automate) in Windows I can easily write a quick app for.
Lastly, I do not agree with some of MicroSoft's business practises, I'm against DRM, against software patents, and in favour of open source. I do however think that Bill Gates does do tremendous good with the considerable financial resources that he commands due to MicroSoft; he and his wife truly go above and beyond the call of duty to use both their wealth and intellect to aid those with lesser privileges around the world.
Heya :)
;)
;) - hence the somewhat formal and academic style; however, in its current form as an article on DevMaster it is intended for intermediate readers. Those that look for some additional insight into (spatial) graphics algorithms. The article isn't a tutorial and (given its history) is not bothered with technical details, however, it does make reference to useful starting places for those that wish to explore the matter some more.
;) Those that really need them should go to the website.
I'm the author of the article. So I guess I can explain a few things.
Originally the article was written 3 years ago as a technical report for a small course I needed to do. DevMaster found this work and asked me whether they could make it available.
The course took place over 8 weeks, covering each algorithm in a week - and 2 weeks for the report at the end. The actual course work is still accessable at
http://www.cs.sun.ac.za/~henri/advgfx.html
And includes pictures and sources to keep everybody happy.
To those that are uncertain who the intended target audience is - well, originally my supervisor...
Although I agree - pretty pics would've been nice.
The choice of algorithms reflects not the state-of-the-art, nor the best approaches to solving graphics issues. The algorithms were, however, easily accessable to me at the time - and hence featured in my one-algorithm-a-week plan.
Somebody mentioned that BSPs are outdated, this isn't true - though they have been around for ages, they are still the work-horse for most indoor engines around. Sure, BSPs are rarely used for the actual rendering process (as mentioned in the article), but in terms of processability of spatial organization they are hard to beat.
I stand to be corrected but I'm rather sure Doom3 makes use of some form of BSPs as well. That should be good enough for anybody.