Duke4.net Forums: EDuke32 2.0 and Polymer! - Duke4.net Forums

Jump to content

  • 213 Pages +
  • « First
  • 153
  • 154
  • 155
  • 156
  • 157
  • Last »
  • You cannot start a new topic
  • You cannot reply to this topic

EDuke32 2.0 and Polymer!  "talk about the wonders of EDuke32 and the new renderer"

User is offline   Fox 

  • Fraka kaka kaka kaka-kow!

#4621

So "fog" has been disabled for normal palettes?
0

User is offline   Helixhorned 

  • EDuke32 Developer

#4622

View PostFox, 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.

View PostFox, 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.
0

User is offline   LeoD 

  • Duke4.net topic/3513

#4623

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!

1

User is offline   Hendricks266 

  • Weaponized Autism

  #4624

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.

This post has been edited by Hendricks266: 07 May 2014 - 02:35 PM

0

User is offline   LeoD 

  • Duke4.net topic/3513

#4625

View PostHendricks266, 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.

View PostHendricks266, 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.

View PostHendricks266, 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!
0

User is offline   Hendricks266 

  • Weaponized Autism

  #4626

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

User is offline   LeoD 

  • Duke4.net topic/3513

#4627

View PostHendricks266, 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,
0

User is offline   Micky C 

  • Honored Donor

#4628

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

User is offline   rhoenie 

#4629

View PostMickey 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/
3

User is offline   Micky C 

  • Honored Donor

#4630

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?
0

User is offline   rhoenie 

#4631

View PostMickey 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.
2

User is offline   Micky C 

  • Honored Donor

#4632

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

User is offline   LeoD 

  • Duke4.net topic/3513

#4633

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

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

This post has been edited by Mblackwell: 18 May 2014 - 10:02 PM
Reason for edit: spoilered for HUGE

0

User is offline   MetHy 

#4634

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.
0

User is online   Danukem 

  • Duke Plus Developer

#4635

View PostMetHy, 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.
0

User is offline   MetHy 

#4636

View PostTrooper 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 ?
0

User is online   Danukem 

  • Duke Plus Developer

#4637

View PostMetHy, 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.
0

User is offline   MetHy 

#4638

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

User is offline   Fox 

  • Fraka kaka kaka kaka-kow!

#4639

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

User is offline   MetHy 

#4640

Well, the spaceship is high above playing level. Well, not that high, like 40 units higher; and that seems to be the reason why the rockets explode as they're shot in classic Duke.
The only way I could make it work in classic Duke was if I lowered the subway SE (which is where the rockets come from) by at least 15-20 units (come to think of it, the spaceship in E2L1 wasn't that high above the player), however that wouldn't work at all in the level I've made unless I completely reshape the whole level, and even then it wouldn't be as good as it is now.

I've tried everything btw and the source of the rocket shooting being too high is the only explanation I've found. It has nothing to do with the rockets hitting the spaceship itself or the sky, or the size and shape of the sector, etc

Conclusion : the level will be eduke32 only (even though I like my levels to be playable in all dukes if possible). What pisses me off a little though is how I had no idea those subway parallax sector rockets behaved differently in eduke32, and if I had known, considering how early on I implemented that spaceship, I COULD have come up with a way to make it work in all Dukes. Now though, it's too late as reshaping the whole level at this point is out of question.
Then again, how could I have known; I doubt even the makers of eduke32 knew those rockets behave differently than in classic Duke.

Something else completely different now : the sprite no shade feature doesn't work on flat ("ground aligned") sprites when there is a parallax sky above. Is that how it's always been?
0

#4641

Do you have shade preview enabled ( ' + X ) ? I don't think it shows up without that, assuming you're talking about Mapster of course. If it's in EDuke I certainly don't remember it behaving like that.
0

User is offline   Daedolon 

  • Ancient Blood God

#4642

View PostMetHy, on 20 May 2014 - 03:55 AM, said:

Something else completely different now : the sprite no shade feature doesn't work on flat ("ground aligned") sprites when there is a parallax sky above. Is that how it's always been?


It only works for floor shade, if you have a parallaxed ceiling, the sprite will take its shade. Check out the cables in my CBP map for the winch system outside.
0

User is offline   MetHy 

#4643

Well, I've built a workaround, it's only 3 sprites so I built I tiny sector at the base of the sprites and I gave the skies of those tiny sector the shade value I wanted for the sprite; I was just wondering if that's how sprite no shade is supposed to behave. Wouldn't it be nice if it also worked when there are parallaxed skies?
1

User is online   Danukem 

  • Duke Plus Developer

#4644

View PostDaedolon, on 20 May 2014 - 04:04 AM, said:

It only works for floor shade, if you have a parallaxed ceiling, the sprite will take its shade. Check out the cables in my CBP map for the winch system outside.


That's a bug. spritenoshade is supposed to make the sprite unaffected by the sector's shade, regardless of whether it is floor or ceiling.
0

User is offline   Helixhorned 

  • EDuke32 Developer

#4645

View PostMetHy, on 20 May 2014 - 03:55 AM, said:

Something else completely different now : the sprite no shade feature doesn't work on flat ("ground aligned") sprites when there is a parallax sky above. Is that how it's always been?

I can't reproduce this. Placing a floor-aligned sprite into a sector with a parallaxed ceiling and enabling the sprite's "don't take over shade" bit (key [N] in Mapster32), the sprite keeps its own shade value in the editor (don't forget to enable shade preview with [']+[X] as High Treason remarked) as well as the game.
0

User is offline   Sobek 

  • There's coffee in that nebula!

#4646

Hmm. So I've been away for a couple of years really (popped my head in the door from time to time). Could anyone tell me what some of the biggest improvements or changes have been to eDuke32 in that time? I remember every couple of days I'd read the changelog on new builds and be amazed at some of the excellent fixes present, but I'm just curious if there have been any MAJOR improvements made anywhere that I should know about. I used to struggle with some annoying little glitches (like models that would just vanish because the engine decided they didn't need to be rendered from that particular viewpoint or sector, for example). Just curious what you consider to be the highlights so I can start getting caught up again :)

Spent the last few days just cleaning up a fresh install so I can get back into things. Have been playing some dukematches with my best friend on some of our old maps we made and having such a blast. Just about ready to get stuck into it all again I think!
0

User is offline   Micky C 

  • Honored Donor

#4647

One thing you might find useful is something called clipshape maps, allowing you to have accurate model clipping by recreating the rough shape of the model using sector geometry in a special map file, which the engine then uses for clipping information.

Not sure how familiar you are with Polymer and TROR but those are around. There's also better fogpal for openGL modes independent of shade, and alternate palates in polymer are now accurate for hightile textures when using the correct generated references "tables" (can't remember the name).

This post has been edited by Mickey C: 20 May 2014 - 04:49 PM

0

User is offline   Daedolon 

  • Ancient Blood God

#4648

View PostHelixhorned, on 20 May 2014 - 08:15 AM, said:

I can't reproduce this. Placing a floor-aligned sprite into a sector with a parallaxed ceiling and enabling the sprite's "don't take over shade" bit (key [N] in Mapster32), the sprite keeps its own shade value in the editor (don't forget to enable shade preview with [']+[X] as High Treason remarked) as well as the game.


Note that few sprites have hardcoded behaviour to ruin this as well.
0

User is offline   MetHy 

#4649

There has been a glitch for quite a while now (still in the latest eduke32 version, i checked) that makes turrets a LOT harder to hit then they should be.
0

User is offline   Helixhorned 

  • EDuke32 Developer

#4650

View PostDaedolon, on 21 May 2014 - 06:51 AM, said:

Note that few sprites have hardcoded behaviour to ruin this as well.

Yes, in actors.c, some cases of the actor SFLAG_NOSHADE have inconsistent coding. The set of problematic tiles is probably as follows.

In G_MoveZombieActors(); the A_CheckSpriteFlags() call is currently buggy r4477: on transitioning from zombie actors to STAT_STANDABLE, these will always take over either the ceiling or the floor shade:
Spoiler

Sprites affected by SE12 (light switch) when "Lights flickering on":
                for (SPRITES_OF_SECT(SECT, j))
                {
                    if (sprite[j].cstat&16)
                    {
                        if (sc->ceilingstat&1 && A_CheckSpriteFlags(j,SFLAG_NOSHADE) == 0)
                            sprite[j].shade = sc->ceilingshade;
                        else sprite[j].shade = sc->floorshade;
                    }
                }


This is not to be confused with functionality for the sprite "don't take over shade flag", which controls sprite[].shade -> displayed sprite shade in G_DoSpriteAnimations(). This one should be working fine.
So, MetHy: was this a false alarm (shade preview not enabled?) or is it one of the problematic cases above?

---
Regarding the few last reports of alleged bugs in general: posting a test case straight away usually yields better results than merely telling.

EDIT2: actually, I recall the turret-hard-to-hit bug from playing the beach CBP. No need for a test case for that, but it might be a while until I'll debug it.
0

Share this topic:


  • 213 Pages +
  • « First
  • 153
  • 154
  • 155
  • 156
  • 157
  • Last »
  • You cannot start a new topic
  • You cannot reply to this topic


All copyrights and trademarks not owned by Voidpoint, LLC are the sole property of their respective owners. Play Ion Fury! ;) © Voidpoint, LLC

Enter your sign in name and password


Sign in options