[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.

[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 :P

[icecoldduke]

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

How I wish I could have only 144 FPS :P

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.

[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.

[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! :lol:

[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... :lol:

[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.

[Hendricks266]

Definitely Not Robman, on 24 May 2020 - 07:38 AM, said:

It would be recommended to have the key defaults be the same as the defaults in the original.

You are the only person on earth who would make such an asinine request.

[Martin Howe]

Regarding MIDI music, for the shareware part of the game, VoidSW does play it but seems to only want to do OPL emulation; changing MusicDevice seems to have no effect. It doesn't sound at all like the original music much. With EDuke32 I cheat and use Raze's soundfont as eduke32.sf2 but VoidSW doesn't seem to recognise that as voidsw.sf2.

Am I to assume that due to the prevalence of people using the OST from Steam/GOG (or ripped from a genuine original SW CD LOL), there is no support for any other form of MIDI playback? If there is such support, how can I enable it, please?

[Morpheus Kitami]

Is there some option I'm missing when building from source? I can only get it to build EDuke, not VoidSW. It doesn't register my SW files as existing.

[LeoD]

Morpheus Kitami, on 26 July 2020 - 08:03 AM, said:

Is there some option I'm missing when building from source? I can only get it to build EDuke, not VoidSW. It doesn't register my SW files as existing.

make[.exe] voidsw[.exe]

[Martin Howe]

Morpheus Kitami, on 26 July 2020 - 08:03 AM, said:

Is there some option I'm missing when building from source? I can only get it to build EDuke, not VoidSW. It doesn't register my SW files as existing.

On Linux, the target for VoidSW is "sw", I built it yesterday. ( Didn't think the target would be different on Windows, but since I won't pollute my PC with that, I cant' say :P )

[LeoD]

Martin Howe, on 27 July 2020 - 02:15 PM, said:

On Linux, the target for VoidSW is "sw", I built it yesterday. ( Didn't think the target would be different on Windows, but since I won't pollute my PC with that, I cant' say :P )

Works on Windows/MSYS2/MinGW, too. Builds both game and editor executables. The latter (Wangulator) is mostly unusable, though.

[Morpheus Kitami]

Works fine, but doesn't build the editor for some reason. If it is unusable I don't see much point in trying for it. Thanks.