[Fox]

Latest snapshot (4388) is not loading EDUKE.CON, instead it says "CON file 'EDUKE.CON' missing". It's working fine with 4384.

[Helixhorned]

Try r4391. One of the preceding changes introduced a typo that led to an access out of the MAXQUOTES bound. Note how this has no apparent relationship with the produced observable issue: undefined behavior at its best .

[Helixhorned]

Fox, on 06 March 2014 - 11:09 AM, said:

Since we are talking about shading, why is the shading of HUD sprites different in OpenGL? Map structures are relatively similar to 8-bit, while HUD sprites are not. Most notable when you are throwing a Pipebomb, which changes from the HUD to a spawned sprite.

Fox, on 08 March 2014 - 08:49 AM, said:

Color me stupid, I forgot to mention it's with highres tiles.

That seems merely like a perceptual glitch with the HRP pipebomb model to me. Note that it has two sides, a shiny one and a dark one. The HUD model shows it from the shiny side, but when it's thrown, it ends up with the dark side toward the player.

[Fox]

There is a noticeable difference beetween the shading of HUD sprites and game sprites if not using 8-bit tiles.

[Danukem]

Fox, on 22 March 2014 - 12:33 PM, said:

There is a noticeable difference beetween the shading of HUD sprites and game sprites if not using 8-bit tiles.

It looks like the 8-bit tiles have higher contrast.

[Fox]

That's because the shade for each color is different in 8-bit, but that's part of using "highres" textures.

My point is that the shade of HUD sprites are brighter than game sprites. While the Pipebomb of the HUD and game have the same shade in 8-bit mode, that's not the case in polymodes.

[Micky C]

In the classic renderer, textures on highly sloped surfaces at a distance become warped and fullbright. The warping is obviously a limitation of the renderer, but is there anything that can be done about the fullbright? I mean I have sectors whose textures only become warped at such a large distance that it'd be much better for them to be pitch black when this happens.

[Helixhorned]

Fox, on 22 March 2014 - 12:33 PM, said:

There is a noticeable difference beetween the shading of HUD sprites and game sprites if not using 8-bit tiles.

First, let's not conflate terminology here. You're using "8-bit tiles" in both cases. Sure, in the OpenGL modes, they're uploaded as RGB textures, but it's certainly inappropriate to start calling them "highres" just because of that. Second, it's important to specify the exact renderer settings you're running with. I had to experiment a bit and it looks like you're running either Polymost with r_usetileshades 0, or Polymer with r_pr_artmapping 0. And most likely, therein lies the problem.

In the classic renderer, shading it done via lookup into a table, as described in some detail in the Lunatic manual. Take a look at the second "ramp" of colors with indices 32-63, which is used for skin and note that the yellow (perceptually most significant) and blue components have a convex shape. Thus, at higher shades, they are darker than the linear blending with black. But linear blending is exactly what the "original" GL modes do.

[Fox]

Alright, I will try to make a appropriate report:

Classic mode:



Polymost (r_usetileshades 0)



Polymer (r_pr_artmapping 0)

Attached File(s)

•  hudshade.zip (242bytes)
  Number of downloads: 477

[TerminX]

You need to set those vars to 1 to get it to look similar...

[Helixhorned]

OK, I see it now -- the shades also differ in the GL modes with table lookup.

Edit: even with having full visibility in the sector.
Edit 2: the shades also differ in classic. Take a very close look at the exact pixel values!
Edit 3: see r4392

[Fox]

Yes, it diff by 1 shade table if ≥ 16. I am guessing the value is rounded when visibility is calculated.

However the difference is clearly more than 1 shade in OpenGL.

[Helixhorned]

Fox, on 23 March 2014 - 06:35 AM, said:

Yes, it diff by 1 shade table... I am guessing the value is rounded when visibility is calculated.

The problem was that the HUD shade value temporally approaches the ceiling/floor value to provide a smooth transistion when changing sectors: each time, the difference is roughly halved. It was the last step that was flawed: if the difference was 1 or -1, a value of 1/2 == 0 was added (in C's integer arithmetic, division is defined to round toward 0 [*]).

[*] While right shifting rounds towards negative infinity. Another rounding detail to keep an eye out for!

Also, as an addendum: the HUD shade deliberately is clamped at 24. So, your example was in a sense the strictest one that displayed the issue.

Quote

However the difference is clearly more than 1 shade in OpenGL.

As I said, without table lookup, the OpenGL modes are hopeless to faithfully reproduce the wealth of effects of the classic renderer. See it that way: table lookup is more general than linear blending. For example, you could create a shade table with a darkness "bump" in the middle, while near and far pixels would be bright. So, the issues described with r_usetileshades and r_pr_artmapping set to 0 won't be fixed because there's no sense in attempting.

[Fox]

So the difference was because of the weapon display code. Let's put that aside:

gamevar TEMP 0 0

onevent EVENT_DISPLAYREST
  getsector[THISACTOR].floorshade TEMP
  rotatespritea 160 150 65536 0 FIRSTGUN TEMP 0 8 0 0 0 xdim ydim
endevent

Now the shade of HUD sprites and game sprites are exactly the same in Classic mode.



But they are different in Polymost and Polymer (using r_usetileshades 0 and r_pr_artmapping 0).





And I think this is something that should be fixed. For instance, the game sprites are relatively accurate to Classic mode, but HUD sprites are much more brighter than expected.

I may be talking shit, but it shouldn't be so hard to fix it since you could just copy the algorithm used by game sprites to HUD sprites.

[Mblackwell]

By setting those values to 0 you aren't using the new shading display code.

[Fox]

That's not the point. The same flaw applies to "highres" textures.

[Mblackwell]

Ugh. Those setting change the shade display ramp to better match classic if desired. If you don't have them set you don't want to match classic and want a nice linear ramp instead.

[MetHy]

I have a request : would it be possible to improve sector copy/pasting so that textures look the same no matter where you paste the copied sectors?

What I mean by that is, when you move a sector around, the textures don't 'move' with it so you'll end seeing the 'next' part of the texture (rather than the same) if you paste it near it.

That would make copy/pasting even more efficient.

I guess that's a texture behaviour as a whole though and the same could be said about simply MOVING sectors around (and not just copy/pasting); actually it's more due to the moving rather than the copy/pasting.

This is probably asking a lot though considering in the current version of mapster copy pasting doesn't even work at all

[Helixhorned]

Fox, on 23 March 2014 - 07:26 AM, said:

gamevar TEMP 0 0

onevent EVENT_DISPLAYREST
  getsector[THISACTOR].floorshade TEMP
  rotatespritea 160 150 65536 0 FIRSTGUN TEMP 0 8 0 0 0 xdim ydim
endevent

Now the shade of HUD sprites and game sprites are exactly the same in Classic mode.

(...)

I may be talking shit, but it shouldn't be so hard to fix it since you could just copy the algorithm used by game sprites to HUD sprites.

No, I think you have a really good point. I fixed a small off-by-one issue, but the differences here are enormous! And that's for pretty much all combinations of GL renderer settings. It's certainly something that warrants further investigation, and maybe at the end there's also a resolution of the two r_usetileshades modes to be had... Currently there are two, 1 (TX, default) and 2 (my tweaks), but both have their flaws.

[Fox]

Hmm, the latest SVN seems to have fixed the difference beetween HUD sprites and game sprites. But overall the shading seems too bright compared to 8-bit mode, the last one seemed to reproduce the lighting more accurately.

[Stabs]

really bright now in polymer, brightness / contrast can change it for a split second but always just reverts back to original brightness

[Jblade]

Just a quick question about LunaCON - will the benefits of the new mapformat still work with CON code, even if (obviously) you won't be able to access various things in con itself? There's no way I can port my code to LUA but some of the benefits of the new map format like blend ability for walls would be very useful for the mapping side.

[Helixhorned]

Micky C, on 22 March 2014 - 07:39 PM, said:

In the classic renderer, textures on highly sloped surfaces at a distance become warped and fullbright. The warping is obviously a limitation of the renderer, but is there anything that can be done about the fullbright? I mean I have sectors whose textures only become warped at such a large distance that it'd be much better for them to be pitch black when this happens.

I encountered this once, it's an overflow somewhere in the classic code. Should be fixable.

[Helixhorned]

Stabs, on 23 March 2014 - 11:54 PM, said:

really bright now in polymer, brightness / contrast can change it for a split second but always just reverts back to original brightness

I did encounter this after changing r_pr_artmapping or the like: remember that you have to do restartvid afterwards. Did this happen to you while playing? If so, it's a bug.

The overall brighter appearance is a consequence of the fix, I'll write in more detail about the differences of r_usenewshading 2 and 3 later. Keep in mind that you can always change it back if it makes your map look not as intended.

[Helixhorned]

James, on 24 March 2014 - 03:09 AM, said:

Just a quick question about LunaCON - will the benefits of the new mapformat still work with CON code, even if (obviously) you won't be able to access various things in con itself?

Of course. CON is just an interface to certain structures and a collection of commands. If something is not accessible through CON, why should that imply the non-functioning of a feature that doesn't by itself belong to CON?

Quote

There's no way I can port my code to LUA but some of the benefits of the new map format like blend ability for walls would be very useful for the mapping side.

You seem a little confused. It's not like you have to use Lua code to enable certain features, that would be pretty silly. Under the hood, CON and Lua are on equal footing -- after all, the former is translated to the latter. Moreover, you don't need to port the whole thing: CON and Lua can exist side-by-side. I think that I explained the broad picture in the introductory post, but maybe it was not so clear? (Or the post too long...?)

[Jblade]

Yeah you're right I was a bit confused, I appreciate you clearing it up for me. I just wanted to be 100% sure rather than jumping into anything and getting stuck later. It's not something I plan on doing until I've finished this episode at least though.

[TerminX]

I've been a bit busy lately, could someone please post comparison shots demonstrating this new r_usenewshading mode 3 and why it's visually (not technically) superior to the existing modes? Thanks!

[Kyanos]

Spoiler

There are a few shots from polymost, first of each set is r_usenewshading 2, then 3. 3 is brighter.

[Micky C]

Got some classic shots to compare it with?

[Stabs]

r_shadescale just needs tweaking for me, i think you are actually correct to make newshading 3, as i use shade 21 as a base for DNE now instead of 27, now its actually displaying shade 21 as it should be i suspect, no worries r_shadescale is here to fix the day

but here is 2 comparison shots of newshading 2 vs 3

shading 2



shading 3