[LeoD]

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

actually implementing the user maphacks tokens

Yessss! I was already thinking about tackling that myself, but I guess you'd be done with it before I even figure out where to begin in the sources.

"if polymost / if polymer" doesn't seem important right now, because maintenance wise I'd prefer the parallel Polymer/Polymost DEF hierarchy.

Btw, I'd like to see radio buttons in the startup window to choose the renderer from "Classic", "OpenGL Polymost" and "OpenGLPolymer". Currently it's confusing that ingame you can only choose between "OpenGL" and "Software", and Polymer isn't mentioned.

I don't know how you plan to implement conditional DEF parsing, but something like:

if exist "dukedc_hrp.def" then ...

or

includeifexist "dukedc_hrp.def"

might come in handy.

[Hendricks266]

LeoD, on 10 October 2013 - 12:13 PM, said:

"if polymost / if polymer" doesn't seem important right now, because maintenance wise I'd prefer the parallel Polymer/Polymost DEF hierarchy.

Maintenance pales in comparison to easing burdens on end-users. The goal is for users to be able to download only one package that uses the respective content for both renderers.

LeoD, on 10 October 2013 - 12:13 PM, said:

I don't know how you plan to implement conditional DEF parsing, but something like:

if exist "dukedc_hrp.def" then ...

or

includeifexist "dukedc_hrp.def"

might come in handy.

I have no plans for anything like this. It has never been discussed.

[Jimmy]

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, actually implementing the user maphacks tokens, and making the Wii port use more Wii-like pointer controls. Thoughts?

I would say the Wii port should be the last of your priorities. Probably 1% of EDuke32 users use the Wii port.

[Lunick]

I'm in the 1% \o/

[Hendricks266]

Said code would also be important for the upcoming Android port. It would be toggleable by a cvar that is merely set by default on the Wii so you could use a lightgun on your PC if you wanted, or use your mouse like a point-and-click game while you move with a flightstick, or something.

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