[0utlawz]

Maybe it looks small because I stay away from her
look nice when she making babies out from her bottom
I've just tried the latest polymer hrp, now the alien's egg look shiny like from duke nukem forever screen shot

[LeoD]

The Commander, on Jan 11 2011, 03:24 AM, said:

My suggestion would be to always use the latest one available, and always use the eduke32/mapster32.debug.exe
That way if it "does" crash you can upload the "eduke32.crashlog" which contains a lot more useful information than the "eduke32.log"

Since I'm not that deep into compiling/debugging: does it make sense to run a self-compiled debug-executable (I have fiddled with some compile options) or will the debugger outputs be mostly unusable to the developers?

[Plagman]

As long as you build with RELEASE=0 on Windows, it should enable the code that dumps the crashlog. You're using MinGW/GCC, right?

[LeoD]

Plagman, on Jan 11 2011, 09:04 PM, said:

As long as you build with RELEASE=0 on Windows,

I do.

Plagman, on Jan 11 2011, 09:04 PM, said:

You're using MinGW/GCC, right?

Yes.

OK, I'll keep using my debug executables.

[Scrooge]

Scrooge, on Jan 7 2011, 09:25 PM, said:

Hello,

I have a ATI X1900, and I want to set the option r_pr_ati_nodepthoffset manually,
because this looks like what I need. (freeze when a sprite come in sight)

Unfortunately, setting this option, followed by "restartvid" doesn't seem to work, and the flag is reset after the restart : (eduke32.log)

EDuke32 2.0.0devel 20100727
...
Uninitializing DirectInput...
Executing "settings.cfg"
Disabling desktop composition...
Setting video mode 1280x800 (32-bit fullscreen)
Enabling ATI FBO color attachment workaround.
OpenGL Information:
 Version:  2.1.8545 Release
 Vendor:   ATI Technologies Inc.
 Renderer: ATI MOBILITY RADEON X1900
......
 Version:  2.1.8545 Release
 Vendor:   ATI Technologies Inc.
 Renderer: ATI MOBILITY RADEON X1900
 Maximum anisotropy:      16.0
 BGRA textures:           supported
 Non-power-of-2 textures: supported
 Texure compression:      supported
 Clamp-to-edge:           supported
 Multisampling:           not supported
 Nvidia multisample hint: not supported
 ARBfp fragment programs: supported
 Depth textures:          supported
 Shadow textures:         supported
 Frame Buffer Objects:    supported
 Rectangle textures:      supported
 Multitexturing:          supported
 env_combine:             supported
 Vertex Buffer Objects:   supported
 Shader Model 4:          not supported
 Occlusion queries:       supported
 GLSL:                    supported

I've tried on build 1750 / 1753, the log contains the glinfo.
Is there another way to force r_pr_ati_nodepthoffset to 1 ?
Thank you for your help !

Whoo ! Found the problem myself in the code ,1759 smapshot
sdllayer. c (1138) and winlayer.c (2854):

  if (!Bstrncmp(glinfo.renderer,"Radeon X1", 9))
                {
                    r_vbos = 0;
#ifdef POLYMER
                    pr_ati_nodepthoffset = 1;
                    initprintf("Enabling ATI R520 polygon offset workaround.\n");
#endif
                }

==> Problem is, the test in glinfo.renderer fails because it expects somthing starting with "Radeon X1.." so that
my Mobility x1900 defined as ATI MOBILITY RADEON X1900 fail the test.

I think the ATI model test should be smarter here, since it leads for some perfectly good cards to be inplayable because they fail to be detected properly, such as (seen in own driver .inf installation file):

"ATI MOBILITY RADEON X1600"
"ATI MOBILITY RADEON X1700"
...

but also desktop ones that (may ) be OK, that have vendor-specific strings:

"ATI Radeon X1050 "
"ATI Radeon X1550 Series"
"ASUS Radeon X1550 Series "

....such as [whatever] Radeon X[NNNN] ..."

indeed, in my Catalyst 10.2 Legacy driver (latest available for pre-HD boards)
the only cards that could have worked are very few...

I confirmed this by two means :
- hacking the test string in the excutable
- Reinstalling my driver after modifying the string in the driver Inf into something "Radeon X1900 MOBILITY"

And no, I was too lazy to install VS2010, SVN and recompiling the thingy, sorry...

So, after that, the pr_ati_nodepthoffset was indeed set at Polymer startup, and... the game works well, if not very fast !!

Enabling ATI FBO color attachment workaround.
Enabling ATI R520 polygon offset workaround.
OpenGL Information:
 Version:  2.1.8545 Release
 Vendor:   ATI Technologies Inc.
 Renderer: Radeon X1900 MOBILITY

[TerminX]

Thanks for the thorough bug report. I'll change the detection to use strstr() to find any instance of the string "Radeon X1" inside the gl.renderer string instead of only checking the beginning of it.

[Scrooge]

TX, on Jan 15 2011, 06:43 PM, said:

Thanks for the thorough bug report. I'll change the detection to use strstr() to find any instance of the string "Radeon X1" inside the gl.renderer string instead of only checking the beginning of it.

Well...sorry to bother you again

I got a problem with texture cache. When I run eduke in command line (-nosetup option), texture cache is activated,
while if I ran using the setup window, it is systematically de-activated with a lovely :
"Unable to open cache index: no such file or directory" in the eduke.log. (I'm runing Windows Vista 32)

My hypothesis: in polymost.c(755) : cacheindexptr = Bfopen(ptempbuf, "at+");

it attempts to open/create/append a file named "textures.cache", doing so in the current dir I suppose.
So apparenty, when lunched in command line , the current dir is set correctly (the one of the executable)
while it is...somewhere else while lunched in the setup window, apparently where we have no RW access.

I definitive fix would be to always pass the full path of the desired file. (concerns both textures and textures.cache file)
A classical trouble I got reguraly in my own job.

[TerminX]

How exactly are you executing it when you run into that problem? I don't have access to Windows for another week but I have NEVER encountered the problem you're experiencing. One thing you might want to check is that you haven't previously set a mod dir to use from that dropdown box in the setup window and then gone and deleted it, possibly leaving an invalid dir specified in the cfg.

[Scrooge]

TX, on Jan 16 2011, 07:11 PM, said:

... One thing you might want to check is that you haven't previously set a mod dir to use from that dropdown box in the setup window and then gone and deleted it, possibly leaving an invalid dir specified in the cfg.

Well, you got it right !
the ModDir entry in eduke32.cfg pointed to a non existsing dir. Deleting this entry alone set the thing right again.
I didn't realize it first because the drop-down mod list in Setup is hidden, probably due to my police settings (115% normal size) that sometimes make trouble in window layouts.

[TerminX]

Ugh... I don't know how it is in Vista, but in Windows 7 when you increase the size of things, the window controls and layout and everything else scale accordingly. Unfortunately, I think the only way to fix this for the older operating systems is to have a bunch of blank space at the bottom of the window to account for where things will be when the setting is changed. Blah.

[Stabs]

so whats the deal with newer versions of eduke Iam missing lights in the streets and whole sectors are just unshaded now, lights are not lighting up models untill you get closer to them, is this just early stages of optimization?

[Danukem]

DanM, on Jan 16 2011, 06:09 PM, said:

so whats the deal with newer versions of eduke Iam missing lights in the streets and whole sectors are just unshaded now, lights are not lighting up models untill you get closer to them, is this just early stages of optimization?

You have done a direct comparison with the older versions using the exact same CON code and Polymer settings, right? Just making sure.

EDIT: Try comparing r1759 with r1760, since r1760 is the most likely recent revision to be the culprit.

[Stabs]

DeeperThought, on Jan 16 2011, 06:17 PM, said:

You have done a direct comparison with the older versions using the exact same CON code and Polymer settings, right? Just making sure.

EDIT: Try comparing r1759 with r1760, since r1760 is the most likely recent revision to be the culprit.

yeh ive played around with older version i can give some more exact numbers when i get home tho

[Stabs]

It is 1757 fault

Perform the highpal lookup after the diffuse modulation and detail to hit more range in the highpalookup map. This shuffles a fair bit of lighting model around, so I wouldn't be surprised if I broke something.

The prophecy has been fulfilled!

[Plagman]

I totally called it. Sorry about that, can you send me a map where I can easily see the before/after?

[Plagman]

DanM, can you try revision 1773? Let me know if you see any more glitches like that; thanks for the heads-up.

[Stabs]

Will check it out when i get home in about 3 hours, iam guessing if that map i sent you is displaying properly now then its fixed

interesting to note, some of those dark bug areas still had there height/ spec working and what looked like some faint light, it actually looked like some really good moonlight / global light

[Plagman]

Yeah, that's because the bug removed the diffuse contribution of the light but kept the specular contribution, so you only had the highlight remaining. If you change your diffuse maps to be very dark, you'll get the same result (as opposed to using a bright diffuse map and darkening it using sector shading).

[Stabs]

Well that works fine again

That "bug" actually looked like some of the best natural moonlight with the way it would just glint the high points and have this dark light on it, I hope global lighting looks like that when it gets implemented, i wouldnt write that of as a bug

[Danukem]

As Plagman was saying, you can change the diffuse maps to be dark in the model defs and it should have the same effect.

[Plagman]

Not in the DEF, that's the same as shading and gets ignored by the diffuse contribution of lights. Having an actual dark diffuse texture will do that, though.

[Stabs]

Is this right plagman?,

i Had a quick go of 1775 which ran fine, but afterwards i opened up afterburner and it says only averaging 10 - 20% of my GPU for eduke, the max was at the start of the map it when spiked to 32%, its a gtx570 shouldn't it be using a bit more than that?

[Plagman]

It should, but it doesn't because the GPU is constantly interrupted and forced to wait until given more work (when switching materials, etc). That's mostly what the "optimization" work is going to target.

[bioman]

Rev 1776 fails to build with POLYMER=0 :

src/defs.c: In function ‘defsparser’:
src/defs.c:1492: error: ‘PR_HIGHPALOOKUP_DATA_SIZE’ undeclared (first use in this function)
src/defs.c:1492: error: (Each undeclared identifier is reported only once
src/defs.c:1492: error: for each function it appears in.)
src/defs.c:1510: error: ‘PR_HIGHPALOOKUP_DIM’ undeclared (first use in this function)
src/defs.c:1524: error: implicit declaration of function ‘polymer_definehighpalookup’
Failed building ../eobj/defs.o from src/defs.c!

[Stranger1st]

Is it possible to have the original precalculated shadows while using polymer?

[Micky C]

If you mean the sector based shading then yes. Why would you even ask that question? Just load up the game and see for yourself.

[Danukem]

I'm pretty sure he was referring to sprite shadows. I wouldn't call those "pre-calculated" though. They are just black transparent sprites that are shortened and placed at the base of the regular sprite.

[SwissCm]

Geez, you're all wrong. He means pre-baked lightmaps and no they aren't going to be implemented since build's levels geometry changes too much on-the-fly for it to look any good.

[Micky C]

But that definitely can't be right SwissCm as he used the word "original" as in the feature was in the game since it was released in 1996. What I'm sure we can all agree on is that he worded his question terribly, however DT's interpretation is the most likely.

In that case to answer his question fully: Is it possible? yes. By that I mean one of the eduke developers can put it in, but right now polymer can't do that as far as I'm aware, so in reality the answer is no. But polymer has better, far more realistic shadows so there's no reason to use the old method. Check the maphacks link in the signature of this post to get the light pack for Duke3D. Episode 3 has the best lights with the most shadow emitting lights as well, but I might be biased because I made them myself http://forums2.duke4...tyle_emoticons/default/biggrin.gif

[Stranger1st]

I meant sprite shadows, nevermind.