DescentBB

If the game host was already running a match, a client with an outdated level version trying to auto-d/l a new one had immediately received an error in previous game versions.

All that has changed in v1.4.18 besides slightly improved auto-d/l code is that it is lightmap enabled. Turn lightmaps off in the render options menu (I am not really satisfied with them yet anyway), and you will have exactly the same render path as in v1.4.17.

Oh yeah, and re-download v1.4.18. I have changed a thing or two about lightmap rendering.

The game host was at the "Select up to 8 players, Press Enter to begin" screen when the "join" client would error out.

I'm at a loss on the rendering glitch - it is completely reproducible here, and I don't have any rendering option referring to "lightmaps" (just downloaded 1.4.18 again; created a new pilot; no change). The non-circular automap blobs appear in both single-player and multi-player in 1.4.18 "a" & "b", but with 1.4.17 they are round ...

Geez - on my machine, the blobs look like pacman smileys who had their scalp shot away by someone! WTF ... !

Diedel wrote:pacman smileys who had their scalp shot away

Zaktly!

ROFL!

Go kiss your good wife, and get some sleep ... the diseased pacmen will still be there in the morning ...

Hm... you know the menu error I was talking about? It seems I was somewhat mistaken there... it doesn't just happen after loading a game now, it happens all the time.

Which is ... somewhat weird, as I was able to use D2x W32 last night, at least mostly without those problems...

I think it probably has more to do with the Radeon 7500 drivers than anything else.

jehu,

fixed. I shot away Pi's scalp obviously today. Never mutilate numbers at their beginning.

Sirius,

Are you by any chance running folding@home, or Rivatuner's refresh rate fix or a comparable program in the background? I have found these to interfere with D2X-W32's renderer. PSP pro 9 can cause problems, too.

Nope, but I found out what it was.

Always-on-top programs do not work well with fullscreen 3d games. At least not of D2's ilk.

Heh.

Looks like the reverse view thing is not happening in 1.4.19

EDIT: Riot and I played several games in Dark Hall and TombZ Of DeZtruKtion. Seemed pretty stable with the occasional lag issue.

Roit did have a friend join at one point who seemed to have some issues, but it could probably be chaulked up to net loss.

I did notice several powerups that weren't spinning and would not stop being drawn when picked up (although you couldn't pick them up twice, thankfully). Not sure what was causing it, especially considering they would eventually disappear/correct themselves.

Nosferatu wrote:Looks like the reverse view thing is not happening in 1.4.19

EDIT: Riot and I played several games in Dark Hall and TombZ Of DeZtruKtion. Seemed pretty stable with the occasional lag issue.

Roit did have a friend join at one point who seemed to have some issues, but it could probably be chaulked up to net loss.

Hey, you forgot to say that you seemed to be having trouble running into my fusion cannon fire.

Ya I was mothing quite a bit. Wasnt I? DOH.

But why did you keep hitting yourself with my gause ammo?

The bogus client player view issue has been solved a while ago. Just read my D2X-W32 update notifications.

Nosferatu wrote:But why did you keep hitting yourself with my gause ammo?

LOL!

Do you like TombZ? Did you play the small or big version? Try Speed! - that should be a fun level to play.

Diedel wrote:... improved auto-d/l stability ...

1.4.19 did the trick in one direction, and turning off XP firewall (:oops:) fixed the other.

Now, to go get a video card that can handle the lightmap enhancements ...

Just noticed that the help commandline switches (-?, -h, -help) don't ...

The D2X-W32 section of my descent site contains a page explaining all D2X-W32 switches and in-game commands.

Diedel wrote:The bogus client player view issue has been solved a while ago. Just read my D2X-W32 update notifications.

Nosferatu wrote:But why did you keep hitting yourself with my gause ammo?

LOL!

Do you like TombZ? Did you play the small or big version? Try Speed! - that should be a fun level to play.

We played the big one. Pretty cool level. Wish you could get to the shaker.

d2x-w32.zip 1.4.22: zip unable to open, file corrupted, direct from download site!

edit - 4th time was the charm n/m

Coloured lighting on doors doesn't appear to work until they start to open. Otherwise they are not lit according to any palette.

In addition, it would be a bit nicer if the lights themselves were coloured according to the type of light they emit. Red door lights look funny otherwise. I think this only happens for secondary textures though, because lava appears to behave precisely as I would expect.

Final thing, which is VERY VERY hard to notice and thus I don't care much about, but I suspect is still there; if you have a white light near a coloured light such as lava, then the coloured light will be lit in a sort of mixed colour. Fair enough. But when the white light is blown, I think - I am not totally sure - the coloured light just dims to a darker shade of its previous colour, rather than reverting just to the shade of light it emits...

Might be worth checking into, but if you don't have time I'm sure no-one will really notice.

The light (vertex) colors are pre-calculated, so they will not change when a light is turned off somehow.

Ah, wondered about that... so the only way to get it 'right' per se, without being undue hassle, would be to use lightmapping. I think.

The problem is that the lightmaps would need to be recomputed if a light is turned off, at least those in its vicinity. Pretty hard to do.

As far as I can see, the current lightmaps simply are colored, partially transparent textures rendered on top of the base textures.

Store seperate lightmap collections for each light? It'd take more memory, but it'd make it tons easier to implement normal mapping and shadows later on, and gives brightness control of each light. Death would occur in levels with lots of lights though. Maybe lights in such levels could "share" lightmaps, and be given weighting values?

hrm... All the per-vertex light processing has to occur per-texel now... Might just be easier to move to per-pixel shader-based lighting. lol

I too experience very poor performance with lightmapping enabled. It's easy for the framerate to sink below 30 in D2 level 1. At that point, the controls feel very jerky (if I hold my stick in a direction, it doesn't turn smoothly, even given the framerate).

I note also that hitting the +/- keys does the same thing that hitting the function keys have done for a while (don't know if that's been fixed): it resets some timer in the game to zero. Which is just really weird.

Some renderer state is screwed up, too. Laser blasts and doors are getting depth tested and maybe drawn in a weird order, lightmapping or not. Very strange indeed.

pATCheS wrote:Some renderer state is screwed up, too. Laser blasts and doors are getting depth tested and maybe drawn in a weird order, lightmapping or not. Very strange indeed.

Screen shot?

Diedel wrote:The light (vertex) colors are pre-calculated, so they will not change when a light is turned off somehow.

It did on my version. I think the problem is setting the light values in render_side. My method of changing the light levels when a level load allows vertex lighting to work correctly. I think that's the only way to get it to work correctly.

Also lightmaps aren't semitransparent. They are multiplied in. Causing them to be blended based on it's brightness.

There must and will be another way to get the lighting work with lightmaps, and I will find it. I don't like the idea of setting the light values once and for all when loading a level.

Edit: Been there, done that.

The current version of D2X-W32 allows you to switch between lightmapped and non lightmapped rendering on the fly. If switching in game, the lightmaps will only be computed once, so subsequent switches work instantaneously.

When changing screen res or toggling full screen mode, lightmaps will need to be recomputed though.

D2x-W32 v1.4.23
MP or SP

In this version the movement is jerky. With or without Lightmapped enabled.

V1.4.22 was no probs for me and ran smooth as can be.

**EDIT: I take that back! In Display Properties, under Advanced options. I checked my FX 5950 setting and I had disabled Vertical sync. I enabled it (application-controlled) and everything is fine now! All nice and smooth again!
Sorry Diedel!

The only way I can imagine this happening is if the door was drawn with depth testing after the laser bolts, and depth writing was enabled when drawing them. The bolts should be the last thing to pop up on the screen, sorted back to front with other bolts and objects, and with no depth testing.

Aus,

np! Phew, I'm glad it was that simple.

patches,

Did you play with "Render Entire Mine" checked? Try unchecking it then. I will look into what happens with "Render Entire Mine" enabled and probably change the sequence in which walls (doors) and objects are drawn. It looks like objects currently are drawn before walls. This makes sense because D2X will not render stuff behind transparent (cloaked) walls at certain occasions otherwise, and that way it will.

Render entire mine was off. Didn't think to try it with it on.

[edit] oops, it was on. The sprite problem went away when I turned it off, but walls and doors still exhibited the issue.

Well, I just registered here, so I have quite a few things that I think need to be fixed in D2X-W32:

Cockpit & Statusbar mode @ 320x200 (No, I'm not THAT crazy, but you may as well fix it anyways... )
-Guages and reticle drawn as if the resolution was 160x100.
-Blurry.

Cockpit & Statusbar mode:
-Transparent pixels drawn as black below a certain position (also happens in rearview).
-Reticle, score, lives, message, and countdown displays should have their vertical position calculated based on the position of the lowest horizontal line of at least a certain length on the top half of the screen (and veiwpoint position should be adjusted accordingly) (that's how it looks like the normal D2 does it).

Credits:
-Text flickers rapidly; very annoying. (Maybe the background is being drawn after the text?)

Lightmaps:
-Textures on walls with no secondary texture not rendered; Only primary texture on walls with a secondary texture is rendered. Only happens when Lightmaps are on. (It's my video card, isn't it? )

Colored Lights:
-Light doesn't appear to go away after a wall with it (such as a forcefield) is opened.
-Light goes through walls (or, at least it shows on both sides of a wall when it should only be showing on one).
-Effect seems to be a little exaggerated.

Render Options:
-"High Movie Quality" shows as off, but it's actually on.
-Wasn't there supposed to be a "Draw Hud" toggle?

That's pretty much it. I think that your Super-sonic Coding will be able to take care of these things soon enough...

I'm also noticing a trend now where D2x-w32 is dropping packets after the ship explodes in multiplayer against players using D2 DOS v1.2 and D2_3DFX. The powerups aren't dropping after death like they should be. On the other persons end they see nothing. I've had this happen twice today on Kali with two different people while I was using D2x-w32.

Just wanted you let you know that I've d/l version 1.4.24 and when I start up D2x-w32. It still says its version 1.4.23. D/L twice in the past 3 hours and no change. hummmm

No current D2X-W32 available right now due to a bug.

Lightmapping still in beta state.

320x200? Never mind.

Credits? They're really important ...

Heck - the draw hud toggle is gone awol?

Movie Qual? How do you know high qual was on? For me, the visual difference isn't even noteable.

Packet loss? In KALI, I guess ... I haven't changed any IPX communication code.

The render problem with entire mine rendering enabled has been solved.

Just wait for v1.4.25, ppl. I currently have a crash bug I need to fix.

Sounds good... good luck.

Just curious - do you plan to keep supporting the rendering engine sans lightmap? I would assume so, but just making sure.

Ofc I will. Actually, I am not that happy about the current lightmapping code, as it runs very sluggishly on my X800 XT PE despite clean video driver install.

Tyranny wrote:I'm also noticing a trend now where D2x-w32 is dropping packets after the ship explodes in multiplayer against players using D2 DOS v1.2 and D2_3DFX. The powerups aren't dropping after death like they should be. On the other persons end they see nothing. I've had this happen twice today on Kali with two different people while I was using D2x-w32.

I have seen this also but it had nothing to do with d2x-w32, Descent2, nor D2_3dfx and the interaction of the 3 (except framers which is obvious of why)

Yet anyone using teh h@cked up version of D2x-sdl drops no spew!! We see this alot on kali and choose not to play anyone using that version. Not to mention the other network related issues with that version, it was never finished and barely has a network code

I had a long match with riot, nos and temporarily some more guys using UDP/IP via tracker a few days ago, and there were no problems with lost spew or packets. Only jehu somehow kept disconnecting.

Diedel wrote:320x200? Never mind.

Well, yeah, as I said, I'm not crazy, but... maybe in your spare time?

Diedel wrote:Credits? They're really important ...

Yeah, that's not too important, but still... would be nice to have them working right.

Diedel wrote:Movie Qual? How do you know high qual was on? For me, the visual difference isn't even noteable.

Yeah, the visual difference is barely noticeable, but my comp's only 1.8GHz, so for me, the performance difference is.

Oh, and also (I just remembered this), powerups at certain distances away from you sometimes appear to flicker...