[Plagman]

It's not really a rule for today, though it can help some. What I meant if that if you did that, it would make it easier for me to improve the situation later when I get to it.

What the engine does now is determine which models to draw, then go through them in a rough closer-first order and draw all their surfaces, in order. That means that if the part of your model that's fully opaque ends up behind the part that's translucent from the angle you're looking at it but everything is in surface 0, your translucent stuff might not be drawn in the right order and you might not see through it. If you move the translucent part to surface 1, you're guaranteed that it's at least going to be drawn after all the opaque parts of the same model.

Now, what I want to do eventually is have a "translucent" DEF token that tells the engine "this surface is translucent", because it would be a huge pain in the ass to try to examine the models at runtime to figure out which parts are translucent or not. This way the engine could draw all the surfaces of all the models that are opaque just fine, then walk through the translucent surfaces only and try to figure out how to alleviate any artifacts (by trying to sort them, or any other approximation that would yield better results than today). This way even if the method to make it look OK is expensive, it would only apply to a small portion of the scene.

Intersecting translucent planes are never really going to work right, however. It's not wonder than modern games avoid translucency like the plague and always use alpha-testing for world stuff. The only translucent stuff you see are particles, which are easy to sort since they're conveniently aligned.. Even things like glass panes are generally rough approximations, like additive blending.

[Mblackwell]

Couldn't you have users flag them so they are both drawn fully and blended?

[Plagman]

Which part are you referring to exactly? You can't render intersecting translucent planes without breaking them up into more polygons and carefully sorting them, which is very expensive.

[Mblackwell]

That part. I'm saying skip proper sorting and blend them if a flag is set by the modder. This would look terrible if any part wasn't alpha, and could produce visual artifacts, but for many instances it would be as good as anything.

[MusicallyInspired]

MusicallyInspired, on 09 February 2013 - 08:38 PM, said:

Got a problem with polymer on my laptop. My laptop is a decent build with a NVidia GeForce GT 550M 2GB video device. Polymer works fine and smoothly except for spotlights. In Mapster and ingame the spotlights don't show up at all. If I do 'restartvid' in the console the spotlight will appear for a split-second before disappearing again (also, I've noticed that it does not cast a shadow). I'm not sure if this was ever a problem before or not as I don't remember if I ever saw an ingame spotlight on my laptop or not. I guess I just assumed it would work. I'm already running the latest driver so that's not the problem. Any suggestions? I've tried the latest snapshot as well as the 64-bit build that was posted a little while back. No change. I'm not sure why it's not working as it's a decent NVidia card and NVidia is supposed to the best compatible device for polymer, right?

The eduke32.log file displays these lines of messages every time I typed in 'restartvid' if it means anything:

Can I bump this one more time? Also, I notice when playing e1l1 the spotlight in the street flickers on and off, and still no shadows.

[Gambini]

Are you sure you dont have either an autoexec.cfg or something in your eduke32.cfg disabling those?

I say, because, if you ever run a command like r_pr_lighting it will be embedded into your cfg forever.

[The Commander]

MusicallyInspired, on 02 March 2013 - 07:50 PM, said:

Can I bump this one more time? Also, I notice when playing e1l1 the spotlight in the street flickers on and off, and still no shadows.

A full log file please would help, and do what Gambini said and remove ANY 'CFG' files.

[MusicallyInspired]

There are no CFG files except for eduke32.cfg. Delete that? I apologize about the log not showing up. I inputted a portion of it in the original post, but it didn't show up in the quote. Here's the log. It seems the output from the previous log contents isn't the same this time around. Don't know what's going on.

EDIT: Ah, I just noticed that it's using my intel graphics chip instead of the NVidia one. That might be it...

Attached File(s)

•  eduke32.log (138.85K)
  Number of downloads: 531

[The Commander]

Yes delete all CFG's
They will be regenerated next time you launch.

[The Commander]

Well there is your problem...

Quote

Setting video mode 1920x1080 (32-bit fullscreen)
OpenGL Information:
Version: 3.1.0 - Build 9.17.10.2867
Vendor: Intel
Renderer: Intel® HD Graphics 3000

Either you haven't installed your NVidia GeForce GT 550M correctly or you have really messed something else up, but it's still using your Intel chip as the video driver.
Please make sure you have the latest Nvidia drivers.

Also using the latest eduke32 wouldn't go a miss either. (Your version is 3 months old)
http://dukeworld.duk...e32_current.zip

[MusicallyInspired]

Yeah, I just noticed that. It looks like the Intel graphics were set to global default for everything on my laptop and wasn't using the NVidia at all. A quick switched solved the issue. My mistake.

[Kyanos]

Mblackwell, on 02 March 2013 - 05:14 PM, said:

That part. I'm saying skip proper sorting and blend them if a flag is set by the modder. This would look terrible if any part wasn't alpha, and could produce visual artifacts, but for many instances it would be as good as anything.

This conversation was going down a road I think should be addressed sooner rather than later. I hope it hasn't been forgotten. The issues discussed above apply to more than just model skins. Translucent windows, TROR water, and sometimes just normal transparent sprites near multiply lights are more examples of what I believe to be a relative issue, drawing orders.

[Helixhorned]

Gambini, on 16 February 2013 - 05:26 PM, said:

Yes sir! I Here is the attached map.

I can confirm wild flickering on a system with an AMD CPU and GPU. Just a thought, could it be that it's specific to AMD CPUs, maybe because of a difference in floating point implementation? Can the testers confirm or refute this?

[Gambini]

Yes the first person having that problem has both AMD CPU and GPU. The key here would be knowing if The Big Cheese has an AMD cpu since he´s the only one reporting it with a Nvidia.

So glad to know you´re working on it!

[Plagman]

We're not using fast-math, so you'd expect anything we do to be 754-compliant no matter what the machine is. Maybe we should do a test build with "-frounding-math -fsignaling-nans" to ensure complete compliance in the cornerest of cases, and see whether that normalizes behavior for everyone? Be it glitchy everywhere or fixed everywhere..

[Gambini]

I was about to say that!

[Micky C]

I have intel.

[Plagman]

Well, there you go; next theory, people. Get the whiteboard.

[Hendricks266]

Spoiler

[Player Lin]

Is that flickering problem related the automap one in polymost renderer?

(I still get random textures/edge of sectors' boundary messed up when rotating the automap at some specific angles in recently eduke32 versions, as always.)

[Jblade]

So when I zoom into a certain level in Mapster's 2D mode, it all slows down dramatically and my console is spammed by this:

L50: RETURN=0
L50: RETURN=0

hundreds and hundreds of times. How do I stop/disable this, since it renders 2D mode unusable for me.

[RichardStorm]

Is it just my pc, or arrow keys no longer work in Mapster ?

[Mike Norvak]

RichardStorm, on 06 March 2013 - 06:08 AM, said:

Is it just my pc, or arrow keys no longer work in Mapster ?

Always remember: use the latest eduke32 Some synthesis comes with errors from time to time.

[The Commander]

RichardStorm, on 06 March 2013 - 06:08 AM, said:

Is it just my pc, or arrow keys no longer work in Mapster ?

This was fixed 7 days ago.
http://forums.duke4....post__p__149997

Use the latest revision.
http://dukeworld.duk...ke32_latest.zip

EDIT: @Norvak, My link I posted will always download the latest version.
Your link is probably more for the people that actually want to read the log and get the source.

[Jblade]

James, on 06 March 2013 - 02:07 AM, said:

So when I zoom into a certain level in Mapster's 2D mode, it all slows down dramatically and my console is spammed by this:

L50: RETURN=0
L50: RETURN=0

hundreds and hundreds of times. How do I stop/disable this, since it renders 2D mode unusable for me.

Anybody? I don't want to seem impatient but I was looking to do some work but I can't locate a version old enough that still supports TROR and doesn't have this.

[TerminX]

The "L50" might signify line 50 of one of the Mapster32 scripts you have loaded.

[Jblade]

TerminX, on 06 March 2013 - 12:56 PM, said:

The "L50" might signify line 50 of one of the Mapster32 scripts you have loaded.

And you're correct, haha! For some reason I had set EVENT_LINKTAGS to addlog RETURN. I can't remember why now, but it's fixed the problem so thanks

[TerminX]

James, on 06 March 2013 - 01:19 PM, said:

And you're correct, haha! For some reason I had set EVENT_LINKTAGS to addlog RETURN. I can't remember why now, but it's fixed the problem so thanks

No problem, glad I could help!

[RichardStorm]

Quote

Always remember: use the latest eduke32 Some synthesis comes with errors from time to time.

In fact now it has been fixed

[Mateos]

Good evening,

In the latest build (eduke32_win32_20130304-3555), the music volume is modified by both Sound and Music sliders, tested here on Windows 7, and asked a friend to test it, same issue.

Also, during loading, my screen tilt quite a lot; I suspect F.lux, a software which modifies the luminosity depending on the time of the day, to enter in conflict with EDuke32... EDuke32 tries to reset the luminosity to its default, while F.lux re-move it.

Hope I'm in the right thread to report ^^' If not, sorry, and please move this where it should be :/