[OVERLORD]

Do you guys consider to implement 9400.png (Background widescreen cover) and 9401.png (Widescreen Hud) into capabilities of VoidSW in order to make it to support it properly?

Because when we install widescreen HUD for example it moves to the right side of the screen.

That would be amazing to have it implemented.

Best regards.

[Hendricks266]

I don't like the use of those two tile numbers. It makes sense that they're above the (iirc) 6144 tile limit of the original game to avoid conflicts with OG mods but they're floating in the middle of a range which is not very pretty and could be an annoyance in the future. I would prefer a more robust solution that would also work for other games with the same problems, such as some way to define a widescreen extension over an original tile that only shows up in the menus and not in the game world.

[OVERLORD]

Hendricks266, on 26 August 2020 - 07:59 AM, said:

I don't like the use of those two tile numbers. It makes sense that they're above the (iirc) 6144 tile limit of the original game to avoid conflicts with OG mods but they're floating in the middle of a range which is not very pretty and could be an annoyance in the future. I would prefer a more robust solution that would also work for other games with the same problems, such as some way to define a widescreen extension over an original tile that only shows up in the menus and not in the game world.

What in your opinion may cause that strange behavior of those two tiles?

For instance when I replace original tile (Status Bar HUD) with widescreen status bar HUD - half of it is invisible and goes beyond the screen, to the right.

Same for widescreen background cover (in menu). But the widescreen background cover is not that necessary. It's not really needed.

Widescreen status bar HUD would be nice to see. It's like widescreen HUD made by Fox for Duke Nukem 3D.

[Ninjakitty]

r_shadeinterpolate is not saved for some reason. I like to keep it off but it won't stay off.

[Phredreeke]

Lots of CVARs aren't saved AFAIK

[Searinox Navras]

The config operates similarly to how it did in the Classic Redux in that it doesn't save more than button config and menu options. In addition there is no support for autoexec.cfg in order to manually set these.

[OVERLORD]

Here is another bug.

VoidSW.exe does not detect SW.RTS and therefore it is impossible to play Remote Ridicule lines of Lo wang by pressing ALT+F1 through ALT+F10.

Even if you pack SW.RTS into .zip and use the following command line:

"Start VoidSW.exe -gSW_RTS_File.zip"

Nothing happens there. It needs to be fixed.

Meantime in SWP v4.3.0 everything works as inteded - SW.rts file is detected automatically and picked up by source port.

===================================================================================================

The second thing I would like to request is a fix to be implemented which would allow widescreen hud (new 2434.png) to be correctly rendered and not sliding to the right side off the screen.

I took 9401.png and renamed it to 2434.png and used coresponding "tile from texture" line and replaced 9401.png with 2434.png.

In-game, hovewer, widescreen hud slided to the right side, off the screen. It is essential to make it functional like widescreen HUD in Duke Nukem 3D,
which installs perfectly in the same way to EDuke32.

Here is the code from sw-widescreen.def

HUD Status Bar (2434)

tilefromtexture 2434 (was 9401) { file "sw-widescreen/2434.png" }

See 9401.png attached.

Attached thumbnail(s)

• 

[Phredreeke]

You may need to add X offset to the definition.

[OVERLORD]

Phredreeke, on 09 September 2020 - 06:08 AM, said:

You may need to add X offset to the definition.

If I remember correctly it does not solve the problem.

X offset is just ignored by the source port regarding this particular tile.

Just checked again - X offset is definetely ignored.

[Hendricks266]

If I remember correctly, SW's remote ridicule is only active in multiplayer, not in singleplayer like it is in Duke. [EDIT: Or maybe that was Blood.]

[OVERLORD]

Hendricks266, on 09 September 2020 - 10:41 AM, said:

If I remember correctly, SW's remote ridicule is only active in multiplayer, not in singleplayer like it is in Duke.

In SWP it is active in singleplayer, I checked it.
So I think it works the same way as in Duke Nukem 3D.

I suppose It will work if VoidSW starts to recognize SW.rts file.

VoidSW does not pick up SW.rts file at all.


It should do it like SWP does:

============================================

SWP - Version 4.3.0 - Revision 331.128
By ProAsm - http://www.proasm.com
Detected registered Grp
Adding Group file: sw.grp
Adding Group file: SWP.grp
Commandline: SWP.exe -gSW.grp -gSWP.grp -gSWCustom.zip
Adding Group file: SW.GRP
Adding Custom RTS: SW.rts
Adding Group file: SWP.GRP
Adding Group file: SWCustom.zip
Initialising DirectInput...

============================================

[Jimmy]

SWP isn't accurate to many of the original game behaviours. If you want to test if its supposed to work in singleplayer, you're gonna have to crack open DOSBox or something.

[Hendricks266]

Yeah, please don't compare VoidSW to mods or other ports when determining the baseline correct behavior. VoidSW still has the original behavior, where no message is printed if no RTS is loaded, and if the RTS is not present, it prints "RTS file sw.rts was not found". You should also check in DOSBox whether the RTS is active in single player. Be sure to test Duke 3D in DOSBox too because sometimes there are issues with getting Alt+FunctionKey combinations to work.

[comorbidity]

(nsfw)
*cough*

[OVERLORD]

So I downloaded Shadow Warrior Complete for GOG, this edition comes only with DOSBox as launcher. Checked original game and it's 2 expansions by pressing ALT+F1 through ALT+F10. It doesn't not work in singleplayer, nothing happens at all. Now I confirm it. So I think Hendricks was just right when mentioned that it supposed to work only in multiplayer and not in singleplayer. It would be fun to have it in singleplayer either, but as from purity pov it is unnecessary.

Here is another bug.

Twin Dragon Expansion.

After killing Hung Lo, there is custcene being played and when it's done an intermission screen which follows after becomes innormally bright and when you skip it - menu becomes overbrightened either. You have to reload VoidSW to get rid of that excessive brightness. That's the only option.

There is definitely something to investigate.


P.S. For some reason, just as it was in SWP, brightness slider dies nothing in software mode.

[Putrid Pete]

OVERLORD, on 10 September 2020 - 03:43 PM, said:

After killing Hung Lo, there is custcene being played and when it's done an intermission screen which follows after becomes innormally bright and when you skip it - menu becomes overbrightened either. You have to reload VoidSW to get rid of that excessive brightness. That's the only option.

I can confirm this bug and it actually happens to me after every cinematic, including during the main game. I actually took a screenshot of it here:

Spoiler

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

Also Lo Wang's rap wasn't playing the last time I got through the game, but I have no idea if that's been sorted out since that was a while ago.

[MetHy]

I've been playing VoidSW r9257-93f62bbad

Great stuff overall, feels pretty good to finally play this game with smooth mouse aiming.

Couple of glitches I found:

1) some sprites/voxels turn to tile#0 when viewed through the RoR portal. I've only found 2 examples so far and I've been unable to pinpoint the exact cause as of yet:

- in $HIDTEMP.MAP, you can see this tile from the upper floor. The sprite is actually an ST1 so there should be nothing visible, and there is nothing visible on the lower floor

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

- in $BATH.MAP these 2 medkits turn into tile#0 when viewed from the upper floor:

https://i.imgur.com/7X4hBVf.png
https://i.imgur.com/Uw7SdWy.png

2) In $SUBBASE.MAP this keycard voxel can only be seen from the back. It is worth noting that the keycard sprite is one-sided so this is also a mapping issue, however the original SW behaviour is that voxels are not affected by the one-sided bit as the keycard voxel can be seen from all sides in the original game:

https://i.imgur.com/twRB303.png
https://i.imgur.com/wZcQUa1.png

Also I hope you can implement the underwater fullrange palette soon.

Edit: I'm sorry I missed that both these things were already reported in page 1, though I have some extra details. Also joined are some savefiles for the RoR glitch. Also launching $bath.map again and noclipping straight to the upper floor of the pool didn't turn the medkits into tile#0, so it appears that something triggers the switch along the normal way

Edit: here is another example of the RoR sprite glitch in $volcano.map, this time with an atomic missile:

https://i.imgur.com/WpFaroZ.png
https://i.imgur.com/cTdc1ex.png

I have also found a rendering glitch with this switch showing up through this poster (I had no idea there was a secret place there!). I believe this switch isn't supposed to be seen as it is behind the poster and pressing use on the poster (on the switch) opens the secret:
https://i.imgur.com/u4Ve2iP.png

This rendering issue only happens in 8-bit and happens regardless of voxels being turned on. I have included a savefile for this one as well in the attached rar.

Attached File(s)

•  RoR_Renderglitches.rar (483.08K)
  Number of downloads: 3

[jkas789]

MetHy, on 26 September 2020 - 05:03 AM, said:

Couple of glitches I found:

1) some sprites/voxels turn to tile#0 when viewed through the RoR portal

Sorry for the question mate but what is an Ror Portal?

[Jimmy]

Room-Over-Room, like the pool in the first level. Any time two different sectors are connected by the game engine but not "physically" so to speak to give a more 3D effect. Duke3D didn't have a functional version of this feature (now EDuke32 does) but Blood and Shadow Warrior did.

[jkas789]

Oh now I get it! Thanks Jimmy. :)

[Phredreeke]

There's something like six or so different implementations of ROR in Build. Including one that was discovered as recently as last year in Duke3D 1.5 (which was later used in Redneck Rampage Rides Again)

[Jimmy]

Yeah, I think it was deactivated or buggy in the DOS version. I believe Icculus' port uses that code if I remember right.

[Ninjakitty]

I've noticed some issues with sound:

For some reason music isn't playing on saved games I load from the main menu. If I load a save while on a level with music then it works, but not loading it from the main menu.
Also I'm noticing a difference in sound vs music volume in DOS SW compared to VoidSW. In VoidSW the sounds are much louder and in most cases overpower the music (or maybe the music is just much weaker than the sound), whereas in DOS neither the music or the sound usually cancels out the other (tested this with music and sound set to max on both DOS and Void)
And lastly, sounds still cut off very frequently for me. It's usually one sound cutting out for another, but barely any sounds are happening so I don't think it could have hit the max sounds at one time, and DOS cuts out way less.

Here's an affected save: https://www.dropbox..../game3.sav?dl=0

[MetHy]

MetHy, on 26 September 2020 - 05:03 AM, said:

Couple of glitches I found:

1) some sprites/voxels turn to tile#0 when viewed through the RoR portal. I've only found 2 examples so far and I've been unable to pinpoint the exact cause as of yet:

- in $HIDTEMP.MAP, you can see this tile from the upper floor. The sprite is actually an ST1 so there should be nothing visible, and there is nothing visible on the lower floor

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

- in $BATH.MAP these 2 medkits turn into tile#0 when viewed from the upper floor:

https://i.imgur.com/7X4hBVf.png
https://i.imgur.com/Uw7SdWy.png

Don't know if this helps but I just noticed something else about this: the glithy sprites pick up light fx from the other floor. Example: lower floor has the sprite and no flickering light, and the upper floor has a flickering light. When viewed through the portal from the upper floor: the sprite will turn to another tile and be affected by the flickering light.
It also seems that only effect sprites and pick-up sprites are affected by this whole thing, as purely decorative sprites will not turn to another tile and won't pick up the flickering light.

[MetHy]

MetHy, on 26 September 2020 - 05:03 AM, said:

2) In $SUBBASE.MAP this keycard voxel can only be seen from the back. It is worth noting that the keycard sprite is one-sided so this is also a mapping issue, however the original SW behaviour is that voxels are not affected by the one-sided bit as the keycard voxel can be seen from all sides in the original game:

The exact same issue also happens in Twin Dragon's Crazy Train and I think this one is even more nasty

Dos:
https://i.imgur.com/39aiCu1.png

Voidsw:
https://i.imgur.com/fou2qpr.png