[Diaz]

Thanks a lot

[LeoD]

r3233 / r3234 come without ebacktrace1.dll - intentionally?

[Hendricks266]

No, it's a problem with the cross compiler Plagman switched synthesis to use.

Windows/src/backtrace.c:33:17: fatal error: bfd.h: No such file or directory

http://sourceforge.n...msg_id=28824872

[Striker]

StrikerMan780, on 01 November 2010 - 06:39 AM, said:

Don't know if this counts, but one annoyance is that in Polymer, when you shoot two rockets into the same spot, the explosions have giant squares cut out of them on occasion, and sometimes flicker, or cut out sprites behind them.

Bringing this up again... thinking more about it, would this be an issue with Depth Sorting?

[LeoD]

r3334 has left a bunch of empty directories in source/jaudiolib/third-party.

[Hendricks266]

That's git-svn being insufficient. I'll take a look after my next push and delete them using my home synthesis svn checkout.

[LeoD]

Savegame version mismatch:
I'd like to have the last part of the version number being equal (or close) to the EDuke32 repository version that introduced the increment.
That way it's easier to find a binary that runs older saved games. There have been a lot of changes recently...

[Tetsuo]

If there's two "paper cuts" that annoy me with eduke32 (on the Mac in particular) is the delete key on the mac keyboard not deleting (backspace for you PC folk) and the eduke32 log is getting saved into the application folder rather than in the user folder where everything else for eduke32 resides. No files should be saved into the Application Folder in OS X.

[Helixhorned]

LeoD, on 04 January 2013 - 02:12 PM, said:

Savegame version mismatch:
I'd like to have the last part of the version number being equal (or close) to the EDuke32 repository version that introduced the increment.
That way it's easier to find a binary that runs older saved games. There have been a lot of changes recently...

Mmh, I dunno. On one hand, it seems logical, but it would make these version numbers have holes. What you can do now is to browse the change history of source/duke3d.h -- most of them tend to be BYTEVERSION bumps.

Tetsuo, on 04 January 2013 - 03:15 PM, said:

(...) and the eduke32 log is getting saved into the application folder rather than in the user folder where everything else for eduke32 resides. No files should be saved into the Application Folder in OS X.

I think that the log file gets saved to the initial current working directory of the EDuke32 process. For Windows, you'd configure that in the settings of the shortcut icon. When you're running from a terminal, then the cd'd directory is obviously the initial CWD. I don't know how OS X handles that when running programs from its "bundles".

[Tetsuo]

How are you putting the cfg files or loading stuff (like the HRP) from the user folder ~/Library/Application Support/eduke32/ then?

[LeoD]

r3422 :
It seems to me that eduke32.debug.exe isn't built correctly. (Only 2.7MB compared to 4.9MB of r3411.) A crash with a map known to be corrupt leaves a somewhat dissatisfying eduke32_or_mapster32.crashlog.

Attached File(s)

•  r3411-eduke32_or_mapster32.crash.log (2.48K)
  Number of downloads: 271
•  r3422-eduke32_or_mapster32.crash.log (2.58K)
  Number of downloads: 290

[Helixhorned]

Weird. I'm definitely getting debugging symbols in the RELEASE=0 build.

edit: OK, should be fixed.

[Player Lin]

Not have time to test with recent SVN/synthesis builds with HUB maps/mods, but want to ask a question...

Do the "resetting statistics of level to all 0 when changing one of HUB levels" bug still exists on recent eduke32 builds? I remember it was annoying when I play AMC TC and in some HUB levels, it keeps resetting my statistics and make me confusing about that...

[Hendricks266]

Was that ever even reported?

[Player Lin]

Hendricks266, on 23 January 2013 - 04:47 PM, said:

Was that ever even reported?

I guess not...so should I post a post about on the bug report forum?

[Hendricks266]

No, posting here is a perfectly valid report. I was just answering why the bug still exists.

[Player Lin]

Hendricks266, on 24 January 2013 - 01:31 AM, said:

No, posting here is a perfectly valid report. I was just answering why the bug still exists.

OK, I just think too much.

Apparently, looks like no one care this minor bug except me so it never got report...I think I were too lazy to report that...

[Player Lin]

I tried the latest one synthesis build of eduke32 (r3433), I noticed two small glitches/bugs happened...

1. ALT-TAB out from eduke32 and go back to it will cause it forced to switching to window mode, only happens on 16/32bit OpenGL renderer, software one is fine.

2. The sector light level that player's direction of facing(or something related the light level of sector) will affected AutoMap's "light level" too, if I faced/stand on a room where it's very dark, when I actives AutoMap and it will looks very dark too, again it only happens on OpenGL renderer too, classic software just working fine as hell.

[LeoD]

make POLYMER=0 fails as of r2567:

{eduke32_svn-2567}> make POLYMER=0
source/game.c: In function 'G_DrawRooms':
source/game.c:3763:25: error: implicit declaration of function 'bglReadPixels' [-Werror=implicit-function-declaration]
source/game.c:3763:53: error: 'GL_RGBA' undeclared (first use in this function)
source/game.c:3763:53: note: each undeclared identifier is reported only once for each function it appears in
source/game.c:3763:61: error: 'GL_UNSIGNED_BYTE' undeclared (first use in this function)
cc1.exe: some warnings being treated as errors
Failed building obj_win/game.o from source/game.c!

r3438 changes the error message style:

{eduke32_svn-3438}> make POLYMER=0
In file included from source/duke3d.h:33:0,
                 from source/game.c:23:
build/include/build.h: In function 'push_nofog':
build/include/build.h:1067:9: error: implicit declaration of function 'bglPushAttrib' [-Werror=implicit-function-declaration]
build/include/build.h:1067:23: error: 'GL_ENABLE_BIT' undeclared (first use in this function)
build/include/build.h:1067:23: note: each undeclared identifier is reported only once for each function it appears in
build/include/build.h:1068:9: error: implicit declaration of function 'bglDisable' [-Werror=implicit-function-declaration]
build/include/build.h:1068:20: error: 'GL_FOG' undeclared (first use in this function)
build/include/build.h: In function 'pop_nofog':
build/include/build.h:1077:9: error: implicit declaration of function 'bglPopAttrib' [-Werror=implicit-function-declaration]
source/game.c: In function 'G_ReadGLFrame':
source/game.c:3509:13: error: implicit declaration of function 'bglReadPixels' [-Werror=implicit-function-declaration]
source/game.c:3509:41: error: 'GL_RGBA' undeclared (first use in this function)
source/game.c:3509:49: error: 'GL_UNSIGNED_BYTE' undeclared (first use in this function)
cc1.exe: some warnings being treated as errors
Failed building obj_win/game.o from source/game.c!

[Gambini]

Modern Eduke32 builds fix an issue that has been exploited to create effects in old mods.

When a composite parallax texture is used as sky (ie big orbit) and in another part of the map a simple sky is used, the latter will automatically build a set, using the tiles that follow it (in the order of the hardcoded sky). This that could cause visual glitches when the mapper is mentally handicaped, also allowed modders to create new sets of skies. I tested it and works in jonof and a 2006 Eduke32 build, but not in recent ones.

Another thing: Could it be possible to play with the usenewshading thing so we can find a tradeoff between the old and the new way? I say because I have a large map that shows up fine in software, when I switch to poylmost it looks very very dark and if I disable "usenewshading" it looks fullbright. There´s no mid term, both modes are extreme.
If something like "r_usenewshading 0.8" or something could be applied, mappers would be able to find a balance for each situation.

[Gambini]

Ding Ding Ding!

[Helixhorned]

Gambini, on 27 January 2013 - 07:49 AM, said:

Another thing: Could it be possible to play with the usenewshading thing so we can find a tradeoff between the old and the new way? I say because I have a large map that shows up fine in software, when I switch to poylmost it looks very very dark and if I disable "usenewshading" it looks fullbright. There´s no mid term, both modes are extreme.
If something like "r_usenewshading 0.8" or something could be applied, mappers would be able to find a balance for each situation.

I think this would only compound the problem of having already too many "tuning knob" variables. What kind of dark do you mean? Recently, r_shadescale was set to 1.0 by default, but if the old value 1.3 was overridden, that one will be loaded. Also, are the GL modes and classic the same as far as color correction is concerned on your system? Maybe a screenshot would tell more...

[LeoD]

Helixhorned, on 27 January 2013 - 12:39 PM, said:

I think this would only compound the problem of having already too many "tuning knob" variables.

The problem, even for experienced players, is to find and to know them.
eduke32.cfg, settings.cfg, autoexec.cfg, console commands ... all that makes my head spin, tbh.
If there was a modern ingame menu or at least a setup program that helps me actually turning the knobs (and maybe even explains them for the non-experts) ...

[Gambini]

Helixhorned, on 27 January 2013 - 12:39 PM, said:

I think this would only compound the problem of having already too many "tuning knob" variables. What kind of dark do you mean? Recently, r_shadescale was set to 1.0 by default, but if the old value 1.3 was overridden, that one will be loaded. Also, are the GL modes and classic the same as far as color correction is concerned on your system? Maybe a screenshot would tell more...

Well I understand that, but as long as it´s a command that modders can use in favor of optimizing the visual aspect of their work (so damaged by the large amount of other knobs) I don´t see problem at all. It´s not like I´m going to give installation instructions that read "turn r_thisthing to 0.97 and r_thisotherthing to 1.135 but not without first turning r_thisanotherthing into 0.0043". I plan to make it work automatically (I hope that´s possible).

Right now the lack of that knob is like having a car with a button instead of a gas pedal, it can go either 10km/h or 130km/h. And we know neither of those speeds are suitable for avenues. The same happens with the newshading system. What´s its purpose if it can´t emulate the software renderer? Right now feels like a third shading system that will only create more incompatibility issues.

[Plagman]

The point that Helix made is that it's supposed to look like software. If it doesn't, there's a problem with it and it needs to be fixed rather than implementing a new stop-gap. Can you attach a map with a scene that looks different in SW vs GL with usenewshading = 2 and shadescale = 1.0?

[Gambini]

The map where I´m having this problem can´t be published (by many reasons), but I´ll try to reproduce the same problem on a clean map.

I´m downloading the latetetest eduke32 build firt, but the one I have has no usenewshading = 2.

[Gambini]

Well, certainly, the usenewshading 2 is as closest as humanly possible is to emulate the software shading on open-gl renderers.

I just happened to have a quite dated copy, because it worked OK and because I wasn´t aware further changes were made in regards to the matter of discussion.

Now, considering the great progression this means, I´d consider the next steps, in the hunt of perfection, being the following:

polymost/polymer with newshading 2 looks much more like software when contrast is set to 1.05. This means software:contrast:1.00 and polymost/er:constrast:1.05 are much more similar than software:contrast:1.00 and polymost/er:constrast:1.00

Another thing that may be a little bit more complex but worth the try anyway is the color correction. In software colors look much more warm. In open gl everything looks greenish. I played with my monitor setup, fixing two different presets and ended up having a great result by slightly lowering the green and sliglthy raising the red for open-gl. This could be tied to the newshading 2, considering it´s ment to emulate the software renderer.

The following paragraph is hardly related to my initial report, and it´s just a suggestion:

Now, just letting my mind go... I´d study the possibility of using posterization for this newshading thing. Posterization restrains the use of colors to a specified range. With which -once the right value is nailed- we could emulate the gritty look of the shadetables in a much more easy way than applying the shadetables to a modern engine (at least until that is finally applied).

[Plagman]

What do you mean by contrast exactly? Which cvar?

[Gambini]

In the color correction setup. dunno if it´s operable through the console.

[Gambini]

Bug: The intro sound stops playing as soon as I skip the intro animation.