Strife: Veteran Edition for Nintendo Switch now available (Widescreen update)

Great news! A big "Thank You" to everyone involved. :)

Fight for the Front and freedom!

The prices are now in. It'll be 10 bux, plus we'll have a 25% discount on launch. 

On 10/20/2020 at 9:20 AM, Edward850 said:

In addition, the Windows versions on Steam and GOG will be finally updated to use SDL2

What about the Linux versions?

1 hour ago, Marisa Kirisame said:

What about the Linux versions?

We need to fix up the build manager for that with Steams chroot requirements and GOGs nonexistent build environment (they still don't have Galaxy support on Linux, it's maddening) among other things. It's not pretty. As such while it'll happen, I just can't predict a timeline on it. 

On 10/20/2020 at 3:20 AM, Edward850 said:

Greetings sportsStrife fans. The release date of Strife:VE on Switch is finally locked in, the 25th. Yes that's the end of this week! Weird release date I know but that's how we roll.

 

The eShop pages should be available on that day (I've checked, they presently aren't deployed) so I'll update this page with links then, though you'll just be able to search "Strife" on the Switch and it'll pop up just the same.

Nothing super fancy but you'll get an updated weapon selection method (because cycling through the 11 guns with weird alt-weapon rules was extremely not ideal) and gyroscope support.

 

In addition, the Windows versions on Steam and GOG will be finally updated to use SDL2 with various other minor additions (the menu sliders now reveal numbers!). This will of course come with a source release.

Special thanks to @fraggle as always, @Altazimuth for assisting me in the SDL2 updates, and MVG for figuring out how to run the OpenGL1.5 core profile on Switch allowing to make this port possible at all.

You're finally releasing the game on consoles? Can't wait for the Xbox One version.

5 hours ago, The Strife Commando said:

You're finally releasing the game on consoles? Can't wait for the Xbox One version.

Hold your horses there, we currently have no plans for any other consoles. A Switch port was only done because we didn't have to change any of the rendering code, Xbox One and PS4 don't support OpenGL, let alone 1.5, and thus would be a significant amount of work that at the moment we can't currently invest in its code. 

8 hours ago, Edward850 said:

Hold your horses there, we currently have no plans for any other consoles. A Switch port was only done because we didn't have to change any of the rendering code, Xbox One and PS4 don't support OpenGL, let alone 1.5, and thus would be a significant amount of work that at the moment we can't currently invest in its code. 

How do they not have OpenGL?

2 minutes ago, The Strife Commando said:

How do they not have OpenGL?

They just don't. Microsoft of course design the Xbox hardware and APIs around DirectX, and the PlayStation is whatever Sony does. Heck the Switch probably only has OpenGL because at heart the hardware is the Nvidia Shield TV with its Tegra hardware and drivers and Nintendo had no business in changing any of that if they didn't need to.

I see. Well a shame Strife won't come to the Xbox.

15 hours ago, Edward850 said:

Hold your horses there, we currently have no plans for any other consoles. A Switch port was only done because we didn't have to change any of the rendering code, Xbox One and PS4 don't support OpenGL, let alone 1.5, and thus would be a significant amount of work that at the moment we can't currently invest in its code. 

PS4 actually does support OpenGL ES 2.0 (So atleast you could get OGL 1.5 equivalence, i suppose?) called Piglet and PS3 had a OpenGL derivative, called PSGL. It was essentially GLES 1.x with a lot of custom stuff bolted on top of it. In the end devs hardly used it because it was a lot slower than the native API, GCM.

6 hours ago, The Strife Commando said:

How do they not have OpenGL?

Because consoles tend to use custom API's that enable extreme low level access to the hardware.

8 hours ago, Redneckerz said:

PS4 actually does support OpenGL ES 2.0 (So atleast you could get OGL 1.5 equivalence, i suppose?) called Piglet

You'd think so, but that's homebrew which is of no help to us when we need to use the official SDKs. We do official ports that are sold on official stores, not hacker projects. 

1 hour ago, Edward850 said:

You'd think so, but that's homebrew which is of no help to us when we need to use the official SDKs. We do official ports that are sold on official stores, not hacker projects. 

Was it not part of an official SDK somewhere down the drain?  and if not, could the high level GNMX not achieve similar in a relative time span?

18 minutes ago, Redneckerz said:

Was it not part of an official SDK somewhere down the drain?  and if not, could the high level GNMX not achieve similar in a relative time span?

I shouldn't get into that kind of detail because of NDAs. Also the entire point is that we don't presently have the resources to rewrite the renderer, so GNMX cannot be the answer to that problem by default, because that would be rewriting the renderer. 

Hopefully everything goes well.

Super cool- so many things are coming to the Switch these days. I'll definitely grab this to show some support.

1 hour ago, Edward850 said:

I shouldn't get into that kind of detail because of NDAs. Also the entire point is that we don't presently have the resources to rewrite the renderer, so GNMX cannot be the answer to that problem by default, because that would be rewriting the renderer. 

Understandable.

Outside of this, i definitely would love to know some slides on how the tech was ported over from PC to Switch, what kind of troubles you ran into, what element of the code provided the most strain for the system, what, if any, optimizations were persued and implemented, and so on.

47 minutes ago, Redneckerz said:

Outside of this, i definitely would love to know some slides on how the tech was ported over from PC to Switch, what kind of troubles you ran into, what element of the code provided the most strain for the system, what, if any, optimizations were persued and implemented, and so on.

There's honestly not much, if at all. The only real troubles was with getting it to compile on Clang (the behaviour of double float to unsinged int conversion are implementation specific when the value isn't in range, this turned out to be a one line change to fix the rendering). The only other stuff was optimising storage writes for save files. The source code will be up tomorrow so you'll be able to review the differences, everything missing will just be Switch SDK specific implementations, and everything else is left to SDL2.

Two minor issues and a couple feature requests:

• The graphic indicating the button to press to open the menu is a little confusing, displaying "+ - MENU" since the Switch has both a - and a + button, I pressed the - button first just because it was convenient for my finger, didn't work. The hyphen might be better removed from these displays.
• The description for the crosshair option has redundant text on the Switch version. Since the high-quality renderer is the only one available and software rendering can't be used, part of the description doesn't really apply on the console.
• Options to revert all settings to defaults, not just controls, would be appreciated, especially for gameplay options.
• The ability to delete saves in-game on the console would be great. I've never been bothered by it on the PC since it's easy to delete the save folders, but on console, it's all or nothing.

Steam and GOG builds updated for Windows: https://steamcommunity.com/games/317040/announcements/detail/2959387848758571146

Switch version is now released: https://www.nintendo.com/games/detail/strife-veteran-edition-switch/

Source code: https://github.com/NightDive-Studio/strife-ve

Does this version work, or still have an ungodly amount of issues causing games breaks and soft locks?
I remember distinctly reporting the bugs and game breaks I found, but they took it as a personal, client-side issue... thing is hundreds of others had the same problems as I. That was years ago however- has there been any complete fixes since then? Or has it dropped-dead... much like Fresh Supply?

42 minutes ago, Zillah said:

Does this version work, or still have an ungodly amount of issues causing games breaks and soft locks?
I remember distinctly reporting the bugs and game breaks I found, but they took it as a personal, client-side issue... thing is hundreds of others had the same problems as I. That was years ago however- has there been any complete fixes since then? Or has it dropped-dead... much like Fresh Supply?

Huh!?

Not only has this version and patch only just come out yesterday, we have certainly never received any such reports to the degree that you are apparently claiming. I think you might have the wrong game?

Also if you want to argue soft locks in Strife you'll have to do that with @Quasar, he made absolutely sure no scripted soft locks couldn't occur in the enhanced mode and to my knowledge it was successful, nobody has ever reported one.

This obviously doesn't include GZDoom, which because it changes the physics actually can introduce a few weird issues. Those couldn't have any less to do with us, however.

Classic Mode should be the only way that "soft locks" can occur, by the original game's design. SVE has always, by default, removed them.

5 hours ago, Edward850 said:

Huh!?

Not only has this version and patch only just come out yesterday, we have certainly never received any such reports to the degree that you are apparently claiming. I think you might have the wrong game?

 

Also if you want to argue soft locks in Strife you'll have to do that with @Quasar, he made absolutely sure no scripted soft locks couldn't occur in the enhanced mode and to my knowledge it was successful, nobody has ever reported one.

This obviously doesn't include GZDoom, which because it changes the physics actually can introduce a few weird issues. Those couldn't have any less to do with us, however.

Hmm?
I reported several bugs/softlocks but I got either a shoulder shrug, or no response at all. If my memory serves me right, several others had the same issues, but they reported them on the Steam discussion page instead. That must've been maybe... 2 years ago? I refunded the veteran edition because it became unplayable and I went back to Dos to see if I was crazy, but nope.

But it has been some time, so I'd hate to imagine it's the same.
I'll do you a solid. When I get the chance I'll re-buy the game and give it another shot.
Who/where would I go to report any other bugs I find?

31 minutes ago, Zillah said:

Who/where would I go to report any other bugs I find?

Just report them here if anything, we deliberately don't go to the Steam forums for bug reports because a lot of times bugs get misrepresented and we tired of dealing with that place (if I see one more person complain that they can't fire exactly 90 degrees up, it'll be far too soon). Though I strongly suspect this is a misunderstanding or the mandela effect in play, as Strife is extremely well researched at this point and we don't know of any soft-locks that occur within the vanilla engine outside of the ones that occur in classic mode. Also, more to the point, this is a complete disassembly of the DOS engine and is the "vanilla" engine, lacking only demo compat because Strife doesn't actually have demo compat due to the dialogues. Finding new soft-locks that somehow don't crop up in DOS is extremely suspect in itself.

Or to put it more straightforward, this is Chocolate Strife but with a different renderer stapled on and some bugs fixed (by default). I'm just as dubious of such a claim as anyone would be over a new soft-lock being discovered only in Chocolate Doom or the Unity port, the notion is very improbable.

6 hours ago, Zillah said:

Does this version work, or still have an ungodly amount of issues causing games breaks and soft locks?
I remember distinctly reporting the bugs and game breaks I found, but they took it as a personal, client-side issue... thing is hundreds of others had the same problems as I. That was years ago however- has there been any complete fixes since then? Or has it dropped-dead... much like Fresh Supply?

The hostility of this response reminds me of that comment Kaiser got when posting the differences between the Doom 64 rerelease and EX, and someone basically jumped at him saying "REEEEEE the pirated version allows for freelook and jumping and therefore is superior, I won't pay you a cent because you're having the nerve to charge for your work now, and I demand free stuff". But I digress.

1 hour ago, Edward850 said:

Just report them here if anything

About this, not that I myself have found any bugs that aren't also found in the DOS version, but I saw a video a while ago where some guy mentioned a game-breaking glitch with the saved games. Never encountered this myself, though:

4 minutes ago, hfc2x said:

a game-breaking glitch with the saved games

Basically an oversight with the way you are allowed to overwrite save slots. Problems may occur if the old save game included maps that weren't yet visited on the current game's progression paths. Neither Chocolate Strife and SVE do not exhibit this bug.

https://doomwiki.org/wiki/Overwriting_a_Strife_save_game_can_cause_invalid_game_state

14 minutes ago, hfc2x said:

About this, not that I myself have found any bugs that aren't also found in the DOS version, but I saw a video a while ago where some guy mentioned a game-breaking glitch with the saved games. Never encountered this myself, though:

First I'm hearing let alone seeing such a thing. Looks like their player_t object got reset somehow, and the fact that it carried information over suggests the save file itself isn't rebuilding the table, but I couldn't even give a hypothesis without some kind of consistent reproduction, let alone that fact that I'm missing any kind of surrounding information like what the situation was in that save he loaded it later. This is by all accounts a unique (as in rarity) issue, assuming it's even a bug in the save game and not some kind of disk write issue on his own behalf. Didn't even reproduce anything like it while hammering the save system in the Switch port, and that has saves being swapped between two partitions (NAND and a RAM disk).

Could Steam cloud saves be suspected in any way? Probably interrupting the sync process, or something like that?