DescentBB

Do they look dark in my screen shot? Tried the brightness slider in the game options already?

Btw, with "-legacyzbuf" you get the original D2 rendering w/o any modifications by me. If that still doesn't look alright to you, it might be your monitor/game settings.

Laser bolt brightness can be fixed by using a different blend mode (I was thinking something like glBlendFunc(GL_ONE, GL_ONE_MINUS_SRC_ALPHA) ) and by not lighting their polymodels. Turn off the alpha blending and shoot your lasers into a dark area, even with your modifications turned off it will light the polymodels (it did it in the original D2X, I can't imagine anything else being the case, seeing how you haven't touched on it yet). This is very very wrong, they should always be full bright, like in the original game using software rendering. Another thing you could try is using the stencil buffer to get the inner bolt on top, but the weapons would need to be drawn back to front for that to work properly (which they probably are anyway), and it would require some playing around to get it working right.

The cloaking powerup fade definitely does not work on my machine, and this is between a GF4MX440 and an FX5700.

Oh, an interesting bug I found: if you get up close to walls and tilt your ship just so, you can get the wall to clip your HUD. o.0


And some new things I've noticed:

In level 1, the hostage door gets drawn before the hostage, so in the translucent part of the hostage door's texturing, the hostage does not show. Some similar things occur with other bitmaps, like weapon explosions (try the Spreadfire close up on a wall, you'll see the edges of things), robot debris, and exploding doors.

When a wall is in the second half of its decloaking process, bitmap objects behind it are not visible.

Z buffering is "broken" again, yielding the artifacts in that other screenshot even on this FX5700 (which I lose tomorrow morning, gotta give it back ). It was working in the last build I tried, but only on this card, it didn't work on my GF4MX440.


No change on the state of command line screen modes.


D2X modified: May 30, 2004, 5:38:18 PM
SDL modified: May 28, 2004, 8:31:58 PM

With -legacyzbuf, no alpha blending or z buffering takes place on my behalf. Blame it on OpenGL or whatever.

Laser bolts do not get "lit". Apart from using the OpenGL Z buffer and rendering laser & fusion bolts transparents, I have not changed the rendering code of D2X. I don't really understand what you want to explain, and what you refer to with "poly models". Laser bolts light the area around the path they travel. They're also pretty bright themselves. Using the blend mode you mentioned fixes their brightness compared to the one I used.

I wouldn't know what I'd have to do with D2X's clipping.

I have noticed problems with transparent textures and don't know how to fix them. Setting the glAlphaFunc() value to small causes problems as well as too high. These effects do not happen all the time. I don't know what causes OpenGL to go bogus here.



Btw, I am doing this for free and for fun. I am not obliged to put any of your "requests" into D2X, and the word itself implies a state of mine regarding D2X development that does not apply.

Turn off Z buffering or don't use my D2X version. Or get MSVC 6 and fix the bugs themselves. I will be happy to incorporate your changes into my code.

Sorry, but that's all I can do here.

in order to show you what I'm talking about I need some place to host an image or two.

email me

I never said you had to implement any of what I am saying, I'm just telling you that those are the bugs I've found. If your interest is not in perfection (which it clearly is not, most understandably), then that's fine. I'm just trying to be helpful.


What's happening with the hostage (and possly other bitmaps) is that he's getting drawn after doors, which is why he gets clipped by the translucent parts of it. Which is curious, with the hostage being deeper than the door, he'd have to get drawn first in the original game to appear behind the door. Whatever controls the render order of that has been somehow changed from the original. This isn't actually OpenGL's fault, it's just that the D2 rendering engine wasn't designed with depth buffering in mind (or OpenGL for that matter).

By polymodel, I mean the model used to show the laser bolt, robot, or whatever. An object made from polygons. The player's ship is also a polymodel. Sorry about the confusion, I'm rather used to using the term from the old Descent Manager tools and such.


methinks I'll download the source after school gets out, I'll be too tempted to try and do things with it to get the last of my work done

Patches,

I know what a polymodel is, but I did not understand what you referred to. Generally I appreciate hints about bugs in D2X, but if I don't understand them they're not particularly helpful.

E.g. you write "it will light the polymodels". The laser polys do however not get "lit". They're simply drawn in the color given in their polymodel data. There's no "lighting" code involved. When drawing them with transparency applied, the color is darkened somewhat - that's all.

The cloaking powerup fade does work on my machines, although it's not a very strong effect.

About the prison door: I still don't understand what the problem with the hostages is. How about a screenshot? They look fine on my machines. The hostage is visible behind the holes in the prison door.

It just makes a differences to me whether somebody writes "I request ..." or "could you ...".

Btw, to make this game "perfect" would require a complete rewrite, imho. So many people have tinkered around with the code, and quite a few of them not exactly very professional. And I am by no means an OpenGL expert. I even failed in properly Z sorting the cubes in relation to the viewpoint, because I don't understand well enough how D2 handles it. There is a projection function which should compute Z coordinates relative to the viewpoint, but applying a sort after using that function did not yield the desired results.

The hidden surface removal code of D2 is not working for complicated levels (e.g. Kruel's Koolkave), but it is undocumented and very hard to understand.

So currently, with Z buffering enabled, I am simply pushing all visible sides to the frame buffer and let OpenGL sort it out.

Honestly, sometimes if I look into the D2X code my hair raises.

Btw, Radeon 9600 pro > GF FX 5700.

Ferno wrote:in order to show you what I'm talking about I need some place to host an image or two.

You have my e-mail address from DLE-XP beta testing, don't you? Just e-mail the screenies there.

I have some questions.

How come the sound quality is 11 Khz in d2x?

How come the animated textures from walls and objects aren't animated (except for doors) in d2x?

How do I make the animated textures from objects and walls animated in d2x?

How do I change the sound quality from 11Khz to 22Khz in D2x?

mail sent.

Note: I used level six lasers as an example.

Dark Falcon wrote:I have some questions.

How come the sound quality is 11 Khz in d2x?

Huh? I don't know. I'll try to find out and fix this.

Dark Falcon wrote:How come the animated textures from walls and objects aren't animated (except for doors) in d2x?

aren't they? I have built a small test level with an animated lava, water, wall, fuel center and image texture. They all were properly animated.

Dark Falcon wrote:How do I make the animated textures from objects and walls animated in d2x?

I would need to know which textures exactly should be animated but aren't.

Dark Falcon wrote:How do I change the sound quality from 11Khz to 22Khz in D2x?

Dunno (yet). When I however run D2X on my systems in the debugger, the audio system is initialized with a sample rate of 22050 Hz (~ 22 KHz), stereo. You can enforce 22 KHz sample rate by adding "-sound22k" to the d2x.ini file in your descent 2 folder.

Ferno wrote:mail sent.

Note: I used level six lasers as an example.

I have used patches' proposition of the glBlendFunc() and lasers look now as they should as far as I can tell.

Ty Patches. Got some more good hints?

patches,

re: screenmodes

You should be able to specify a screen mode by adding "-<X>x<Y>" to the d2x.ini file in the descent 2 folder, e.g. -1280x960.

D2X currently supports the following screen modes (at least when parsing command line/ini file parameters):

320x100
320x200
320x240
320x400
640x400
640x480
800x600
1024x768
1152x864
1280x960
1280x1024
1600x1200

I can't tell whether all are accepted by the SDL video code though.

Currently my recommendation for d2x.ini looks like this:

-fullscreen
-sound22k
-nocdrom
-gl_trilinear
-gl_alttexmerge
-gl_reticle 0
-playermessages
-noredundancy

An important hint: D2X doesn't like it if the last parameter in d2x.ini is not followed by a newline, so add an empty line to the end of the file to make sure all parameters are properly evaluated.

Update: Guess what - screen size command line parameters are overridden by the in-game screen modes settings, which are stored in the player file ... this project has been so messed up by all the amateurs tinkering around with it.

I have fixed that now, and added the screen modes that were allowed in the command line but not accepted by the video code.

You can get the fixed D2X exe from my Descent site (strangely enough I cannot activate my signature in the profile - it contains the link to my descent site. Please look into my profile).

Look! Lit laser bolts!



For this to occur, they must be getting lighting information stuck to them somewhere. The blend mode I suggested would help a bit, but it won't fix it. This is a problem that needs to be fixed, cuz it's kinda hard to dodge what you *should* be able to see and can't.


"About the prison door: I still don't understand what the problem with the hostages is. How about a screenshot? They look fine on my machines. The hostage is visible behind the holes in the prison door."

No, no, see, it did it in your screenshot too. The border between the opaque and the transparent texels of the hostage door are translucent, right? But they still write Z data, since they require modifying the framebuffer. And when a bitmap behind the door is drawn after that, it won't show up in the translucent area. It appears to occur with all powerups being seen through transparent walls, though:



Fixing this is a matter of getting transparent textures and bitmaps to draw back to front. I don't know how hard it would be to do that, though I would imagine not extremely.


"Btw, Radeon 9600 pro > GF FX 5700."

Not as far as OpenGL support is concerned, it isn't Though ATI has definitely been getting better, NVIDIA still wins in OpenGL as far as support and compatibility. Not that I have an ATI or anything, so I can't say my opinion on this is unbiased...


"Ty Patches. Got some more good hints?"

hmmmmm, not that I can think of at the moment, except maybe that you could try working on what was once palette-based fade code. And not reuploading old versions would be a pretty good idea The version you have up currently is dated 5/28, the one I had was dated 5/30. And, sure enough, the one dated 5/28 has its share of bugs back... tsk tsk.

Now I see what you mean. The light on the laser bolts comes from the object lighting, which is set per cube. Nothing I can change. As I have however changed the blend mode for laser bolts and they're now all fully bright, this won't be a problem any more.

The "translucent" parts of the prison doors actually are not translucent. They are solid. They may appear translucent due to texture smoothing. Esp. the prison doors have see-through (holes) and solid parts. Nothing in between. Basically, whether they appear translucent depends on the alpha test settings, and there's a limit as to what can be done here. I have been fiddling around with them quite a bit, and imo the current setting is the best compromise feasible.

Me uploading old d2x version comes from using different game paths on my different machines and exchanging the workspaces all the time ... so this time the executable destination folder got messed up. My most recent D2X version is now available on my Descent site.

Re Radeon vs. Geforce: As long as an OpenGL game runs properly on a Radeon I cannot see why superior general OpenGL support by a Geforce should speak against the Radeon. The Radeon 9600 pro has superior DX9 performance compared with a GF 5700 and a better price/performance ratio. And I bet you won't buy a GF 5700 only to play Descent 2 on it ... maybe one or the other DirectX game too, huh?

Btw, I was a die-hard NVidia GPU equipped gfx card user for a loooong time (my first such card after my dual Voodoo2 rig was a TNT2 Ultra), but I am using a Radeon 9800 pro now at home (you gotta see Far Cry on it ... ), and I probably won't buy another NVidia GPU any time soon. The new GF 6800 cards imo are totally overpowered. Nobody will need PS 3.0 in another year or more. Imo ATI has gone the right way with their next gen GPUs.

Actually, the only difference between PS 2.0 and 3.0 is the ability for vertex shaders to perform texture lookups, which enables displacement mapping. I've done some looking around on this.

"The new GF 6800 cards imo are totally overpowered."

No such thing But actually, the X800 beats the first FX6800 that came out. I dunno what NVIDIA will be doing later on to counter this.

But see, I didn't actually buy the FX5700, I was just borrowing it from a friend. Regardless of how it performs compared to an ATI, I was sad to have had to let it go. Anyone with as much money as me woulda been


hmm, the -sound22k option didn't do anything for me.


"The "translucent" parts of the prison doors actually are not translucent. They are solid. They may appear translucent due to texture smoothing."

Exactly! There are no texels that are actually translucent, but because of the smoothing, there are areas on the textures that are. Other cube faces show properly through the holes, but bitmaps do not. This is because of the rendering order issue that I explained before.


methinks it's time to download some source code!

The main difference between PS 2.x and PS 3.0 is that PS 3.0 allows conditional execution, i.e. different pixels in the pixel pipeline can be handled differently.

I understand that having to let go any gfx card in the power range of a GF FX 5700 is somewhat troublesome for you. Btw, an R9600 pro is quite a little cheaper than a FX5700 ...

The GF FX 5800 as well as the Ati X800 cards are overpowered. Nobody will need that gfx power for any game in a year or so imo. I can run FarCry with high settings on my R9800 pro w/o problems. I don't expect HL2, D3 or Stalker to be more demanding on my hardware (and hope there will not be an unpleasant surprise in this regard).

All cube faces are rendered before bitmaps and polymodels (lasers, robots). "Translucency" of parts of a cube face depends on how "black" they are due to the current glAlphaTest mode (which is 0.01, i.e. everything with an alpha value < 0.01 is considered "not there"). Maybe it also depends on glBlendMode; I have the suspicion that D2X somewhere turns off texture blending which is not desired. I can get rid of this effect by rendering all cube faces after all objects, but then all explosion bitmaps get ugly black borders.

As far as I can tell D2X runs in 22 KHz sample rate sound by default.

Ok, I got the thing to build and run successfully, and I was able to fix the lighting problem with a little trigraph that checks to see if the weapon being drawn consumes any energy. If it does, it draws it full bright, otherwise it will let it have its lighting value (so that missiles still get lit, ala D2 Win95, which I just compared it against.). The problem now is that glow faces on missiles need to get full lighting too, and need a Z offset so they don't clip with the polys of the missile.

object.c lines 881, 891, replace with the following:

(Weapon_info[obj->id].energy_usage)?F1_0:light, //pATCheS - if a weapon uses energy, make it full bright

Now I want to hack in a cheap halo effect for the laser bolts.

I'm going to keep looking around the GL code and try to optimize things as best I can. I also want to implement a cool alpha effect for explosions, I'm going to look into how that can be done.

[edit]
Woah, some of this stuff IS kinda scary o.0
[/edit]

Fixed the sound problem: digi.c, line 32, replace with:

int digi_sample_rate = SAMPLE_RATE_22K;

The command line option -sound22k *SHOULD* be working, but it isn't for some reason. The argument loader works fine. Doing a "find in all files" for digi_sample_rate only shows the initialization assignment and a couple instances where it is used (the other references are to files that I'm assuming do not get built). But regardless, the sound is MUCH better now

nice. now two people are working on d2x. awesome.

Are you giving Diedel your fixes Patches?

set up a subversion repository.

much better than CVS

Actually, I'm not much for build maintenance, so I'm just going to give him my fixes and he can keep them. I suppose I could e-mail them to him.


Currently, I am having some serious troubles with D2X though, when I select my pilot it tells me "Trying to cheat eh?" for a very short time then aborts. In the stdout.txt is

"Error: Bad control type (Config_control_type):255

Error: Bad control type (Config_control_type):255"

Creating a new pilot gives me the dialog normally, so I hit enter and start a game on D2 level 1. Controls are gone, screwed to hell. I'm clueless, I have tried everything. Deleting the entire source tree and started from scratch did nothing to help. Multiple times. I even reinstalled MSVC6. Same thing. And the builds I have from Diedel work just fine, even using the SDL that I built. I have absolutely no idea what could be wrong. I'm going to do a virus check momentarily, just to be sure.

Maybe the code is designed to fail so miserably after 11 am today.

I have fixed that. D/L the current source archive, or look for the following code in playsave.c:

• unsigned char m = cfile_read_byte(file);
  if (!VR_screen_mode_override)
  Default_display_mode = cfile_read_byte(file);
  }

And change it to

• unsigned char m = cfile_read_byte(file);
  if (!VR_screen_mode_override)
  Default_display_mode = m;
  }

Btw, the -sound22k argument sets digi_sample_rate to SAMPLE_RATE_22K, and on my systems the sound system is initialized with 22 KHz.

ok BIG problem with the latest build. whenever i fire d2x up it crashes to the desktop.

Try the one I just uploaded. The reason for the crash is the same as for patches' problem.

nope, still dumps me to the desktop.

Dammit, does it for me too. It's a new error (found in stderr.txt):

"Fatal signal: Segmentation Fault (SDL Parachute Deployed)"

Does it as soon as the pilot menu gets drawn.

Is there any point to trying D2X in debug mode (windowed, of course)?


"Btw, the -sound22k argument sets digi_sample_rate to SAMPLE_RATE_22K, and on my systems the sound system is initialized with 22 KHz."

I know. It doesn't make any sense. Isn't that one of the first things done? I'm not sure where the main function is (I'm guessing the one in inferno.c in /main?).

Ferno wrote:nope, still dumps me to the desktop.

Same here Ferno!

Wrong .exe file? The one Diedel has in the .zip is d2x-gl.exe, not d2x-w32.exe (which is what my shortcut was set to). I tried running the w32 one I had and it wouldn't open.

Btw, could you add an option to change the game's Keyboard Ramping like one can in D3?...

bad idea sky.

if one is running D2x and another is running D2_3dfx (I know a lot of people that still run D2_3dfx), they'll think you're cheating if you can turn/move faster than they can.

My most recent d2x-gl.exe is from 5 jun 04 23:15 (GMT+1 DST), size 696,320 bytes.

It works for me.

As the recent bug had to do with the player config file, try to delete your player files and re-create them, or if you have stored them somewhere else use that copy.

Ferno,

you won't be able to move faster than in other D2 versions, only to turn faster. And that option you have with changing joystick and mouse sensitivity anyway. So no cheating here.

My d2x version improves mouse sensitivity greatly anyway.

Could you illuminate on the "turning faster" part? I was tinkering with the build available today and noticed that you turn really fast.

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?

hmm, 2 problems.
1. D2 drops out if you try to use a name more then once
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

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.

I found out that much by turning myself woozy in the mines. I thought something was broken, but I really was turning that fast. My question is more at why the increased turning rate?

patches fixed the lasers.

If you use keys for turning (which is much easier to do in normal D2 than in D3... at a sane framerate anyway), you turn far more than 2x as fast. Hold down the turn key and your ship will go 90 degrees bank/roll in a matter of seconds.

Methinks it's another thing that needs looking into, but not right now. Got homework to (not) take care of.

Yay! I finally have D2 working... now I just need the sound to not be choppy and I'll be good.

That might be due to my own D2 setup, rather than D2x.