RUDE: another Chocolate Doom fork (3.1.0pre11)

Game Engines like EDGE, LZDoom, QZDoom, ECWolf, and others, go in this forum
Forum rules
The Projects forums are ONLY for YOUR PROJECTS! If you are asking questions about a project, either find that project's thread, or start a thread in the General section instead.

Got a cool project idea but nothing else? Put it in the project ideas thread instead!

Projects for any Doom-based engine are perfectly acceptable here too.

Please read the full rules for more details.
User avatar
drfrag
Vintage GZDoom Developer
Posts: 3150
Joined: Fri Apr 23, 2004 3:51 am
Location: Spain

Re: RUDE: another Chocolate Doom fork (2.5.0)

Post by drfrag »

Uploaded another test build with the latest changes from SmileTheory's v0.99 PR and Quasar's medusa emulation (tested in cybie2.wad). I reverted my slowdown emulation since it made Planisphere 2 unplayable (it's full of medusas but you don't see them). I bet medusas will be slow on a pentium anyway.
https://github.com/drfrag666/chocolate- ... -win32.zip
User avatar
drfrag
Vintage GZDoom Developer
Posts: 3150
Joined: Fri Apr 23, 2004 3:51 am
Location: Spain

Re: RUDE: another Chocolate Doom fork (3.1.0pre)

Post by drfrag »

I've merged with Choco3 and it's working but needs testing. That's why i've released a test build.
https://github.com/drfrag666/chocolate- ... g/3.1.0pre

Next i want to port Widescreen from Russian Doom but i want it to be an option and as less intrusive as possible so the idea is to make it work only at max screen size. And i want to add the mugshot (only) for that mode.
User avatar
drfrag
Vintage GZDoom Developer
Posts: 3150
Joined: Fri Apr 23, 2004 3:51 am
Location: Spain

Re: RUDE: another Chocolate Doom fork (3.1.0pre)

Post by drfrag »

Finally i managed to get it working but it's a bit rough. It's not real widescreen but a zoomed view, Julia fooled me into thinking it was with her scaled down weapons trick. :lol:
It's been an interestig exercise anyway. Fabian is implementing it too using a global but i was not sure about that.
I've used the widescreen global and a couple of static variables in i_video (actualwidth) and v_video (screenwidth), then either locals or conditionals everywhere else. I've tried to keep it as less intrusive as possible so everything is still at the left part of the screen, and no black background. And finally i set width to 400 so it works better on 16:10 and you don't lose too much vertical view (mainly the lack of status bar makes up for this). It's only for Doom. I haven't tested much but seems it's working well and demos play. :)
Now it compiles with Travis, i removed the -Werror switch and they also run a set of demos to ckeck compatibility but i can't wait hours to see if every commit passes.
The analyzer target fails but i think it's a false positive.
https://github.com/drfrag666/chocolate- ... its/master
User avatar
drfrag
Vintage GZDoom Developer
Posts: 3150
Joined: Fri Apr 23, 2004 3:51 am
Location: Spain

Re: RUDE: another Chocolate Doom fork (3.1.0pre2)

Post by drfrag »

I've done a new pre-release to try widescreen. It's loosely based on Russian Doom implementation and fabian did the trick to support real widescreen.
It's a bit rough, here there's no resolution autodetection. Both zoomed view and real wide are implemented. With the full view (screenblocks 12) the mugshot is shown, also in 4:3 mode.
Of course Doom 1.0 and 1.1 emulation by Smiletheory is included.
I've changed ammo balance in Unholy Massacre, it was too hardcore but had a nice survival touch tough. Now ammo balance it's pretty tight but before it always was like pistol start or even more extreme and you had to think and know the levels very well. I've added the -halfammo parameter to play old demos but this one will not be stored in demos and it's only SP. Given the lack of feedback from those Doom Gods out there i decided to change it, but IMO it's a blast now.

Now as i've compiled with SDL 2.0.8 gamepads work again and setting a fake splitscreen game is very easy (it's more complicated in LZDoom but there you have viewport resizing). Four players should be doable on a decent dual core. You need two folders and run the game either using a shortcut or console (-server and -connect 127.0.0.1) or setup. Configure different controllers in setup. Networking at the same time should be possible.
I want to play online but i can't create the server without port forwarding, so if someone wants to accept the challenge for a UM coop run with backpacks and create it... :)
I'm thinking about adding 8 player support but i don't know if it's worth and what i'd need exactly, besides new colors and using DM starts for coop. Seems there's not much interest anyway.
Read first post for details.
User avatar
drfrag
Vintage GZDoom Developer
Posts: 3150
Joined: Fri Apr 23, 2004 3:51 am
Location: Spain

Re: RUDE: another Chocolate Doom fork (3.1.0pre2)

Post by drfrag »

The README had a typo, the parameter for the backpacks is -backpack and not -dropbackpack.

It's not worth adding 8 players, first becouse the lack of interest and then it only would work well for big maps. There are a few problems too: i've been comparing Legacy 1.11 with Dosdoom 0.2 and they added a hack to convert DM starts to coop starts on the fly, if there were not enough DM starts first it would crash and then players would get stuck so i'd have to make them telefrag each other besides using DM starts directly. But many maps have no DM starts. Then i'd need more translations for the status bar, automap arrows and players themselves. There are 11 in legacy i think but some are fugly. And then there are the stats in intermissions. The network code in choco supports already 8 players for Hexen AFAIK. Sure 4 players are very few for a master server and online play but the game was designed for 4 players and more would be too many for common maps and coop. BTW seems legacy 1.12 is lost i'd liked to try it in Dosbox.
User avatar
drfrag
Vintage GZDoom Developer
Posts: 3150
Joined: Fri Apr 23, 2004 3:51 am
Location: Spain

Re: RUDE: another Chocolate Doom fork (3.1.0pre3)

Post by drfrag »

I've uploaded a new pre-release. There was a crash in widescreen when default screenblocks were less than 10, i thought it was fixed but it wasn't. It appeared when i restored the status bar. Seems nobody tried it. Also backpacks could be crushed and that wasn't nice, also i've enhanced the incremental backpacks to exchange supplies. BTW did you know that backpacks also work in single player with SP respawn?
The solution to the lack of starts for 8 players problem is pretty simple, in modern ports they don't block each other and i could do that and redirect them to existing starts when there are more than 4 players. I could add a double ammo switch too. But i can't even find volunteers for a 4 player UM game besides how would i test this?
I still think 8 player support would be cool having a master server available.
I see there's not much interest in the port, may be people expect it to be bad or it's becouse if you change a single line in the source it's not Doom anymore. 8-)
https://github.com/drfrag666/chocolate-doom/releases
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
Posts: 49182
Joined: Sat Jul 19, 2003 10:19 am
Location: Germany

Re: RUDE: another Chocolate Doom fork (3.1.0pre3)

Post by Graf Zahl »

drfrag wrote: I see there's not much interest in the port, may be people expect it to be bad or it's becouse if you change a single line in the source it's not Doom anymore. 8-)

No, the real reason is that for most users it doesn't add anything of value. I mean, what do you really expect? Chocolate Doom serves a very narrow purpose - and most of it does not concern actual playing but testing vanilla compatible mods. So what value does a fork offer for those that deviates from strict vanilla support?
User avatar
drfrag
Vintage GZDoom Developer
Posts: 3150
Joined: Fri Apr 23, 2004 3:51 am
Location: Spain

Re: RUDE: another Chocolate Doom fork (3.1.0pre4)

Post by drfrag »

I've released another test build. https://github.com/drfrag666/RUDE/releases
I've fixed a random crash in menus and centered the UI on widescreen modes.
Replaced the UM graphic with a better one by JNechaevsky. Thanks!
Now you can also exchange stimpacks in coop with 'c' and i've fixed another problem with backpacks, added joystick buttons for both.
Now Boom maps can't be loaded without the -boom parameter, they don't work properly.
Fix (testbed) for Chocolate issue #1254 https://github.com/chocolate-doom/choco ... ssues/1254
Full list of changes:

Code: Select all

* - UI centering for widescreen.
* - Hopefully fixed random crashes in the menu.
* doom: remove SPECHIT limit
* heretic: print a warning when the SPECHIT or INTERCEPTS limits are hit
* heretic: entirely remove INTERCEPTS and SPECHIT limits
* - Fixed: the crash with invalid blockmap fix broke maps with extended nodes.
* - Don't load Boom maps by default, only with the -boom parameter.
* - Add delay to drop things for joystick buttons.
* - Change setup title.
* - Extend demo format for halfammo. While this breaks old RUDE demos i don't think there are many and there were several game logic problems anyway.
* - Support the halfammo parameter in netgames.
* - Fixed keys for other games appeared in the extra controls section.
* - Add key and joy button to drop stimpacks in netgames.
* - Don't let monsters prevent spawning backpacks.
* - Add joystick button to drop a backpack.
* - Don't drop backpacks if there's no room, they would dissapear.
* - Use short limit macro.
* - Replaced the Unholy Massacre title graphic.
* - Fixed crash with invalid blockmap (DWHEEL.WAD).
Edit: changes from 3.1.0pre5:

Code: Select all

* Merge branch 'master' of https://github.com/chocolate-doom/chocolate-doom
* - Do not open the menu while chatting.
* - Adjust halfammo, fixes rockets not giving ammo.
* - Fixed ESC key not stopping chat input.
* - Add a -doubleammo parameter. This breaks old RUDE demos again.
* - Always allow spawning backpacks.
* - Double lost souls, they don't count as monsters. Fixes lost souls stuck inside other monsters. Also double cyberdemons.
* - Don't spawn doubled monsters if there's no room between floor and ceiling.
* - Fixed keys being restored after changing levels in coop.
User avatar
drfrag
Vintage GZDoom Developer
Posts: 3150
Joined: Fri Apr 23, 2004 3:51 am
Location: Spain

Re: RUDE: another Chocolate Doom fork (3.1.0pre7)

Post by drfrag »

Another pre-release to fix some more bugs:

Code: Select all

* Revert "Generate a random "pet" player username" (partial revert)
* - Fixed you could not select the supershotgun in classic mode without the shotgun.
* - Enable the ANALYZE Travis CI target.
* - Changed some code to enable the analyzer.
* Do not release the "STFB0" lump in multiplayer games (Crispy)
* - Enabled novert by default, now it affects only player movement. (adapted from Crispy)
* correctly color the status bar face background in multiplayer demos (Crispy)
* - Keep more clips in backpacks, don't account for the initial ammo.
* - Fixed: P_CheckDoubleSpawn was taking a pointer as parameter and not a pointer to pointer.
* - Recover not picked up backpacks upon level end instead of losing inventory.
* - Now keeping keys also works with SP respawn.
* - If a backpack cannot be dropped recover inventory instead of losing it.
* Merge branch 'master' of https://github.com/chocolate-doom/chocolate-doom
* - Fixed wrong position of the pause pic in widescreen.
* - Fixed wrong low resolution turning message when recording extended demos.
* - Added the -extended parameter to record extended demos on MP clients.
* - Fixed players could cheat getting extra ammo dropping backpacks with the doubleammo parameter.
We really abused that extra ammo bug these days playing MP. :)
<link deleted>
Last edited by drfrag on Sat Jun 20, 2020 4:04 am, edited 1 time in total.
User avatar
drfrag
Vintage GZDoom Developer
Posts: 3150
Joined: Fri Apr 23, 2004 3:51 am
Location: Spain

Re: RUDE: another Chocolate Doom fork (3.1.0pre7)

Post by drfrag »

Another build to fix a couple of bugs we found.
https://github.com/drfrag666/RUDE/relea ... 3.1.0pre7a
User avatar
Redneckerz
Spotlight Team
Posts: 1090
Joined: Mon Nov 25, 2019 8:54 am
Graphics Processor: Intel (Modern GZDoom)

Re: RUDE: another Chocolate Doom fork (3.1.0pre7)

Post by Redneckerz »

I think what this thing needs, considering it is described as an inbetweener of Choco and Cripsy, is a logo. And its most standout features should be standout more.

What you have now is that people get recommended Chocolate Because it is vanilla and Crispy Because it improves playability but retains compatibility.. For RUDE, there is not an instant highlight that is engrained in people's minds.

Lastly, it might be worthwhile to talk to Fraggle and see if you can get RUDE supported in the autobuilds alongside Crispy and along with a mention on the ChocoWiki and possibly DoomWiki.

Because personally i think RUDE has a lot going for it, but the way it is presented to the outside user (A ZDoom thread and a DoomWorld thread along with a Github page) might be one reason why it is not picked up on like Crispy is. Because Crispy well, its pretty much officially sanctioned by Fraggle.

So i think that's worth exploring. LZDoom gets featured on its pages here because its an official-enough deriviative that keeps features in sync. A similar act should be done for RUDE (So being sanctioned).
User avatar
drfrag
Vintage GZDoom Developer
Posts: 3150
Joined: Fri Apr 23, 2004 3:51 am
Location: Spain

Re: RUDE: another Chocolate Doom fork (3.1.0pre7)

Post by drfrag »

Thanks, it would be certainly cool having it mentioned in the ChocoWiki and DoomWiki. For instance Marshmallow isn't very popular either and has a detailed page with things that were the goals of the port but now i don't know if all of them are implemented or if it's still maintained, and the released source is very old. But i think it's better to wait until the 3.1.0 final release, the changes i made introduced a lot of bugs and there are very few people testing. Now it's working much better and i think the port is underrated yes, now when i'm having the most fun is playing enhanced coop with the backpacks, doubled monsters in classic mode and being able to share ammo and health. And there's a single player respawn option with backpacks too. Yet it still has that vanilla/chocolatey feel right from the startup screen.
About the logo i can't do it so i used Romero's head. :)
User avatar
drfrag
Vintage GZDoom Developer
Posts: 3150
Joined: Fri Apr 23, 2004 3:51 am
Location: Spain

Re: RUDE: another Chocolate Doom fork (3.1.0pre7)

Post by drfrag »

Hey Red, this afternoon we'll be playing extreme coop again with TNT.wad, around 20:00 UTC+2 (probably a bit earlier). I forgot to mention it.
So if someone from europe or nearby wants to join drop me a line, that's becouse if you're very far from spain there could be massive lag.
User avatar
Redneckerz
Spotlight Team
Posts: 1090
Joined: Mon Nov 25, 2019 8:54 am
Graphics Processor: Intel (Modern GZDoom)

Re: RUDE: another Chocolate Doom fork (3.1.0pre7)

Post by Redneckerz »

drfrag wrote:Thanks, it would be certainly cool having it mentioned in the ChocoWiki and DoomWiki. For instance Marshmallow isn't very popular either and has a detailed page with things that were the goals of the port but now i don't know if all of them are implemented or if it's still maintained, and the released source is very old.
That Marshmellow page always gives me a good chuckle given its attention to detail - It dwarfs even more well known ports by quite a mile.
drfrag wrote: But i think it's better to wait until the 3.1.0 final release, the changes i made introduced a lot of bugs and there are very few people testing. Now it's working much better and i think the port is underrated yes, now when i'm having the most fun is playing enhanced coop with the backpacks, doubled monsters in classic mode and being able to share ammo and health. And there's a single player respawn option with backpacks too. Yet it still has that vanilla/chocolatey feel right from the startup screen.
Exactly. I think this, LZDoom, your various Doom flavors definitely have to be more in the limelight because honestly outside of Kokak i don't know many other port authors that make so many ports. :lol:

And honestly i just want to cover it all, but covering all your ports is quite a task indeed.

With that said, try to get in touch with Fraggle regarding ChocoWiki. I am sure he is able to help you out.
drfrag wrote: About the logo i can't do it so i used Romero's head. :)
Contact Torm! He will whip you up a great logo in no-time. Make use of your community, Frag! It has helped me out a lot and in return i could help out a lot of others because of it. Its one of the finest aspects of the Doom community no matter if its ZDoom or DoomWorld - People will help you out as long as you have a set goal in mind.

And your ports are quite a set goal in the first place!
drfrag wrote:Hey Red, this afternoon we'll be playing extreme coop again with TNT.wad, around 20:00 UTC+2 (probably a bit earlier). I forgot to mention it.
So if someone from europe or nearby wants to join drop me a line, that's becouse if you're very far from spain there could be massive lag.
Haha :lol: One day! (But i very much appreciate you asking me, thank you.)
User avatar
drfrag
Vintage GZDoom Developer
Posts: 3150
Joined: Fri Apr 23, 2004 3:51 am
Location: Spain

Re: RUDE: another Chocolate Doom fork (3.1.0pre8)

Post by drfrag »

Torm made the LZDoom logo. Is a new logo really important? For an official release may be, we don't want to dissapoint Mr. Romero. :P
I've uploaded a new release to fix a bug with a TNT big multipatch texture (bad merge from Crispy) and the server security issue in Chocolate Doom. There's a Choco 3.0.1 release too but it's important only if you're running servers online.
We'll play later again BTW.
https://github.com/drfrag666/RUDE/relea ... /3.1.0pre8

Return to “Game Engines”