[z0mb1e]

where is everyone getting a polymer build? can someone send me one?

[Danukem]

Polymer does not support the view distortion that occurs in the other renderers when the player changes y size (from shrinking or growing). I hope it is added, because that effect is useful.

[itsmydamnation]

hi i have been reading though this thread i have something to suggest, maybe you already planned something along these lines or maybe it can already be done, i dont know because i haven't really looked into yet it.

I was reading that there is currently a maximum of 5 light sources that can be cast on a surface and this in the future would likely be tied to a configurable setting under renderrer settings in the future. well if you do that i would also think it would be useful to be able to conditionally use light sources based on this value set.

so for example set you define 3 settings low, medium, high. low has 3 lights per surface , medium has 6 lights per surface and high has 10 lights per surface.

now imagine a room that has a bunch of lights(not light sources) in it,

for low you might just want to define one strong light source in the room to light the entire room. where as on medium you might have 3 or 4 weaker light sources and high even more. it would also make sense to be able to define a light source that can be used for multipule settings where there are cases where there would be the same lighting requirement regardless of the configurable setting set.

This gives people who put in the time and effort to make very detailed lighting setups but not remove an entire chuck of users whos machines cant handle it.




ps: is there anywhere that documents the features of the eduke32 /polymer engine/renderrer particularlly around textureing filtering/mapping etc and the ligthing side of things, im keen to do some research into these different aspects and contribute something to a project thats doing some kick arse work!

Cheers

[Hendricks266]

That's a really good idea.

[TerminX]

There's already a cvar that controls how many lights can be cast on a plane at once, and there's already a light priority system in place as well as another cvar which controls which priority levels of lights to render. Eventually they will be exposed in new menus. What more is needed?

So yeah, this is one of those things we've already thought of/already implemented.

[The Commander]

R_PR_MAXLIGHTPASSES

Equals five by default. Increase the value if you want more lights as such.

[Fox]

Hmm, back to the hard-coded sprite lightning question.

I just don't feel right to it not been through DEFs... May I ask if it was implemented that way because:

1) That's the better way found;
2) Couldn't figure which commands and how it would be defined through DEFs;
3) Beyond current coders ability or not worth time and effort;

[High Treason]

I just had a small idea, and it wouldn't only be a good thing in the Polymer version.
A lot of people (me included) don't realise you need OpenAL for the High Res music at first. Perhaps a link could be added to EDuke32 startup screen, perhaps it will only show up if OpenAL is not installed, it could have text like "OpenAL not installed, High Res music will not work, Click Here to get OpenAL" or something.

Just a thought.

[lycanox]

Doesn't it already do that in the log?

[High Treason]

lycanox, on Aug 21 2009, 04:11 PM, said:

Doesn't it already do that in the log?

Yes, but not everybody reads that or even knows it is there.
It's probably in the ReadMe somewhere as well, but i expect that few people read that either.

[TerminX]

OpenAL isn't required anymore in EDuke32 2.0. That hack has been removed for good.

[Jimmy]

Hurray!

[High Treason]

Nice one! now we don't have to worry about OpenAL any more

That would explain why the Vorbis music was working on my server when i was sure there was no OpenAL on there - I just assumed i must have installed it ages ago and forgotten.

[Fox]

This is something I think is up for a non-8bit renderer.

Just that screen tints affects the entire screen, including status bar and menus.



Although it was removed from console port, since they don't use a palette limit



I suppose this is something that should be there, no?

1) Anything draw with rotatesprite should not be affected with it, excluding weapons (EVENT_DRAWWEAPON or EVENT_DISPLAYWEAPON).
2) Or if it was hard-coded so that the default stats bar won't be affected, and there was a orientation flag that would get rid of screen tinting.

[Danukem]

I don't think it makes sense to have the status bars and menus get smeared with color because they are not part of the game world. It's also annoying, because you can't read the text (depending on the intensity of the color). That's especially bad if you can't read the menu and you want to save, change settings etc

[Fox]

Phew, it's obviously like that just because the palette is limited. Not just damage tint, but underwater and nightvision also affect the screen color.

[Danukem]

Ilovefoxes, on Aug 25 2009, 11:03 AM, said:

Phew, it's obviously like that just because the palette is limited. Not just damage tint, but underwater and nightvision also affect the screen color.

I guess I misunderstood. Are you talking about having something like setgamepalette that would work on hi-res art/models?

[TerminX]

Well, damage tint in GL modes is handled by drawing a translucent colored surface on top of the whole screen IIRC, so making certain rotatesprite calls affected by it but not others isn't really something that's going to be happening any time soon.

[Fox]

DeeperThought, on Aug 25 2009, 03:08 PM, said:

I guess I misunderstood. Are you talking about having something like setgamepalette that would work on hi-res art/models?

Nooo, I am just saying that the tints affect the status bar in 8-bit mode because there is a palette limit.

TX, on Aug 25 2009, 04:41 PM, said:

Well, damage tint in GL modes is handled by drawing a translucent colored surface on top of the whole screen IIRC, so making certain rotatesprite calls affected by it but not others isn't really something that's going to be happening any time soon.

Hmm can't the surface be draw after weapons but before the status bar?

[Sobek]

I was just curious if anyone would care to speculate when/if we might see Normal Map support for models? It's not critical (at least not for me) to have it implemented, but I'd love to see it in action. With some fine tuning, it could be a great way to cut back on the polycount on some models, while still retaining nice detail levels.

[Chip]

I was just curious if anyone would care to speculate when/if we might see a public release soon? I don't really care about all those bonus features like light maps, I just would like to actualy own a copy of this and actually see lighting in Duke3D to see how my models get shaded.

Are we close to a release or will it be next year some time? How well are things going with it - are there massive problems or are things going well? Will it be released as soon as ....what ever is not making it released or will it only be released once it contains all the stuff people could ever want from a Duke port?

[Devon]

id like to know exactly that too. all of it actually..

[TerminX]

There will probably be a build with Polymer enabled released as-is sometime soon. Plagman has been swamped with real work lately so Polymer development has been at a standstill for a while now... I think he's also supposed to be moving from France back to the US this month so the problem with free time is likely to get worse before it gets better.

[Fox]

TX, is it possible to you add that Eduke HUD as a completely new HUD, instead of replacing the original small HUD?

It is quite troublesome when it comes to add your own HUDs for your mod.

.screen_size values are incremented by 4, so you could add the new HUD as a value of 2. Sounds good for me.

[Jblade]

Ilovefoxes, on Sep 2 2009, 06:42 PM, said:

TX, is it possible to you add that Eduke HUD as a completely new HUD, instead of replacing the original small HUD?

It is quite troublesome when it comes to add your own HUDs for your mod.

.screen_size values are incremented by 4, so you could add the new HUD as a value of 2. Sounds good for me.

I'm not sure what you mean by this, since it already is a new HUD that's activated/deactivated in the game options menu. You can access it in CONS with the userdef 'althud' (0 means it's off, 1 mean it's on IIRC)

[TerminX]

There's already a menu option to toggle between the new/old HUD.

[Fox]

Yes, but I mean just using + and -

[Tea Monster]

Hey, I was thinking of building a part of a level out of an MD3 model (UTIII style!) and I was considering that putting in all the blocking sprites to make parts of it block the player's progress would take the better part of a million years.

Would there be any chance at all that someone could put an auto-blocking feature for imported MD3 meshes into EDuke32? So that if a blocking tag was activated on the sprite and you had put a model in there, the player would not be able to cross into the space of the model. But it wouldn't work on the sprite, but on the actual mesh of the MD3.

You could, for example, build a shattered office building, HL2 style in Blender or Max and have it be part of the level as the player would be able to stand on the floors and pass through the doors of the MD3 model that you had made of the building

[Fox]

One request: I noticed some commands return an error log if used in a state. This happens at least with settspr and getticks while I am using state in the correct event. Can it be disabled error logging in states?

[TerminX]

Anyone have any super huge major game crippling bugs in the current svn that absolutely need to be addressed before releasing a build with Polymer?