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

Simple question about Testing with Source Ports.

Recommended Posts

I will be creating several maps and eventually mods for Doom. I have downloaded the latest versions of GZDoom, Zandronum, and ZDoom LE, and the dev versions of GZDoom and Zandronum. I am wondering what other source ports I should be using to test my maps on, I know I should use some kind of Boom port, but I have heard of so many, that I am not sure which one is the best. I should also use one of the "Authentic Retro Doom" Source ports, like Chocolate Doom, Doom Retro, and Crispy Doom. Which one of those should I use? Also which of the "Authentic Retro Doom" source ports can be recorded with fraps? Thanks in advance.

Share this post


Link to post

What port(s) you test with all depend on what port(s) you plan to target. If you are shooting for Boom compatibility using Boom format of maps, use PrBoom+ and test exclusively with that. I may be wrong but anything that works in Boom will work in all other ports that are more advanced.

 

If you are mapping in UDMF, you should be targeting GZDoom. More ports have been getting support for UDMF so you should be safe there, but the map format won't be the problem in that case, it will end up being ACS or something else that breaks compatibility.

 

So it all depends. I see you also said you should use an authentic port, well then that means you must be planning to map for vanilla no? So then I'd use Chocolate Doom and test with it instead.

Share this post


Link to post
2 hours ago, leodoom85 said:

Doom95...for a very authentic port

That's a very strange way to spell Chocolate Doom.

 

Edit: In fact Doom95 isn't even a properly authentic port, making your statement contradictory.

Edited by Edward850

Share this post


Link to post
2 hours ago, leodoom85 said:

Doom95...for a very authentic port. And for advanced purposes, GZDoom

As I said, I already have GZDoom.

Share this post


Link to post

Basically, what you aim for plus one or two more advanced ports.

 

For example, you want to test gameplay with aimed port, but also keep in mind how things are handled differently in other ports. Ex. shooting through self-referencing sectors.

 

Minute differences between port features are really annoying. Each one handles conveoyors differently...

 

Share this post


Link to post

If you want to make a vanilla compatible map, you should always test it in the original vanilla executable or in Chocolate Doom.

If you want to make a limit-removing compatible map, you should always test it in PrBoom-plus with parameter -complevel 2.

If you want to make a Boom compatible map, you should always test it in PrBoom-plus with parameter -complevel 9.

If you want to make a source-port-specific map, you should always test it in the respective specific source port.

Share this post


Link to post

Pretty much what Scifista said, except I use Crispy Doom for limit-removing. If you're aiming for broad compatibility then it's worth testing lots of ports, since they all have their own quirks.

Share this post


Link to post
14 hours ago, leodoom85 said:

Doom95...for a very authentic port. 

Please don't try to use Doom95 for anything or recommend it to anyone. It's thoroughly broken and does not work on modern systems.

Share this post


Link to post

Chocolate is fine to test in for vanilla mapping in my experience.  It doesn't handle dehacked files 100% vanilla-like last I checked, though.

Share this post


Link to post

Pretty much what Sci said.

 

There is a general order of "newness" or "complexity" that most wads seem to fall into. Thoroughly test using the port that matches your level of complexity, and at least some testing on all ports "higher" on the scale (anything lower on the scale won't support it). The general order I tend to use is:

  • True vanilla: Chocolate Doom
  • Limit-removing: Crispy Doom, or PRBoom+ Complevel 2
  • Boom: PRBoom+ Complevel 9
  • UDMF: GZDoom

There are plenty of other source port options, but if you test with the above, it's unlikely anyone will think you under-tested anything.

Share this post


Link to post
2 minutes ago, Angry Saint said:

Isn't complevel 2 vanilla?

Yes; but PrBoom+ itself remains limit-removing regardless of complevel. It's not because you put complevel 2 that it'll start to correctly and adequately crash when you exceed the visplane limit, for example.

Share this post


Link to post

Recommending to use only one port for testing is not the best idea. Since engines handle differently and even if they don't, they may have different defaults.

All advice being told only holds true if your map doesn't depend on some exploit by accident. Some ports may have fixed the cause of the exploit. This particularly applies to render tricks in hardware accelerated ports which simply cannot emulate all the quirks of the software renderer.

 

Share this post


Link to post

I use zdoom and gzdoom for my testing, since both handle things differently but I map using hexen. I dont know if anyone would agree, but if you had to test with any two ports, i'd choose prboom+ and zdoom, as anything that works in those both will most likely work in gzdoom. If you are mapping for gzdoom, prboom+ won't work.

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
×