DescentBB

Cool! Unintended, but amusing nonetheless.

Haha, I take it you put a texture with transparency on a cube side that wasn't a wall joined to an adjacent one?

At least it doesn't give you that psychedelic texture repeating effect from the old versions... Unless you like that sorta thing, of course.

PS: You got me pretty close to drooling with that last one, Diedel.

"At least it doesn't give you that psychedelic texture repeating effect from the old versions..."

Actually, that's because OGL is being told to clear the color buffer, which the original game doesn't do for performance reasons. And even on today's graphics cards, it costs quite a bit of performance, especially on older cards (Z clear is supposed to be pretty fast though, dunno why. not clearing Z results in some very interesting artifacts btw ), and under normal circumstances, the color buffer never needs to be cleared, because the entire screen is drawn opaquely before anything is blended. Actually, drawing two black triangles to clear the screen might even be faster than a color clear... Sounds silly, but for some reason I remember that being the case, from back when I was toying with OpenGL. Give it a try, Diedel? It's glClear(), in case you don't know

Actually, that effect was not supposed to occur in the level.

You see, it doesn't actually have custom textures. For some reason, the underlying 'scrolling' background is being cut out from the secondary texture.

That isn't the only strange thing, either; the secondary textures in many places (as some of you would probably note quite quickly) don't have any rotation on them - look at the door in the roof there, and the light next to it.

Weird thing #3... you see the difference in shading on the black wall I assume? Note how the secondary texture appears to be unaffected...

There are two other errors I noticed that the screenshot doesn't reveal; firstly, nothing animates any more. Except 'sliding' textures such as lava falls and, naturally, the face this shot is taken through.

The second one was that normal doors never close; non-auto doors never open; thus, you can't escape the level after you blow the reactor. Ever.

Kind of strange. Never seen anything like this before.

Which version of D2X-W32 did you produce that shot/notice these errors with?

I usually play on weekends so it takes me a bit to catch up.

Posted Sun Jun 26 wrote:currently there is an issue when a d2x-w32 host no one else can join, unless they have d2x-w32 after 1.4.27 somewhere

Others have reported this also after my post which was overlooked/ignored to deal with eyecandy issues instead This is not a kali issue, this is a D2x-W32 as the host and D2x-W32 programing issue

Could you fix the multiplayer issue thanks, eye candy can wait, I think this is about the time it started, if this helps .

Posted Thu Jun 23 wrote:D2X-W32 1.4.34

• D2X-W32 will now understand the name tag "d2x-name" of D2X-W32 missions that has been introduced with DLE-XP v1.4.15. This should take care of non-D2X-W32 program versions loading D2X-W32 levels and crashing when trying to display them.

------------------------------------------------

SPUD / TANKIE : I went back to 1.4.27 until this is resolved

BUBBALOU wrote:...Others have reported this also after my post which was overlooked/ignored to deal with eyecandy issues instead

It wasn't overlooked. If I get an error message like this I will wait for some confirmation before I assume a bug and not some network problem. I must say I don't appreciate subtle allegations like yours here.

Edit: I wouldn't bet too high.

Grand Master D ( I like that )

When I make a Post about a Real BUG, I have about 10-20 people behind me reporting to me the same issue and it is VERY reproducable. And ones I have reported, were right on the MONEY. So What should I do, should I have them quote me and Post behind me in the future and make 1 real bug report turn into 3 pages of quotes! I think not

Nor will I fill up this thread with multiple long winded posts that only apply to isolated cases and have nothing to do with Multiplayer or GamePlay issues between Online Players (those posts urk me). I do not want to waste your time like that or the DBB's Resources.

But in all seriousness, you do have an issue with people that use KALI, which are 95% of the users in this thread, and they adore you. but you beat up on them why?

I haven't seen 10 or 20 ppl reporting this bug, or posting a petition created by Bubbalou and signed by them here to fix this bug.

So far it has been three, and two reports were made just yesterday and today.

So stop whining.

Diedel wrote:So stop whining.

I will start whining if you do not give me some cheese and crackers, but to date I have not!

maybe you can lob a smart over my head too!

BUBBALOU wrote:But in all seriousness, you do have an issue with people that use KALI, which are 95% of the users in this thread, and they adore you. but you beat up on them why?

In all seriousness, this is utter and total crap.

/Diedel is busy painting "Bubbalou - gotcha!" on the smart missile he has just filled with ... ummm, cheese crackers ...

Bugs fixed.

I could host an IPX game in my LAN here using D2X-W32 v1.4.38 as game host and join the game using D2-Win95 as client.

Version was 1.4.37. The version just before that seemed to work fine.

Edit: Checked 1.4.38. Secondary texture alignment fixed, doors working; however secondary texture lighting still appears broken and that texture is still transparent in the wrong places. (Primary: misc101 Secondary: rock314)

Sirius,

can you see an option "use high-res textures" in the render options menu? If not, the required shader program doesn't work on your computer. I have just changed the rendering code to take care of that, please re-download v1.4.38.

On my GF FX 5200 your "see thru" bug does not appear with that program version - neither w/ nor w/o shader.

Edit: Another high-res texturing shot: Novacron has sent me three new textures, so this screenies contains exclusively high-res textures:

Daaamn, those high res textures look good.

So when I launch 1.4.38 in full screen mode, I hit F3 once and then I'm in "letterbox" mode, I hit F3 again and *blam* I'm crash back to XP.

I also get a mysterious CTD with version 1.4.38. However, unlike spud, it occurs whenever I enter a mine, just after the message "Prepare to begin descent..." appears - whether I'm running full screen, windowed, or in any myriad of resolutions. In the meantime, I have reverted to 1.4.35, which works fine.

Here are my specs:
Athlon 64 3000+
1GB PC3200 RAM
MSI Neo2 Socket 939 motherboard
PNY Verto nVIDIA 6600GT AGP video card w/128mb RAM
Samsung 160GB PATA HDD

I'll keep toying around with settings to see what might be causing it.

Well, rather let me toy around with the debugger ...

Sure...we can all toy with what we please...

CTD when switching to cockpit or bar hud fixed. This will hopefully fix your CTD too, Motorman.

Looks like it doesn't (which doesn't surprise me, it's a DX7 video card). But the problem is gone anyway - both of them.

If your card doesn't support my multitexturing shader, D2X-W32 will render the mine as it did before my introducing that shader.
____________________

Here's another screenie, this time with some high-res textures from theoutrider who had posted them here a while ago:



Neato, huh?

Now we just need a high-res textured fully 3D cockpit and dynamic textures (for instance, displaying psuedorandom statistics for things like temp, power usage, or whatever.)

More seriously, the AB and energy bars could fairly easily be redone with polys, rather than dithered paletted filtered textures. And the key indicators, too. Dunno how best to store their color values... Hard-coding them would be too easy I don't know of any levels that change the cockpit in any way though, so maybe it doesn't matter.

The AB and energy gauges aren't polys. Their interior is drawn line by line, depending how full they have to be. The energy gauges have a special formula for the line angle, as the two angles of the gauges's sides are different. It took me an awful lot of time to translate that formula into something working halfway acceptably at every available screen res. A different system would be desirable.

Couple of things in D2X-W32 1.4.40:

- Animated textures on robots and props like reactors don't seem to animate. For example, the "Cylon eyes" on robots, or the waterfall texture on the water reactor don't move.

- In the Descent Maximum Anarchy pack, the Quartzon / Limefrost Spiral doors show their background texture behind the door when the door is opened. Don't know if this is intrinsic to the DMax pack or not.

Object texture animation fixed.

Descent Maximum Anarchy pack ...

/Diedel thinks for a while ...

Please e-mail me the level to karx11erx at hotmail dot com, Kyo.

That problem is due to my changing overlay texture transparency handling (I am using a pixel shader to allow for high res overlay textures). Maybe the transparency color testing fails.

Kyouryuu wrote:Quartzon / Limefrost Spiral doors show their background texture behind the door when the door is opened.

This problem seems to be true with all levels using a non-groupa palette and textures using the "see-through" palette index that's used on grates, fans, doors, etc. to see through the texture that they're put onto.

Also, it seems that closed-type walls with see-through or transparency parts cannot be shot through. Also cloaked walls which use the texture to determine which parts can be shot through. Possibly others.

With the 1.4.41 build, no shots are able to go through grates and other related textures for both player and robots.

*looks at HUD code*

wow, that's fugly. No wonder there's so many drawing artifacts.

It draws the whole energy guage first, and then draws black lines back from the left or right (depending on which side), top to bottom. The AB guage is done in a similar manner, but it uses a hard-coded table of values indicating the different heights of its parts. It requires quite some effort to keep these algorithms pixel-accurate.

*goes back to his little corner and resumes hacking*

Dito Ferno's post.

Energycenter on level 1, go there, you might see some orange flickering artifacts like I did.

Endscreen level 1, possibly other levels too:
somewhat corrupted (distorted, garbled) purple font-texture...same font in other color (gray) were ok.
I have not double checked this yet, I might have reproduced this font-texture distortion thing by coincidence.

Lightmapping runs smooth! First I thought it ran only somewhat smooother until I noticed I was running the game at 1600 using 4x alias 8x anisotropic.

Switched to 800*600 with same anti-alias/anisotropic settings...runs really smooth.

Where's the screen origin, top left or bottom?

.42: Flickering artifact at energy center fixed
Level complete screen, purple font still distorted, which happens at level 1 & 2 (confirmed) so probably at any end level screen.

pATCheS wrote:"Actually, drawing two black triangles to clear the screen might even be faster than a color clear... Sounds silly,

Yep that's true. I don't remember why that's true.

glClear() isn't a problem. This is a problem: When having visible transparent textures (e.g. the energy sparks), swapping the render buffers takes twice as much time as if they're invisible. I found this out with a profiler when noticing sudden frame rate drops if such textures got in sight. Any clue?

3803,

obviously the transparency color key is used for that font, so I need to add code to turn color key determination off depending on what D2X-W32 is doing (rendering the mine or not, that is).

patches,

afaik bottom.

1.4.42 Just testing Level 1 all animated doors are opaque, screenies from both sides, same holds true for all multiplayer levels .. eek

Fixed. Only occured when the hardware did not support the required shader program. Multitexturing (requiring that shader program) will now only be enabled for lightmapping or use of high res textures.

With 1.4.43, I don't seem to be able to get to the "configure keyboard" or "configure above" part of the controls menu. Pressing 'up' on the keyboard positively refuses to move the selection any higher than "Mouse Sensitivity".

Yeah, I got that too... somewhat odd, but in the meanwhile you can use the mouse for that...

Fixed.

In .43, I noticed that some alpha-transparent TGA's weren't rendered transparent. Take a look at those reinforced glass textures in that level I sent you a while back if you still have it. Speaking of which, I should finish that.

I still have it - taos11 was the name. No problems with the glass textures - they're partially transparent here.

Oh fooy. Some of them don't look like they're rendered against a solid black background? Over here, it looks like that cubes behind the walls are improperly being culled, as if the walls were being handled by the engine as completely opaque even though you can still see them. It also seems similar to that other issue I had with cloaked walls a long time ago. Which is strange, because I have "render entire mine" checked too. I'll send some shots.