[Hendricks266]

The purpose of the def code is so that one set of defs will be able to provide different assets to the two OpenGL renderers. I am fine with your implementation as long as it is ok that defs are reprocessed whenever the renderer switches.

[Helixhorned]

Hendricks266, on 13 October 2013 - 10:03 AM, said:

I am fine with your implementation as long as it is ok that defs are reprocessed whenever the renderer switches.

Hm, it's that particular point that I think is hardest to get right. To me, highres assests seem like they are to stay forever after being loaded. Off the top of my head, there are functions to remove e.g. loaded models, but the whole management will be finicky then, I think.

Then again I may be misjudging the situation. When I suggested the preprocessor, I was a bit behind the current HRP developments: I see that it's now got a duke3d_hrp_polymost.def file there, so selection up-front can be had with -h<desired.def>. This pretty much includes all that I wished for myself (selecting one of two DEF sets, or none), but I can imagine how some conditional parsing might make HRP maintenance a bit easier.

[Hendricks266]

The main issue is that we don't want to require people to run -hAnything or -Danything because command line arguments are an unnecessary burden, especially on noobs, and it is also convenient to have one def set work for both renderers without having to close and reload the game.

[Plagman]

Just take the Microsoft approach and make switching renderers require a game restart.

[Micky C]

That seems a little extreme, if nothing else, it's useful for mappers to change renderer mid-game for testing purposes. Besides, apparently there would be no point for such a restriction of the HRP isn't being used?

[NightFright]

Hendricks266, on 12 October 2013 - 10:32 PM, said:

Synthesis now builds with SDL2 and includes 64-bit exes. [...]

At long last! I'm gonna test the shine outta that binary. Thanks a lot for this, it was really overdue! ^^

PS: News was important enough to mention it on the HRP website.

[Hendricks266]

Quote

Polymer users are especially encouraged and recommended to use them due to better memory management.

Polymer runs faster under 64-bit because it is CPU-bound and x86_64 has a higher number of registers compared to x86. It has little to do with having twice 32 times the address space for memory management.

[NightFright]

Well, I know little about technical aspects. xD I will correct it once I am able to access the website FTP again. It has decided to be bitchy on me today (again) for some weird reason. x.x

[neoacix]

WOW!!! That 64bit Build just blew me away!!!

Tested with polymer + HRP + Dukeplus on my WIP openworld map... and ... freaking hell!
It runs so much faster!
Up to 80 % more performance compared to the 32 bit build!
Not joking here!

Even if FPS drops under 25, everything runs fine and quite smooth.
This is realy an amazing step forward to me!
GREAT WORK!

And now... I just got to ask... would it be possible to increase the wall limit in the 64 bit build?
Because I'm starting to cut out details on my map to prevent hitting this limit before the map is finished.

And @Hendricks266, a late thanks for the link to the svn.

[MacoMan]

Hey guys. Just wanted to thank you all for your hard work on this WIP. The polermer renderer looks fabulous, and while I'm aware that it's as yet rather unoptimized and runs rather clunky on even my i5, Nividia GTX 660 TI-based system (sometimes with frame rates dipping below even 20-25 FPS) I was wondering if there are any tweaks that will make it run smoother without sacrificing too much visual quality. A guide of some sort maybe? In the meantime, I'm kind of relying on the HRP 5.3 with the old polymost renderer but discovered that it has it's own quirks, noticeable in the HUD/weapons display, which are nevertheless more tolerable to me than slow framerates. In fact, I posted about it in the HRP bugs report section but didn't get any replies .

[LeoD]

Helixhorned, on 13 October 2013 - 11:11 AM, said:

Hm, it's that particular point that I think is hardest to get right. To me, highres assests seem like they are to stay forever after being loaded. Off the top of my head, there are functions to remove e.g. loaded models, but the whole management will be finicky then, I think.

Then again I may be misjudging the situation. When I suggested the preprocessor, I was a bit behind the current HRP developments: I see that it's now got a duke3d_hrp_polymost.def file there, so selection up-front can be had with -h<desired.def>. This pretty much includes all that I wished for myself (selecting one of two DEF sets, or none), but I can imagine how some conditional parsing might make HRP maintenance a bit easier.

Switching HRP contents after loading seems pretty much over the top.
Maintenance-wise I'd prefer keeping two different DEF trees and let, for example, duke3d_hrp.def branch conditionally to either duke3d_hrp_polymost.def or (yet to be added) duke3d_hrp_polymer.def.
Parsing the HRP DEFs takes quite a while already. Merging too much stuff into them might take even longer then.

[NightFright]

I checked out the 64bit build and I have to say it kicks ass. While having a pretty good rig, I was always suffering from micro lags when switching weapons, blowing up stuff etc (at least when doing it for the first time, i.e. when textures got loaded into memory). Also level loading took pretty long. These problems belong to the past now.

What I have noticed, but I dunno if it's just me or not (r4103): "Esc" key doesn't work any more in the beginning to skip the intro movie/screens - it used to do that before. Also, my existing key bindings didn't fully work any more. I am using keypad numkeys, and it seems with the new build these have different names so you have to remap several of them.

Other than that, if you use Polymer AND HRP, 64bit is definitely making a difference (I didn't see considerable improvements before since I wasn't loading HRP at the same time). Nothing less than a milestone, as far as I am concerned!

[neoacix]

Yeah, a milestone definitely!
I'll only use 64 bit from now on!
Btw, I don't experience any issue with the build from LeoD, which is r4096 ... on my windows machine.

Duke: "I'm not on optimization! Bruteforce bandwidth baby!"

Teaching the game to run the hard way.... haha! xD

[LeoD]

NightFright, on 14 October 2013 - 12:01 PM, said:

What I have noticed, but I dunno if it's just me or not (r4103): "Esc" key doesn't work any more in the beginning to skip the intro movie/screens - it used to do that before. Also, my existing key bindings didn't fully work any more. I am using keypad numkeys, and it seems with the new build these have different names so you have to remap several of them.

At least SDL2 finally gets some keys right now on non-QWERTY keyboards it seems. Check DNKROY -> DNKROZ

[neoacix]

Actually there is another issue I found on the 64 bit version...
...and this is realy weird.

Why is the picture of the guy when starting up the engine looks so ... well desperate Max Payne 3 like?
This realy has to be changed!!!!
(I hope you guys have some humor left)

[Hendricks266]

By the way guys, the eduke64.exe name is temporary. The way it's looking now, 64-bit builds will be split into a separate download that keeps the "eduke32.exe" name.

NightFright, on 14 October 2013 - 12:01 PM, said:

What I have noticed, but I dunno if it's just me or not (r4103): "Esc" key doesn't work any more in the beginning to skip the intro movie/screens - it used to do that before. Also, my existing key bindings didn't fully work any more. I am using keypad numkeys, and it seems with the new build these have different names so you have to remap several of them.

This is due to the change from DirectDraw and DirectInput to SDL2 on Windows. I'll look into the "Esc" thing but I can't promise anything on the numpad keys.

[neoacix]

Sorry... I just have to admit this...

When Duke64 loads up...

...somthing like this should be in that window:



At least, this is how I'm feeling about it.... ^^

[neoacix]

sorry.... double post

[MacoMan]

Where can I find this new 64-bit version of eDuke that speeds up polymer by 80% (!)? I want it, I need it! *salivates*

[neoacix]

You want it real fast?
Grab LeoDs link here: http://www.mediafire...096-20131012.7z

Check out more great stuff from LeoD here: http://forums.duke4....-more-greyduke/

[Hendricks266]

Is anyone else getting these issues with the SDL2 builds?

• The Pause key does not work
  
• The startup window freezes if you get a CON error
  
• Pressing keystrokes in Mapster like Alt+P causes the system to "ding"

[MacoMan]

MacoMan, on 14 October 2013 - 06:01 PM, said:

Where can I find this new 64-bit version of eDuke that speeds up polymer by 80% (!)? I want it, I need it! *salivates*

Thanks for the link. TBH, it doesn't feel significantly faster than other recent builds I've used. But then again, I was using DukePlus, and with both the HDP & polymer enabled, all that gibbing can bring even the most powerful systems to a momentary crawl, I imagine. On "vanilla" Duke it seems a bit faster.

[necroslut]

Hendricks266, on 14 October 2013 - 08:06 PM, said:

Is anyone else getting these issues with the SDL2 builds?

• The Pause key does not work
  
• The startup window freezes if you get a CON error
  
• Pressing keystrokes in Mapster like Alt+P causes the system to "ding"

I'm getting the ding thing, but worse than that RAlt doesn't work anymore and neither does combinations like '+S, '+H, '+T...

[NightFright]

Hendricks266, on 14 October 2013 - 02:29 PM, said:

[...] I'll look into the "Esc" thing but I can't promise anything on the numpad keys.

Actually, I am fine with the change for the numpad keys. For the first time, they have their proper names in the settings menu. It's just that if you used a previous build which didn't have it, EDuke32 wouldn't recognize the keys, requiring you to configure it again even though it's still the same key. It is just a one-time effort though, nothing I cannot live with. I won't go back to any previous builds, anyway.

[Helixhorned]

Hendricks266, on 14 October 2013 - 08:06 PM, said:

Is anyone else getting these issues with the SDL2 builds?

• The Pause key does not work

Yup.

Quote

• Pressing keystrokes in Mapster like Alt+P causes the system to "ding"

Not here, seems to be Windows-specific.

necroslut, on 15 October 2013 - 07:27 AM, said:

I'm getting the ding thing, but worse than that RAlt doesn't work anymore and neither does combinations like '+S, '+H, '+T...

It looks as if the SDL2 build recognizes the keys dependent on the OS keyboard layout setting. Thus, if you have e.g. German selected, you'll get a 'z' when pressing the key left of 'x', but the positions of the special keys will be messed up (and non-functional for the editor; e.g. in the German layout, a single quote is Shift+[what is '\' on a US keyboard]). Personally, I prefer the old way where it's pretended as if the keyboard were US regardless of the selected layout.

[LeoD]

As of r4100, make SDL_TARGET=1 is broken.

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:15:23: fatal error: SDL/SDL.h: No such file or directory
 #  include <SDL/SDL.h>
                       ^
compilation terminated.
Failed building source/obj_win/game.o from source/game.c!
make: *** [source/obj_win/game.o] Error 1

dpax, on 14 October 2013 - 12:13 PM, said:

Btw, I don't experience any issue with the build from LeoD, which is r4096 ... on my windows machine.

The switch to SDL2 was in r4100.

dpax, on 14 October 2013 - 01:48 PM, said:

Why is the picture of the guy when starting up the engine looks so ... well desperate Max Payne 3 like?

I changed the image to make it obvious that you're not running an 'official' synthesis build.

[NightFright]

Something very minor and purely cosmetic, but anyway...

Icon doesn't show up properly in the taskbar with r4103 x64, at least for me (Win7 SP1 x64).

[Hendricks266]

LeoD, on 15 October 2013 - 10:22 AM, said:

As of r4100, make SDL_TARGET=1 is broken.

Do you have SDL/SDL.h in your compiler setup?

[necroslut]

Helixhorned, on 15 October 2013 - 08:40 AM, said:

It looks as if the SDL2 build recognizes the keys dependent on the OS keyboard layout setting. Thus, if you have e.g. German selected, you'll get a 'z' when pressing the key left of 'x', but the positions of the special keys will be messed up (and non-functional for the editor; e.g. in the German layout, a single quote is Shift+[what is '\' on a US keyboard]). Personally, I prefer the old way where it's pretended as if the keyboard were US regardless of the selected layout.

Yeah, it used to be Ä as ', but the '/* key doesn't work either and I've tried every possible combination I could think of. And I'd guess Ralt would be the same anyway? Can you even change the mapster keys, or do I have to change keyboard layout every time I want to run mapster?

[Stabs]

Yeah I am having key problems with mapster '+x for lighting preview does not work, same with changing vis.