[Mark]

nope

[Definitely Not Robman]

Great Job!

F11 for brightness didn't function in the previous iteration either.
It would be recommended to have the key defaults be the same as the defaults in the original.

[Darkus]

I did more extensive testing, here's what I found:

- Some of the console commands are missing (map, exit/quit, god, map...), and some have no effects (r_maxfps). I'll have to use the normal cheat codes instead. For example, SWLOC to display the FPS counter.

- Screen flashes are not working as expected. For example, when you're blinded, the screen turns completely white for some seconds. In the classic render, it's just barely white, but you can still see around. In OpenGL, it turns white, but for a shorter period.

- I also got one crash to desktop, but there was nothing in the log, like a normal exit. Happened when I was surrounded by enemies (especially shadow ninjas), I pressed a lot of keys in panic, and poof...

- Seeing medikits from a different ROR level cause them to turn into a flat tile 0 (Classic render only):

https://i.postimg.cc/kGK3GY0D/Void-SW-bug1.png


- Because the engine handle differently one-sided flat voxel sprites from the original game, some keycards (tested in level 16) don't appear when looking at them from a certain angle (you can still pick it up, it's just invisible):

https://i.postimg.cc/V6ScQk4q/Void-SW-bug2.png

Once looking from a certain angle (seen from the front), it becomes visible:

https://i.postimg.cc/26PNzNXP/Void-SW-bug3.png

[Jimmy]

Seems to work pretty good. I am having a small issue though, when I apply the widescreen fixes, all of the weapons work, but the main menu and the HUD do not. Whats up with that? Also did some minimal testing with Wanton Destruction and Twin Dragon and it seems to run them just as well.

[Darkus]

The tiles are not defined correctly, this should work:

// HUD Title Screen (2324) (widescreen extension by Hendricks266)
tilefromtexture 2324 { file "sw-tiles/9400.png" }

// HUD Status Bar (2434)
tilefromtexture 2434 { file "sw-tiles/9401.png" }

EDIT: Err, not really, the tiles are now aligned to the left side of the screen, and xoffset does nothing...

[NightFright]

Are the two expansions (Twin Dragon and Wanton Destruction) already fully supported? I see they are already recognized if you place the grp files in the VoidSW directory.

[Searinox Navras]

NightFright, on 25 May 2020 - 03:25 AM, said:

Are the two expansions (Twin Dragon and Wanton Destruction) already fully supported? I see they are already recognized if you place the grp files in the VoidSW directory.

I played through a few levels of the two expansions and never had any problem. Just a word of warning the game keeps all its saves available in the menu and if you load a save file that was created playing with a different expansion, textures and enemies will be replaced or missing.

[Hendricks266]

Darkus, on 24 May 2020 - 12:20 PM, said:

I did more extensive testing, here's what I found:

Thanks for the detailed reports.

Darkus, on 24 May 2020 - 02:33 PM, said:

The tiles are not defined correctly

No, this statement is wrong. Redefining those tiles over their original number is what is wrong. General Arcade knew this.

https://i.imgur.com/PCBfKCk.png

WangGDX fell for the trap:

https://i.imgur.com/t2nJsb5.jpg

I haven't implemented support for using the 9000-range tilenums because I'm unsure if I want to hardcode anything using tiles up there.

NightFright, on 25 May 2020 - 03:25 AM, said:

Are the two expansions (Twin Dragon and Wanton Destruction) already fully supported? I see they are already recognized if you place the grp files in the VoidSW directory.

Yes.

[Radar]

Is a mini HUD planned?

[Ninjakitty]

jumping seems to cause a tiny bit of jitteriness. If you turn to the right or left slowly while jumping around moving forwards, it violently jerks back for a frame. Although this is only barely noticable because the game usually runs really well ;)

[axl]

Ninjakitty, on 25 May 2020 - 09:29 PM, said:

jumping seems to cause a tiny bit of jitteriness. If you turn to the right or left slowly while jumping around moving forwards, it violently jerks back for a frame. Although this is only barely noticable because the game usually runs really well ;)

Indeed. Mouselook is very smooth when standing still. However when moving, strafing or jumping, it seems to stutter a bit. I don't experience this issue with EDuke32, NBlood or RedNukem.

[icecoldduke]

If anyone is experiencing sluggish gameplay/movement/input, and you have a 144hz or higher monitor, with PolymerVK, users have reported smoother gameplay/movement/input with Vulkan compared to OpenGL.

[Phredreeke]

How I wish I could have only 144 FPS ;)

[icecoldduke]

Phredreeke, on 28 May 2020 - 06:41 AM, said:

How I wish I could have only 144 FPS ;)

I'm not talking about FPS, i'm talking about the refresh rate of your monitor. If your monitor is only 60hz PolymerVK won't make your gameplay smoother, but if you have a 144hz monitor, then you'll notice the gameplay a lot smoother compared to Polymost.

[Radar]

How?

[icecoldduke]

R A D A Я, on 28 May 2020 - 07:03 AM, said:

How?

With Vulkan we control how gpu command buffers are submitted to the GPU, and when we stall the main thread if the GPU is behind the CPU. With OpenGL your at the whim of the driver, which becomes a more noticeable bottleneck at higher refresh rates, not to be confused with higher framerate, I'm talking about higher refresh rate monitors.

[Radar]

So I just completed episode 1, and I think I'm going to stop here until the next major update. I've been waiting until VoidSW's release to play the entire game again including the 2 expansions. The only thing preventing me from continuing is the lack of an EDuke32-style mini HUD. The current HUD doesn't display detailed info like keycards and such. And the full status bar takes up almost a quarter of the screen. I'll wait until an alternate HUD is available.

[Definitely Not Robman]

This thread needs more pomp.

[Mark]

Here's the pomp.

Attached thumbnail(s)

• 

[NY00123]

Hey,

Ninjakitty, on 25 May 2020 - 09:29 PM, said:

jumping seems to cause a tiny bit of jitteriness. If you turn to the right or left slowly while jumping around moving forwards, it violently jerks back for a frame. Although this is only barely noticable because the game usually runs really well :)

I think that the possible bit of horizontal jitter reproduced upon beginning to jump or landing on ground, all while concurrently turning left or right, is resolved.

[Ninjakitty]

NY00123, on 08 June 2020 - 12:32 PM, said:

I think that the possible bit of horizontal jitter reproduced upon beginning to jump or landing on ground, all while concurrently turning left or right, is resolved.

I think it is too, now it's smooth as hecc! I rike dat! :)

[Darkus]

Found another case of a sprite voxel not displayed correctly (like I said above), this time it's the nuke sprite in level 20 (I'll stop mentioning them, there are probably many others):

https://i.postimg.cc/KYmBDHwV/Void-SW-bug4.png


Since I use the debug builds, I didn't get any crashes, except this one: enabling kid mode crashes VoidSW when a censored tile is displayed:

https://i.postimg.cc/cLRfYS9w/Void-SW-assert1.png

[filipetolhuizen]

It's working great so far. The only thing I noticed was simultaneous sounds failing sometimes. A Vsync option in the menu would be nice as well (these build ports quickly overheated some of my cards in the past without vsync). Never noticed any visual glitches so far.

[bullbob]

So am noticing an issue that might be incorrect scripting or something. At the very start of the game, theres a bus that crashes into a car at the end of the street and turns around until its linked up behind the car it hit in a straight line. sometimes though, this animation plays out wrong and the bus just ends up perpendicular with the other car instead. i'm not sure if this is possibly a sign of bigger problems with the source port, but theres a number of areas in this game where stuff needs to move in a scripted fashion. not sure if there will be trouble further in the game

also is there any way to disable/enable vsync or cap the framerate like you can in eduke32? would be nice for the options menu to have the option. maybe it does now, idk. the build i was last using was from the end of last week

[Lunick]

It's unlikely but the bus doing that actually happens in the DOS version too

[RPD Guy]

Finally! Now the blood pools are standing above the ground! Haven't seen this for a while... :)

[RPD Guy]

Lunick, on 14 June 2020 - 05:19 PM, said:

It's unlikely but the bus doing that actually happens in the DOS version too

Indeed

[bullbob]

Lunick, on 14 June 2020 - 05:19 PM, said:

It's unlikely but the bus doing that actually happens in the DOS version too

interesting. though it seems like a 1 in 3 chance or so with voidsw

[ReaperAA]

Somebody reported a bug on Zdoom forums which is probably present in both VoidSW/Raze and it seems to be vanilla SW bug (I haven't personally tested this bug yet).

Quote

Basically, in SW (as in, even the original DOS version to my knowledge), it is possible to trigger a sequence break by simply saving and reloading after killing a boss once its health bar vanishes and before the cutscene/end level stats screen appears. This can be reliably triggered with any of the 3 main bosses, if you reload such a save the game will not proceed any further, leaving the player stuck on the map until they either restart it or warp to a new level. Fixing this major softlock issue would be a great QoL improvement to add to the list.

That being said, not sure if this is best done here or better saved for upstream though.

Graf Zahl told to report it here as well, so I decided to post this here.

[NY00123]

I'm updating that mmulti, a Build Engine component in use for VoidSW multiplayer games, has been reverted to an older revision.
Reason is that Striker had some problems with using the newer revision in EDuke32-OldMP.

IPv6 support is lost, while, at least in theory, Windows XP support is resurrected.

A side-effect of this is that the command-line syntax for starting up a Peer-2-Peer game is now reverted to what's there in EDuke32-OldMP and older versions of JFDuke3D and JFSW.
2-players example:

Player 0: voidsw -net -n1 <player1Addr>
Player 1: voidsw -net <player0Addr> -n1

It's still not ideal, but at least the option is there.

ReaperAA, on 09 July 2020 - 07:39 AM, said:

Somebody reported a bug on Zdoom forums which is probably present in both VoidSW/Raze and it seems to be vanilla SW bug (I haven't personally tested this bug yet).



Graf Zahl told to report it here as well, so I decided to post this here.

Thanks for bringing the attention, I've hopefully taken care of the problem. I've also responded in the ZDoom thread.