Jump to content
Search In
  • More options...
Find results that contain...
Find results in...
YukiHerz

Coding newbie's first dabble into sourceports

Recommended Posts

I've been messing around with the source for ports like choco and crispy, mainly to occupy myself on something instead of succumbing to an anxiety attack.

 

This port here is the result of me messing with MBF for ms-dos, based on the updated MBF source found at Vogons, which i've mildly modified (mostly while learning how things work by copypasting and going over the changes) after setting up the necessary tools to compile it, the changes are:

 

-Made weapon switching twice as fast

-Added the extra sprites and states from modern dehacked implementations (taken from the code in Crispy).

-Added A_FirePlasmaNoAmmo (while learning how codepointers are defined).

-Added A_DropItem (while trying to implement something that could have some actual use).

-Added A_FireTrap (wall trap function).

 

The main reason I'm posting this here is, i'd like to know from actual source port developers, is there a reason why there haven't been new codepointers beyond what MBF added? is it purely due to having to coordinate with other authors to make sure all the modern ports support these new actions?

 

Downloads:

Compiled Port

Source Code on Github

 

Load the provided .bex and .wad to check out the custom actions, the fist will be changed into the Quake 2 blaster and fires plasma, Imps have A_DropItem added to their death.

 


Credits to the actual authors of Boom, MBF, MBF 2.04, Chocolate Doom, Crispy Doom and Doom Retro.

Edited by YukiHerz

Share this post


Link to post
2 hours ago, YukiHerz said:

The main reason I'm posting this here is, i'd like to know from actual source port developers, is there a reason why there haven't been new codepointers beyond what MBF added?

More advanced source ports, like EDGE (the one I worked on), ZDoom, Eternity, etc have better systems than DEHACKED for defining things, and have added plenty of new actions via those systems (DDF, EDF, DECORATE).  For these ports, DEHACKED support is only there for compatibility with existing mods and there is no incentive to add any new codepointers to it.

 

Most other source ports are quite conservative and don't add many new features, so I think it is mostly a case that the advanced ports do their own thing and there is nothing really pushing the envelope in the space between those ports and the vanilla-y / chocolate-y ports.

Share this post


Link to post

The real reason for this degree of stagnation is that PrBoom+ is, for all intents and purposes, dead in the water, and being hosted on a web site and a VCS that's hardly inviting for collaboration.

 

Since nothing here will gain any acceptance without PrBoom+ or a viable successor supporting it, we can discuss the problem until all eternity but since the baseline port has been the main reason for stalling any progress there is no chance to move forward.

 

For what it is worth, what the Doom community really needs right now is not a multitude of retro ports below PrBoom+, but someone willing to take over that port and help make such improvements universally available. I did my take with UMAPINFO, in the hope that it'd filter back to the mainline but have been hit with this stagnation problem as well and it doesn't really provide motivation to keep active on such a side project.

 

And the same goes for Crispy's Dehacked extensions. I wouldn't hesitate one moment to add support to GZDoom, but as long as the feature is restricted to Crispy, a few forks, maybe Doom Retro (I don't know if it has it) and GZDoom, it leaves out the one port that really matters for more classic gameplay.

 

 

Share this post


Link to post

And to think I did everything from scratch and used some parts of Boom, MBF and Heretic for graphical fixes and freelook.

It can be useful to have some better documentation about how to navigate the source code and how to do some basic stuff (like DEHACKED integration).

Some (if not most) times it's better to learn how to do some of these things rather than copy pasting and hoping for the best.

Share this post


Link to post
1 hour ago, MadGuy said:

Some (if not most) times it's better to learn how to do some of these things rather than copy pasting and hoping for the best.

 

Very true, and that's how I started with Doom coding, i.e. hacking existing ports, adding new features, transplanting features from one port to another etc.

But in the end when I had gained the understanding I deliberately made GZDoom a superset of ZDoom with a clearly stated goal (i.e. ZDoom with hardware rendering) and made sure that all non-hardware rendering features got back to ZDoom as well, instead of doing my own thing and creating more fraction in the community. Even the 3D-floors, GZDoom's biggest selling point eventually got backported (by someone with a stronger interest in software rendering, though. ;))

 

Share this post


Link to post
12 minutes ago, Graf Zahl said:

 

Very true, and that's how I started with Doom coding, i.e. hacking existing ports, adding new features, transplanting features from one port to another etc.

But in the end when I had gained the understanding I deliberately made GZDoom a superset of ZDoom with a clearly stated goal (i.e. ZDoom with hardware rendering) and made sure that all non-hardware rendering features got back to ZDoom as well, instead of doing my own thing and creating more fraction in the community. Even the 3D-floors, GZDoom's biggest selling point eventually got backported (by someone with a stronger interest in software rendering, though. ;))

 

So, did you make GZDoom and ZDoom? Or just GZDoom, I'm kinda never pay attention to who made it, so a simple answer would be great.

Share this post


Link to post

Some view into history from long ago:

 

ZDoom was created by Randy Heit. Back in 2004 I forked it and added the OpenGL renderer I had been working on for several years before in a custom engine based on PrBoom. Back in 2005 ZDoom was in a pretty bad state with a failed rewrite to use floating point math which stopped the project cold in its tracks for more than half a year. At this point a few coders from the community forked the engine and started adding the features that had been collecting dust. The result was the ZDoom 2.0.96 fork. This was around the same time when I was done with my porting work on GZDoom, so when it got released it was based on said 2.0.96x fork, not the real ZDoom 2.0.96.

When the botched floating point rewrite mentioned above was abandoned, all of 2.0.96x's features got ported to the main ZDoom and in 2006 I was given access to the ZDoom SVN repo as well. From that point on I split my own work so that all non rendering features got to ZDoom and all hardware rendering features to GZDoom. This went on for almost 11 years when ZDoom was discontinued.

Share this post


Link to post

I see now, I hadn't realized the state PrBoom+ was in, certainly explains a lot.

 

I'll continue to experiment, hopefully with less/no copypasting involved past this point.

Share this post


Link to post

I've created a github repo with the source code, link in first post.

 

Also a new compiled executable with another experimental codepointer, it may be a simple projectile shooting function, but it took me some thinking to come up and code it, no copypasting this time! yay! (but I did look at similar functions while coding it), the provided bex file has been updated to give zombiemen a questionable new ability.

Share this post


Link to post
On 12/1/2019 at 8:16 AM, Graf Zahl said:

And the same goes for Crispy's Dehacked extensions. I wouldn't hesitate one moment to add support to GZDoom, but as long as the feature is restricted to Crispy, a few forks, maybe Doom Retro (I don't know if it has it) and GZDoom, it leaves out the one port that really matters for more classic gameplay.

 

Well, the extra states originally came from Doom Retro. @bradharding introduced them to add support for loading @VGA's Black Ops and Smoothed mods both at the same time. I merely adapted them for Crispy Doom.

 

Share this post


Link to post

PS: But as you said, as long as standards are defined by support being available for PrBoom+, let's just make facts and add the extra states there. I have created a PR for this for your fork.

Share this post


Link to post

Thanks, I'll add them to GZDoom then as well, it'll be a bit of messy ZScript coding, though to get it all in, but technically no problem.

 

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×