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

[blizzart]

I haven´t downloaded a synthesis build recently, so I want to ask, which of all these packages I have to download if I want to use the 64bit Eduke and Mapster? And where do I find the sample files?

Sorry, but it´s a little bit confusing to me...

[MusicallyInspired]

The synthesis builds now have 64-bit binaries as well as 32-bit. All the latest builds should have them listed along with the regular 32-bit.

[blizzart]

MusicallyInspired, on 08 December 2013 - 02:43 PM, said:

The synthesis builds now have 64-bit binaries as well as 32-bit. All the latest builds should have them listed along with the regular 32-bit.

Thanks for your reply,
so the EDuke32.exe files are for both 32- and 64-bit?

[Hendricks266]

eduke32_{arch}_{debug}
eduke32-sdk_{arch}_{debug}

"eduke32" contains EDuke32; "eduke32-sdk" contains Mapster32 and the samples folder.

{arch} will be "win32" for 32-bit and "win64" for 64-bit. Currently, classic performs better under 32-bit and Polymer performs better under 64-bit.

"debug" will be present in debug builds, and absent in release builds. Debug builds run slower and take up more space than a release build, but they contain extra information that can help us fix crashes if you encounter them and report them properly.

While you mention it, I need to make each synthesis build folder sort by name, not by date.

While you mention it, I need to redesign all of Dukeworld.

[Helixhorned]

necroslut, on 18 October 2013 - 04:12 AM, said:

Edit: I tried it on another computer and it's the same, Ralt does nothing. Changing the keyboard layout didn't help either.

Is this still an issue? It works for me on Windows 7, with both 32 and 64-bit builds, so maybe it's specific to the Windows version?

In the meantime, you could try mapping a different key to the RAlt functionality by adding to the "remap" option of mapster32.cfg. For example:

; make backslash function as RAlt
remap = 2B-B8