[supergoofy]

what about a new 64bit binary?

thanks in advance

[LeoD]

 supergoofy, on 11 October 2013 - 03:30 AM, said:

what about a new 64bit binary?

Follow my signature...
However, I wouldn't recommend latest versions due to the texture cache leak, unless you desperately need the last bit of performance during gameplay.

[Hendricks266]

I'm planning on releasing a 64-bit, C++, SDL2 build but I wanted to fix the aforementioned texcache bug first. I also sent Plagman information about adding a 64-bit compiler to synthesis.

[neoacix]

Uhm... since the netcode is broken and for this, a main feature of the game is not available, should'nt this has the top priority?

I'm realy waiting for it, because EDuke is the only port that supports TROR and stuff like that.
Polymer works quite nice atm, I think.
And ports to other plattforms... well... in my opinion you should concentrate on the PC, since this is a PC game.
Other plattforms ports should come later...

[MusicallyInspired]

TerminX is working on the netcode....right?

[Hendricks266]

 dpax, on 11 October 2013 - 09:18 AM, said:

Uhm... since the netcode is broken and for this, a main feature of the game is not available, should'nt this has the top priority?

I've never worked with the netcode and I don't know what its current state and roadmap are, so I really can't be helpful until I learn much more about it from others.

[neoacix]

 Hendricks266, on 11 October 2013 - 10:15 AM, said:

I've never worked with the netcode and I don't know what its current state and roadmap are, so I really can't be helpful until I learn much more about it from others.

Well then, sorry for my interruption, but I would be glad to here about some progress or roadmap about the netcode.

[Hendricks266]

TerminX and maybe Plagman would be the ones to ask about a roadmap.

You can (generally) view progress on the netcode specifically at the following link, but it's look to watch all SVN revisions as changes may not be in net.c itself. http://svn.eduke32.c...Fnet.c&rev=4079

[NF64]

Hello, I'm adding some lights to a map and have come across a video on youtube showcasing a form of water caustics. http://www.youtube.c...h?v=1D0ckPyMsCc
Could this effect be done using other textures like stained glass? Can someone also point me in direction where I could do this? Wiki and forum search doesn't show any results I'm looking for.

[Mark]

I'm pretty sure that effect was made by using SE50 spotlights to project an animated texture in those rooms. Sorry, I don't remember which SE50 setting you put the tile number you want display.

[Micky C]

Owner in the F8 menu.

[NF64]

Micky C, on 12 October 2013 - 01:12 PM, said:

Owner in the F8 menu.

Thanks, I see it is actually in the se50 page on the wiki lool. I feel dumb now

[Hendricks266]

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

Welcome to 2013.

[Spiker]

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

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

Welcome to 2013.

Great job with fixing the leak. Wow, the name eduke64 looks so cool. Welcome to 2014

[Spiker]

The only problem is that your scripts for the addons don't detect eduke64. What's also strange when there was no eduke32 it also stated there is no duke3d.grp although it was there.

[NY00123]

A few thoughts about the topic:

- 32-bit or not, EDuke32 is still known as EDuke32.
- In fact, thinking about it, the original DOS executables for the game Duke Nukem 3D are 32-bit (using a DOS extender). So I guess the number "32" in the name "EDuke32" may refer to the fact it started as a port of older EDuke code for DOS to Win32 (if not more at the same time).

[Hendricks266]

Spiker, on 13 October 2013 - 12:09 AM, said:

The only problem is that your scripts for the addons don't detect eduke64.

If all goes well with the 64-bit exes, I plan to commit code so that the 32-bit exe will redirect the command line to the 64-bit exe under a Win64 system, and if possible.

NY00123, on 13 October 2013 - 12:18 AM, said:

- 32-bit or not, EDuke32 is still known as EDuke32.

This is intended.

[Hendricks266]

Spiker, on 13 October 2013 - 12:04 AM, said:

Great job with fixing the leak.

That was Helix.

[Helixhorned]

Hendricks266, on 09 October 2013 - 12:06 PM, said:

I have a month-long winter break from the middle of December to the middle of January, and I've been thinking of holding myself to a personal EDuke32 Winter of Code where I polish off four or five long-standing items on my to-do list every seven days. Things like the "if polymost / if polymer" def code (...). Thoughts?

Is this supposed to select one of two alternative model definitions at game time, depending on which renderer is running? Or is it meant to be effective at DEF parsing time?

While the former might have its uses, I think the modifications needed to the hightile/model replacement system will add complexity to what I already find not so easy to see through. Also, merely selecting depending on renderer falls too short of imaginable use cases IMO.

What I suggest instead is basically implementing a subset of the C preprocessor in the scriptfile.c layer. The preprocessor would run before the scriptfile is used for its specialized purpose, maybe in scriptfile_preparse(), and allow to include or exclude portions of the main text conditional on provided #definitions. Thus, you'd be able to specify alternatives at any level of granularity. From the command line, there would be an option -D to pass user-provided defines. Implementing it in scriptfile.c means that all of its users like DEF or maphack can benefit from the functionality.

Sounds good?

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