I have exactly the same issue as the OP and I'm using an ATI HD4670. Could you tell me what this problem is or point me to the bug track page?
At present, it makes Doomsday unplayable, these textures are displayed properly in GZDoom. It's a shame as Doomsday is a prettier engine and I was looking forward to seeing how it had developed since I last ran Doom some years ago. Everything else about the package is excellent.
I'd love to see this issue resolved, but as I don't have an ATI card to debug with I can't really do much about it (apart from shooting in the dark). I thought I could use my old office laptop with an ATI Mobility Radeon but of course I can't remember its boot password... :grr: The latest I heard from DaniJ is that he has an ATI card stashed somewhere but hasn't had a chance to install it anywhere.
I'll be frank and state what is obvious from the picture - I did take it from my shinka port - which was last rebased against doomsday 1.9.0-beta6.2 - there are NO changes in the opengl renderer from doomsday (you can check the git repo to verify if you wish).
Please note the OpenGL information in the screenshot,
Me again. I downloaded the windows build of the doomsday 1.9.0-beta6.4 release and had windows 2000 installed on my ATI box. Same system as the previous test, but with windows 2000 and the catalysts 6.2 drivers (latest drivers that support my card).
I've leave it to you to draw your own conclusions from this.
Yes, your ATI card is too old.
I was visiting the folks today and remembered my dad has a PC with an ATI Radeon 9600. Upon first try everything seemed to work perfectly, using the old ATI driver from 2006 (atiogl1x.dll 6.14.10.1030). I then upgraded to the latest one available (from April 2009, atioglxx.dll 6.14.10.8543) and the masked textures were no longer rendered correctly.
After a bit of checking I found the problem: the texture coordinates for the masked walls were not specified correctly according to the OpenGL specs of glMultiTexCoord2f. It's now fixed for Beta6.5.
Apparently the old ATI drivers (and Nvidia drivers, for that matter) are more forgiving when it comes to using values that are not valid according to the spec.
I've leave it to you to draw your own conclusions from this.
Yes, your ATI card is too old.
The conclusions should be as you note further down in your post is that something in the drivers changed and it no longer likes the values you erroneously give it.
Apparently the old ATI drivers (and Nvidia drivers, for that matter) are more forgiving when it comes to using values that are not valid according to the spec.
That's at least 2 sets of ATI drivers (opensource and closed source), nvidia drivers, intel drivers.
Thanks for the dismissal though - I'll keep it in mind when I next get tempted to research doomsday bugs - like this one that has been ignored for what 2 years now ?
Thanks for the dismissal though - I'll keep it in mind when I next get tempted to research doomsday bugs - like this one that has been ignored for what 2 years now ?
What do you want, a medal? :thumb: I give thanks for useful information.
Seriously, though, better late than never. The biggest failing I see here is that neither me or DaniJ uses a modern ATI card daily -- we really should.
Hey thanks a lot Yagisan for investigating the issue and Skyjake for fixing this (I'm suprised you're still at it after all these years), :yay: Doom looks as pretty as a classic Disney cartoon on Doomsday.
I think ATI cards aren't perceived as "sexy" as nVidia's. Maybe because they're cheaper? My HD4670 was certainly the cheapest way to get relatively modern performance on my old box - it copes well with Fallout 3, Bioshock and I can even get playable frame rates on Crysis on my poor overheating P4HT. The new HD4890s are pretty cheap.
Oh wait, I suppose I'll have to request a name change?
Well as far as I know, ATi have the fastest card on the block right now - or at least as of a month ago or something. The HD4890 X2 or something... i'm not up-to-date with video cards.
Oh, nah the nVidia GTX295 is faster apparently. Lawl.
Anyway, I remember on a previous version of Doomsday I had a *different* graphikal glitch on my HD3200 (onboard). I found that turning on texture clamping and locking the Z-buffer depth (or something?) fixed it but then it ran like a dog. Then I realized that it was only an OpenGL issue, whereas Direct3D worked fine. Insignificant now though as I run a 9600GT that was shit loads cheaper than the ATi HD3800 (which isnt even as good according to benchmarks).
Considering the original drafters of the Glide specification, 3DFX, had all their tech liquidated into nVidia R&D some years ago, it'd make sense that nVidia kind of pave-the-way for OpenGL specifications or something like that. ATi always sort of was the shadow of nVidia, but their main drive always used to be Home Theater and Mobility/Integrated solutions. Even now that they are owned by AMD, they are still smaller than nVidia. Regardless, I think the Fusion platform will be interesting... the Intel and nVidia Laptop scene will be under threat from AMD Fusion, but nVidia Ion platform might storm the Netbook industry. Either way, i'd be happy if all Intel GMA's were left dead.
Ahem... So skyjake fixed the coord call? Nice work
If I understand, I don't need to submit a bug report. This is the bug that was fixed? Those are supposed to be "windows", but they flash and blink between windows (like the one nearest to me) and orange boxes (like the two farthest away).
Since when did the Ethereal Crossbow get a new model? Looks nice! On another note, looking at the wall on the left I can see how the Texture has "restarted" (because it's a new wall) and you're presented with a physical line... maybe in future we can see Doomsday do some-kind of "megatexture pointmapping" that can detect if a different-angled wall is connected but assigned the same texture to just wrap the graphic and continue... if you know what I mean. That'd be cool, but I assume such a thing would come along with stuff like psuedo Curved Surfaces (e.g., Quake 3) and Model-Based mapping. By that I mean, post Deng 2
looking at the wall on the left I can see how the Texture has "restarted" (because it's a new wall) and you're presented with a physical line... maybe in future we can see Doomsday do some-kind of "megatexture pointmapping" that can detect if a different-angled wall is connected but assigned the same texture to just wrap the graphic and continue...
All surfaces which are part of the physical map (basically walls and floors) take a unique set of coordinates which are used to align textures upon them. In the DOOM, Heretic and Hexen, said coordinates are specified within the map format itself. This means that responsibility for correctly aligned textures belongs with the map's author(s).
However, there is the possiblity for an algorithm that would attempt to automatically align world surface textures (many editors such as DOOM Builder already feature such functionality). The problem with such an algorithm in the context of Doomsday's map loader is that it would be in direct competition with the intention of the original map author(s). For example, a frequent practice is to deliberately miss-align textures in a mathematical sense but by doing so, a more visually pleasing result is achieved.
As has already been announced, part of the plan for the 2.0 Doomsday architecture is the integration of (some) key mod-authoring functionality, including an in-game map editor. An automatical tool for aligning textures would be part of the necessary featureset of such an editor. So, as this means we will be implementing such logic at some point anyway, there would be relatively little additional work involved in allowing the user to (optionally) have the engine run this algorithm on all maps as part of the map load process.
I have a pretty good understanding of what is required for such an algorithm, what with the experience I've gained through various automatical map generator side-projects that I've tinkered with over the years (anyone remember the ever-delayed SCUDD?). Of particular note is the algorithm used for this very purpose devised by David Chess for his Slige project. A key feature of the implementation allowed the user to influence results by supplying additional metadata for textures, which is used to guide the auto-align logic.
The problem with such an algorithm in the context of Doomsday's map loader is that it would be in direct competition with the intention of the original map author(s).
Well, in regards to IWAD's there could be perhaps some DED sector supplements or something like that (a sort of "patch" file) that could predict a continuation of a texture and adjust alignment appropriately on map generation or something, IDK just spinning ideas really.
For example, a frequent practice is to deliberately miss-align textures in a mathematical sense but by doing so, a more visually pleasing result is achieved.
Yeah, i'm familiar with that sort of thing. I understand how some from history would do some 3D engine trickery (hacks even) to achieve a sense of 'fake' perspective or dimension, probably a similar thing. Hel, Doom is a 2.5D game after all.
As has already been announced, part of the plan for the 2.0 Doomsday architecture is the integration of (some) key mod-authoring functionality, including an in-game map editor. An automatical tool for aligning textures would be part of the necessary featureset of such an editor.
I have a pretty good understanding of what is required for such an algorithm, what with the experience I've gained through various automatical map generator side-projects that I've tinkered with over the years (anyone remember the ever-delayed SCUDD?).
Of particular note is the algorithm used for this very purpose devised by David Chess for his Slige project. A key feature of the implementation allowed the user to influence results by supplying additional metadata for textures, which is used to guide the auto-align logic.
Hey that's close to what I was thinking for my reply on the first quote here. But yeah - to actually provide extra instructions for the already existing alignment... I would assume that the said "auto-align tex-cord logic" would have to be relatively close to the core of the graphic engine, unless of course it generates new 'Normals' at load time.
Comments
I have exactly the same issue as the OP and I'm using an ATI HD4670. Could you tell me what this problem is or point me to the bug track page?
At present, it makes Doomsday unplayable, these textures are displayed properly in GZDoom. It's a shame as Doomsday is a prettier engine and I was looking forward to seeing how it had developed since I last ran Doom some years ago. Everything else about the package is excellent.
Cheers.
According to the DE blog, it seems that not a lot is going to be changed for the next version, but this fix would make it an awesome release.
I'll be frank and state what is obvious from the picture - I did take it from my shinka port - which was last rebased against doomsday 1.9.0-beta6.2 - there are NO changes in the opengl renderer from doomsday (you can check the git repo to verify if you wish).
Please note the OpenGL information in the screenshot,
And the results are:
I've leave it to you to draw your own conclusions from this.
I was visiting the folks today and remembered my dad has a PC with an ATI Radeon 9600. Upon first try everything seemed to work perfectly, using the old ATI driver from 2006 (atiogl1x.dll 6.14.10.1030). I then upgraded to the latest one available (from April 2009, atioglxx.dll 6.14.10.8543) and the masked textures were no longer rendered correctly.
After a bit of checking I found the problem: the texture coordinates for the masked walls were not specified correctly according to the OpenGL specs of glMultiTexCoord2f. It's now fixed for Beta6.5.
Apparently the old ATI drivers (and Nvidia drivers, for that matter) are more forgiving when it comes to using values that are not valid according to the spec.
That's at least 2 sets of ATI drivers (opensource and closed source), nvidia drivers, intel drivers.
Thanks for the dismissal though - I'll keep it in mind when I next get tempted to research doomsday bugs - like this one that has been ignored for what 2 years now ?
Seriously, though, better late than never. The biggest failing I see here is that neither me or DaniJ uses a modern ATI card daily -- we really should.
I think ATI cards aren't perceived as "sexy" as nVidia's. Maybe because they're cheaper? My HD4670 was certainly the cheapest way to get relatively modern performance on my old box - it copes well with Fallout 3, Bioshock and I can even get playable frame rates on Crysis on my poor overheating P4HT. The new HD4890s are pretty cheap.
Oh wait, I suppose I'll have to request a name change?
Well as far as I know, ATi have the fastest card on the block right now - or at least as of a month ago or something. The HD4890 X2 or something... i'm not up-to-date with video cards.
Oh, nah the nVidia GTX295 is faster apparently. Lawl.
Anyway, I remember on a previous version of Doomsday I had a *different* graphikal glitch on my HD3200 (onboard). I found that turning on texture clamping and locking the Z-buffer depth (or something?) fixed it but then it ran like a dog. Then I realized that it was only an OpenGL issue, whereas Direct3D worked fine. Insignificant now though as I run a 9600GT that was shit loads cheaper than the ATi HD3800 (which isnt even as good according to benchmarks).
Considering the original drafters of the Glide specification, 3DFX, had all their tech liquidated into nVidia R&D some years ago, it'd make sense that nVidia kind of pave-the-way for OpenGL specifications or something like that. ATi always sort of was the shadow of nVidia, but their main drive always used to be Home Theater and Mobility/Integrated solutions. Even now that they are owned by AMD, they are still smaller than nVidia. Regardless, I think the Fusion platform will be interesting... the Intel and nVidia Laptop scene will be under threat from AMD Fusion, but nVidia Ion platform might storm the Netbook industry. Either way, i'd be happy if all Intel GMA's were left dead.
Ahem... So skyjake fixed the coord call? Nice work
http://img403.imageshack.us/img403/8115 ... ext000.jpg
If I understand, I don't need to submit a bug report. This is the bug that was fixed? Those are supposed to be "windows", but they flash and blink between windows (like the one nearest to me) and orange boxes (like the two farthest away).
Thanks!!
codone
jHeretic Resource Pack (jHRP)
http://forums.newdoom.com/showthread.php?t=11686
(Hooraayy!!!)
See picture below!
http://img248.imageshack.us/img248/6571 ... ext002.jpg
Since when did the Ethereal Crossbow get a new model? Looks nice! On another note, looking at the wall on the left I can see how the Texture has "restarted" (because it's a new wall) and you're presented with a physical line... maybe in future we can see Doomsday do some-kind of "megatexture pointmapping" that can detect if a different-angled wall is connected but assigned the same texture to just wrap the graphic and continue... if you know what I mean. That'd be cool, but I assume such a thing would come along with stuff like psuedo Curved Surfaces (e.g., Quake 3) and Model-Based mapping. By that I mean, post Deng 2
However, there is the possiblity for an algorithm that would attempt to automatically align world surface textures (many editors such as DOOM Builder already feature such functionality). The problem with such an algorithm in the context of Doomsday's map loader is that it would be in direct competition with the intention of the original map author(s). For example, a frequent practice is to deliberately miss-align textures in a mathematical sense but by doing so, a more visually pleasing result is achieved.
As has already been announced, part of the plan for the 2.0 Doomsday architecture is the integration of (some) key mod-authoring functionality, including an in-game map editor. An automatical tool for aligning textures would be part of the necessary featureset of such an editor. So, as this means we will be implementing such logic at some point anyway, there would be relatively little additional work involved in allowing the user to (optionally) have the engine run this algorithm on all maps as part of the map load process.
I have a pretty good understanding of what is required for such an algorithm, what with the experience I've gained through various automatical map generator side-projects that I've tinkered with over the years (anyone remember the ever-delayed SCUDD?). Of particular note is the algorithm used for this very purpose devised by David Chess for his Slige project. A key feature of the implementation allowed the user to influence results by supplying additional metadata for textures, which is used to guide the auto-align logic.