[oasiz]

I last used it when making slum noir and haven't touched it since, found it a bit quirky.

[Jmoc]

Hi,
It seems that the update from r7187 to r7238 introduced a bug that makes the game hangs when loading the map (e.g. E3L2) with DukePlus 2.40.

It crashes exactly at this error:
"Line 19803, espawnvar: invalid sector 4096"

Before r7238 such errors were handled correctly. Now, it just hangs. In debug I see that it hangs at the OSD method, trying to print to the log (which is truncated before the error could even be written).

There are a lot of commits between the two versions but I suspect r7195 is the commit to blame since the stack trace passes through a VM assertion before going to the OSD printer:
"Refine CON VM error handling behavior."

[Danukem]

 Jmoc, on 14 April 2020 - 01:18 PM, said:

Hi,
It seems that the update from r7187 to r7238 introduced a bug that makes the game hangs when loading the map (e.g. E3L2) with DukePlus 2.40.

What about after r7238?

[Mark]

From a recent changelog: "Running glFinish() can have an detrimental impact of Polymer users depending on whether they use the HRP or not."

What is glFinish's purpose and is the bad behavior when running HRP or when not running HRP? And by HRP do you mean any high res content? Normal and spec maps?

I ask because everything I do is Polymer with higher res content.

[Jmoc]

 Trooper Dan, on 14 April 2020 - 03:11 PM, said:

What about after r7238?

Forgot to mention that this happens with every version since then (up to the latest snapshot)

[Mark]

 Mark, on 14 April 2020 - 06:47 PM, said:

From a recent changelog: "Running glFinish() can have an detrimental impact of Polymer users depending on whether they use the HRP or not."

What is glFinish's purpose and is the bad behavior when running HRP or when not running HRP? And by HRP do you mean any high res content? Normal and spec maps?

I ask because everything I do is Polymer with higher res content.

I did a google search for glFinish and while its a bit too technical for me to completely understand, I did read that it's use is desired by some and not by others and there are different opinions on how and when to use it. I'm sure you researched this function before including it.
Now I'm wondering what issue is being addressed by this command. Is the cure worse than the disease?

[LeoD]

Kudos to TerminX for fixing a number of issues right after I had added them to the new issue tracker!
Btw, #4 is already fixed as well.

[Danukem]

I could use some help.

In our upcoming overhaul of WGR, one of the boss fights usually causes a crash to desktop. It does this without entering anything to the log. So, naturally I try the debug version. Well, the debug version doesn't crash at all. So I don't know what to do about it except using the debug version. I periodically check non-debug versions when new revisions come out, but the crash persists.

EDIT: This is probably unrelated, but in recent revisions the log can be absolutely spammed with messages like this:

Quote

clipupdatesector():1023 shortest distance between origin point (78426, 19249) and sector 277 is 6608. Sector may be corrupt!
clipupdatesector():1023 shortest distance between origin point (78442, 19317) and sector 277 is 6540. Sector may be corrupt!
clipupdatesector():1023 shortest distance between origin point (78458, 19385) and sector 277 is 6471. Sector may be corrupt!
clipupdatesector():1023 shortest distance between origin point (78474, 19453) and sector 277 is 6404. Sector may be corrupt!
clipupdatesector():1023 shortest distance between origin point (78490, 19521) and sector 277 is 6336. Sector may be corrupt!

I have seen this across all mods and maps, and it's super annoying because it make it hard to search the log file for actual problems and casual users think they have found something important when they see that.

[TerminX]

When you get that spammed in your logs, it usually means you changed the coordinates for a sprite and forgot to update the sector number at the same time.

[Danukem]

 TerminX, on 21 April 2020 - 01:38 PM, said:

When you get that spammed in your logs, it usually means you changed the coordinates for a sprite and forgot to update the sector number at the same time.

Knowing that was useful in eliminating those log entries. However, the silent crash to desktop still happens in that boss fight even after those were eliminated. Can you think of a reason why there would be a silent crash to desktop that does not happen in a debug build?

[LeoD]

 Trooper Dan, on 21 April 2020 - 02:48 PM, said:

Knowing that was useful in eliminating those log entries. However, the silent crash to desktop still happens in that boss fight even after those were eliminated. Can you think of a reason why there would be a silent crash to desktop that does not happen in a debug build?

I can think of two three things:

- an unusual insecure C/C++ construct which the compiler doesn't know and therefore can't complain about
- a bug in one of the optimizing compiler routines enabled by the -O options
Trying out different optimizing options and/or different compiler versions might help narrowing down these cases

- some weird interactions with the OS or its drivers
Can the crash be reproduced on different computers?

[Danukem]

 LeoD, on 21 April 2020 - 03:18 PM, said:

Can the crash be reproduced on different computers?

The crash happens on different systems, yes. I'm still trying to narrow it down -- since it only happens in that boss fight, in theory I should be able to pinpoint what's triggering it, but because it does not generate a log entry and because it does not happen consistently, it will take a lot of testing.

[Danukem]

I'm 90% sure now that I have figured out what causes the silent crash to desktop. This isn't a formal report yet, but what I found is that the crashes went away when I stopping doing a certain thing.

in EVENT_ANIMATESPRITES, if you try settspr[THISACTOR].tsprcstat 32767 apparently this can cause the crash (but not always!)

I used that in WGR2 for enemies that had an invisibility aura -- rather than change their actual cstat which would make them unhittable, I would have them flash transparent and on random frames become completely invisible, all handled in EVENT_ANIMATESPRITES. But it seems that nowadays, making the t-sprites invisible in that event can cause a crash. It's like the renderer doesn't like being told not to render something it had already decided to render.

EDIT: It could also just be the wrong cstat value to be using, although it did make them invisible in the past

[TerminX]

32767 is the wrong value to be using; the bit that causes a sprite not to be drawn is 32768.

[Danukem]

 TerminX, on 22 April 2020 - 01:48 PM, said:

32767 is the wrong value to be using; the bit that causes a sprite not to be drawn is 32768.

But using settspr[THISACTOR].tsprcstat 32768 in EVENT_ANIMATESPRITES does not make the t-sprite invisible, it makes it appear to have cstat 0. EDIT: To quickly confirm this you can add "seta[].mdflags 16" to the APLAYER actor, and then use "settspr[].tsprcstat 32768" in ANIMATESPRITES, then check F7 mode and you will see that the player is solid, not transparent like normal.

That was why I had experimented with using 32767 back in 2009 when the code was written, and back then it worked. Now 32767 causes a silent crash. In fact, I can see no way of making t-sprites invisible in that event now. It's not a problem because I don't need full invisibility and we have .alpha now.

[TerminX]

Maybe 32767 worked because 16 and 32 on a tsprite at the same time mean that the picnum is treated as a voxel id. Either way, turning all bits on except for the one that actually controls invisibility is not a valid way to make a sprite invisible.

[LeoD]

 Jmoc, on 14 April 2020 - 01:18 PM, said:

It seems that the update from r7187 to r7238 introduced a bug that makes the game hangs when loading the map (e.g. E3L2) with DukePlus 2.40.

It crashes exactly at this error:
"Line 19803, espawnvar: invalid sector 4096"

Before r7238 such errors were handled correctly. Now, it just hangs. In debug I see that it hangs at the OSD method, trying to print to the log (which is truncated before the error could even be written).

There are a lot of commits between the two versions but I suspect r7195 is the commit to blame since the stack trace passes through a VM assertion before going to the OSD printer:
"Refine CON VM error handling behavior."

Game freeze confirmed and bisect-compiled to (as predicted) r7188-f9e26c5a6 / svn7195.
I have a feeling that the issue is related to DeeperThought's recent WGR problem.
Added to issue tracker.

[Micky C]

There are still cases of TROR causing HOM in both polymost and classic for absolutely no reason, when looking down through a TROR portal where the lower layer has multiple sectors. If you create multiple TROR portals, one for each sector, then the problem goes away, however this is both time-consuming and wall-consuming. I've explored different scenarios and can't find common trend between them besides the multiple sector thing. Is there some room for improvement here?

[Mark]

I noticed the wiki still mentions being able to look up/down during lockplayer. Since eduke32 has changed to no up/down looking, the wiki needs to be updated.

[Fox]

 Trooper Dan, on 22 April 2020 - 03:56 PM, said:

But using settspr[THISACTOR].tsprcstat 32768 in EVENT_ANIMATESPRITES does not make the t-sprite invisible, it makes it appear to have cstat 0. EDIT: To quickly confirm this you can add "seta[].mdflags 16" to the APLAYER actor, and then use "settspr[].tsprcstat 32768" in ANIMATESPRITES, then check F7 mode and you will see that the player is solid, not transparent like normal.

That was why I had experimented with using 32767 back in 2009 when the code was written, and back then it worked. Now 32767 causes a silent crash. In fact, I can see no way of making t-sprites invisible in that event now. It's not a problem because I don't need full invisibility and we have .alpha now.

Cstat 32768 prevents a sprite from being rendered, meaning it skips the animatesprites event. Likewise, cstat 32768 won't work inside of animatesprites because it's too late.

The original source code set xrepeat to zero in animatesprites to hide some sprites (i.e. adult content).

If you set cstat 32767, you are using almost all bits available, including values that may be used in the future... so expect nasty bugs.

[Hendricks266]

I enabled synthesis builds for VoidSW.

Extract http://hendricks266....x_widescreen.7z to use Jimmy's widescreen tiles.

[Radar]

Will they show up here next time there is an autobuild?

https://dukeworld.co...ynthesis/latest

[Hendricks266]

They are already there inside the 7z files.

[The Battlelord]

 Hendricks266, on 21 May 2020 - 08:08 AM, said:

They are already there inside the 7z files.

Thanks Thanks and Thanks!!!May i ask if does change anything from the old GRP ('97) and the Redux one? The weight looks the same, just asking to be sure.

[enderandrew]

 RADAЯ, on 21 May 2020 - 04:24 AM, said:

Will they show up here next time there is an autobuild?

https://dukeworld.co...ynthesis/latest

What is the recommended way to use the SW HRP pack with VoidSW?

[Radar]

 enderandrew, on 21 May 2020 - 08:43 PM, said:

What is the recommended way to use the SW HRP pack with VoidSW?

The recommended usage is not using it. I'm not being facetious. These are effectively abandoned projects.

[enderandrew]

 RADAЯ, on 21 May 2020 - 09:18 PM, said:

The recommended usage is not using it. I'm not being facetious. These are effectively abandoned projects.

Wouldn't it make sense to just include some of the new upscales in the HRP?

[Mark]

If its easy to drop the HRP in there, give it a try. With 100's of new textures I wouldn't dismiss it before even trying it. That said, there is a whole lot not yet remade so including it would be wrong.

[Radar]

 enderandrew, on 22 May 2020 - 10:29 AM, said:

Wouldn't it make sense to just include some of the new upscales in the HRP?

It would make the most sense to just use the upscales on their own for consistency.

[Hendricks266]

 enderandrew, on 21 May 2020 - 08:43 PM, said:

What is the recommended way to use the SW HRP pack with VoidSW?

I would recommend checking out the sw_hrp svn repository as a subfolder to your VoidSW folder and launching the exe with -jsw_hrp. You probably want to add your own sw.def to the root folder to include sw-widescreen.def and highres/sw_hrp.def. Or, you can use the -mh command line parameter to load individual def files in succession.