[v1.1] Flipper - DoomGuy's World Gone Backwards

[YasuoProjectX]

This mod it hurts my feelings

While in Automap dosent seems flipped

Edit: Also Overlay Mode

[Rachael]

What about adding the feature to the source code itself? I've had a quick look at Crispy's source and looks like is portable. It introduced some serious issues fixed later tough.
This commit: "port flipped levels over from Strawberry Doom". But GitHub search doesn't work on forks.

https://github.com/madame-rachelle/gzdo ... extensions
https://github.com/madame-rachelle/flip ... at_version

Not exactly what you requested, but close.

Have fun!

It's controlled by a CVAR - flipper_method - which has 3 bit switches:

Code: Select all

// cvar flipper_method
// flipper_method & 1 = enable shader and turn reversing (the 'fake' backwards method)
// flipper_method & 2 = enable levelcompatibility method (the vertex and line flipping method)
// flipper_method & 4 = enable sprite flipping (useful with method 1)

The entire thing is BSD licensed, so if for some really crazy and odd reason you want to integrate this into LZDoom, go ahead. (Though you'll probably be met with disapproval from certain other developers if you do so. >_>)

[drfrag]

I wasn't making any request, just asking on opinions about porting the feature to the source itself.
I'll have a look at it. Which other developers are you talking about? Yourself?

[Rachael]

Nope. I really do not mind one way or the other.

[leodoom85]

What is this........a parallel universe that works backwards?
Nice.

Next challenge is using a mod that alters the FOV and movement badly, like the one that TerminusEst13 did which is called Doom But It's F****** Unplayable.

[drfrag]

May be i'm becoming mad but now i don't see that the automap is not inverted with the current version, controls are. What i don't like is the inverted weapon.
The mod is playable, i don't see the point in unplayable mods.
Merging the mod into the engine as is could wreak havoc, i'm not sure about what i will do. I'll take a look at Crispy's code soon. When you enable/disable flipping some serious issues would arise, and most likely even without doing it.
What i could do now is porting the compatibility options to support the mod, i see they are still not in GZDoom.
I plan to do the next release in a few days BTW.

[Rachael]

flipper_method 2 will reverse the automap. It requires a restart of the map though.

[drfrag]

I mean that to me in 0.4 the automap looks already reversed. This is confusing.
Edit: obviously it was not, i don't know what i was thinking.
BTW now they are making it a renderer only effect in Crispy for demo compatibility.

[Rachael]

V1.0 released!

Actually, it happened silently a couple days ago, but I held it off because a necessary ZScript function was in hiatus at the time.

Anyhoo, this version actually requires a very recent dev build. It is controlled via CVar "flipper_method" - which is a flag CVar.

To calculate the flag, do the following:

Code: Select all

Start with 0
- Add 1 to activate the shader. This version simply reverses the screen's X coordinates and reverses your player's left/right orientation to match. This method is compatible with Hexen. It cannot reverse the sound or the automap, however. (Limitations!)
- Add 2 to activate the level post-processor method. This requires a map restart. This method can break some scripted maps, but it is otherwise compatible with any Vanilla/Boom/Heretic that does not use scrollers.
- Add 4 to use sprite flipping. Meant to be used with 1, but can be used separately. This also requires a map restart.

For example: 5 (1+4) activates the shader method, and then flips the sprites on the map to make it look like the map was actually reversed.

If you're too confused to math out your flags, there's a menu option that allows you to cycle through all available modes (even the redundant ones).

[Gez]

So 7 gives a needlessly complex way of playing the levels "normally"?

[Rachael]

Pretty much.

[drfrag]

Actually the compat version worked in the latest LZDoom release and changes in 1.0 are minimal.

[Rachael]

Considering you did a release with my function names, you'll now have to create alias functions to remain compatible with GZDoom's mainline and to ensure that you don't break mods made specifically for LZDoom.

If I were you, I'd actually use GZDoom's version of the functions as a base, and then just create wrapper functions for the same functions that I created.

I think now you are starting to see why I sometimes have troubles with maintaining a fork, especially one that takes on beta features. But as a general release port that's meant to be used in production, the wisdom of taking beta features and throwing them into releases is something that must be called into consideration. To put it another way: "usually it's not a good idea" and this is why.

[drfrag]

I don't have to do anything, in theory i should add aliases but i don't think anyone is using those functions. I just added those in case you wanted to release your mod earlier. I usually don't add scripting features since it doesn't make sense. Beta or not they worked. Maintaining an old fork is shitty, with a modern codebase i could just do a merge.
https://github.com/drfrag666/gzdoom/commits/g3.3mgw

[Rachael]

Updated to v1.1

Newest feature is weapon flipping

I plan to expand the cvar into flag cvar's so that each setting can be configured individually

Enjoy