ZDoom

Thanks for the quick and honest reply. I appreciate it.

I now have one more question.

Down the track is a 32bit color renderer going to be possible?
I would love to make a great UltraHD texture pack for Wolf 1-6, Spear of desting and Return to Danger + The Ultimate Challenge, but I can't make textures in 32bit and have them all scale down to wolfenstein's original 256 color palette.

Maybe have the option to set the color depth ingame, so people that want to revisit the game in it's original 256 color format don't miss out?

I have such fond memories of this game, and would love to make some seroius UltraHD content for it some day.

To me the 8-bit software renderer is an vital part of the experience so while not impossible I might decide to work on alternative renderers, your best hope is that another developer takes interest and submits one.

Thanks again for a quick and honest reply.

Keep up the great work with this port.
I can't wait to see what happens down the road.

EDIT: I was also wondering is the latest version of ECWolf still capped at 70FPS? If so is there any way to uncap it to 120fps?
Also is there any way to force a custom resolution? (I use DSR, on my 1080p ASUS VG278 monitor, and 3840x2160 has performance issues, I would like to set use 2880x1620, but that resolution isn't an option and I can only get 2560x1440 in DSR).

Where can I download older versions of ECWolf?

Blzut3 wrote:To me the 8-bit software renderer is an vital part of the experience so while not impossible I might decide to work on alternative renderers, your best hope is that another developer takes interest and submits one.

The software renderer is probably the best way to preserve the classic experience, but I enjoy trying to make old games look better when possible. It is my understanding that ECWolf borrowied a bit of ZDoom code when it started. These days GZDoom has an even better software renderer, and a fairly robust and feature-rich hardware renderer as well.

At some point, would it make sense to try and sort of the Wolfenstein-specific features into a patch set that could be re-applied GZDoom if/when you ever want to update it? Or rebase the ECWolf code on a new release of GZDoom at some point?

If nothing else, there are probably old bugs you inherited from ZDoom that are fixed in recent GZDoom releases.

I may be in the minority, but I'd almost like to see this just get merged into GZDoom (even if you have it spit out separate binaries) so you can focus on supporting Wolfenstein features, but inherit all the other aspects of GZDoom development.

Wiw wrote:Where can I download older versions of ECWolf?

http://maniacsvault.net/ecwolf/files/ecwolf/1.x/

enderandrew wrote:At some point, would it make sense to try and sort of the Wolfenstein-specific features into a patch set that could be re-applied GZDoom if/when you ever want to update it?

Not really. The two engines are very similar in construction, but there's a very large number of small differences that are just not practical to factor out. More importantly the Wolf3D engine didn't provide as much of a framework as Doom to build upon, so there are a lot of redundant formats I need to support that I really don't think the GZDoom code base should be cluttered up with. Lots of what would normally be considered questionable heuristics as well.

Overall I think it makes a lot of sense for these to be separate projects as it allows me to make different trade offs when necessary in order to best represent the games that ECWolf supports.

enderandrew wrote:Or rebase the ECWolf code on a new release of GZDoom at some point?

ECWolf is based off of Wolf4SDL with some GZDoom things mixed in. This mostly includes resource management, a few parsers (but not all since DECORATE for example is new), and some OS interaction. I have rebased these bits from time to time, but I have to be careful now since ECWolf is dual licensed so I can only use code that is still licensed under the BSD.

(I may eventually decide to go GPL only with ECWolf, but I really don't like the restrictions on the GPL and all the oddities that it brings so dual licensing has been my way to force all new code to be licensed permissively.)

enderandrew wrote:If nothing else, there are probably old bugs you inherited from ZDoom that are fixed in recent GZDoom releases.

The code I use isn't very volatile so I don't usually get reports of bugs that were fixed in GZDoom, but ECWolf has in many instances exercised code paths that were rarely or never traveled in GZDoom. Some of these fixes made it back upstream, and in at least one case I fixed an issue which is not fixed in GZDoom due to backward compatibility. (Edge case in texture loading ordering that only really affects ECWolf due to some shortcuts taken internally.)

Which of course brings up another point, being a separate project I'm able to utilize hindsight to hopefully correct mistakes that are just being kept around to support older mods. For example ECWolf's DECORATE dialect doesn't suffer from the issues that required ZScript to be a whole separate language. (This is not commentary on ZScript, just saying that ECWolf's DECORATE dialect has a lot more flexibility as a result of hindsight.)

enderandrew wrote:I may be in the minority, but I'd almost like to see this just get merged into GZDoom (even if you have it spit out separate binaries) so you can focus on supporting Wolfenstein features, but inherit all the other aspects of GZDoom development.

If the binaries were split then the goal could equally be served by a libzdoom which includes the common pieces. I have thought about trying something like this in the past, but since ZDoom wasn't designed to be a library there are some aspects of the core bits that would make such library probably more work than its worth to factor out. Of course if someone were to take on such an effort I would look into using it with ECWolf provided it's BSD or LGPL licensed.

Are you still working on support for Blake Stone?

Trusty McLegit wrote:Are you still working on support for Blake Stone?

Yes, but not actively.

What I'm working on in the immediate future is namespaces for decorate and multiplayer.

Oh cool I didn't realize this had multiplayer

So I was working on replacing the fonts for the intermission and this was the result:

Spoiler:

---

Why are they all mangled?

I made sure the images were 4-bit (16 colours) with no transparency and keeping the original size of the graphics.

CeeJay wrote:Why are they all stretched and squashed?

The usual aspect ratio correction.

So how do I go about fixing that ?

Short answer: You don't.

Long answer: Use individual graphics/FONTDEFS for your font and then use TEXTURES to apply a yscale of 1.2 on each character to counter the aspect correction.

Fontdef:

Spoiler:

---

IntermissionFont
{
Template "FONTL%03d"
SpaceWidth 16
}

Texture:

Spoiler:

---

Graphic FONTL033, 0, 0
{
YScale 1.2
Patch FONTL033, 0, 0
}

Graphic FONTL037, 0, 0
{
YScale 1.2
Patch FONTL037, 0, 0
}

Graphic FONTL039, 0, 0
{
YScale 1.2
Patch FONTL039, 0, 0
}

Graphic FONTL048, 0, 0
{
YScale 1.2
Patch FONTL048, 0, 0
}

Graphic FONTL049, 0, 0
{
YScale 1.2
Patch FONTL049, 0, 0
}

Graphic FONTL050, 0, 0
{
YScale 1.2
Patch FONTL050, 0, 0
}

Graphic FONTL051, 0, 0
{
YScale 1.2
Patch FONTL051, 0, 0
}

Graphic FONTL052, 0, 0
{
YScale 1.2
Patch FONTL052, 0, 0
}

Graphic FONTL053, 0, 0
{
YScale 1.2
Patch FONTL053, 0, 0
}

Graphic FONTL054, 0, 0
{
YScale 1.2
Patch FONTL054, 0, 0
}

Graphic FONTL055, 0, 0
{
YScale 1.2
Patch FONTL055, 0, 0
}

Graphic FONTL056, 0, 0
{
YScale 1.2
Patch FONTL056, 0, 0
}

Graphic FONTL057, 0, 0
{
YScale 1.2
Patch FONTL057, 0, 0
}

Graphic FONTL058, 0, 0
{
YScale 1.2
Patch FONTL058, 0, 0
}

Made no difference what so ever, maybe I'm doing something wrong.

EDIT: Silly me, forgot to add the size of the image(s)

And here is the final result:

Spoiler:

---

I am very pleased.