[Jblade]

Using all that fancy shading/additive stuff you coded in a while back helix, would there be a method to make a 'reverse' additive (or whatever the real term for it is) where black is opaque and the brighter something is the more translucent it becomes?

[MetHy]

Helixhorned, on 22 May 2014 - 12:49 AM, said:

So, MetHy: was this a false alarm (shade preview not enabled?) or is it one of the problematic cases above?

No, that's not the problem. I just checked and, I was wrong; it's not that no shade doesn't work on (some) sprites made flat with R; it's that no-shade doesn't work on sprite #1059 when it is flat or normal. It only works on it when it's wall aligned.

It just happened that I used that sprite as flat and with a parallaxed sky so I thought that's what the issue came from.
Now, wether some other sprites behave like #1059 or not I can't tell unless I stumble upon it.

[Helixhorned]

James, on 22 May 2014 - 01:45 AM, said:

Using all that fancy shading/additive stuff you coded in a while back helix, would there be a method to make a 'reverse' additive (or whatever the real term for it is) where black is opaque and the brighter something is the more translucent it becomes?

Well, a blending table is conceptually a function ColorIndex × ColorIndex→ColorIndex, so the question is usually how to express a derised look in terms of functions of background r, g, b and foreground R, G, B color components (for reverse translucency, the meaning is reversed). I think the one I coded up in shadexfog.lua, create_brightpass_trans(), matches what you want pretty well:

        function(r,g,b, R,G,B, alpha, numtabs)
            local a = alpha/numtabs
            local F = 1 - min(a, (R+G+:) / (3*63))
            local f = 1 - F
            return f*r+F*R, f*g+F*G, f*b+F*B
        end,

It's alpha blending, but one dependent on the texel's values. In the case of one table, it simplifies to:

            local F = 1 - (R+G+:) / (3*63)
            local f = 1 - F
            return f*r+F*R, f*g+F*G, f*b+F*B

MetHy, on 22 May 2014 - 02:34 AM, said:

No, that's not the problem. I just checked and, I was wrong; it's not that no shade doesn't work on (some) sprites made flat with R; it's that no-shade doesn't work on sprite #1059 when it is flat or normal. It only works on it when it's wall aligned.It just happened that I used that sprite as flat and with a parallaxed sky so I thought that's what the issue came from.Now, wether some other sprites behave like #1059 or not I can't tell unless I stumble upon it.

Ah, it's hard-codedness striking here. When a MASKWALL* sprite is spawned, some bits are cleared and the blocking one is set:

        case MASKWALL1__STATIC:
(...)
        case MASKWALL15__STATIC:
            j = sp->cstat & SPAWN_PROTECT_CSTAT_MASK;
            sp->cstat = j|CSTAT_SPRITE_BLOCK;
            changespritestat(i, STAT_DEFAULT);
            break;

With r4478, the mask of protected bits also includes CSTAT_SPRITE_NOSHADE.

[MetHy]

Helixhorned, on 22 May 2014 - 03:26 AM, said:

With r4478, the mask of protected bits also includes CSTAT_SPRITE_NOSHADE.

Not sure what you mean. Does that mean it will be fixed in an upcoming version? Because I can't see r4478 here and before my previous post I tried it in the latest version of eduke32 I downloaded a couple of days ago

[Jblade]

Quote

Well, a blending table is conceptually a function ColorIndex × ColorIndex→ColorIndex, so the question is usually how to express a derised look in terms of functions of background r, g, b and foreground R, G, B color components (for reverse translucency, the meaning is reversed). I think the one I coded up in shadexfog.lua, create_brightpass_trans(), matches what you want pretty well:

That works fantastically, thank you very much!

[Helixhorned]

MetHy, on 22 May 2014 - 03:31 AM, said:

Not sure what you mean. Does that mean it will be fixed in an upcoming version? Because I can't see r4478 here and before my previous post I tried it in the latest version of eduke32 I downloaded a couple of days ago

Yes, it should be fixed in the new build, r4480. I might announce a new revision before the synthesis build has completed, which in my experience never takes longer than 30 minutes. You can see it's finished when the ChangeLog.txt is finally there.

[MetHy]

Helixhorned, on 22 May 2014 - 12:49 AM, said:

EDIT2: actually, I recall the turret-hard-to-hit bug from playing the beach CBP. No need for a test case for that, but it might be a while until I'll debug it.

Could it be something related to auto-aiming against enemies set in particular upwards angle ? Come to think of it, I've never had trouble shooting turrets put on ground level plus sometimes I seem to have trouble hitting slimers when they're on the ceiling, too.

[MetHy]

Also something else I forgot to mention, whenever a map uses ambientsound 279 which is the helicopter sound; that sound appears during the loading of the map. It's no big deal but I guess it ruins the surprise of seeing the helicopter...

Edit : okay sorry I'll be more specific. The issue isn't every time a map uses that sound, it's every time a map uses that sound on a working subway sector (we just happend to use that twice in the duke hard episode). Doesn't seem to happen with other ambient sounds.

Edit 2 : joined is an example map

Edit 3 : Wow. I thought this was eduke32 specific but actually, this glitch also appears in the original dos Duke3d ! (and in megaton, too obviously)

Attached File(s)

•  SOUNDTEST.rar (807bytes)
  Number of downloads: 288

[Wolf]

Sorry if this is slightly off-topic, but I figured since this thread has always been the hotspot for technical eduke32 talk, I was wondering, have any improvements been made to the sound system in eduke32?

[Helixhorned]

MetHy, on 22 May 2014 - 11:03 AM, said:

Also something else I forgot to mention, whenever a map uses ambientsound 279 which is the helicopter sound; that sound appears during the loading of the map. It's no big deal but I guess it ruins the surprise of seeing the helicopter...

Edit : okay sorry I'll be more specific. The issue isn't every time a map uses that sound, it's every time a map uses that sound on a working subway sector (we just happend to use that twice in the duke hard episode). Doesn't seem to happen with other ambient sounds.

Yeah, that was some strange coding going on there. For SE6/14, A_CallSound() was called from premap A_Spawn() to retrieve the movement sound of the subway. But that also made it play once! With r4481, not any more.

By the way: the turret issue is present in DOS Duke, as can be seen by ripping out and playing the area around (80000, 50000) from the beach CBP.

[MetHy]

Weird I don't recall that, but then again I don't play DOS duke3D as much as I used to...

So you're fixing it even if it was like that in the original game?

[Stabs]

hey guys, got a nice stable android setup again, xperia play phone and nexus 7, xperia play has hardwired gamepad controls so wouldnt mind giving some of those android versions a go, just PM me the links

[Daedolon]

This has been pissing me off for some time now and it's related to the SDL 2.0 bug (that still doesn't allow us to select sectors without tapping LeftCtrl, plus it also almost always gives the wrong tile when Left Clicking the mouse in the tile selector, hopefully these can be fixed one day). Anyway, whenever I open the console I get this:



Basically it adds those characters to the console (although opening it fine). If I hit the console key to toggle it multiple times, I just get a bunch of these characters. It's super annoying having to hit backspace twice or more times every time I need to do something with the console (which is quite often for debuggin mods etc.).

The log inputs different character:

"§" is not a valid command or cvar

Cheers.

[Helixhorned]

MetHy, on 23 May 2014 - 02:21 PM, said:

So you're fixing it even if it was like that in the original game?

The subway sound glitch looks like a genuine bug and nothing except a curious quirk is lost by fixing it. I'm less sure about tackling the turret issue. Original game functionality is better left as-is, IMO, unless a problem is extraordinarily severe (for example because C undefined behavior is invoked, in which case the "effect" is just mere coincidence).

Daedolon, on 23 May 2014 - 09:00 PM, said:

This has been pissing me off for some time now and it's related to the SDL 2.0 bug (that still doesn't allow us to select sectors without tapping LeftCtrl, plus it also almost always gives the wrong tile when Left Clicking the mouse in the tile selector, hopefully these can be fixed one day). Anyway, whenever I open the console I get this: (...)

These issues are not something I can reproduce, so unfortunately you're mostly on your own. It seems that other users experienced the RAlt one, so maybe this new one always appears together with it? Would you be willing to give debugging your console key bug a shot? It'll better be away from this thread to avoid spamming it, though.

By the way: there's still an open request for running SDL2's checkkeys.exe and pressing RAlt. If that one turns out to reflect what we've seen in the logs from Mapster32, we could report that to the SDL devs.

[MetHy]

Helixhorned, on 24 May 2014 - 01:57 AM, said:

These issues are not something I can reproduce, so unfortunately you're mostly on your own. It seems that other users experienced the RAlt one, so maybe this new one always appears together with it? Would you be willing to give debugging your console key bug a shot? It'll better be away from this thread to avoid spamming it, though.

You mean you're able to use the "select sector" functions with right-alt? Everybody I know can't use it. Also yes, I also do get those weird symbols when checking the console, but only in mapster. When I check the console in game, instead there are a few blank spaces.

[Helixhorned]

MetHy, on 24 May 2014 - 06:04 AM, said:

You mean you're able to use the "select sector" functions with right-alt?

It was about keyboard layouts after all (NY00123 was right). Fixed in r4482.

Sermon: I had repeatedly said that the reason may be due to keyboard layouts and even recommended to switch to US before starting Mapster32. All I needed would have been a "yes, I checked both <my own> and US, the bug appears only when my local one is selected." [Counter-sermon: then again, I failed to notice that when I attempted to play with a German layout, Windows would switch to US when the setup window appeared, probably due to it being the "primary" one on my setup.]

Edit: this is now an issue on OSes other than Windows. Make sure to manually follow the above advice there.

[MetHy]

To be honest I thought about that when you mentioned you didn't have the issue, so what I did i switched to "US" keyboard layout by clicking on that button near the clock on the start bar (i'm using windows 7 pro 64bit if that matters somehow) but was still unable to select sectors with rAlt in mapster. I tried switching before launching mapster, as well as switching once mapster has already been launched, in both case with no success.

[Mark]

Darn. I was hoping the fix would also have restored function back to being able to use the Rshift key when panning wall textures. It works for fine tuning slopes but not the wall textures. Not a big deal, I just have to go back to remapping that key. BTW, my cntrl buttons were never an issue either.

[MetHy]

Oh! Remapping the key works for right-alt. Now I'll just have to find a non-used key to remap it to. Thanks for tip

[Mark]

I ended up using KP0 for my Rshift

[MetHy]

Weird, if I do "remap = KP0-B8" and save, whenever I launch mapster, that doesn't work and gets automatically deleted in the .cfg.
It works if I do "remap=31-B8" for example though

[Mark]

KP0 is actually 52

[MetHy]

I derped. Thank you that worked. Sorry for the spamming, just trying to help and find a solution.

[Helixhorned]

Mark., on 24 May 2014 - 08:18 AM, said:

Darn. I was hoping the fix would also have restored function back to being able to use the Rshift key when panning wall textures. It works for fine tuning slopes but not the wall textures. Not a big deal, I just have to go back to remapping that key. BTW, my cntrl buttons were never an issue either.

Actually, there's a workaround for Shift+KP5+KP2/4/6/8 since r1788: just use Alt insead. Back then, it was coded since the combination with KP5 is blocked at the keyboard level, but with the Windows SDL2 builds, I can in fact confirm that plain Shift+KP2/4/6/8 doesn't work either, but this time for a different reason.

MetHy, on 24 May 2014 - 08:37 AM, said:

Oh! Remapping the key works for right-alt. Now I'll just have to find a non-used key to remap it to.

Wait, do you mean that r4482 didn't fix the RAlt sector selection issue?

[MetHy]

Helixhorned, on 24 May 2014 - 10:08 AM, said:

Wait, do you mean that r4482 didn't fix the RAlt sector selection issue?

Sorry, it did, I thought you meant that even before r4482, switching to US keyboard was enough to make rAlt work.

btw thank you for fixing the helicopter thing

[MetHy]

Hey, me again

I've already mentioned this glitch in another thread and I found a way to 'fix" the problem but the 'fix' I found doesn't work anymore.

Here is the thing, some textures get misaligned when switching to 32bit mode.
Check the metal texture against the pavement at the bottom, here is how it looks in 8bit (how I built it) :
http://i101.photobuc...zps49113ec7.png

and here is how it looks in 32bit:
http://i101.photobuc...zpsd51a4eaf.png

That's the 3rd time this happens to me, I used to 'fix' this issue simply by pasting a non glitchy texture (in this example, the same texture on the right doesn't glitch) onto the glitchy ones; however that doesn't even work anymore, or at least not in this case.

Any idea ? That trimming texture is actually around almost all of this map and now it's glitchy most of the times in 32bit so it's pretty bad in this case for me...
Joined is an example map with the glitch occuring. All I know is that it's "32-bit" specific, and not just Eduke32, it also appears glitchy in Megaton. Meanwhile I'll try to find another way to get around the issue...

Edit: forgot to mention but obviously, if you align those textures so that they look right in 32bit, it will be the contrary and they'll look off in 8bit

Attached File(s)

•  ALIGNGLITCH.rar (575bytes)
  Number of downloads: 288

[Mark]

Helixhorned, on 24 May 2014 - 10:08 AM, said:

Actually, there's a workaround for Shift+KP5+KP2/4/6/8 since r1788: just use Alt insead.

That works. Thanks for the info.

[MetHy]

MetHy, on 24 May 2014 - 01:20 PM, said:

Hey, me again

In r4482 in mapster, sometimes when I left-click to select a sprite in the textures list (the list of all textures), it actually gives me the sprite next to the one I chose rather than the one I want. Sometimes it happens, sometimes it doesn't, but it seems to happen whenever I just used the mousewheel to go through the list.

Edit : also, now the helicopter ambientsound (ambient sound#279) has much lower volume (or radius?) than before

[Daedolon]

MetHy, on 24 May 2014 - 01:20 PM, said:

Here is the thing, some textures get misaligned when switching to 32bit mode.

32 bit modes always draw textures accurately and 8 bit is to blame (or rather the textures) for not being power of two.

MetHy, on 25 May 2014 - 12:04 PM, said:

In r4482 in mapster, sometimes when I left-click to select a sprite in the textures list (the list of all textures), it actually gives me the sprite next to the one I chose rather than the one I want.

Another SDL 2.0 problem (same category as rAlt etc), been pissing me off ever since the SDL switch.

[MetHy]

Daedolon, on 25 May 2014 - 03:23 PM, said:

32 bit modes always draw textures accurately and 8 bit is to blame (or rather the textures) for not being power of two.

Then how comes the same texture used in the same manner sometimes will look off and sometimes not ? (that's what happens in my example) I also wonder why the fix that I had found no longer works...The only solution I've thought of is replacing that texture by one alike that doesn't glitch in 32bit but that one looks a bit worse so I'm tempted to say "fuck you 32bit" and leave the glitchy stuff in the map (I also thought of using a hundred sprites all over the map that would go over the glitchy textures, but due to the alignment for the texture i used I can't do that).
Btw "8bit" being to blame when everything looks right in 8bit doesn't make much sense to me. If it looks right in DOS Duke but doesn't in 32bit, whatever the issue comes from, I'll take that as a problem with the 32bit renderer.

Edit : it seems that the reason why I can't fix the glitchy textures simply by pasting the same non glitchy texture onto it, is because in this case the glichty textures are at the bottom of a texture swap bit (=2 textures on the same wall).
I just tried drawing a new wall (with no bottom texture swap on this new wall), and then pasting the glitchy texture onto it. So, it appears glitchy in 32bit, as expected. Then, I pasted a non glitchy version of the texture on this new wall, and that fixed it for this wall.
However, if I do the bottom texture swap bit, it can no longer be fixed this way.

(then I thought perhaps the issue was dependant to the top texture in those cases? But apparently not.)

So in other words, I have found a solution to my problem : I'll have to waste tons of walls and sectors and add tiny new sectors everywhere so that the top and bottom textures are different walls, like this no need for bottom texture swap and I can paste the non glitchy textures. (Because, yes, the previous solution, using another texture, didn't satisfy me because that would be sacrificing the maps looks even in 8bit)
That's how much effort I'm willing to make the map look not glitchy for all the tasteless and clueless people who play Duke3D in 32bit and that the said 32bit makes things look glitchy (Yes, I'm pissed, I had to let this out). You know, I think that after that I'll only care about my how my maps look and play in dos Duke, everything else is just a painfull mess.