[RPD Guy]

Hey guys,

I'm having this issue while atempting to use the tile selection screen (V):
It seems that this only occurs when I'm using polymer renderer.

Spoiler

I'm using the latest mapster32 build, both 32 and 64 bit versions behave like this.
Also this problem happens to different computers with different video cards.

[LeoD]

RPD Guy, on 28 February 2020 - 03:14 AM, said:

I'm having this issue while atempting to use the tile selection screen (V):
It seems that this only occurs when I'm using polymer renderer.

"Polymer" => Fix is very unlikely.
However, for unknown reasons decided to hunt it down, which I shouldn't have done. It seems to be double-broken, and during bisecting Mapster32 started to read the cfg files from AppData\Roaming at some point.
I didn't notice and thought my forward-ported fix would still work...

Issue first introduced in sdlayer.cpp r6938. (make RENDERTYPE=WIN would therefore cover it.) Shows black screen. Reverting a part of that change (line 1598: setvideomode_sdlcommonpost(x, y, c, fs, regrab); ) works until r7619.
As of Mapster32 r7620 the result matches your screenshot; I assume that an additional issue has been introduced. Too many files changed at this point; I didn't investigate any further.

[Mark]

I have been using a much older Mapster for quite a while now but I decided to try out 8641 to see if I had the problem. I do.
I also have this error message twice in both the Mapster and eduke log files:

debug: DwmGetCompositionTimingInfo() FAILED! HRESULT: 0x80263001 (Unknown error)

[LeoD]

Mark, on 28 February 2020 - 10:25 AM, said:

I have been using a much older Mapster for quite a while now

Which one?

Mark, on 28 February 2020 - 10:25 AM, said:

I also have this error message twice in both the Mapster and eduke log files:
debug: DwmGetCompositionTimingInfo() FAILED! HRESULT: 0x80263001 (Unknown error)

Seems like a message from a Windows API. Might be related to your graphics hardware or driver.

[blizzart]

LeoD, on 28 February 2020 - 11:32 AM, said:

Which one?

I´m stick with r6129.
I Didn´t tried a newer one beside a broken one from last year (which also showed the same bugs like yours).

Mark should know, if there a newer builds which run fine.

[LeoD]

blizzart, on 28 February 2020 - 11:54 AM, said:

I´m stick with r6129.
I Didn´t tried a newer one beside a broken one from last year (which also showed the same bugs like yours).

Mark should know, if there a newer builds which run fine.

I'm usually fine with the latest Mapster32 debug executables, because my range of usage is very limited and 99.x% 2D mode.
I'm more interested in the versions which the 'regular' mappers prefer to stick to and why. Some easy shit like the fix above could be forward-ported to more recent versions, so that people might be able to use additionl features without suffering the issues of latest synthesis builds. The same might be possible the other way round for rather simple improvements or bugfixes.
I think it's desirable to have one or two pragmatically patched versions of each Mapster32 and EDuke32 on which most people can agree that they're suitable for their mapping purposes and run as many pre-existing maps and mods as possible. Until such a build pops out on synthesis one day...

[Mark]

Back when 6927 was the latest version I had Photonic modify Mapster32 to fix the wall sprite flickering issue under Polymer. All it does is pull the sprite away from the wall an infinitesmal amount when hovering over it with the cursor in 3D mode and pressing a key. Since I don't want to learn how to compile my own Mapster every time there is an new revision I keep using the old one. What I need to do is ask someone to make that fix a script that can be easily used with any new revision.

And concerning the other thing. I haven't changed my video card or driver in well over a year IIRC so why the error message only showed up in recent builds I don't know.

edit: found this on a google search. "I want to use DwmGetCompositionTimingInfo to get information about dropped frames and so on for a performance testing tool i am writing."

Maybe this has to do with the devs attempting to solve once and for all the framerate stutters some people have had.

[LeoD]

Mark, on 28 February 2020 - 02:08 PM, said:

Back when 6927 was the latest version I had Photonic modify Mapster32 to fix the wall sprite flickering issue under Polymer. All it does is pull the sprite away from the wall an infinitesmal amount when hovering over it with the cursor in 3D mode and pressing a key. Since I don't want to learn how to compile my own Mapster every time there is an new revision I keep using the old one. What I need to do is ask someone to make that fix a script that can be easily used with any new revision.

That's the type of stuff I'm interested in. Although you're talking about m32 scripting, I suppose.
@Photonic: would you mind sharing that patch?

[Kyanos]

It's around here somewhere, I will post it once I re-read Marks and mine messages from the time and remember what I'm looking for.

[Kyanos]

build.cpp revision 6927 lines 2171 - 2177 in function correct_ornamented_sprite (current revision 8659, line 2240+)

        //Make sure sprite's in right sector
        if (inside(sprite[i].x, sprite[i].y, sprite[i].sectnum) != 1)
        {
            j = wall[hitw].point2;
            sprite[i].x -= ksgn(wall[j].y-wall[hitw].y);
            sprite[i].y += ksgn(wall[j].x-wall[hitw].x);
        }

changed to:

        //Make sure sprite's in right sector
        //if (inside(sprite[i].x, sprite[i].y, sprite[i].sectnum) != 1)
        //{
            j = wall[hitw].point2;
            sprite[i].x -= 3*ksgn(wall[j].y-wall[hitw].y);
            sprite[i].y += 3*ksgn(wall[j].x-wall[hitw].x);
        //}

What it does:

Quote

Pushes ornamented sprites to 3 build units off the wall, slightly less than half the smallest grid size.

Affects default placement using "S" to insert a wall sprite. If you have any old placed sprites that still need moving, pressing "O" on them will bump them out to this new setting.

[LeoD]

Photonic, on 29 February 2020 - 08:01 AM, said:

build.cpp revision 6927 lines 2171 - 2177 in function correct_ornamented_sprite (current revision 8659, line 2240+)

Thanx man!
That part of build.cpp hasn't changed since then, so patching later versions should be a no-brainer for now.
Mark, if you'd like to try a certain revision, I'll happily patch+compile it for you.

[Mark]

I have 8573 in one of my current projects and the error message I posted earlier from newer revisions is not present. Patch that one. Thanks. I hope that revision wasn't buggy. Its still in the folder so I'll assume it was OK.

edit, forget that one. It crashes when switching from 2d to 3d. I'll find another one

Patch 8629.

[LeoD]

Mark, on 29 February 2020 - 02:41 PM, said:

I have 8573 in one of my current projects and the error message I posted earlier from newer revisions is not present. Patch that one. Thanks. I hope that revision wasn't buggy. Its still in the folder so I'll assume it was OK.

edit, forget that one. It crashes when switching from 2d to 3d. I'll find another one

Patch 8629.

Too late, man. 8573 uplading...
[Edit:]OK, here you go. Time for bed it seems. I deleted the files instead of zipping them ... twice.

[Mark]

When pressing O it puts the wall sprite directly on the wall. It didn't offset it away.
Stock Mapster32 puts it about 1/4 smallest grid size away. The patch is suppose to offset about 1/2 or slightly less.

[LeoD]

Mark, on 29 February 2020 - 07:28 PM, said:

When pressing O it puts the wall sprite directly on the wall. It didn't offset it away.
Stock Mapster32 puts it about 1/4 smallest grid size away. The patch is suppose to offset about 1/2 or slightly less.

I need to ask annoying questions now.
Is the patch above really the only change needed?
Are you sure you ran the correct executable?
I have rebuilt, and the only difference between the binaries appear to be the usual compiler timestamps. I have added a patched r6927 to a new download. It should act the same as the one you've got from Photonic. I have included a simply patched E1L1. When I press "O" on the wall aligned graffiti sprite near the new starting point, it gets moved away by three units (3/8 of minimum grid size). That's the only thing I've tested since I don't know anyway how "S" is supposed to work in detail.

[Kyanos]

LeoD, on 01 March 2020 - 03:25 AM, said:

Is the patch above really the only change needed?

Yes, I double checked, build.cpp was the only file changed and I diff'd it again it was only that one section posted above.

LeoD, on 01 March 2020 - 03:25 AM, said:

That's the only thing I've tested since I don't know anyway how "S" is supposed to work in detail.

When pointed at a wall in 3d mode "S" will insert a wall aligned sprite at that point. Regularly it is shifted 1 build unit into the sector towards the camera, with the patch now 3 build units in the same direction.

[LeoD]

Oops, kind of forgot about this.
"S" works for me in 3D mode. @Mark : please re-check.
Btw., the r6927 builds crash for me when changing back from 3D to 2D, as do the r6927 synthesis builds.

[Mark]

When testing earlier I saw the S key working as described. I used 6927 for many months in multiple projects and had no crashes.

[RPD Guy]

Any updates?