[Jblade]

I've got 2 requests about skies; the first is that is it possible to prevent large textures from being squashed, so we could use a say 512 width image similar to how Shadow Warrior does it and it'll wrap all the way around? The second is the re-implementation of the bug that lets us use our own tiled textures for skies by placing the LA-sky texture somewhere else in the level (I'd ask for some kind of def feature so we can define our own tiles in a sequence but I imagine that would be alot of work for an 8bit feature)

[Jblade]

Got another query - I remember a while ago we were discussing the fact that useractors seem to interpolate less than the regular Duke actors (or whatever the terminology) something like once every 4 tics instead of once every tick? Was there something added to let them interpolate at the regular rate?

[ReaperMan]

Skulldog, on 17 July 2013 - 03:36 PM, said:

Check the shadow out.

Better then having a big ass RPG shadow when you have a pistol.

Personally, i think Duke just needs the multigun.

[Fox]

James, on 03 August 2013 - 01:04 AM, said:

Got another query - I remember a while ago we were discussing the fact that useractors seem to interpolate less than the regular Duke actors (or whatever the terminology) something like once every 4 tics instead of once every tick? Was there something added to let them interpolate at the regular rate?

Yes, mostly because the interpolation was not the same for all skills.

[TerminX]

James, on 03 August 2013 - 01:04 AM, said:

Got another query - I remember a while ago we were discussing the fact that useractors seem to interpolate less than the regular Duke actors (or whatever the terminology) something like once every 4 tics instead of once every tick? Was there something added to let them interpolate at the regular rate?

Yeah, it was fixed. At one point I actually had them moving so smoothly that it looked outright weird. Compare it between builds older than that discussion and builds that are newer and you should see a pretty significant difference.

[Mblackwell]

Did it look like televisions that have Smooth Motion/TruMotion/Auto Motion/etc enabled where your brain sees the movement as too smooth to be real?

[Fox]

Not sure if that's the case. The thing is that when you walk, you make a stop every step. So a monster that moves every tic looks like it is sliding.

[TerminX]

It was sort of a combination of what both of you mentioned, with the additional weirdness of having seen the original movement millions of times. I actually wasn't going to mess with it at all until someone brought up that it was skill settimg dependent and a regression between 1.3D and 1.4 which made me view it as a bug.

[Mia Max]

Hallo!

Where can I find all console commands for the polymer renderer?
I took a look at eduke32 wiki console commands and it seems there are missing some.

[TerminX]

Go into the console and type "listsymbols" and look for the ones that start with r_pr_ in the output. I should really alter the listsymbols command to take an argument specifying a prefix for the symbols to list...

[Mia Max]

Thank you TerminX

[TerminX]

Went ahead and added that. I'll commit it later.

[TerminX]

Added this too... seemed like a good idea. Now .ogg music can be louder than sound effects if you want. I'll commit it later.

[MusicallyInspired]

Nice!

[DavoX]

Hell yeah TerminX, You're the man!

[The Commander]

I haven't been keeping up with eduke development in months, has there been any major improvements in the net code?

[TerminX]

No, though I did work on it for a few minutes earlier today...

[The Commander]

One line of code a day keeps the moders at bay.

[Mia Max]

Hallo!

In polymer mode, the player himself causes a dynamic light, like he is holding a torch.
It looks good, but in many cases or in some maps (especially in mine), it looks like that there would be no shadows around the player.
Is there an option to turn it off, or can it be turned off by con coding (like Trooper Dan added an option to turn of weapon flashing)?
I couldn't find any command line for doing that on eduke wiki

[TerminX]

No, that's something in whatever mod you're using. The player does not spawn a dynamic light in EDuke32 unless a weapon is being fired or the shrinker or expander is equipped.

[Mia Max]

Damn it, you are right

I'm always using Dukeplus. Hmm, maybe there's already an option for that.

[Micky C]

Just wondering here, when the new map format rolls in, would it be theoretically possible to add fancy new features like pitching sprites and rotating them in the vertical plane?

[Helixhorned]

Mikko C, on 17 August 2013 - 03:30 AM, said:

Just wondering here, when the new map format rolls in, would it be theoretically possible to add fancy new features like pitching sprites and rotating them in the vertical plane?

It's really more a question of engine code, not so much of the format. The scaffolding would be there, but you'd have to build the building.

[supergoofy]

Playing Attrition mod with one of the newer eduke32 builds (after the introduction of r_usetileshades 1), it makes dark areas very dark (when r_usetileshades 1 is used).

for example the official Duke Nukem 3D Episode 1 Level 1 (Hollywood Holocaust), the small corridor in the toilet area gets very dark (you enter this corridor to get to the secret small room, where next to it is the room with the keycard).

r_usetileshades 0 fixed the darkness problem.

[TerminX]

Screenshot comparison with software mode using the newest build, please.

[supergoofy]

r_usetileshades 0 / 1 in attrition mod test :

here is the comparison in Duke Nukem 3D Episode 1 Level 1 (Hollywood Holocaust) :

attrition - polymost.rar
http://www26.zippysh...42919/file.html


note: I have tested it only in polymost, because in software renderer there is no difference


EDuke32 r4019 is used

[Micky C]

What TerminX is saying is that polymer with cancer mode and polymost with usetileshades should look as close to classic as possible. That's why he wants the classic renderer comparison, because if the new modes look just like classic, then it's not considered a problem.

[supergoofy]

In software renderer there is no difference between r_usetileshades 1 and r_usetileshades 0 (as expected - it takes effect in polymost)

Do you need a comparison between polymost r_usetileshades 1 and software renderer ?


polymost r_usetileshades 0 is more close to software renderer. still though r_usetileshades 0 is darker than software renderer.

r_usetileshades 1 makes you unable to see in dark places, because it makes them very dark

The comparison that I did was in polymost renderer wirh r_usetileshades 0 and r_usetileshades 1, The screenshots show how much darker the r_usetileshades 1 makes the same areas.

[Micky C]

The shading in the classic renderer is considered a constant, and since TX, Helix and Plagman want to make polymost and polymer look just like classic in terms of shading, if you post up a direct comparison with classic against polymost in both modes, they might use that to help perfect the shading. That's what I think he's getting at anyway.

[TerminX]

Yes, I need a comparison between Polymost r_usetleshades 1 and the classic renderer. Brightness/contrast/gamma and ambient light level should all be at defaults as well.