DescentBB

tested the cockpit in multiplayer works perfectly now as advertised!!!

the bomb indicator has been fixed in the cockpit mode also except for 1 minor detail.

After cockpit mode is engaged and view missle diplay is on, when a missle is fired the bomb display is occluded, not sure if this applies to Shift-F2 also, will check that next game and update this post. so when weapon diplay is on(default) the bomb indicator display at the lower right works fine since 1.3.56

(update)yes it does affect shift-f2 also, yet the key display indicators still show when these features are enabled.

Is it because the key incators are drawn above the alternate active display window and the weapon status window is below the alternate active display window in layers?? that being said, the active window size is slightly larger ocluding the bomb indicator??

A screen shot would have been helpful. But I guess the bomb display is the box below the three key indicators on the right - is that correct? I wondered what this box was good for. It can indeed be that it is not rendered correctly, as I had to change the gauge rendering screen coordinates for all cockpit elements, and as I couldn't figure what this space was for, I did not fix it.

Is the force field sound turned off in legacy D2 if the force field is disabled? I don't know/can't remember. Well, what the heck, I will test that with D2-W95.

Edit: Both fixed. The force field bug must have been introduced by me just recently.

I'll try to keep it short.
OpenGL reticle should not change size when switching to full cockpit.
The letterbox hud is still in d2x w32 but i can not set to this mode. Once I have pressed f3 i can only cycle between full screen and full cockpit. Actually it would be nice to cycle between:
full cockpit->letterbox hud cockpit->full screen
or something like that, don't know what other players would like. I have some weird 5 seconds jump behavior when I press f3 in non cockpit resolutions.
Hmm and could you please make missile explosions transparent again? (in weird cases they are transparent anyway, must be some bug)
And another thing. I was wondering if it is hard to 'fix' d2x surface rendering. This 30% performance loss might be noticable on slower computers...anyway, it's just a thought.

Thanks in advance

Found an "interesting" bug in 1.3.59 when I was playing last night in keg. Apparently sometimes when you pick up a smart when you don't have an afterburner, the cockpit will show a full afterburner reserve. When you hit the ab key you've bound, nothing happens. Hell, sometimes the energy indicator will flash to full even though I had less than 100. When I actually pick up the afterburner, it all works like normal, other than the energy indicator. We were all playing on insane.

I was playing at 640x480 with cockpit enabled, just to see the cockpit again. This bug does not appear with the cockpit disabled. I haven't tried it with the letterbox "cockpit" yet. This did not appear in 1.3.50 (which is the oldest previous version I have).

XP2800+
PNY GF4 Ti4600 running current drivers
512MB PC2700 DDR

I also noticed that the D1 driller uses the FM sound effect instead of the soundblaster effect.

I know about the gauges cockpit bug, but have no clue yet what causes it.

FM and soundblaster effects?

The "letterbox" HUD (bar HUD) can be obtained by pressing the minus key. That was always like that, although having F3 cycle through the modes would admittedly be more desirable.

I cannot fix the surface rendering problem, because I don't really understand the hidden surface removal code, and it is pretty hard to understand. Actually, the "render entire mine" option is a work around for those extremely rare levels (actually, I only know Jeff250's new creation) that cause missing faces. So usually you will not need to enable it. The most intricately built D2 level I have ever seen is Kruel's Koolkave (a must have and see), and it works perfectly will with D2's hidden surface removal code enabled.

Thanks for answering. Since it is optional to render the whole map I can live with it, I was just asking.

Thx for the minus key hint.

With soundblaster fm/effects he probably means that D1 used the soundblaster fm-chip to generate some sound effects. (note that i have not played d1, so I'm not entirely sure)

The only way to simulate this is trough emulation (which would be stupid) or record the fm-effect and add it to the d2 w32 package.

By the way, now I know that the game makes 5 second jumps when i press f3 OR the minus key. Not that bugs me, but I don't think it does network games any good.

No time warps when trying to change cockpit mode here.

Btw, I have added HUD cycling via F3. Didn't like it the way it was. Sometimes I just need somebody else to have the same idea as me to change stuff like that.

"By the way, now I know that the game makes 5 second jumps when i press f3 OR the minus key. Not that bugs me, but I don't think it does network games any good."

Start level 1 and hit any function key at a steady rate, just after the GB fires a flare. He fires the same amount of time after hitting the function key every time. Also try going forward, then stop, and while your ship is still drifting, hit a function key. Something is wrong


No sound effects in any Descent ever used FM synthesis. FM was used for music only. D1 keeps its sounds in descent.pig, D2 keeps them in descent2.s11/descent2.s22, and D3 keeps most of them in d3.hog. If you're referring to that pain in the ass Vulcan-shooting f*cker, the sound you're hearing is 11khz played at 22khz. Somebody at Parallax forgot to resample it (there's a few other sfx which were similarly left at 11khz, play around in DTX2 to find them).


hmm, emulation wouldn't be too terribly stupid. DOSBox already has very good OPLx emulation


I should look into D2's hidden cube removal. I remember staring at the code for it at one point a while back and thinking that it could benefit from a depth sort. Also, D2 renders from back to front, but since depth buffering is enabled now, it'd be better to render opaque faces from front to back, and then non-opaque faces from back to front, since all gfx cards since the GF3 perform depth testing before rendering to save fillrate.

You probably don't need full-blown DOSBox to run D1 properly. A simple sound emulator such as VDMSound will work for most cases.

And yes, what Descent 2 did to some sound effects was utterly hideous. Instead of creating a crisper, more detailed waveform with those extra samples, they just played the same sound twice as fast...

I mean, sure, it works, and in most cases it isn't so bad - but the mouse-squeak from the Class 1 Driller is just so... wimpy. The D1-style screech actually scared the hell out of you.

Edit: I don't know whether your recent change did this or not, but the entire problem with clipping that has plagued Descent since D1 has now evaporated. Even levels that D2 original had trouble with it doesn't now. (Well, except those that genuinely do have intersecting geometry, but there's only so much you can do about that.) Nice work. (Although, by the sound of it, the only difference is using OpenGL's in-built implementation instead of the Parallax programmers' notoriously lousy one. Fast, but it sucks...)

It only sucks for complicated geometry. The reason it doesn't always draw correctly is because it bases draw order on cube depth from your current position. A cube having more than one route to it (because of cubes with more than two attached cubes) could possibly get drawn at the wrong time. If they used a distance sort, it would never be a problem. But square roots (needed to calculate distance) are expensive, and I'm sure they didn't want to spend 700 (or whatever the cube limit is.. well, actually it depends on the level as to how many there are... but in any case, point made) of those each frame plus a quicksort to determine what order to draw things in when in most cases an integer cube depth number sufficed. Of course, nowadays we don't give a damn about 700 sqrt()s. For the most part, the depth buffering isn't actually necessary. Just a matter of changing how the "draw me" cube list is created. Only time that it would have problems where depth buffering wouldn't is with intersecting cubes.


"You probably don't need full-blown DOSBox to run D1 properly. A simple sound emulator such as VDMSound will work for most cases."

I never said to run the whole game in emulation. DOSBox is open source, and it has an OPL emulator in it. My point was that that code could be used for playing the FM tunes. The trouble would be figuring out how to talk to it the way the original D1/D2 did with the OPL chips, since D1/D2 used the closed-source HMI interface libs.

patches,

as you say faces are rendered depending on the travel depth to their segments from the player segment. There's some additional code though determining which face are visible, and in the case of Jeff's level that code 'thinks' some faces are completely hidden when they're not.

My work around fixes Jeff250's problem though. It would be no problem to implement a real depth sort, but then the invisible faces would still be needed to removed before rendering - or you will get some performance penalty. As far as I remember it was you who removed the performance penalty because you found out that enabling Z buffering already fixed the missing surface problem w/o need of rendering every face (remember Kruel's Koolkave?)

I need to look into the function key problem again, so it appears ...

What's the name of the level? Where can I get it? I need to see it before I can come to any conclusions.

Good to hear that D1 did not use FM synths for soundFX (some games do, think of stunts, lotus3)
I claimed that 'emulation was stupid'(lol you really should take that with a grain of salt, you know )

I thought it was encredibly useless to implement emulation code for a single sound effect in the game. Since it turns out that the driller in D1 is not fm-synthesis at all it does no longer matter.

Anyway, in a way it would make sense to use emulation for game music. But it sure puts strain on the cpu, so I think implementing mp3 support would be more realistic. That way both opl2 and opl3 versions of the music could be recorded directly to a wav using dosbox. (i'm not -entirely- sure if it works for fm tunes, though). Just a thought for later on really.

pATCheS wrote:What's the name of the level? Where can I get it? I need to see it before I can come to any conclusions.

Ask Jeff250 for a link and refer to me.

I think D2x is hiding surfaces that it shouldn't be because it seems to be mishandling the cloaked walls and treating them as opaque. Anyways, switching the cloaked walls to a grate-type wall seems to fix it. This is just my observation without looking at the code or anything. I've sent Diedel a PM about it. I'll send you one too Patches.

No Jeff, you are wrong, or you couldn't see anything behind cloaked walls.

DOSBox 0.63 works incredibly well for recording the music of D1/D2. OGG is better than MP3 for FM synthed music though (well, better for everything ), less perceivable distortion and better quality/size ratio. I've encoded several tracks, which I rendered at 176,400hz to get as accurate a tune as I could. Like D1 level 2's music, which has that high-pitched thing.. the higher sampling rate makes it sound a million times better Of course, you have to have the CPU for it, and change a few other settings like buffer size and mixer sampling rate.

patches,

please continue that discussion in another thread - it's OT here. Thanks.

Nothing else to say about it.

I just tested the levels. It does do what you say it does when the Render Entire Mine option is disabled; enabling it fixes it. Think it's time to take a look at the code that decides what to render. And cloaked walls are apparently handled differently in some way, since the missing faces problem goes away when using the grates. With both levels, there's another visual bug I found, my best visual description is here:



And Jeff250's screenie of the issue he was talking about:



You can see plenty of missing faces. You shouldn't be able to see the lights in the right middle part of the image, which are above the face that does get rendered.

A screen shot says more than a thousand words ...

Yes, I know Post edited.

Diedel wrote:No Jeff, you are wrong, or you couldn't see anything behind cloaked walls.

Obviously there are more variables involved, but look at what happens when I entirely remove the cube and texture it with the "empty" texture (creating a hack that allows me to "see" through ordinarily opaque void)...

http://home.comcast.net/~jeff250/descen ... ender1.png

Now look at the original render when the cube existed with the "cloaked" wall:

http://home.comcast.net/~jeff250/descen ... ender2.png

It's almost the same, except in that the former picture with the missing cube, the effect is slightly closer and affects more surfaces because the cloaked wall is on the far end of the cube, and the "empty" texture naturally is viewed from the near end. Other than that, they're the same.

And now take a look when I remove the walls and there are no walls at all! There are absolutely no rendering errors:

http://home.comcast.net/~jeff250/descen ... ender3.png

The problem must somehow involve D2x's treatment of walls (or at least cloaked walls), because, when they're removed, the shot is rendered perfectly. Otherwise, I would think that they would seem to be rendered as if there was an entire opaque cube missing between the viewer and the scene, although that is speculative. But, regardless, the fact remains that when the cloaked walls are there, the issue is present, and, when they are not, the issue is resolved.

Jeff,

please don't try to tell me what D2 and OpenGL do with the faces if you don't know how D2 and OpenGL work here.

I told you before that this depends on the sequence D2 renders this stuff. Now if the cloaked wall gets rendered before the e-sparks, OpenGL cannot apply the color (darkening) effect of the cloaked wall to the subsequently rendered e-sparks behind it, so it will not render the e-sparks at all. My fix takes care of distant walls being rendered before closer walls, that's why this works. Try setting your cloaked walls' cloak value to 50 to make them visible and things will get clearer.

Does that phenomenon apply to faces (that aren't strickly "walls") as well? I didn't make any mention of energy sparks, and I understand that that issue was resolved a while ago.

Basically this has nothing to do with the type of texture behind the cloaked wall. Every face behind the cloaked wall that happens to be rendered after the cloaked wall will not be displayed. Don't ask me why and when D2 renders the missing faces after the cloaked walls in front of them. Background is that each cloaked wall pixel is actually rendered, while transparent pixels of other textures (e.g. grates) aren't rendered at all, so at their location there is no entries in the OpenGL draw and Z buffer that would cause other pixels at that location not to be drawn any more.

Nice feature in the new version.
Though wide screen mode has no reticle and reticle size varies per camera mode while it shouldn't (it should always be like it is when the reticle is shown in full screen)

When I saw the widescreen option I was wondering if there could not be anything done for widescreen laptops (discard the bars)

Not that it is needed for me, just a matter of extending descent 2 to todays standards.

I just finished level 16 and level 17 won't load. I get the briefing about a new bot type, then I get the message: "cannot open the correct version of calie. . . " (the last word is truncated.)

Also, I still can't get D2X to recognize my middle mouse button and scroll wheel.

Any ideas?

tia

Please send me your last save game to karx11erx at hotmail dot com and tell me which campaign you are playing (D1/D2/Vertigo).

D2X will not handle the mouse wheel. It should however detect the middle button (actually, with my mouse the wheel is also the middle button and I use it - I said it already - for the afterburner).

Hey Diedel I finally started playing with your updated version with the cockpit. I've been to busy with other things to keep up with the pace of your updates:).

Current Hud seems to work okay with hires modes, so that isn't as much of an issue as I had feared. I forget what are the reasons you changed the FOV when in cockpit mode? I personally don't like it. Because if you look at the edges you can see the scene distort. Also I'm running at 1280x960 and the viewports (ie rearview and missile view) are drawn in the wrong place. Oh and if I got to automap and come back it's back in fullscreen mode again.

Currently, whenever calling a non in-game screen (menu, automap, etc.) you will be back to full screen if not in standard res (320x200 or 640x480). I will change that, but a few things need to be taken care of if doing that.

The FOV is changed simply because the visible height is decreased in cockpit mode. It's the same for the status bar mode, which I never touched.

Could a workaround be made then for 100% transparent cloaked walls? As it is now, they still produce misrenderings, but I would think that something 100% transparent wouldn't need to be rendered.

Jeff,

just try whether rendering the entire mine actually does hit the performance.

Funky bug in the version I d/led just 5min ago: changed the stick sensitivity in game (F2) from one-below-max to max. Now it resets to min every time I exit that menu -- kinda hard to play w/ a turn rate of one rev every ten seconds or so

Edit: 1.3.65. Even after restart and changing it from the main menu no go -- resets it to min as soon you leave the menu.

Diedel wrote:Jeff,

just try whether rendering the entire mine actually does hit the performance.

The performance difference in that level is negligible, but it is more significant on others. Granted I could toggle it on and off, but I'd rather stay put until if and when a solution arises that avoids that hassle.

Also, with respect to the "render entire mine" option, I'd like to report that when it is enabled, I cannot see objects (such as power ups) behind cloaked walls.

edit: This also seems to apply to robots, missile fire, etc.

I am playing on a UDP/IP game (Descent2 D2X-w32 1.3.65) with another computer in my house and the other computer can't see the spew of weapons when I die and can't pick them up. I can return after spawning and pick up all the stuff. It doesn't matter which one of us is hosting the game, the one computer is the problem.
I don't have a third computer to test it on so I don't know much more than that. I recorded a demo of the two pilot's view of the same space if you would like to see it.

Can you tell me any advice? Hopefully it's just something that i am doing and not a software bug.

Thanks for your work... Descent is the best.

Like the new cockpit bar at high res, great work.

I have found the intro and cut scene movies and sound to play slow in 1366 on Windows ME/XP

Camron,

I have heard of this problem before, but have never encountered it myself - neither when starting two D2X instances on the same machine, nor when playing via UDP/IP in a LAN.

Dennis,

what is '1366'?

I assume D2X-W32 build 1.3.66.

Diedel wrote:Camron,

I have heard of this problem before, but have never encountered it myself - neither when starting two D2X instances on the same machine, nor when playing via UDP/IP in a LAN.

Dennis,

what is '1366'?

Everytime I've encountered it, it was always with someone that had high packet loss. It didn't matter if the other person used d2x or not.

Camron, its either something setup wrong on that computer or in the switch/router. Try switching ports and see if it follows.

Bug somewhere from D2X-W32 1.3.65 - 1.3.67

Customize Keyboard - brings up joystick configuration screen customize above(joystick) - goes no where