Doom 3 source code packaged and tested. - by lost_soul
nbohr1more on 10/11/2011 at 00:04
Quote:
That's a bit akin to saying that doing VSD on the CPU is akin to running in "software mode". Some parts of the rendering process are, and will probably always be, performed by CPUs, but that doesn't mean it results in what you would call "software rendering".
Doing everything on the CPU, as would be the case when using WARP or some other software rasterizer, would be software mode rendering.
Given that the whole engine is predicated on the ability to generate massive amounts of Vertex data per-light, even if it's not accurate... the effective reality is virtually the same. Doom 3 needs Vertex processing... using a CPU for that task is crippling.
Intel regressing to CPU processing for Vertex operations was
idiotic considering the trends in real-time graphics. Maybe Id Software should have predicted that stupidity but when has
any hardware vendor ever removed core meat and potato features like TnL? Even shitty graphic vendors like S3 never did something that stupid. Even "The Sims" ran poorly on most of those Intel parts. They were fortunate that many games like HL2 and COD were happy to stick with light mapping.
The sad thing is that Intel squeezed all the other chipsets outta the laptop market with their "Centrino" platform garbage and so we have generations of those crappy graphic chips out there still... (Who invariably will whine that Doom 3 or The Dark Mod don't run well on their "new" laptop.)
zombe on 10/11/2011 at 12:06
Quote Posted by nbohr1more
Intel regressing to CPU processing for Vertex operations was
idiotic considering the trends in real-time graphics.
If it would have been idiotic then they would not have done it (or are you trying to imply they are idiots? - i hope you are not that stupid.) If you do not understand their reasons then it is a problem with you.
I can think of some very-very good reasons to do what they supposedly did.
nbohr1more on 10/11/2011 at 15:28
The Prescott Pentium 4 was no better or potentially worse than it's predecessor the Northwood. Both were substantially less capable of Floating Point math than an Athlon 64. Why would they choose to highlight that weakness? The only reasons I can think of to justify the design are "it saves transistors and therefore is cheaper" ... "we want to hurt GPU manufacturers by invalidating the PC platform as a gaming platform" ... Perhaps those are not idiotic reasons but if not idiotic then out-right malicious. It would be a different story if the Intel CPU line-up had loads of FP capability at the time these graphic parts were introduced (it would make sense). Please clarify your presumptions about the wisdom of that design decision?
lost_soul on 16/11/2011 at 15:09
(
https://twitter.com/#%21/ID_AA_Carmack/status/136614459887202305)
Do you think we are allowed to send the guy donations? He is actually going to write some code to fix the "problem" instead of just saying "forget it, I have better things to do and I don't care about that technology anymore". Now how badly will this break TDM, and how long will it delay the release?
EvaUnit02 on 16/11/2011 at 20:43
Quote Posted by lost_soul
Do you think we are allowed to send the guy donations?
Yes, thank him by buying a BRAND NEW copy of Rage.
Volitions Advocate on 17/11/2011 at 09:26
A well planted, solidly connected punch of irony to the FACE!
C'mon LS, you've got to admit he's got your number on that one.
Al_B on 17/11/2011 at 17:19
Quote Posted by lost_soul
Now how badly will this break TDM, and how long will it delay the release?
You worry too much.
Quote Posted by John Carmack
... the workaround added four lines of code and changed two
Bjossi on 17/11/2011 at 19:09
One line of changed code can completely change the way thousands of lines function.
wonderfield on 17/11/2011 at 20:39
If something manages to somehow break within the Dark Mod due to a change in six lines of code for stencil shadow volumes, I'll drink my own urine.
nbohr1more on 17/11/2011 at 20:57
More has changed than that shadow casting code. Carmack had to remove other proprietary code such as Punkbuster. I also imagine that some changes were done to improve compilation on more modern C++ compilers. The most likely scenario; it will be no more difficult to get TDM to work with the compiled source build than if Id had released a new patch and corresponding SDK update. The TDM team resolved that fairly quickly before and should be able to do so again.
I must state, however, that instantly jumping on the source build as soon as it arrives is probably not the wisest way to go. It's better if they wait 'till the open source community tinkers with the code awhile and shows-off some clever new improvements. :thumb:
