[darkprince227]

Strangely, whenever I play Nuclear Winter of Caribbean with Polymer, it seems to go okay (a bit laggy) but whenever I run it with the original game or Duke DC, it goes unbearably slow. I'm using LeoD's 64-bit build, is there something wrong?

[LeoD]

darkprince227, on 19 October 2013 - 12:05 PM, said:

Strangely, whenever I play Nuclear Winter of Caribbean with Polymer, it seems to go okay (a bit laggy) but whenever I run it with the original game or Duke DC, it goes unbearably slow. I'm using LeoD's 64-bit build, is there something wrong?

If you use the HRP then this is mostly because of the Polymer lights which have been added in the maphacks for Atomic and DC maps (and more polymerized textures being used).

[Micky C]

What's the console command to save the current state of the map in eduke32 as a new map? I've got some massive kind of bug going on which happens about halfway through progression, and I need to examine it in mapster post-glitch to try to isolate the problem.

[Mblackwell]

dndebug

[Micky C]

Thanks, crisis averted.

[Mblackwell]

Micky C, on 25 October 2013 - 07:52 PM, said:

Thanks, crisis averted.

Any time!

[MacoMan]

Just finished playing an excellent community map called "Suburban Hive" but discovered that even on my fairly beefy system (i5, GTX 660 Ti) polymer really kills framerates (even with 64-bit eduke builds), especially when there's lots of fire around or masses of enemies. Though I found polymer invaluable for helping me get around in the dark (the shrinker emits an eerie pulsating green glow in its non-firing state... hehe) it's murder during firefights - as in the murder of me, when FPS drops to less than 4-5. Have to exit, then restart the game with polymer disabled. I would like to request a feature for a future eduke build to turn on & off polymer in the console so we don't have to exit & restart, if this is in fact even possible. Thanks for the great work.

[Helixhorned]

MacoMan, on 28 October 2013 - 09:24 AM, said:

I would like to request a feature for a future eduke build to turn on & off polymer in the console so we don't have to exit & restart, if this is in fact even possible.

It's already there: "setrendermode" will immediately switch the rendering mode. Also, Polymer has various fine-tunables and sub-feature flags, starting with "r_pr_". See the console commands wiki entry for more.

[LeoD]

In addition you can bind it to a key of your choice in settings.cfg:

bind "Kpad3" "setrendermode 3"
bind "Kpad4" "setrendermode 4"

[MacoMan]

LeoD, on 28 October 2013 - 10:54 AM, said:

In addition you can bind it to a key of your choice in settings.cfg:

bind "Kpad3" "setrendermode 3"
bind "Kpad4" "setrendermode 4"

Oh, cool! I never even knew. Thanks, guys.

[MacoMan]

Helixhorned, on 28 October 2013 - 10:48 AM, said:

It's already there: "setrendermode" will immediately switch the rendering mode. Also, Polymer has various fine-tunables and sub-feature flags, starting with "r_pr_". See the console commands wiki entry for more.

Excellent. Just tried it, bound it to some keys on my Xbox 360 controller that I use to play eduke with, and it works fabulously. One thing I did notice when I'm instantly able to change renderers like this is that the FOV increases slightly when I switch to polymere or software mode over polymost, but I'm assuming this is normal. I'm just happy I'm able tp play with true widescreen support on my 16:9 monitor. Thanks again, boys, for your great work on this. Can't wait for the day when polymere is fully optimized with little or no slowdown.

[Mblackwell]

I believe the change in projection prevents a rendering bug at extreme vertical look angles.

[GreatSudoku]

I'm trying to build this in Arch Linux 64 bit and I run into the following error:

In file included from build/include/sdlayer.h:8:0,
                 from build/include/renderlayer.h:5,
                 from source/game.c:26:
build/include/sdl_inc.h:19:18: fatal error: SDL.h: No such file or directory
 # include "SDL.h"
                  ^
compilation terminated.
Failed building source/obj/game.o from source/game.c!
Makefile:437: recipe for target 'source/obj/game.o' failed
make: *** [source/obj/game.o] Error 1

I do have SDL.h installed in several places on my sytem:

$ locate SDL.h
/home/sudoku/Downloads/eduke32svn/eduke32/polymer/eduke32/platform/Wii/include/SDL/
SDL.h
/home/sudoku/Downloads/eduke32svn/eduke32/polymer/eduke32/platform/Windows/include/
SDL2/SDL.h
/usr/i486-mingw32/include/SDL/SDL.h
/usr/include/SDL/SDL.h

but it's not in the polymer/eduke32/build/include/

Is there some file I need to edit or some packages I need to install to get this to compile correctly?

[Helixhorned]

EDuke32 switched to SDL2 recently, it seems you don't have its headers. If there's no easy way to install SDL2 on your distro and you don't feel like compiling it yourself, you can go back to SDL1.2 by passing an appropriate SDL_TARGET to 'make', like this:

$ SDL_TARGET=1 make

or editing build/Makefile.shared, changing

SDL_TARGET ?= 2

to

SDL_TARGET ?= 1

[GreatSudoku]

I installed SDL2 but then ran into the following error:

In file included from build/include/sdl_inc.h:19:0,
                 from build/include/sdlayer.h:8,
                 from build/include/renderlayer.h:5,
                 from source/game.c:26:
build/include/SDL.h:33:23: fatal error: SDL_cdrom.h: No such file or directory
 #include "SDL_cdrom.h"
                       ^
compilation terminated.
Failed building source/obj/game.o from source/game.c!
Makefile:437: recipe for target 'source/obj/game.o' failed
make: *** [source/obj/game.o] Error 1

for now I can build it with SDL, but I'd like to be able to build it with SDL2. Is there a helper library I'm missing perhaps?

[Hendricks266]

It sounds like you have some conflict with SDL.h. SDL_cdrom.h is only in SDL 1.2.

[GreatSudoku]

Hendricks266, on 05 November 2013 - 08:36 PM, said:

It sounds like you have some conflict with SDL.h. SDL_cdrom.h is only in SDL 1.2.

Oh snap! You were dead on. I still had an SDL simlink from when I was tinkering around before I knew to install SDL2. I started over from scratch with svn checkout, and compiling worked like a charm this time. Thank you Hendricks and Helixhorned

BUT then the executable crashed and burned upon launch
Pastebin from the terminal

[NY00123]

GreatSudoku, on 06 November 2013 - 08:01 AM, said:

Oh snap! You were dead on. I still had an SDL simlink from when I was tinkering around before I knew to install SDL2. I started over from scratch with svn checkout, and compiling worked like a charm this time. Thank you Hendricks and Helixhorned

BUT then the executable crashed and burned upon launch
Pastebin from the terminal

*Sigh*

I guess that you can see the GTK2 startup window for a bit before it happen?

Well, anyway, yeah, this is sadly a hard-to-solve known issue, also described here: http://forums.duke4....393#entry175393

As told over there, for now you can avoid this by building EDuke32 with HAVE_GTK2=0 (or targetting SDL 1.2).

[Paul B]

There is no changelog for Oct 14th & Oct 15 synthesis builds located here: http://dukeworld.duk...ke32/synthesis/

This is my daily newspaper. =)

[LeoD]

Paul B, on 15 November 2013 - 07:36 AM, said:

There is no changelog for Oct 14th & Oct 15 synthesis builds located here: http://dukeworld.duk...ke32/synthesis/
This is my daily newspaper. =)

That is because there were no changes on Oct 14/15

Spoiler

Nov 14/15

Quote

Revision: 4155
Author: hendricks266
Date: Freitag, 15. November 2013 08:24:33
Message:
This should fix Synthesis for real. BUILD_LUNATIC.
----
Modified : /polymer/synthesis.sh

Revision: 4154
Author: hendricks266
Date: Freitag, 15. November 2013 06:45:22
Message:
A stab in the dark at fixing the Synthesis problems. BUILD_LUNATIC.
----
Modified : /polymer/synthesis.sh

If it's that interesting for you, get TortoiseSVN and browse the logs comfortably.

[TerminX]

Or use this page to get a nice overview of the last 20 commits.

[Fox]

From actors.c:

        if (dasectnum < 0 ||
                ((actor[spritenum].actorstayput >= 0 && actor[spritenum].actorstayput != dasectnum) ||
                 (spr->picnum == BOSS2 && spr->pal == 0 && sector[dasectnum].lotag != ST_3) ||
                 ((spr->picnum == BOSS1 || spr->picnum == BOSS2) && sector[dasectnum].lotag == ST_1_ABOVE_WATER)
//                 || (sector[dasectnum].lotag == ST_1_ABOVE_WATER && (spr->picnum == LIZMAN || (spr->picnum == LIZTROOP && spr->zvel == 0)))
                )

What's the reason for that line being commented out? That's what is causing the issue with Troopers and Enforcers walking in water sectors.

For reference here is the original:

        if( dasectnum < 0 || ( dasectnum >= 0 &&
            ( ( hittype[spritenum].actorstayput >= 0 && hittype[spritenum].actorstayput != dasectnum ) ||
              ( ( sprite[spritenum].picnum == BOSS2 ) && sprite[spritenum].pal == 0 && sector[dasectnum].lotag != 3 ) ||
              ( ( sprite[spritenum].picnum == BOSS1 || sprite[spritenum].picnum == BOSS2 ) && sector[dasectnum].lotag == 1 ) ||
              ( sector[dasectnum].lotag == 1 && ( sprite[spritenum].picnum == LIZMAN || ( sprite[spritenum].picnum == LIZTROOP && sprite[spritenum].zvel == 0 ) ) )
            ) )
          )

[Hendricks266]

^You can use TortoiseSVN's "Blame" GUI tool to find out for yourself.

In this case, it was r1044.

Quote

---------------------------------------------------------------- --------
r1044 | terminx | 2008-09-01 02:15:16 -0500 (Mon, 01 Sep 2008) | 2 lines

A bunch of random shit

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

[Mark]

If that code is fixed and those enemies avoid water will there be an easy way to disable the fix in con code?

2 of my custom enemies are using the con code for those original enemies and they need to be able to walk through water ( and lava ) sectors.

[Hendricks266]

They will walk through water as long as their picnums are not the same as the default enemies.

[Mark]

Which they are for me. Oh well....

[Fox]

Well, you shouldn't have used hard-coded enemies as the base.

[Mblackwell]

Perhaps that kind of thing should be a flag if anything. It's kind of a weird behavior.

[Jblade]

Mouse buttons 4 and 5 aren't responding in the latest snapshots, but they work fine in a September build I have so I know it's not my mouse playing up.

[Hendricks266]

It's probably related to how SDL2 doesn't treat mouse wheel scrolling as buttons any more. We have code to compensate for that but perhaps there isn't any yet for mouse buttons beyond 3.