[MetHy]

MetHy, on 29 April 2014 - 07:50 AM, said:

In the version of mapster I'm using (says Mapster32 2.0.0devel r4128 Compiled Nov 2 2013 21:10:46), when manually editing sprites or sectors coordinates with F7 or F8 in 2Dmode, I can't set a "minus" coordinate because it won't register the minus key. I even tried remapping the minus key to another key but that didn't help.

I wanted to check if there was a newer version of mapster (perhaps the issue got fixed) but to be honest I can't even find it here http://dukeworld.duk...ke32/synthesis/

Help please! I'm doing ants work with small sectors, so manually editing sector Z coordinates in 2D mode would be very convenient.

I Derped. You have to hit the number and THEN hit the minus key...

[Hendricks266]

MetHy, on 29 April 2014 - 07:50 AM, said:

I wanted to check if there was a newer version of mapster (perhaps the issue got fixed) but to be honest I can't even find it here http://dukeworld.duk...ke32/synthesis/

Every binary package contains Mapster.

[Fox]

Is it possible to make windowx-y1-2 variables not read-only? It would be usefull to edit these values.

[Helixhorned]

Fox, on 29 April 2014 - 08:07 AM, said:

There is an old bug with fogpal, which in Classic mode the pixels are never 100% the color of the fog.

I believe this is because the game stores 32 tables each fog, while the algorithm for shading assumes you have 32+1.

That's just a consequence of how the fogpal shade tables are constructed. For the last shade index 31, the entries shtab[31][i] (for color indices i) are color indices whose colors are close to the following linear blend: 1/32 * basePaletteColor[i] + 31/32 * fogColor. Thus, the last entry isn't completely the fog color by construction. That's not so noticeable for the colored fogs because those are a lot less represented in the base palette, and the nearest neighbors of all linear blends boil down to the same color. In contrast, grays are represented by a whole 32-entry ramp in the base palette.
Anyhow, see r4456 for a workaround.

Fox, on 29 April 2014 - 11:17 AM, said:

Is it possible to make windowx-y1-2 variables not read-only? It would be usefull to edit these values.

No, not directly. Various other internal variables have values derived from these. What you really want is an interface to the engine function setview().

[Fox]

It's not so noticeable in other colors, but it is there. Can't you extend that to all colors?

[Helixhorned]

You're right, it's there. I was only testing the ugly brown brick texture and therefore hadn't noticed it. Committed to r4457 and feeling bad spamming synthesis with such mini-changes now.

[Fox]

There is quite a problem with .fogpal, because in Duke 3D the visibility of each texture also decreases with the shade. The result is a very unrealistic and unpleasing effect if the fog is not black.



The solution I can think of would require the fog being rendered in two steps, one which darkens the textures and a second one that adds the fog as if the texture shade is ≤ 0.

Speaking mathematically:

Spoiler

How it is:

• Shade 0: adds 10% of # fog
  
• Shade 10: adds 20% of # fog
  
• Shade 20: adds 30% of # fog

How it would be:

• Shade 0: adds 10% of # fog
  
• Shade 10: adds 9.09% of black fog and 10% of # fog
  
• Shade 20: adds 18.18% of black fog and 10% of # fog

[Helixhorned]

Fox, on 30 April 2014 - 03:37 PM, said:

There is quite a problem with .fogpal, because in Duke 3D the visibility of each texture also decreases with the shade.

Are you referring to the fact that with Polymost and r_usetileshades 1, a texture's constant darkening is also a function of its sector's visibility? (Note that there's no such thing as "a texture's visibilty". It makes only sense to speak of the sector member 'visibility', or as the per-pixel attenuation with distance from the eye.) In fact, that's my major beef with TX's original "use tile shades" mode: it just doesn't make a lot of sense to take something that's varying per-pixel and apply that uniformly to a texture.

For this reason, I propose making r_usetileshades 2 the default, which uses lookup tables for the constant darkness attenuation (i.e. shade) and models fog/visibility as linear fading with distance with a particular color. TX, I understood your last comment to mean that you're fine going forward with that?

Fox: what are the renderer settings you're using in that screenshot? Setting r_showcoords to 2 will show some of the relevant ones.

[Fox]

That just sector .filler with r_usenewshading 3 (r_usetileshades doesn't matter).

Spoiler

Helixhorned, on 01 May 2014 - 02:10 AM, said:

models fog/visibility as linear fading with distance with a particular color. TX, I understood your last comment to mean that you're fine going forward with that?

It would be kinda of weird for me if non-black fog behavior was different, especially because you can have a fog that is 99% black yet would be different.

[Helixhorned]

OK, I went ahead and made r_usetileshades 2 the default. I'm curious how the change will be percieved in real situations. As I noted in the commit log, the new default mode

Quote

does not take a sector's visibility values into account for uniform
darkening of a texture. It is more faithful to classic with respect to
fog/visibility *distances*, but may be less so as far as the "tint" of the
texture due to visibility attenuation is concerned.

Fox, on 01 May 2014 - 10:40 AM, said:

Helixhorned, on 01 May 2014 - 02:10 AM, said:

models fog/visibility as linear fading with distance with a particular color. TX, I understood your last comment to mean that you're fine going forward with that?

It would be kinda of weird for me if non-black fog behavior was different, especially because you can have a fog that is 99% black yet would be different.

I should have said "models fog/visibility exclusively as linear fading with distance with a particular color." Fading with distance (i.e. using glFog()) is what the OpenGL normally do in the absence of per-pixel shade table lookups (as currently only implemented with Polymer's r_pr_artmapping). What the original r_usetileshades 1 does is that it basically splits the darkening due to a sector's visibility and puts a part of that as uniform texture attenuation, and the "remaining" part goes into the actual fragment-depth-dependent fogging. As a consequence, with r_usetileshades 1 fog can sometimes cut off much farther compared to classic, as seen on the earlier E1L1 air duct screenshots. (It still cuts off slightly farther with r_usetileshades 2, but only by a small constant factor.)

Quote

That just sector .filler with r_usenewshading 3 (r_usetileshades doesn't matter).

Ah, I see. It only now dawned to me what you meant. Yes, an object's shade also determines the fog parameters, and with linear fog, in particular the far cutoff distance. This is simply due to the OpenGL modes modeling fog after classic, and is easily seen in the central palookup equation (or the inversion thereof). In r4460, I made an object's shade not contribute to fog parameters if that fog comes indeed from a sector[].fogpal -- the fog calculation is done as if the shade were 0. I'm kind of happy with this special case for 'fogpal' because it differentiates it from setting the same pal as .floorpal on the sector.

[Fox]

Worked REALLY good, especially because you can have linear black fog using a fogpal other than zero.

Edit: Since negative shade has no effect with .filler fog, wouldn't it also make sense to remove the glow colors (or glowmaps from highres textures) in the fog?

[Fox]

So "fog" has been disabled for normal palettes?

[Helixhorned]

 Fox, on 01 May 2014 - 03:13 PM, said:

Edit: Since negative shade has no effect with .filler fog, wouldn't it also make sense to remove the glow colors (or glowmaps from highres textures) in the fog?

IMO whether fullbright colors "shine through" the fog should be a property defined together with a particular pal number, to mimic the behavior of how the corresponding palookup table is set up. Currently, things are a little inconsistent between classic and the non-per-pixel-lookup GL modes (apart from the fact that 8-bit mode doesn't directly support fogpal at all). The default fog palettes are set up such that the fading also applies to the fullbright color indices, >= 240. The lookup result indices could in theory be also fullbright, but for sufficently large shade indices, they shouldn't. On the other hand, the OpenGL modes make fullbright colors always shine through. The other major difference is that in the 32-bit modes, a fogged .floorpal is applied automatically to walls and the ceiling of that sector, whereas in classic you'd have to set it manually.

 Fox, on 02 May 2014 - 08:05 PM, said:

So "fog" has been disabled for normal palettes?

How so? The changes have only been adding new stuff, not breaking old things, at least not intentionally.

[LeoD]

Not sure if I'm doing it wrong (again) but the new MinGW GCC 4.9, both 32 and 64 bit, fails to link EDuke32 with LTO=1 (default):

[gcc.exe (i686-posix-sjlj-rev1, Built by MinGW-W64 project) 4.9.0]:

c:/Users/leod/_VCS/eduke32/platform/Windows/lib/32\libSDL2main.a(SDL_windows_main.
o): In function `console_main':
/Users/slouken/release/SDL/SDL2-2.0.3-source/foo-x86/../src/main/windows/
SDL_windows_main.c:140: undefined reference to `SDL_main'
collect2.exe: error: ld returned 1 exit status
Failed linking executable eduke32.exe!

[gcc is /mingw/bin/gcc gcc.exe (x86_64-posix-seh-rev1, Built by MinGW-W64 project) 4.9.0 RENDERTYPE=WIN]:

C:/Progs/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/4.9.0/../.
./../../x86_64-w64-mingw32/lib/../lib/libmingw32.a(lib64_libmingw32_a-
crt0_c.o):crt0_c.c:(.text.startup+0x25): undefined reference to `WinMain'
collect2.exe: error: ld returned 1 exit status
Failed linking executable eduke32.exe!

[Hendricks266]

That's weird. A shot in the dark, but try commenting out this include in build/src/winbits.c:

// Workaround for a bug in mingwrt-4.0.0 and up where a function named main() in misc/src/libcrt/gdtoa/qnan.c takes precedence over the proper one in src/libcrt/crt/main.c.
#if (defined __MINGW32__ && __GNUC__ == 4 && __GNUC_MINOR__  >= 8) || (defined __clang__ && __clang_major__ == 3 && __clang_minor__ >= 4)
# include "mingw_main.c"
#endif

EDIT: From the GCC changelog:

Quote

When using a linker plugin, compiling with the -flto option now generates slim objects files (.o) which only contain intermediate language representation for LTO. Use -ffat-lto-objects to create files which contain additionally the object code. To generate static libraries suitable for LTO processing, use gcc-ar and gcc-ranlib; to list symbols from a slim object file use gcc-nm. (Requires that ar, ranlib and nm have been compiled with plugin support.)

I have a feeling this could be related.

EDIT 2: It could also be a problem in this early MinGW-w64 build. As I wrote on the wiki, I prefer rubenvb's personal builds for MinGW-w64. His folder shows recent activity but nothing for 4.9 yet. I ultimately prefer mainline MinGW, but they are rather slow to update GCC releases.

[LeoD]

 Hendricks266, on 07 May 2014 - 02:19 PM, said:

That's weird. A shot in the dark, but try commenting out this include in build/src/winbits.c:

Nope, doesn't help.

 Hendricks266, on 07 May 2014 - 02:19 PM, said:

It could also be a problem in this early MinGW-w64 build. As I wrote on the wiki, I prefer rubenvb's personal builds for MinGW-w64. His folder shows recent activity but nothing for 4.9 yet. I ultimately prefer mainline MinGW, but they are rather slow to update GCC releases.

I've been using the 4.8.2 w64 builds from the place linked above since October. Except for the header file copying mentioned in the wiki they run out-of-the-box.

 Hendricks266, on 07 May 2014 - 02:19 PM, said:

From the GCC changelog:
[...]
I have a feeling this could be related.

Yup! make OPTOPT=-ffat-lto-objects does the trick for the time being!

[Hendricks266]

You may want to use CUSTOMOPT for that. Setting OPTOPT clobbers the OPTimization OPTions the Makefile throws in.

[LeoD]

 Hendricks266, on 07 May 2014 - 04:15 PM, said:

You may want to use CUSTOMOPT for that. Setting OPTOPT clobbers the OPTimization OPTions the Makefile throws in.

Hm, CUSTOMOPT only works when no OPTOPT (like -march=bdver1 in my case) is given. Seems like a Makefile.common deficiency,

[Micky C]

Is there a recent version of mapster32 readily available and set up for mac? The dukeworld mac zips don't seem to have it?

[rhoenie]

Mickey C, on 15 May 2014 - 12:55 AM, said:

Is there a recent version of mapster32 readily available and set up for mac? The dukeworld mac zips don't seem to have it?

Starting with eduke32_osx-gtk2_lion_svn4466.dmg it is added again now.

Find it here: http://dukeworld.duk...et/eduke32/mac/

[Micky C]

So I try using eduke32 and mapster32 for mac, and the damn thing just can't find duke3d.grp! I remember hearing that the data might have to be placed in some weird location, but I figure between the grp file in the root folder, and between Megaton I've also got installed, it should be able to find one of them. Any ideas? Has this exposed some kind of problem with the mac eduke's ability to detect the megaton locations, or did it simply not have that feature in the first place?

[rhoenie]

Mickey C, on 17 May 2014 - 05:48 PM, said:

So I try using eduke32 and mapster32 for mac, and the damn thing just can't find duke3d.grp! I remember hearing that the data might have to be placed in some weird location, but I figure between the grp file in the root folder, and between Megaton I've also got installed, it should be able to find one of them. Any ideas? Has this exposed some kind of problem with the mac eduke's ability to detect the megaton locations, or did it simply not have that feature in the first place?

Open a Finder window, move the mouse to the menu "Go", press the ALT key, go to "Library". In there is a folder "Application Support". You need to create a new folder "EDuke32" in here and place all the data files from your DOS Duke Nukem 3D installation there.

[Micky C]

Ah yes that did the trick, even got the AMC TC working by moving all the data there. Thanks Rhoenie

[LeoD]

Another GCC 4.9 issue: make ebacktrace1-64.dll fails:

Spoiler

> make ebacktrace
Build started using:
compiler: "gcc -Wimplicit -Wdeclaration-after-statement -O2 -funswitch-loops -fomit-frame-pointer -DNDEBUG -DUSING_LTO -flto -fno-stack-protector  -W -Wall -Werror-implicit-function-declaration -Wpointer-arith -Wextra  -funsigned-char -fno-strict-aliasing -DNO_GCC_BUILTINS -D_FORTIFY_SOURCE=2 -fjump-tables -Wno-unused-result  -Wno-char-subscripts -I/home/eduke-geralds/platform/Windows/include -DUSE_LIBPNG -DUSE_LIBVPX -Isource -Ibuild/include -Isource/jmact -Isource/jaudiolib/include -Isource/enet/include  -fno-pic -DUNDERSCORES -I/home/sdk/dx -I/home/sdk/dx/include  -DHAVE_INTTYPES -DSDL_TARGET=2 -DSDL_FRAMEWORK -D_GNU_SOURCE=1 -DRENDERTYPESDL=1 -DMIXERTYPEWIN=1 -Wno-strict-overflow -DUSE_OPENGL -DNOASM -DPOLYMER  -Wno-attributes"
linker: " -flto -static-libgcc  -Wl,-Map=start.memmap  -L/home/eduke-geralds/source/jaudiolib/third-party/Windows/lib/64  -L/home/eduke-geralds/platform/Windows/lib/64   -lFLAC -lvorbisfile -lvorbis -logg -ldsound -lm -lvpx  -Wl,--enable-auto-import -lmingwex -lgdi32 -lcomctl32 -lwinmm -lssp -lwsock32 -lws2_32 -lshlwapi -mwindows -static -lSDL2main -lSDL2 -lmingw32 -lgdi32 -limm32 -lole32 -loleaut32 -lwinmm -lversion -ldxguid_sdl -lpng_mini -lz_mini -lcompat-from-mingw-w64  -lstdc++"
C:/Progs/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/4.9.0/../.
./../../x86_64-w64-mingw32/bin/ld.exe: cannot find -liberty
collect2.exe: error: ld returned 1 exit status
Failed building ebacktrace1-64.dll from platform/Windows/src/backtrace.c!
make: *** [ebacktrace1-64.dll] Error 1

Seems they forgot mingw64/lib/libiberty.a. I have copied the 4.8.2 version as a workaround.

[MetHy]

What exactly has changed with eduke32 (compared to vanilla duke) regarding parallaxed subway sectors throwing rockets?
What I mean is, in a map I've made I've made a spaceship throwing rockets E2L1 style. It works like intended in eduke32 but when trying the map in dos duke3d and in megaton, the rockets would always hit a boarder of the spaceship and not come to the player.

It's not really a problem (i'm sure i can fix this so that it works in all dukes), just wondering.

[Danukem]

MetHy, on 18 May 2014 - 02:22 PM, said:

What exactly has changed with eduke32 (compared to vanilla duke) regarding parallaxed subway sectors throwing rockets?
What I mean is, in a map I've made I've made a spaceship throwing rockets E2L1 style. It works like intended in eduke32 but when trying the map in dos duke3d and in megaton, the rockets would always hit a boarder of the spaceship and not come to the player.

It's not really a problem (i'm sure i can fix this so that it works in all dukes), just wondering.

An educated guess: EDuke32 uses higher bit numbers and so has more precision when calculating how to aim at the player. This can make a large difference if the player is far away, especially if the player is above or below the rocket.

[MetHy]

Trooper Dan, on 19 May 2014 - 07:06 AM, said:

An educated guess: EDuke32 uses higher bit numbers and so has more precision when calculating how to aim at the player. This can make a large difference if the player is far away, especially if the player is above or below the rocket.

Would that make a difference regarding enemies, too ?

[Danukem]

MetHy, on 19 May 2014 - 08:47 AM, said:

Would that make a difference regarding enemies, too ?

If my guess is correct and if enemies use the same aiming function (which they probably do), then yes. But it wouldn't be as noticeable, because enemies are coded to fire only when they have a line of sight to the player and they tend to fall asleep when they are far away.

[MetHy]

So technically, for example a Commander being high above the player will have better aiming in eduke32 than in classic duke...

[Fox]

You could post a picture of said spaceship, so we can have an idea of how you are using the effect.