EDuke32 2.0 and Polymer! "talk about the wonders of EDuke32 and the new renderer"
#5792 Posted 11 December 2017 - 03:43 AM
i have updated my installation to the latest synthesis build and noticed some changes in the polymer renderer regarding shadows and shading in general. I really like the new features, but is this still work in progress? In many areas of the levels the shadows fit perfectly, but in lot of cases it's too dark (my personal opinion). And it does help using the night vision goggles, cause the shader seems somehow to overlay it.
#5793 Posted 02 January 2018 - 02:14 AM
I just downloaded the latest eduke build, I noticed for some reason the vacation.grp wasn't listed on the startup thing along with duke3d.grp etc. Is it supposed to be this way?
#5794 Posted 04 January 2018 - 10:50 AM
darkprince227, on 02 January 2018 - 02:14 AM, said:
I just downloaded the latest eduke build, I noticed for some reason the vacation.grp wasn't listed on the startup thing along with duke3d.grp etc. Is it supposed to be this way?
That doesn't sound like a Polymer/rendering bug so this probably isn't the right thread to discuss that. But I downloaded the latest Synthesis build as well from 12/29 and I can't replicate the behavior. Everything looks good on my end.
#5795 Posted 04 January 2018 - 12:45 PM
enderandrew, on 04 January 2018 - 10:50 AM, said:
You're right, it wasn't an eduke problem the vacation.grp I was using seemed to be broken, so I made a fresh one and bada-bing. We're in progress
#5796 Posted 04 January 2018 - 02:25 PM
link to snapshot they stopped working properly:
http://dukeworld.duk.../20170623-6248/
link to last snapshot they did work in:
http://dukeworld.duk.../20170622-6242/
#5797 Posted 27 January 2018 - 08:40 PM
darkprince227, on 04 January 2018 - 12:45 PM, said:
You shouldn't need to make a vacation.grp yourself. EDuke32 will accept VACA15.SSI as taken directly from the original CD release, as well as VACATION.GRP as found in Megaton and the Anthology / Kill-A-Ton 2015 entry on Steam.
Jblade, on 04 January 2018 - 02:25 PM, said:
Fixed in r6605.
#5798 Posted 29 January 2018 - 01:29 AM
Is there an ability to rename main menu commands yet btw? Specifically, I'm looking to replace the Help menu with something like 'Go to HQ' which'll load one of the AMC base maps up. I'm pretty sure I can already do the loading base thing, it's just the string name I need to change. I'm seeing all sorts of interesting stuff in the synthesis (including the ability to flat out remove it and credits* from the menu) but I'm not sure if what I'm asking is possible yet.
EDIT: Also, I'm not sure this is actually a bug but ambient sounds with a hitag over 32767 don't play anymore; was it always the case that sounds shouldn't of worked over that hitag value, or is it indeed a bug? I'll look into tracking down the snapshot if you think it's not intended behaviour.
This post has been edited by Jblade: 29 January 2018 - 01:32 AM
#5799 Posted 29 January 2018 - 03:33 AM
Jblade, on 29 January 2018 - 01:29 AM, said:
No, and this is not on my roadmap.
Jblade, on 29 January 2018 - 01:29 AM, said:
It has to be r6581. It may indeed be the case that those sounds did not work in the original game. However if there are no side effects I would be willing to re-allow them.
#5800 Posted 29 January 2018 - 04:25 AM
Quote
They worked fine and I didn't see any side effects but that's not to say there might not of been some issues around regardless. I can add some con code that will automatically set the volume back down to the max if it's higher, it's no big deal.
#5801 Posted 04 February 2018 - 10:45 AM
#5802 Posted 10 February 2018 - 09:08 PM
Jblade, on 29 January 2018 - 04:25 AM, said:
They should be fixed now. Please let me know if you find any other behaviors broken when hitags and lotags are > 32767 (aka < 0).
Jblade, on 04 February 2018 - 10:45 AM, said:
The autosaves only "fork" a new file when 1) you use the Save Game menu or F2 (as opposed to F6 quicksaving) to make a new manual save and then the `save` or `savenn` CON commands run, or 2) the `save` or `savenn` CON commands run with a different index than when you previously ran it.
I would recommend fixing your ID numbers.
#5803 Posted 11 February 2018 - 10:55 AM
#5804 Posted 11 February 2018 - 12:17 PM
#5805 Posted 14 February 2018 - 12:53 AM
There's the regular one which shows ammo count as a number, and then one notch "above" that there is the special EDuke32 one which show an ammo icon on the right side, etc., and it is still considered size 4 (there is also size 0 with no HUD at all).
My questions is, is it possible in CON to detect which of those two size 4 HUDs is being used? So far I have not found a way. In case it wasn't obvious, I want my display code to do different things depending on the HUD.
#5807 Posted 14 February 2018 - 11:01 AM
Hendricks266, on 14 February 2018 - 10:58 AM, said:
Ah. I saw that struct and I thought it meant that it would be set when the user has the alt hud as one of the huds that gets cycled through, I didn't realize it was only set when the hud was actually being displayed.
EDIT: If you look at the wiki entry, it clearly says that setting it to 0 disables that hud. Anyway I will go test this now.
This post has been edited by Trooper Dan: 14 February 2018 - 11:05 AM
#5808 Posted 15 February 2018 - 09:10 AM
#5809 Posted 15 February 2018 - 12:39 PM
Fox, on 15 February 2018 - 09:10 AM, said:
That makes sense. I updated it just now.
#5810 Posted 27 February 2018 - 01:57 AM
#5811 Posted 06 March 2018 - 01:48 PM
(I am playing the WT content with the stopgap thing)
#5812 Posted 23 March 2018 - 01:03 PM
I´m having some audiovisual issues with latest Eduke32 builds, which I hope someone can address.
I have been using Eduke32 4102 (from 2017) for eduke32 and a 2013 mapster32 build which already supports usetileshades, until Trooper Dan jumped onboard, who suggested to keep builds up to date, mostly for coding reasons.
Now I´m using 6788 and I´m having the following problems:
Sound doesn´t work, only music. Tried deleting eduke32.cfg and tinkering with sound values. I have a Realtek onboard audio, on a gigabyte mobo.
Visibility has changed drastically and console commands like r_usetileshades, r_shadescale, r_usenewshading don´t do anything when entered on the console.
This is how it looks like on mapster32 from 2013 (right after the usetileshades thingie was added):
This is how it looks on the 4102 build from 2017 (notice how dark things are at the distance):
And this is how it looks now on 6788, almost like before but now with a parallax glitch (notice the vertical strips of misalligned sky above the buildings on the distance)
This is what both autoexec.cfg and m32_autoexec.cfg read, at least the r_usetileshades command seems to work on the autoexec for Eduke32:
r_shadescale 0.65
r_usenewshading 2
r_novoxmips 1
r_usetileshades 2
Hope anything can be done about it.
This post has been edited by Gambini: 23 March 2018 - 01:04 PM
#5813 Posted 23 March 2018 - 01:28 PM
Ideally you should not touch r_usenewshading, r_usetileshades, r_shadescale from your autoexec. The defaults we ship with are designed for an experience as accurate to Classic as possible. The only reason the toggles even exist is for compatibility with things released in the past. For something still in development, fix your maps. Let us know if Polymost differs from Classic.
I have an idea of what the parallax issue is. I believe it is related to a change Fox made. As a test, I think you can disable r_parallaxskypanning (or something named similarly). However, do not add that to any autoexec files.
#5814 Posted 23 March 2018 - 01:43 PM
Are you saying I should not use custom values for a mod with custom content? I have these maps in the making from long ago and those are vaules I found fit for them after a lot of work. Not to mention the other mapper working on it has a notch less of a technical understanding of this kind of things, which means reversing 4/5 years of work would be suicidal for our project. It´s never been said before those parameters would eventually end in arbitrary fixed values. Please consider exceptions for experienced users.
This post has been edited by Gambini: 23 March 2018 - 01:43 PM
#5815 Posted 23 March 2018 - 02:46 PM
#5816 Posted 23 March 2018 - 03:17 PM
Hendricks266, on 23 March 2018 - 02:46 PM, said:
Sure, if it's a simple linear change, like changing all shade or visibility values by certain numbers. But if it's more complicated than that, then it will prove problematic.
I'm interested to hear what Gambini will say about the classic shading rule. To my knowledge, he has always cared about how maps looked in classic and I find it hard to believe that he had not paid attention to that when designing those maps.
#5817 Posted 24 March 2018 - 07:58 AM
There is sadly no such thing as a magic mapster32 script which may adjust all parameters involved on restoring what i have achieved after a lot of fine tuning. i doubt anyone would tinker with them unless they have at least a rough idea of what they are doing. So I don´t see no reason for them being locked.
Quote
There´s no lesson here because at the time i built the largest part of those maps, those parameters were of free use. Also, when you design a map for polymost, you can´t map on classic because many things dont work like models, skyboxes, etc.
Can you confirm r_usenewshading, r_usetileshades and r_shadescale commands are locked on the console? Is there a way I can ship a mod which overrides the default values?
#5818 Posted 24 March 2018 - 08:16 AM
#5819 Posted 24 March 2018 - 08:50 AM
Gambini, on 24 March 2018 - 07:58 AM, said:
There is sadly no such thing as a magic mapster32 script which may adjust all parameters involved on restoring what i have achieved after a lot of fine tuning.
Your fine tuning would stay largely intact. The idea is that we figure out a formula that when applied to the current maps, makes the shading and visibility on them look correct in the current Polymost build. The changes between builds surely weren't random, there must have been some rules that were followed governing the changes; therefore it seems reasonable to assume that a script which globally changes shade and visibility settings according to a reverse-engineered formula could at least closely approximate what is needed to make the maps look correct. If you were to, say, fix a small area in one map, and you noticed a pattern in the changes you were making, I could probably make a script that applied that pattern of changes globally. At that point we test it out -- probably it will be wrong in certain ways for other map areas. Then we make some adjustments and try an improved formula. The whole process would probably take a few hours before it was correct, but it would still be a fraction of the time needed to redo all the maps.
Forge, on 24 March 2018 - 08:16 AM, said:
Very unlikely. Ion Maiden evidently uses a somewhat different build where various things work differently (e.g. you have to hold shift and ~ to open the console), so if there was anything they wanted to lock up, it would make sense to do so only on the IM branch.