D2X for MS-Windows
D2's setup has nothing to do with D2X, as D2X is entirely Win32 and cross-platform code. Few configuration-related items (other than pilot files) from D2 are ever looked at in D2X. If your sound is choppy, it might be your version of SDL (use the one that comes in the archive, it should work fine), or a sound driver problem. Or maybe even something that I'm wholly unaware of. I can't say I'm a professional
Use where?Meathead wrote:hmm, 2 problems.
1. D2 drops out if you try to use a name more then once
I don't have that joystick, so can't look into this.Meathead wrote:2. It only recognizes the buttons on the throttle of my Saitek X45
Probably easy fixes, figured I'd post here though.
Looked good so far Diedel
D2(X) does not distinguish between the various input sources when evaluating turn commands. So whether you turn with keyboard, mouse or joystick, it's all gathered in the same variable.Ferno wrote:from what i can determine you can turn 1.5x to 2x faster than stock. fire up d2 (the factory version) and see how fast you turn.
Is joystick input tied in with mouse input?
D2 samples the input device every frame it renders. The more frames, the more samples. It scales the movement speeds by the frame time to keep everything constant. Unfortunately, this does not work for mouse input. If the mouse is sampled too often, it gets extremely inert. This is probably due to the ballistic movement provided by the drivers being killed when sampling the mouse too often.
Now to fix mouse sensitivity, I have limited input device sampling to 30 times a second. All movement is now scaled by that prolongued frame time. This helps the mouse. Actually, keyboard turning should not be faster now than when limiting the frame rate to 30 fps.
This only affects turn/roll/pitch movements though, not the ship speed. It is equivalent to making controls more sensitive.
If that's not possible with the other d2 versions, it will not be with mine.DCrazy wrote:If that's the case, Diedel, watch out for the infamous double-afterburner big that plagued the D3 demo. You could bind multiple keys/joystick buttons to the afterburner and thereby get double, or triple the speed from the afterburner.
I know there was no D2 double-AB bug, but from the description that Diedel gave of his input handling, I thought that it might be possible to trigger a similar bug in his version of D2X. It depends on whether the input code uses booleans like "AB key is on" (and thus no matter how many AB keys you're holding down AB is either on or off) or if the code says "AB's on, set speed a bit higher!" (and thus makes your speed that much higher for each AB key you hold down, as was the problem with D3's coding).DCrazy wrote:If that's the case, Diedel, watch out for the infamous double-afterburner big that plagued the D3 demo.
Just put it in, Diedel It really does help. The lasers looks as they do in the last laser screenshot I posted without my fix:
Which is actually the expected behavior. Why your ATI card doesn't draw it this way is beyond me.
Oh yeah, missile glow faces shouldn't be full bright, I checked that in D2 Win95. It would probably have been too painful to fix anyway.
"...there's static after every explosion."
Sounds to me like you're getting 8 bit audio. Strange. More info (OS, sound card, DirectX, etc) might be useful, but I doubt there is much that can be done to help
It really does help. The lasers looks as they do in the last laser screenshot I posted without my fix:Which is actually the expected behavior. Why your ATI card doesn't draw it this way is beyond me.
Oh yeah, missile glow faces shouldn't be full bright, I checked that in D2 Win95. It would probably have been too painful to fix anyway.
"...there's static after every explosion."
Sounds to me like you're getting 8 bit audio. Strange. More info (OS, sound card, DirectX, etc) might be useful, but I doubt there is much that can be done to help
-
Lothar
- DBB Ghost Admin
- Posts: 12133
- Joined: Thu Nov 05, 1998 12:01 pm
- Location: I'm so glad to be home
- Contact:
WRT my sound:
I can run D2 setup, and configure my sound how I think is appropriate. In fact, I can even run the D2-win95 version (at like 500 FPS) and the sound is fine. When I run D2x, though, my sound is totally different -- and when I exit, it's changed my config file.
Here's my *WORKING* d1x descent.cfg file (the relevant parts):
I removed the -sound22k option from the d2x.ini file, but that didn't change anything.
Anyone have any ideas? Why is D2x overwriting my config file and hosing my sound?
I can run D2 setup, and configure my sound how I think is appropriate. In fact, I can even run the D2-win95 version (at like 500 FPS) and the sound is fine. When I run D2x, though, my sound is totally different -- and when I exit, it's changed my config file.
Here's my *WORKING* d1x descent.cfg file (the relevant parts):
Here's what I get when I run D2 setup and select the sound settings I want (this gives me good sound in regular D2):DigiDeviceID=0xe016
DigiVolume=6
DigiPort=0x240
DigiIrq=5
DigiDma=3
MidiDeviceID=0xa009
MidiPort=0x388
MidiVolume=0
StereoReverse=0
But after I run D2x, my config file gets hosed:DigiDeviceID8=0xe016
DigiDeviceID16=0xe018
DigiPort=0x240
DigiIrq=5
DigiDma8=3
DigiDma16=3
DigiVolume=3
MidiDeviceID=0x0
MidiPort=0xffffffff
MidiVolume=0
StereoReverse=0
RedbookEnabled=0
All the other relevant info is completely gone from the config file. It's like D2x is replacing it with its own config file.DigiVolume=3
MidiVolume=0
RedbookEnabled=0
RedbookVolume=8
StereoReverse=0
I removed the -sound22k option from the d2x.ini file, but that didn't change anything.
Anyone have any ideas? Why is D2x overwriting my config file and hosing my sound?
Your screen shot looks like it's not from my current D2X version, but from an older one with a transparent blend mode.pATCheS wrote:Just put it in, Diedel
Which is actually the expected behavior. Why your ATI card doesn't draw it this way is beyond me.
Oh yeah, missile glow faces shouldn't be full bright, I checked that in D2 Win95. It would probably have been too painful to fix anyway.
The line numbers you gave for your change also do not match with those I'd have to change in my object.c file.
-
Lothar
- DBB Ghost Admin
- Posts: 12133
- Joined: Thu Nov 05, 1998 12:01 pm
- Location: I'm so glad to be home
- Contact:
The one I downloaded from your webpage yesterday morning.Which d2x version are you running?
Shortcut target is C:\Games\Descent2\d2x-gl.exeDiedel wrote:I wonder whether you are actually running d2x-gl.exe.
I've also run it directly from the command line.
It's not touching d1x.ini -- it's touching descent.cfg and removing all of my sound config, resetting it to the awful 8-bit static settings.It does not touch d1x.ini
I've deleted, copied, renamed, and recreated the file multiple times. I'm quite sure it's not cross-linked with anything else.Maybe you check your harddisk, too (cross-linked sectors, if there's any such thing nowadays?)
I think D2X removes all parameters from descent.cfg it does not need. Sound in D2X is created differently than in D2 (via SDL).
The -sound22k switch definitely works. There is only 8 bit sound available though. I tried 16 bit sound and almost ruined my ears.
Btw, I have fixed the Omega bug (was caused by some "lighting hack").
A new exe is available on my web site.
The -sound22k switch definitely works. There is only 8 bit sound available though. I tried 16 bit sound and almost ruined my ears.
Btw, I have fixed the Omega bug (was caused by some "lighting hack").
A new exe is available on my web site.
"The line numbers you gave for your change also do not match with those I'd have to change in my object.c file."
I think that's because I did some formatting above there so I could make more sense of the code around that area. But it was close enough, right?
grrr... As I feared, other things that need to not get lit, like the sniper bots' fire, is getting lit too, so I will have to work on the test used; looking at energy usage alone isn't good enough.
Are there any flat-colored polys in D2 that need lighting, other than walls (with the detail way down)? Lighting information could be much more easily and effectively dumped at the renderer for such polys if this is the case.
hmm, I've been working with render_mine() a bit, and the draw order is now correct!
I'm still working on it though, and framerate is currently a problem... At 1280x960, my vid card should have zero trouble staying at 80 FPS the entire time, and I've seen it go as low as 30 o.0 Sometimes it will hover around 40... very strange.
I think that's because I did some formatting above there so I could make more sense of the code around that area. But it was close enough, right?
grrr... As I feared, other things that need to not get lit, like the sniper bots' fire, is getting lit too, so I will have to work on the test used; looking at energy usage alone isn't good enough.
Are there any flat-colored polys in D2 that need lighting, other than walls (with the detail way down)? Lighting information could be much more easily and effectively dumped at the renderer for such polys if this is the case.
hmm, I've been working with render_mine() a bit, and the draw order is now correct!
I'm still working on it though, and framerate is currently a problem... At 1280x960, my vid card should have zero trouble staying at 80 FPS the entire time, and I've seen it go as low as 30 o.0 Sometimes it will hover around 40... very strange.
Some robots use flat color shading instead of textures, especially in lieu of eye textures or the red flickering "rocket" texture (e.g. on the back of the PIG robots). Whenever flat colors are used on robots, they are supposed to glow fullbright.pATCheS wrote:Are there any flat-colored polys in D2 that need lighting, other than walls (with the detail way down)? Lighting information could be much more easily and effectively dumped at the renderer for such polys if this is the case.
Did you use the source code version where I had added setting the blend mode ("glBlendFunc (GL_ONE, GL_ONE_MINUS_SRC_ALPHA);")? I could observe the lighting problem on my GF MX 400, so I've added your fix. I have modified it a little: It will only take effect if the complete polymodel is blended together from several polys. Maybe that will take care of the sniper shots erroneously being lit up.pATCheS wrote:"The line numbers you gave for your change also do not match with those I'd have to change in my object.c file."
I think that's because I did some formatting above there so I could make more sense of the code around that area. But it was close enough, right?
Please send me your version of render.c. E-Mail address see PM.pATCheS wrote:hmm, I've been working with render_mine() a bit, and the draw order is now correct!
Ok, now I've actually fixed the lighting (I hope, heheh).
Based on the fact that there are no polymodels with single color polys that need shading, you can just remove the shading for said polys. The place to do that is in g3_draw_polygon_model(), under case OP_FLATPOLY. There are three lines in interp.c, the first of which reads
l = f2i(fixmul(i2f(32), model_light));
that need to be commented out. After them, add
l = 32;
and rebuild. The blending stuff that's been added needs to stay, so that the inner bolts see the light of day, but the code I added to change light for energy-using weapons can go.
Based on the fact that there are no polymodels with single color polys that need shading, you can just remove the shading for said polys. The place to do that is in g3_draw_polygon_model(), under case OP_FLATPOLY. There are three lines in interp.c, the first of which reads
l = f2i(fixmul(i2f(32), model_light));
that need to be commented out. After them, add
l = 32;
and rebuild. The blending stuff that's been added needs to stay, so that the inner bolts see the light of day, but the code I added to change light for energy-using weapons can go.
patches,
sorry that I have to disappoint you but your "fix" to rendering is none. You have simply disabled the changes I had added and the code path you have left is identical to the original software hidden surface removal. Try Kruel's Koolkave level, and you will see that the "disappearing walls" problem reappears with your changes to render.c.
btw., bLegacyZBuf is of type int, not bool.
Your changes to gr.c::ogl_do_palfx() are buggy because the depth test is not enabled if any of the function's return statements is executed.
It's btw. pretty hard to find your changes because you have neither marked nor described them, and your source files are quite a bit different from mine.
Finally, I had almost deleted your e-mail unread because the subject was not very informative - it looked like some spam to me. If you had at least written "D2X source code" it would have been easier for me to figure where this came from.
sorry that I have to disappoint you but your "fix" to rendering is none. You have simply disabled the changes I had added and the code path you have left is identical to the original software hidden surface removal. Try Kruel's Koolkave level, and you will see that the "disappearing walls" problem reappears with your changes to render.c.
btw., bLegacyZBuf is of type int, not bool.
Your changes to gr.c::ogl_do_palfx() are buggy because the depth test is not enabled if any of the function's return statements is executed.
It's btw. pretty hard to find your changes because you have neither marked nor described them, and your source files are quite a bit different from mine.
Finally, I had almost deleted your e-mail unread because the subject was not very informative - it looked like some spam to me. If you had at least written "D2X source code" it would have been easier for me to figure where this came from.
hmm, I thought the "patches" in "patches11" would have sparked. Oh well.
You'll have to e-mail me the level. I can't seem to find it anywhere.
If bLegacyZBuf is an int, why isn't it "iLegacyZBuf"? I had counted on it having been accurately named. I knew I shoulda checked... I blame it on you. Bad Diedel, bad!
About ogl_do_palfx(), the depth test gets re-enabled every frame anyway, so it wouldn't affect anything if the re-enable were removed altogether. I wonder if it's time to use the OGL_[EN,DIS]ABLE macros to remove any redundant state setting (though I imagine it's not so bad with the Z buffer)... couldn't hurt.
Hmm, I thought it would be pretty easy to spot the changes that were mine, but I can see how that's kinda short-sighted. I'll be sure to comment on any changes I make in the future.
hehe, yeah, my render code *is* equivalent... oops There aren't many levels with rendering problems like those which you neither describe nor show shots of, because the original rendering system is what most were designed for. I'll try to find a level with complex enough geometry... I think that the artifacts you see might be a result of what is technically illegal geometry anyway (4D comes to mind) which could cause cube sides to show where they "shouldn't".
You'll have to e-mail me the level. I can't seem to find it anywhere.
If bLegacyZBuf is an int, why isn't it "iLegacyZBuf"? I had counted on it having been accurately named. I knew I shoulda checked... I blame it on you. Bad Diedel, bad!
About ogl_do_palfx(), the depth test gets re-enabled every frame anyway, so it wouldn't affect anything if the re-enable were removed altogether. I wonder if it's time to use the OGL_[EN,DIS]ABLE macros to remove any redundant state setting (though I imagine it's not so bad with the Z buffer)... couldn't hurt.
Hmm, I thought it would be pretty easy to spot the changes that were mine, but I can see how that's kinda short-sighted. I'll be sure to comment on any changes I make in the future.
hehe, yeah, my render code *is* equivalent... oops
There aren't many levels with rendering problems like those which you neither describe nor show shots of, because the original rendering system is what most were designed for. I'll try to find a level with complex enough geometry... I think that the artifacts you see might be a result of what is technically illegal geometry anyway (4D comes to mind) which could cause cube sides to show where they "shouldn't".bLegacyZBuf is of type int, but has the semantics of a boolean. I wonder where you got the type "bool" from anyway - it's not a standard C type.
The code in ogl_do_palfx() is buggy, period. No excuses here.
There are quite a few levels with disappearing walls and valid geometry. All you need is a tight enough angle between two faces. Load my multiplayer level "Dogfight!" - which has pretty simple architecture - turn left 90°, fly down the tunnel to where it turns right and look at where the tunnels splits in two. Just one simple example. As far as "describing" the problem goes: "Disappearing walls" pretty much sums it up, and I wrote this a couple of times here.
Koolkave is available on PlanetDescent in the D2 multiplayer missions section under "K".
Btw, before you can tell me what's good and bad coding style, a lot of time has to pass. I'm in this business for over 15 years.
And what's this "patches11" stuff?
There is a German word for your working style, and it's "schlampig".
As a side note: I found 10 (!) different English words for this in an online dictionary.
Now you know why Germans are famous for the quality of their work.
The code in ogl_do_palfx() is buggy, period. No excuses here.
There are quite a few levels with disappearing walls and valid geometry. All you need is a tight enough angle between two faces. Load my multiplayer level "Dogfight!" - which has pretty simple architecture - turn left 90°, fly down the tunnel to where it turns right and look at where the tunnels splits in two. Just one simple example. As far as "describing" the problem goes: "Disappearing walls" pretty much sums it up, and I wrote this a couple of times here.
Koolkave is available on PlanetDescent in the D2 multiplayer missions section under "K".
Btw, before you can tell me what's good and bad coding style, a lot of time has to pass. I'm in this business for over 15 years.
And what's this "patches11" stuff?
There is a German word for your working style, and it's "schlampig".
As a side note: I found 10 (!) different English words for this in an online dictionary.
Now you know why Germans are famous for the quality of their work.
-
SuperSheep
- DBB Benefactor
- Posts: 935
- Joined: Sun Jun 03, 2001 2:01 am
- Location: Illinois
"bLegacyZBuf is of type int, but has the semantics of a boolean. I wonder where you got the type "bool" from anyway - it's not a standard C type."
I don't program in pure C because my compiler doesn't require me to
"The code in ogl_do_palfx() is buggy, period. No excuses here."
Shut up. That one's minor and in the end has no effect (Z buffering is re-enabled every frame).
"As far as "describing" the problem goes: "Disappearing walls" pretty much sums it up, and I wrote this a couple of times here."
Curiously, only upon inserting the command line option -legacyzbuf into my d2x.ini and going to that area of your level did I finally realize what you were talking about. It is not "disappearing walls" that you speak of, but rather, walls getting drawn over by walls behind them. The walls that are drawing over simply cause the walls to "disappear". If the walls were actually disappearing, it would have been an issue with true/false visibility determination (most likely varying sorts of clipping, since backface culling tends to be pretty reliable and I dunno what else might do something like that), which has nothing to do with drawing order. These are two completely different things.
"Koolkave is available on PlanetDescent in the D2 multiplayer missions section under "K"."
DOH!
Wanna know what's funnier than that?
I already had it, from a collection of levels someone gave me a while back. I thought it might be a more obscure level than that.
DOH!
"Btw, before you can tell me what's good and bad coding style, a lot of time has to pass. I'm in this business for over 15 years."
I never once said there was anything bad about your coding style. In the files I gave you, I reformatted some of it only so I could read it more easily. I don't know how this could possibly be offensive or in any way wrong.
"And what's this "patches11" stuff?"
I thought that you'd see my e-mail addy, not my name. My bad. I don't normally send e-mail to people I don't know fairly well, so I almost never hear about it. I usually leave subject lines blank, you should consider yourself lucky
So, you say my files didn't fix anything?
Click! (1280x960, 179kb)
That's your latest build versus mine. I also tried inserting the three files I sent you exactly as they were in the e-mail into their corresponding locations in the source tree I derived them from, as well as the latest source from your site, made the changes to interp.c I described in my previous post, and got perceptual results identical to my build. You did something wrong.
"There is a German word for your working style, and it's "schlampig"."
Care to enlighten me on the meaning of this word? Or is it just some simplistic, underdescriptive insult shoved in my general direction? I wouldn't know, and very well may need to. Self-improvement is kinda important, you know.
"Now you know why Germans are famous for the quality of their work."
It certainly has nothing to do with pride and arrogance. Anyone can tell you that.
Realize also that I'm a month shy of 18 years old. You have been programming for almost as long as I have been alive. That I am as good as I am at this stuff is amazing in itself, especially being an American who has had no formal education or experience on the subject of programming. At least, not any that was of any particular use; Beginning Pascal doesn't exactly count for much. evil Pascal.
Anyone who wants one of my builds can contact me via e-mail. Since I base my work off of Diedel's, he will remain the source of public versions of D2X-GL.
"Diedel, I have a suggestion that may fix the non-lit items, try disabling lighting before rendering the bright objects and re-enabling after."
My most recent fix for lighting essentially does just that. The only things that were having any problems were single color polys on objects, and that's exactly what the code my fix goes in handles. Lighting in D2 isn't enabled or disabled, it is just passed along as full bright, or somewhere between that and black.
I don't program in pure C because my compiler doesn't require me to
"The code in ogl_do_palfx() is buggy, period. No excuses here.
"Shut up. That one's minor and in the end has no effect (Z buffering is re-enabled every frame).
"As far as "describing" the problem goes: "Disappearing walls" pretty much sums it up, and I wrote this a couple of times here."
Curiously, only upon inserting the command line option -legacyzbuf into my d2x.ini and going to that area of your level did I finally realize what you were talking about. It is not "disappearing walls" that you speak of, but rather, walls getting drawn over by walls behind them. The walls that are drawing over simply cause the walls to "disappear". If the walls were actually disappearing, it would have been an issue with true/false visibility determination (most likely varying sorts of clipping, since backface culling tends to be pretty reliable and I dunno what else might do something like that), which has nothing to do with drawing order. These are two completely different things.
"Koolkave is available on PlanetDescent in the D2 multiplayer missions section under "K"."
DOH!
Wanna know what's funnier than that?
I already had it, from a collection of levels someone gave me a while back. I thought it might be a more obscure level than that.
DOH!
"Btw, before you can tell me what's good and bad coding style, a lot of time has to pass. I'm in this business for over 15 years."
I never once said there was anything bad about your coding style. In the files I gave you, I reformatted some of it only so I could read it more easily. I don't know how this could possibly be offensive or in any way wrong.
"And what's this "patches11" stuff?"
I thought that you'd see my e-mail addy, not my name. My bad. I don't normally send e-mail to people I don't know fairly well, so I almost never hear about it. I usually leave subject lines blank, you should consider yourself lucky
So, you say my files didn't fix anything?
Click! (1280x960, 179kb)
That's your latest build versus mine. I also tried inserting the three files I sent you exactly as they were in the e-mail into their corresponding locations in the source tree I derived them from, as well as the latest source from your site, made the changes to interp.c I described in my previous post, and got perceptual results identical to my build. You did something wrong.
"There is a German word for your working style, and it's "schlampig"."
Care to enlighten me on the meaning of this word? Or is it just some simplistic, underdescriptive insult shoved in my general direction? I wouldn't know, and very well may need to. Self-improvement is kinda important, you know.
"Now you know why Germans are famous for the quality of their work."
It certainly has nothing to do with pride and arrogance. Anyone can tell you that.
Realize also that I'm a month shy of 18 years old. You have been programming for almost as long as I have been alive. That I am as good as I am at this stuff is amazing in itself, especially being an American who has had no formal education or experience on the subject of programming. At least, not any that was of any particular use; Beginning Pascal doesn't exactly count for much. evil Pascal.
Anyone who wants one of my builds can contact me via e-mail. Since I base my work off of Diedel's, he will remain the source of public versions of D2X-GL.
"Diedel, I have a suggestion that may fix the non-lit items, try disabling lighting before rendering the bright objects and re-enabling after."
My most recent fix for lighting essentially does just that. The only things that were having any problems were single color polys on objects, and that's exactly what the code my fix goes in handles. Lighting in D2 isn't enabled or disabled, it is just passed along as full bright, or somewhere between that and black.
You are lucky you didn't try to tell me face to face to shut up.
I don't care about your compiler's requirements. D2X is standard C, so mixing it with C++ is not a good idea.
It doesn't matter whether a bug has no or little effect or not. It's a bug. And it's significant for your sloppy approach to coding and your lack of diligence there.
Think about what a diff will yield when you reformat parts of a source file. I simply gave up trying to find all your relevant changes after a while. On the other hand, if you take a look into my D2X source archive you will find a text file there describing every change I had made to the source code.
I also did not say that my changes to D2X are perfect. I have however done more for this project in the last few months than most other people, you included.
Sure does framerate drop with my code, as I simply push all triangles to the graphics driver. But in exchange I get a properly rendered mine at least, which I consider far more significant than distorted bot eyes (which I simply didn't notice, so didn't investigate into).
Contrary to what you believe, D2 does not render distant walls over closer ones in some instances. It doesn't render the closer ones occasionally, hence "disappearing walls". If you had bothered firing up a level editor and checking which walls disappear and which get visible because of that, that would have become clear to you.
You seem to have failed to understand that "-legacyzbuf" simply disables all my changes to rendering. The "Z artifacts" you marked in the related screen shot are "disappearing walls".
I consider your triumphant attitude about my changes rather pathetic. What did you do to fix the problems? Nothing so far. I don't consider an increased frame rate significant here.
Btw, I didn't say your changes do nothing. I said that the particular change where you disabled my additions to rendering simply reverted everything to standard software hidden surface removal, meaning that it did not fix the disappearing wall problem. What's an increased frame rate good for if the rendering is still broken?
I guess you hadn't even bothered trying to find Koolkave, which is a prime example of what can be done with the D2 engine by one of the - if not the - greatest D2 level designers ever.
For me, this all sums up to you working pretty
"schlampig":
blowzy adj. schlampig
dowdy adj. schlampig
frouzy adj. schlampig
frowsy adj. schlampig
frowzy adj. schlampig
grubby adj. schlampig
slatternly adv. schlampig
sleazy adj. schlampig
slipshod adj. schlampig
sloppy adj. schlampig
slovenly adj. adv. schlampig
sluttish adj. schlampig
sluttishly adv. schlampig
slutty adj. schlampig
Cut and pasted from an online dictionary in about 20 seconds.
So much to the overall quality of your work and general dealings with this project, communications, etc.
Me thinks that from what you write it shines through that you are the one who is pretty arrogant. You obviously think you are the coding uber kid here, huh?
You can start talking big when you've actually fixed all the remaining rendering problems.
I don't care about your compiler's requirements. D2X is standard C, so mixing it with C++ is not a good idea.
It doesn't matter whether a bug has no or little effect or not. It's a bug. And it's significant for your sloppy approach to coding and your lack of diligence there.
Think about what a diff will yield when you reformat parts of a source file. I simply gave up trying to find all your relevant changes after a while. On the other hand, if you take a look into my D2X source archive you will find a text file there describing every change I had made to the source code.
I also did not say that my changes to D2X are perfect. I have however done more for this project in the last few months than most other people, you included.
Sure does framerate drop with my code, as I simply push all triangles to the graphics driver. But in exchange I get a properly rendered mine at least, which I consider far more significant than distorted bot eyes (which I simply didn't notice, so didn't investigate into).
Contrary to what you believe, D2 does not render distant walls over closer ones in some instances. It doesn't render the closer ones occasionally, hence "disappearing walls". If you had bothered firing up a level editor and checking which walls disappear and which get visible because of that, that would have become clear to you.
You seem to have failed to understand that "-legacyzbuf" simply disables all my changes to rendering. The "Z artifacts" you marked in the related screen shot are "disappearing walls".
I consider your triumphant attitude about my changes rather pathetic. What did you do to fix the problems? Nothing so far. I don't consider an increased frame rate significant here.
Btw, I didn't say your changes do nothing. I said that the particular change where you disabled my additions to rendering simply reverted everything to standard software hidden surface removal, meaning that it did not fix the disappearing wall problem. What's an increased frame rate good for if the rendering is still broken?
I guess you hadn't even bothered trying to find Koolkave, which is a prime example of what can be done with the D2 engine by one of the - if not the - greatest D2 level designers ever.
For me, this all sums up to you working pretty
"schlampig":
blowzy adj. schlampig
dowdy adj. schlampig
frouzy adj. schlampig
frowsy adj. schlampig
frowzy adj. schlampig
grubby adj. schlampig
slatternly adv. schlampig
sleazy adj. schlampig
slipshod adj. schlampig
sloppy adj. schlampig
slovenly adj. adv. schlampig
sluttish adj. schlampig
sluttishly adv. schlampig
slutty adj. schlampig
Cut and pasted from an online dictionary in about 20 seconds.
So much to the overall quality of your work and general dealings with this project, communications, etc.
Me thinks that from what you write it shines through that you are the one who is pretty arrogant. You obviously think you are the coding uber kid here, huh?
You can start talking big when you've actually fixed all the remaining rendering problems.
the first thing is last written: it's 4 am here, I'm tired, I don't think I read your post correctly... please forgive any shortcomings and all the "pissed-offness" in the text below, I can't sort through it all right now. I should have saved this for later >.<
"You are lucky you didn't try to tell me face to face to shut up."
That was purely in humor. If you knew me face to face, you would have understood that. I had a feeling you'd misconstrue that, but damned if I'd ever listen.
"It doesn't matter whether a bug has no or little effect or not. It's a bug. And it's significant for your sloppy approach to coding and your lack of diligence there."
I'm well aware of that. I said that it had no effect to explain why it remained. I have since fixed it.
By "significant for your sloppy approach", do you mean "demonstrative of your sloppy approach"?
"Think about what a diff will yield when you reformat parts of a source file. I simply gave up trying to find all your relevant changes after a while. On the other hand, if you take a look into my D2X source archive you will find a text file there describing every change I had made to the source code."
I only know that a diff shows changes. I know nothing else about it. Remember, I'm the newbie non-professional "programmer" here.
"I also did not say that my changes to D2X are perfect."
No one said they were. But the goal is perfection within the limitations of those working on the project, is it not?
"I have however done more for this project in the last few months than most other people, you included."
This could not be any more plain. I never once said nor implied I had done more than you nor that my changes were any more significant.
"...But in exchange I get a properly rendered mine at least, which I consider far more significant than distorted bot eyes (which I simply didn't notice, so didn't investigate into)."
Heh, after reading that I could ask, "Did you even look at my screenshot?" You didn't notice at all that the rendering problems in Kool Kave are quite fixed in the screenshot of my build, and with a noticeable improvement in framerate? Just in case you can't tell, I'm talking about the one in the bottom right. That is how it looks on my machine with those three files and the lighting fix/hack/whatever in interp.c implemented.
"Contrary to what you believe, D2 does not render distant walls over closer ones in some instances. It doesn't render the closer ones occasionally, hence "disappearing walls". If you had bothered firing up a level editor and checking which walls disappear and which get visible because of that, that would have become clear to you."
You...jesus. Go look in your own level, Dogfight!, with -legacyzbuf, and observe VERY CAREFULLY how the left and right sides of the cubes in the halls on the top of the split draw on top of the bottom cube's top face. The face is still quite there. It's precisely the same thing as in KK, except that it occurs with faces that are big enough to completely cover multiple cubes, hence your "disappearing walls". Do I really need to get a screenie of your level and spell it out for you? I don't think I can make it any more plain without.
"You seem to have failed to understand that "-legacyzbuf" simply disables all my changes to rendering. The "Z artifacts" you marked in the related screen shot are "disappearing walls"."
You seem to fail to understand that the things I marked as Z artifacts are the zoom-ins of the robots, which are there to make the artifacts on their eyes more visible. That text has zero association with the rendering bugs you have sought to fix. And yes, I know full well what the -legacyzbuf command does.
"Btw, I didn't say your changes do nothing. I said that the particular change where you disabled my additions to rendering simply reverted everything to standard software hidden surface removal, meaning that it did not fix the disappearing wall problem. What's an increased frame rate good for if the rendering is still broken?"
The rendering should only be broken if depth testing is disabled. It works just fine for me.
"I guess you hadn't even bothered trying to find Koolkave, which is a prime example of what can be done with the D2 engine by one of the - if not the - greatest D2 level designers ever."
Oh no, I Googled around for it with a number of mutations of Koolkave: koolkave, kool kave, kruel "kool cave", and so on. I never once turned up a site with a good link. Apparently PD is very anti-Google, and my level collection is better than I thought.
"Me thinks that from what you write it shines through that you are the one who is pretty arrogant here."
I tried my damnedest not to be, because I'm often bad about it, until you wrote these:
"Btw, before you can tell me what's good and bad coding style, a lot of time has to pass. I'm in this business for over 15 years."
"There is a German word for your working style, and it's "schlampig"."
"Now you know why Germans are famous for the quality of their work."
First of all, I never said a damn thing about what was good and bad coding style to anyone, never mind to you.
And you say my coding style sucks. Then I think about how you must mean my haphazard way of working on random parts of random things until I get something I like, look it over, and test it to see if it works. But I could be wrong. I do not know what I'm doing wrong nor how to improve because all you have said is that my style is bad, never once why. Very helpful.
"You can start talking big when you've actually fixed all the remaining rendering problems."
Other than the "missing" cube sides (should already be fixed... might be another ATI vs NVIDIA thing, for all I know; need to check the path followed for enabling and disabling depth testing) and the robot eyes (a matter of changing the zfar value to something a little more sane), what else is there?
"You are lucky you didn't try to tell me face to face to shut up."
That was purely in humor. If you knew me face to face, you would have understood that. I had a feeling you'd misconstrue that, but damned if I'd ever listen.
"It doesn't matter whether a bug has no or little effect or not. It's a bug. And it's significant for your sloppy approach to coding and your lack of diligence there."
I'm well aware of that. I said that it had no effect to explain why it remained. I have since fixed it.
By "significant for your sloppy approach", do you mean "demonstrative of your sloppy approach"?
"Think about what a diff will yield when you reformat parts of a source file. I simply gave up trying to find all your relevant changes after a while. On the other hand, if you take a look into my D2X source archive you will find a text file there describing every change I had made to the source code."
I only know that a diff shows changes. I know nothing else about it. Remember, I'm the newbie non-professional "programmer" here.
"I also did not say that my changes to D2X are perfect."
No one said they were. But the goal is perfection within the limitations of those working on the project, is it not?
"I have however done more for this project in the last few months than most other people, you included."
This could not be any more plain. I never once said nor implied I had done more than you nor that my changes were any more significant.
"...But in exchange I get a properly rendered mine at least, which I consider far more significant than distorted bot eyes (which I simply didn't notice, so didn't investigate into)."
Heh, after reading that I could ask, "Did you even look at my screenshot?" You didn't notice at all that the rendering problems in Kool Kave are quite fixed in the screenshot of my build, and with a noticeable improvement in framerate? Just in case you can't tell, I'm talking about the one in the bottom right. That is how it looks on my machine with those three files and the lighting fix/hack/whatever in interp.c implemented.
"Contrary to what you believe, D2 does not render distant walls over closer ones in some instances. It doesn't render the closer ones occasionally, hence "disappearing walls". If you had bothered firing up a level editor and checking which walls disappear and which get visible because of that, that would have become clear to you."
You...jesus. Go look in your own level, Dogfight!, with -legacyzbuf, and observe VERY CAREFULLY how the left and right sides of the cubes in the halls on the top of the split draw on top of the bottom cube's top face. The face is still quite there. It's precisely the same thing as in KK, except that it occurs with faces that are big enough to completely cover multiple cubes, hence your "disappearing walls". Do I really need to get a screenie of your level and spell it out for you? I don't think I can make it any more plain without.
"You seem to have failed to understand that "-legacyzbuf" simply disables all my changes to rendering. The "Z artifacts" you marked in the related screen shot are "disappearing walls"."
You seem to fail to understand that the things I marked as Z artifacts are the zoom-ins of the robots, which are there to make the artifacts on their eyes more visible. That text has zero association with the rendering bugs you have sought to fix. And yes, I know full well what the -legacyzbuf command does.
"Btw, I didn't say your changes do nothing. I said that the particular change where you disabled my additions to rendering simply reverted everything to standard software hidden surface removal, meaning that it did not fix the disappearing wall problem. What's an increased frame rate good for if the rendering is still broken?"
The rendering should only be broken if depth testing is disabled. It works just fine for me.
"I guess you hadn't even bothered trying to find Koolkave, which is a prime example of what can be done with the D2 engine by one of the - if not the - greatest D2 level designers ever."
Oh no, I Googled around for it with a number of mutations of Koolkave: koolkave, kool kave, kruel "kool cave", and so on. I never once turned up a site with a good link. Apparently PD is very anti-Google, and my level collection is better than I thought.
"Me thinks that from what you write it shines through that you are the one who is pretty arrogant here."
I tried my damnedest not to be, because I'm often bad about it, until you wrote these:
"Btw, before you can tell me what's good and bad coding style, a lot of time has to pass. I'm in this business for over 15 years."
"There is a German word for your working style, and it's "schlampig"."
"Now you know why Germans are famous for the quality of their work."
First of all, I never said a damn thing about what was good and bad coding style to anyone, never mind to you.
And you say my coding style sucks. Then I think about how you must mean my haphazard way of working on random parts of random things until I get something I like, look it over, and test it to see if it works. But I could be wrong. I do not know what I'm doing wrong nor how to improve because all you have said is that my style is bad, never once why. Very helpful.
"You can start talking big when you've actually fixed all the remaining rendering problems."
Other than the "missing" cube sides (should already be fixed... might be another ATI vs NVIDIA thing, for all I know; need to check the path followed for enabling and disabling depth testing) and the robot eyes (a matter of changing the zfar value to something a little more sane), what else is there?
How can you expect me to understand that kind of humor of yours I'd need to know you face to face to understand it, if I do not know you face to face? This is something you just don't say easily to somebody you don't know.pATCheS wrote:"You are lucky you didn't try to tell me face to face to shut up."
That was purely in humor. If you knew me face to face, you would have understood that. I had a feeling you'd misconstrue that, but damned if I'd ever listen.
So why the comment?pATCheS wrote:"It doesn't matter whether a bug has no or little effect or not. It's a bug. And it's significant for your sloppy approach to coding and your lack of diligence there."
I'm well aware of that. I said that it had no effect to explain why it remained. I have since fixed it.
You got it.pATCheS wrote:By "significant for your sloppy approach", do you mean "demonstrative of your sloppy approach"?
If you know that, and you know you changed (quite) some formatting, what do you believe a diff will produce in terms of quantity?pATCheS wrote:"Think about what a diff will yield when you reformat parts of a source file. I simply gave up trying to find all your relevant changes after a while. On the other hand, if you take a look into my D2X source archive you will find a text file there describing every change I had made to the source code."
I only know that a diff shows changes. I know nothing else about it. Remember, I'm the newbie non-professional "programmer" here.
You boast pretty much with your screen shot. It stills shows some artifacts in the cave opening though. The disappearing walls effect is btw. extremely dependant from view angle - a slight turn can have D2 render the walls again. And I have not detected any other changes to the rendering code (in render.c) except you disabling my additions. It's no miracle you get a better frame rate if you revert to D2's visibility test. D2 doesn't draw all cube sides. It's rather strange that you only get 66% of the original frame rate and not 100%.pATCheS wrote:"I also did not say that my changes to D2X are perfect."
No one said they were. But the goal is perfection within the limitations of those working on the project, is it not?
"I have however done more for this project in the last few months than most other people, you included."
This could not be any more plain. I never once said nor implied I had done more than you nor that my changes were any more significant.
"...But in exchange I get a properly rendered mine at least, which I consider far more significant than distorted bot eyes (which I simply didn't notice, so didn't investigate into)."
Heh, after reading that I could ask, "Did you even look at my screenshot?" You didn't notice at all that the rendering problems in Kool Kave are quite fixed in the screenshot of my build, and with a noticeable improvement in framerate? Just in case you can't tell, I'm talking about the one in the bottom right. That is how it looks on my machine with those three files and the lighting fix/hack/whatever in interp.c implemented.
Coding style is not just how you write down your lines of code. It's how you organize everything, how diligently you check for bugs (see gr_do_palfx()), how diligently you check other coders' stuff (bool/int bLegacyZBuf), how well you mark and document your changes, how you communicate your changes, etc.pATCheS wrote:"Contrary to what you believe, D2 does not render distant walls over closer ones in some instances. It doesn't render the closer ones occasionally, hence "disappearing walls". If you had bothered firing up a level editor and checking which walls disappear and which get visible because of that, that would have become clear to you."
You...jesus. Go look in your own level, Dogfight!, with -legacyzbuf, and observe VERY CAREFULLY how the left and right sides of the cubes in the halls on the top of the split draw on top of the bottom cube's top face. The face is still quite therSo why is it that a huge face does not cover all faces in front of it but inside the bounds of its 2D projection when it is "mis-rendered"? I believe that D2 simply does not render the faces you considered cover by the huge one, because each cube face (side) is rendered in a piece (eventually split into two triangles, but that's it).pATCheS wrote:e. It's precisely the same thing as in KK, except that it occurs with faces that are big enough to completely cover multiple cubes, hence your "disappearing walls". Do I really need to get a screenie of your level and spell it out for you? I don't think I can make it any more plain without.
pATCheS wrote:"You seem to have failed to understand that "-legacyzbuf" simply disables all my changes to rendering. The "Z artifacts" you marked in the related screen shot are "disappearing walls"."
You seem to fail to understand that the things I marked as Z artifacts are the zoom-ins of the robots, which are there to make the artifacts on their eyes more visible. That text has zero association with the rendering bugs you have sought to fix. And yes, I know full well what the -legacyzbuf command does.
"Btw, I didn't say your changes do nothing. I said that the particular change where you disabled my additions to rendering simply reverted everything to standard software hidden surface removal, meaning that it did not fix the disappearing wall problem. What's an increased frame rate good for if the rendering is still broken?"
The rendering should only be broken if depth testing is disabled. It works just fine for me.
"I guess you hadn't even bothered trying to find Koolkave, which is a prime example of what can be done with the D2 engine by one of the - if not the - greatest D2 level designers ever."
Oh no, I Googled around for it with a number of mutations of Koolkave: koolkave, kool kave, kruel "kool cave", and so on. I never once turned up a site with a good link. Apparently PD is very anti-Google, and my level collection is better than I thought.
"Me thinks that from what you write it shines through that you are the one who is pretty arrogant here."
I tried my damnedest not to be, because I'm often bad about it, until you wrote these:
"Btw, before you can tell me what's good and bad coding style, a lot of time has to pass. I'm in this business for over 15 years."
"There is a German word for your working style, and it's "schlampig"."
"Now you know why Germans are famous for the quality of their work."
First of all, I never said a damn thing about what was good and bad coding style to anyone, never mind to you.
And you say my coding style sucks. Then I think about how you must mean my haphazard way of working on random parts of random things until I get something I like, look it over, and test it to see if it works. But I could be wrong. I do not know what I'm doing wrong nor how to improve because all you have said is that my style is bad, never once why. Very helpful.
"You can start talking big when you've actually fixed all the remaining rendering problems."
Other than the "missing" cube sides (should already be fixed... might be another ATI vs NVIDIA thing, for all I know; need to check the path followed for enabling and disabling depth testing) and the robot eyes (a matter of changing the zfar value to something a little more sane), what else is there?
From what you say about your fix to the "disappearing walls" (or whatever) problem it looks like you simply re-enabled the standard visibility detection and added depth testing.
I have to say that I did not like at all the tone of your last post, and it looks very much to me like you were simply trying to get the better of me somehow, to show that in the end you are the better coder or whatever. I don't know what urges you to do so though. I have acknowledged your solutions where they worked so far, so no need to prove something.
My remark about 10 English and one German words for "schlampig" btw. was my kind of humor. Doh.
"Schlampig" is simply the opposite of diligent.
distorted bot eyes
Turning off the depth test when drawing objects helps, but causes other problems.
disappearing walls
You were right, it is sufficient to enable depth testing. Nice. I had thought the whole visibility test was flawed.