ZDoom 2.1.0 Released

[Csonicgo]

imagine how fast Holyhell.wad will be with floating point.

[Xtife]

whats about nuts? :)

[TheDarkArchon]

Actually, floating point is just to reduce some of the fixed point overflows or restrictions such as "only" being able to scale sprites up to 4x.

Polymost is basically a different renderer used in build ports, which allows for proper looking up/down. There's probabally other benefits as well, but I don't know what they are.

[Csonicgo]

TheDarkArchon said:

Actually, floating point is just to reduce some of the fixed point overflows or restrictions such as "only" being able to scale sprites up to 4x.

yes, but monster sight code should be optimised too. and monster AI should be too, as it shouldn't be so bad to have 2000+ monsters active. it's such a simple "magnet" AI, and I know some MMX/SSE2/3DNOW!+ would help a lot.

[digit@l_pimp]

i've been lurking for a while and just needed to post:

it's completely different if you view things from a programmer's stand-point. randy is not going to wait around to standardize features when there's only 2 ports that are actually still maintained on a consistent basis.

i like the new features but i also like that you can disable most of them. zdoom is good for what it does, i keep prBoom around for demos and vanilla stuff. do the same and life will be better for you. :)

[pritch]

I'd agree pretty much with what chopkinsca said.

Yes zdoom isn't really Doom anymore, but then it hasn't been for a long time and crouching or whatever isn't a sudden jump into loland.

The fact remains that zdoom can be tweaked to give a unique experience and this puts the end user in contrl of how they play their wads, which OK might make some authors second-guess themselves, but I don't think there's a need to be paranoid about that, it's not enough to make a wad not stand on its own merits.

As has been said, you have other ports including those very close to vanilla (chocolate) to do other jobs.

Doomers never had it so good!

[june gloom]

i like how my frank observations of community behaviour are immediately deleted. deleting posts is stupid.

personally i like zdoom, and would rather not use anything else. partly it's because i've fallen into disinterest as far as "classic" doom play goes. i don't care for the standard FPS anymore, i want something more cerebral, like thief, or system shock. hell, even half-life requires a little more thought than most other FPS.

[Chrono_T]

I was just having fun! I'm sorry. ;-;

Though there was an option to disable jumping at the beginning of the game.

[Graf Zahl]

Csonicgo said:

New Features: polymost and Floating point. Supposed to be faster. :/

Actually the floating point stuff won't make much of a difference with regards to speed.

First, the majority of time is spent in the low-level rendering code which doesn't use floating point.
Second, the floating point code isn't really faster. I was able to do performance tests with Randy's test release last August and the overall speed was the same as the current code.

[Xtife]

what the heck have we been waiting for then =/

[TheDarkArchon]

Randy to recover from a WoW addiction

[Csonicgo]

Graf Zahl said:

Actually the floating point stuff won't make much of a difference with regards to speed.

First, the majority of time is spent in the low-level rendering code which doesn't use floating point.
Second, the floating point code isn't really faster. I was able to do performance tests with Randy's test release last August and the overall speed was the same as the current code.

damnit. can't we have SSE2 or at least MMX optimisation? :( I think everyone with a modern computer would love to have a performance boost.

[Quasar]

Graf Zahl said:

Vavoom uses the same lump but different syntax. Legacy 2.0 is doing the same. Eternity uses a completely different format but at least it names the lump differently so that there are no conflicts. But due to the incompatibilities the 3 aforementioned ports are not compatible anymore. How are you trying to resolve that if the only thing you hear is 'My solution is better'?

In Eternity's case this had two reasons:

1. SMMU had already implemented MapInfo and in order to continue supporting the existing maps (however few, but including the work done on Eternity TC at the time) that used it, I had to preserve the same format.

2. Eternity doesn't (and cannot) contain the sc_man.c parser from Hexen.

Taken in light of those considerations, you can see I had at least some justification for maintaining the existing format, even though doing so means that EE may have problems with Hexen mods in the future (of course I may find a solution in the meantime).

When I chose the lump name EMAPINFO for Eternity's newer global MapInfo lump, I did so consciously to avoid loading Hexen/zdoom MAPINFO and therefore avoiding an unnecessary incompatibility issue. This is probably the kind of cooperation that the people here in this thread are talking about -- a basic consideration of other peoples' work, a modicum of respect that ends up enhancing the potential ability of mods to work with many different ports, and thus allows people to experience them in a way they choose.

This is also why in my 32-bit map format idea I included fields that could specify the intended target source port and doomednum/linespec/sectorspec translations, because a port loading such maps would know what to ignore or would even be able to intelligently dynamically translate the maps to its own internal format if it so chose to implement a proper compatibility layer (which would consist of a few simple functions called from P_SetupLevel). Of course that thread went down in flames for reasons I still don't even know, as I thought we were getting pretty close to an agreement.

I do think it is a shame that more cooperation isn't going on, even if it is only to a point where maps can load even if they're not 100% playable or a few things don't look right. But I, as a programmer, also understand that we all have our own goals for our individual projects and that some of them are not compatible. There will never be one port for all, and people need to be more open to trying other things too. I feel like most of the work I do is ignored for some reason.

[Scuba Steve]

Quasar said:

I feel like most of the work I do is ignored for some reason.

Wait, so which port do you work on, Vavoom?

[Graf Zahl]

Quasar said:

2. Eternity doesn't (and cannot) contain the sc_man.c parser from Hexen.

You sure could have written a simple token based parser yourself, couldn't you? ;)

In the entire sc_man file there is really only one function doing all the work and even in ZDoom that function is gone by now and replaced by original code so in its current state I probably wouldn't need more than a few hours to get rid of all the Raven-based code and still have the same functionality.

When I chose the lump name EMAPINFO for Eternity's newer global MapInfo lump, I did so consciously to avoid loading Hexen/zdoom MAPINFO and therefore avoiding an unnecessary incompatibility issue. This is probably the kind of cooperation that the people here in this thread are talking about -- a basic consideration of other peoples' work, a modicum of respect that ends up enhancing the potential ability of mods to work with many different ports, and thus allows people to experience them in a way they choose.

It is sure better than creating compatibility issues. But you still got a lot of linedef type overlaps with Legacy. So should I ever listen to the requests and add 3DMIDTEX support to GZDoom I have a problem because the linedef types are already taken...

[Graf Zahl]

Csonicgo said:

damnit. can't we have SSE2 or at least MMX optimisation? :( I think everyone with a modern computer would love to have a performance boost.

But the math inside a 3D engine wouldn't profit much from SSE2. I did an SSE2 test compile of GZDoom (which is heavily using floats in the GL renderer) and it got slower by that! The reason for this is that although SSE2 is faster for simple math its performance seems to break down completely when using math functions like sin, cos, tan or sqrt and these functions (in particular atan) are called a lot. For the game engine it is even more proportionally.

[Jon]

AlexMax said:

What standards are there in ZDoom? It seems like ZDoom is simply a mishmesh of things that randy thought would be cool to add, without thinking about how hard these features would be to add for other source ports.

It's not often I say this, but I fully disagree with your opinion. Utterly. It's not even worth trying to refine why, because we clearly are totally polarised here.

There has been some comparison of the way things are done in other communities, such as the Quake community. All I can say is, despite the lack of "formality" here, the doom community is still by far the easiest to grab some ports from and find a bunch of levels all in one place which are worth playing. The amount of work it takes to find some good levels for quake is ludicrous, unless you like sitting in fileplanet queues.

God bless /idgames.

Now I'm going to go and have nightmares of w3c-style boardroom meetings for deciding the feature set of a bunch of doom ports.

[pritch]

That's a very good point, and why I said that in many ways we've never had it so good.

The fact is Doomers have a unitary archive of community work, we have a lot of sourceport choice, and we can still play a huge proportion of that work with all the sourceports. It's not like Randy has shoved a spear through the database.

Also, as Quasar said, developers are under no need to be inclusive. Often they make a sourceport because it's a project and it's a fun test of skill, and ultimately it's we that choose whether to take them up on it or not; I don't see how desgin or feature standards is relevant to a 13 year old game in the same way it might be to hl2, doom3 etc. development.

[Zeroth]

Thats nice and all...but crouching?

if you want features, sure...but why crouching -- in Doom?

You can only change so much about Doom before, well, it no longer feels like Doom when you play it.

two cents deopsited.

[Quasar]

Graf Zahl said:

You sure could have written a simple token based parser yourself, couldn't you? ;)

Certainly, and I may yet do this if I decide converting Hexen MAPINFO is something I need to do. I didn't have the requisite skills to do it at the time I made the decision, however.

Graf Zahl said:

It is sure better than creating compatibility issues. But you still got a lot of linedef type overlaps with Legacy. So should I ever listen to the requests and add 3DMIDTEX support to GZDoom I have a problem because the linedef types are already taken...

Which is why linedef/sector/thing namespaces for different ports were, IMO, a critical idea. There are a number of reasons why it is neither convenient nor practical for these things to match between all ports. But if they could be interpreted relative to the map's intended target, then runtime translation is suddenly possible and it doesn't matter any more. But this idea looks like it will pass away unheeded.

[DaniJ]

What I think would be of great benefit to all us port authors is a central place to register extensions beyond the base DOOM/HEXEN so that we can attempt to avoid overlaps in future.

For example a database of new line types, line/mobj flags, feature design logic (eg slopes) etc, etc in all ports.

With this type of thing in place it becomes a lot more feasible to avoid incompatibilities between ports (such as the 3DMidTex LF_ flag in Eternity) with out us having to manually check all the ports each time we want to implement anything.

This would also allow us to highlight any existing compatibilty problems and work together to resolve them.

However, given the closed nature of some ports (thinking mainly of Risen3D here) I don't know how successfull such an initiative might be...

Also it fully depends on ALL port authors being willing/interested enough.

[Jon]

DaniJ said:

However, given the closed nature of some ports (thinking mainly of Risen3D here) I don't know how successfull such an initiative might be...

I think ignoring the fact Risen3D exists at all might be the best course of action for everyone.

[Graf Zahl]

Quasar said:

Which is why linedef/sector/thing namespaces for different ports were, IMO, a critical idea. There are a number of reasons why it is neither convenient nor practical for these things to match between all ports. But if they could be interpreted relative to the map's intended target, then runtime translation is suddenly possible and it doesn't matter any more. But this idea looks like it will pass away unheeded.

I think the best course of action is to avoid using types that are already in use somewhere else at all. Then you wouldn't need port specific handling. But obviously that can't be done anymore. If Legacy was taken out of the equation it wouldn't even be necessary to think about this if I am not mistaken. I don't think that EDGE, Eternity and ZDoom have any type collisions at all in their standard definitions. For this I'm ignoring custom definitions for EDGE or altered translation tables for ZDoom.

[Enjay]

Zeroth said:

if you want features, sure...but why crouching -- in Doom?

Why not? It's fun. I like it. So do other people. Surely that's what it's all about.

You can only change so much about Doom before, well, it no longer feels like Doom when you play it.

So, don't use the features you don't like and don't play maps that require them. How hard can it be to not do something?

two cents deopsited.

£0.02 paid in reply. ;)

[TheDarkArchon]

Enjay said:

£0.02 paid in reply. ;)

A penny would've sufficed, yno ;)

[Cyb]

I don't understand. I mean, fine, if you dislike the feel of ZDoom or EDGE or Legacy or Eternity then that's fine. If you feel the features shouldn't be there then that's fine, it's very simple to just not use a specific port. Nobody is forcing anything on you. You don't have to play ZDoom maps if you don't want to.

But this talk of standards and what should and shouldn't be in a Doom port is ridiculous. First off, all ports are made because the author loves the game and loves programming. They make no money off any of this and they add what they like based on user input or just something they see fit. If someone wants to change the behavior of invisibility, then what is the big deal? If you don't like it then stick to a port that doesn't alter much.

And standards is even more ridiculous. This is Doom, people, stop taking it so seriously. If a map only works in ZDoom or Eternity then why must it work in other ports? What's even the point of that? If it can play original maps then that's about all that matters. Everything else is entirely up to the port author. It just seems like if you had some kind of standards then you'd have authors wanting to add a feature but not able to because other port authors would have to agree on if they wanted it or how to implement it.

So this really seems like complaining for the sake of complaining in the end. There's no purpose because all of this discussion has been entirely unproductive. It'd be one thing if this had some adverse effect on Doom as a whole, but it doesn't. doom2.exe is still around, and you are free to use it. In fact you are free to use or not use any port you want.

But whatever, this sort of bullshit has been present among Doomers (and I'm sure most other gaming communities) for as long as I can remember (and I have been a part of this community in varying degrees of involvement for a good 8 or 9 years) and I don't expect it to stop. I just can't wrap my head around why it bothers people so much when there is such a clear ability to pick what you want to use and what you do not want to use.

[Enjay]

DaniJ said:

What I think would be of great benefit to all us port authors is a central place to register extensions beyond the base DOOM/HEXEN so that we can attempt to avoid overlaps in future.

For example a database of new line types, line/mobj flags, feature design logic (eg slopes) etc, etc in all ports.

Some sort of cooperation along those lines would be sensible.

Also it fully depends on ALL port authors being willing/interested enough.

Which is partly where, I believe, previous initiatives fell down. :(

[Enjay]

TheDarkArchon said:

A penny would've sufficed, yno ;)

Well, a penny would have been 1.81978 cents. So, rounding up it would have been close enough for most people. But I made sure my £0.02 was worth more than his $0.02. (joking)

[edit]And I agree wholeheartedly with Cybs post.[/edit]

[june gloom]

Cyb smash

bravo. cyb summed it up perfectly. i propose this thread be closed; we're not learning anything from it, and it's just pointless flaming.

[Csonicgo]

Cyb said:

stuff

My name is CSonicGo and I approve this message.