On Compatibility

[Planky]

This isnt a post trying to convert people, nor is it to incite a flamewar. I am giving my opinion and want constructive feedback (hopefully some from smite and hurdler).

This comment (http://forum.drdteam.org/viewtopic.php?t=280&postdays=0&postorder=asc&start=45) by Graf has caused me a bit of concern:

They have everything laid out in front of them by other ports but what do they do? Create an incompatible MAPINFO! In other words, it will be impossible to do maps that work with both ZDoom and Legacy and use some of the enhanced features exposed through that lump!
Equally bad, it seems they did many linedef types which ZDoom already has differently. There goes all hope of even a minimal set of cross-port compatibility...

That is abit of a turn around from his original stance from the discussion about rebirthing the JDS.

I think in order for Legacy to regain alot of it's previous users and new users alike (lets not kid ourselves here, Legacy is nowhere near as popular as it once was), it has to be compatible with the dominant player - in this case zdoom. zdoom has set the standards and I don't think we can afford to ignore them and create our own method of doing things.

That said, I think it necessary to point out that Graf has made public a port he is working on called gzdoom. This intrigued me due to his comments about the JDS and his comment above. He has added opengl support, 3d floors and being based on zdoom, it means it already has acs and slopes (which means slopes on 3d floors (http://pages.quicksilver.net.nz/druids/3dfloor.jpg)). He has also nearly finished adding fragglescript support. From the look of things, he is going for a huge amount of compatibility with other ports (edge, vavoom, legacy and of course zdoom).

I am not suggesting that we try and achieve full compatibility. What I would like to see is a level of compatibility that all ports can share, while still retaining their uniqueness. What I am hoping to see here is discussion that will aid the development of Legacy for a result that will benefit us hugely.

What do you think? Do we need the compatibility (i've used that word too much, it looks and sounds odd now :P)? Can we offer something better than what has already been set as a standard? Am I ranting to the wind?

[xiO]

I'm curious to hear what smite and deepteam have to say about this.

[Danimetal]

So do I.

In a certain way Legacy´s current version (1.42) is way back other ports in diverse aspects (not in all, but in different aspects for different ports like graphics, features, stability... ) but is quite reliable in terms of classic Doom and, why not saying?, really underestimated by people.

My opinion in achieving compatibility is also related to the features that Legacy may offer. Some things, like 3d floors, were Legacy only before (as far as I know, I don´t know when Vavoom or Edge came out) and they made it unique... The only thing I can think of is to offer what the majority of advanced ports can offer now (I´m not mentioning what, of course, ´cos I don´t want to enter in what an advanced port is) and add something that still defines us (allow me to say us as I feel like part of the community), of course, making it compatible with other ports.

I know that getting Legacy to offer full compatibility, compatibility is not about features, I think, it´s about not crashing with other´s features, what, according to Graf_Zahl, is happening with the Mapinfo. Maybe I´m fully wrong, please, correct me if I am. Maybe this can be focused in two main ways:

-What features do we want to have.
-What features do we want to borrow-offer compatibility.

And the rest is about compatibility meaning discussion.

I know it means a lot of work for the Legacy team to get the thing running, so this discussion may add stress to them... God knows I´d want to join if I only knew a bit of code and that I´ll help them with any experience I´ve got (as I tried to do with test maps) if I´m given the chance.

PS: Of course, I love and respect Legacy as it is and don´t want to push anything. If I wanted to have other ports features, why wouldn´t I map for them?.

[Planky]

The other thing I must point out is that I understand the otherside of my view point Ive expressed above. Keep compatibility with vanilla doom, but go our own way and hopefully provide something that is worth having Legacy only maps etc (which is what most ports have been doing).

One of the main reasons of posting this is to get a decent gauge of what Legacy users feel need to happen. Perhaps I should have made this a poll.

[smite-meister]

They have everything laid out in front of them by other ports but what do they do? Create an incompatible MAPINFO! In other words, it will be impossible to do maps that work with both ZDoom and Legacy and use some of the enhanced features exposed through that lump!
Equally bad, it seems they did many linedef types which ZDoom already has differently. There goes all hope of even a minimal set of cross-port compatibility...
Strange. The "JDS MAPINFO" we were working on should AFAIK be perfectly ZDoom-compatible.
See for yourselves:
http://users.tkk.fi/~vberghol/doom/JDS_MAPINFO.html

About the linedefs, the only new non-ZDoom linedef we have introduced is linedef 150 in Hexen (number subject to change),
which is used for ALL Legacy/Boom extensions.

[Ajapted]

Some things, like 3d floors, were Legacy only before (as far as I know, I don´t know when Vavoom or Edge came out) and they made it unique...
Edge was the first with 3d floors (although RORdoom might have been earlier, but it was only a minor port).

The question of compatibility is a hard one. You need to distinguish your port somehow, so you can't spend all your efforts on being compatible (but you should of course spend some time on it).

ZDoom is a very feature-rich port, imho it would be crazy to try to match it feature-for-feature. Select the ones that make the most sense (e.g. the one to control flat alignment).

[deepteam]

Graf's pov is no surprise *smirk* If you are interested in other replies here see the posts by Tiealk too (that's him). FYI - he bashes Legacy quite regularly (obviously not here). If you'd read what he's posted elsewhere (esp ZDOOM forum), I think it will make your eyes *spin*

Part of the Legacy problem I think is caused by the internal node process in Legacy which I just discovered myself. If the nodes are not created by ZENNODE, it goes into a loop at startup and once even rebooted by XP system. The last is quite unusual on XP to say the least. Too bad I didn't notice this earlier or I would have notified you. It's bad enough that it should be fixed ASAP unless you can get the 2.x release done. [Danimetal sent me a WIP that exhibited this problem when I built nodes myself - probably fake 3D bridge induced]

As to his attitude : basically it goes back to my first post on this - most port (and utility) authors are loathe to change anything they already have, even the most trivial of changes, even if the change makes life simpler and rationalize the difference :)

NIV (Not Invented Here) is the enemy over and over again (and not just port code). In fact, there's a discussion in GZDOOM about scaling hires PNG textures and PNG placed between TX lumps that can't be true color (easy to do using PNGLIB). Is there any attempt to discuss this with ANY OTHER PORT AUTHOR? NO (Note there's actually a pretty good compromise solution for scaling that suits editing and ports]

Overall, the idea should be to make stuff fit into existing definitions where possible. And that requires port authors to examine other ports work and to exchange ideas and allow for flexibility. Will that ever happen?

[Aliotroph?]

About the linedefs, the only new non-ZDoom linedef we have introduced is linedef 150 in Hexen (number subject to change),
which is used for ALL Legacy/Boom extensions.

Was he referring to some of the linedefs Legacy already has for DooM?

[DaniJ]

Well that is exactly what I'm doing in developing Doomsday. Before I add ANY new editing feature I always do the rounds and check how its being done in the other big four (Legacy, Zdoom, Edge, Vavoom). It makes sense not to reinvent the wheel time and time again and if you can do it in a cross-port compatible way then surely any rational person would do so.

If they are considering reinventing the TX lump stuff they're crazy. How can they in one post - shout down Legacy for it's linedefs breaking the possibility of cross-port compatibility and then in another openly ignore the way a feature has already been implemented in another port and go about designing another wheel?

I must admit I'm not exactly surprised that comment came from Graf. He continues to consistently bash other ports (and as of late even his beloved Zdoom because Randy "isn't doing his job"!?) and more often than not the reasons he cites are either ill founded or based on a much older version of the port in question.

I wouldn't worry that much about it. Look at it this way: If Graf keeps up this kind of behaviour will any port author support any GZdoom features?

BTW Deep: I'm still very interested in the changes you made to Doomsday's texture manager for R3D/R3DEdit. I'd like to support both the TX and the Risen3D external folder methods for texture replacement in Doomsday. As you've already developed these then it makes no sense me starting from scratch when there is existing code that can be feasibly intergrated.

[Planky]

Graf's pov is no surprise *smirk* If you are interested in other replies here see the posts by Tiealk too (that's him). FYI - he bashes Legacy quite regularly (obviously not here). If you'd read what he's posted elsewhere (esp ZDOOM forum), I think it will make your eyes *spin*


Well despite that, he has been generally supportive when he posts here.

Part of the Legacy problem I think is caused by the internal node process in Legacy which I just discovered myself. If the nodes are not created by ZENNODE, it goes into a loop at startup and once even rebooted by XP system. The last is quite unusual on XP to say the least. Too bad I didn't notice this earlier or I would have notified you. It's bad enough that it should be fixed ASAP unless you can get the 2.x release done. [Danimetal sent me a WIP that exhibited this problem when I built nodes myself - probably fake 3D bridge induced]

This is the first time I have ever heard this, but I don't think it's a major factor people point out when complaining about Legacy. It doesnt crop up on the c++ version.

[Graf_Zahl]

About the linedefs, the only new non-ZDoom linedef we have introduced is linedef 150 in Hexen (number subject to change),
which is used for ALL Legacy/Boom extensions.


In other words, you are not using an already established interface (i.e. ZDoom's - also used by Vavoom) for translating Boom's specials into Hexen format but instead are doing it differently. Thanks for proving my point!
The only thing you really needed something new for is FraggleScript and 3D-floors, nothing else.

[Planky]

So if we change that linedef (which smite said is subject to change anyway), we are using the 'established interface'?

[Graf_Zahl]

NIV (Not Invented Here) is the enemy over and over again (and not just port code). In fact, there's a discussion in GZDOOM about scaling hires PNG textures and PNG placed between TX lumps that can't be true color (easy to do using PNGLIB). Is there any attempt to discuss this with ANY OTHER PORT AUTHOR? NO (Note there's actually a pretty good compromise solution for scaling that suits editing and ports]

Typical. This is utter bullshit - warped beyond recognition so that it fits your argument. Yes, there was a discussion about Hires textures. And in that discussion I said that I intend to support ZDoomGL's way of defining hires textures - a) because it is the method I consider the best and b) because that's the port I'm most interested in to have compatibility with.
And why can't PNGs between TX_START/END not be True Color? Simple! Because these textures are handled by the normal texture manager which can't do that (and I won't rewrite it to do so because it has to work in software mode as well.)

As for Doomsday style texture packs: I already support these although something has to be done about their directory organization. As long as there is no clear way to separate textures belonging to different WADs it is useless as a mapping feature.

[Graf_Zahl]

So if we change that linedef (which smite said is subject to change anyway), we are using the 'established interface'?

The best idea is always to be as consistent with the interface you want to be compatible with. For Hexen-style linedefs it is inevitably ZDoom, particularly now that Vavoom has copied the exact same assignment for all types so yes, if there is a type assigned to a particular Doom/Boom linedef it should be the same. Everyone would profit from it because it would create a much larger user base for mappers using these features and in return would convince mappers to use these features in their maps.

The other issue I originally mentioned was MAPINFO. In this case it is particularly important that absolute compatibility is maintained so that mappers can put a lump in their WAD and be sure that it works with all supported ports. Sadly that might exclude Vavoom becasue it chose to name a few things differently which make ZDoom abort with a syntax error. I think this scenario should be avoided.

[Danimetal]

Well... All this discussion is interesting but maybe it´s getting out of the focus that Planky tried to establish. What about the JDS thread?. That could be a good place to discuss matters of compatibility while this one could remain to proposals of Legacy enhancement.

[DaniJ]

As for Doomsday style texture packs: I already support these although something has to be done about their directory organization. As long as there is no clear way to separate textures belonging to different WADs it is useless as a mapping feature.Quite the opposite in fact. The physical data/GAME/texture folders were never intended to be used for textures for PWADs. The Doomsday ideology is that anything in the data/game folders are for replacing the originals only. If you want to use custom REPLACEMENTS in a PWAD then you should package your hires textures along with your WAD into one of the supported addon formats ie .addon or PK3 or use the virtual directory mapping feature to remap your mod's /resources/type folder to the game's /typeofresource folder dynamicaly at runtime.

It may sound complicated but in practice it is very easy to use/understand. For example:MyCoolLevel.PK3
/textures # contents mapped automatically to the data/GAME/textures
/sounds # same but destination is data/game/sounds
mywad.WAD

The idea being that during development of your mod you create a folder somewhere on your harddrive and then map that folder to your Doomsday data/game folder using the -vdmap command line option. That way you can have everything in a nice tidy manner totally seperate from the originals. Also it means when your mod is finished you only need to right-click->Add to Zip and you've got a fully built addon ready to distribute.

To clarify user created mods should not use the physical Doomsday/data/GAME/resource folders.

At this time we have not chosen a method to allow for creating new textures (hires or otherwise).

Getting back on topic:
Regarding MAPINFO - the problem as I see it is that Legacy, Zdoom, Vavoom have all extended MAPINFO in different ways (Doomsday is excluded as no new features have been added to the lump, only to the MapInfo DED definition so it would be easy to offer compatibility for any of the others). The question is "Can I support the other ports features, in a clean fashion, without losing any of the features in my existing implementation". From what I've read this is a problem facing both Legacy and Vavoom for different reasons. The biggest hurdle being keynames that mean different things but accept the same type of values...

Doomsday's POV is different. It is a case of "who is doing what? how are they doing it? which methods should we support?". So obviously for Doomsday the logical answer is to go with the most used with regard for each feature/keyname, which at even a cursory glance is Zdooms method due to the number of existing Zdoom-specifc PWADs.

[Graf_Zahl]

Quite the opposite in fact. The physical data/GAME/texture folders were never intended to be used for textures for PWADs. The Doomsday ideology is that anything in the data/game folders are for replacing the originals only. If you want to use custom REPLACEMENTS in a PWAD then you should package your hires textures along with your WAD into one of the supported addon formats ie .addon or PK3 or use the virtual directory mapping feature to remap your mod's /resources/type folder to the game's /typeofresource folder dynamicaly at runtime.
It may sound complicated but in practice it is very easy to use/understand. For example:MyCoolLevel.PK3
/textures # contents mapped automatically to the data/GAME/textures
/sounds # same but destination is data/game/sounds
mywad.WAD

The idea being that during development of your mod you create a folder somewhere on your harddrive and then map that folder to your Doomsday data/game folder using the -vdmap command line option. That way you can have everything in a nice tidy manner totally seperate from the originals. Also it means when your mod is finished you only need to right-click->Add to Zip and you've got a fully built addon ready to distribute.

To clarify user created mods should not use the physical Doomsday/data/GAME/resource folders.



That's logical. So this means I hopefully don't have to worry that this might be used to replace textures for a PWAD.

The biggest issue with hires textures right now is for me that there are 3 radically different philosophies regarding the additional data:

- Doomsday using .PK3 and a special directory structure
- Vavoom using a Quake-style directory layout
- the 'one WAD' approach ZDoomGL prefers

And since ZDoomGL is the closest thing to GZDoom and I prefer that way of doing things myself it will be what I do. A generic compatible solution here is most likely not possible due to the major differences in the way of handling things.


Getting back on topic:
Regarding MAPINFO - the problem as I see it is that Legacy, Zdoom, Vavoom have all extended MAPINFO in different ways (Doomsday is excluded as no new features have been added to the lump, only to the MapInfo DED definition so it would be easy to offer compatibility for any of the others). The question is "Can I support the other ports features, in a clean fashion, without losing any of the features in my existing implementation". From what I've read this is a problem facing both Legacy and Vavoom for different reasons. The biggest hurdle being keynames that mean different things but accept the same type of values...


The biggest issue with MAPINFO is that the format is fundamentally not extendable without creating incompatibilities. If there was a simple way to ignore unknown keys it could be so much easier. :(

[DaniJ]

Just to continue the hires textures topic:

Doomsday also supports two other methods for including PWAD specific resources though these two (to my knowledge) are hardly used atm for the reasons listed below:

DD_DIREC (http://deng.sourceforge.net/dew/Editing/DD_DIREC) - This method was implemented a while back and allows any type of resource modifiable in Doomsday to be included as a raw data lump directly in a PWAD.
NOTE: Due to the apparent complexity of the method (plus use of an additonal tool called wadtool), the advent of PK3 and now the new .addon format this method I have yet to see implemented in a PWAD.

Lump Assembly (http://deng.sourceforge.net/dew/Editing/LumpAssemblyOverview) - This method has only recently been implemented (though in essence it has existed since the virtual file system was first implemented as its based on the /auto folder implementation). The idea behind this method is to completely remove the need for apps such as XWE because a WAD can either be 1)a folder somewhere on your harddrive 2)a virtual lump assembly inside a PK3. Net result is that a mod doesn't have to include a PWAD at all, the lump name restrictions are instanly a thing of the past and any file format can be used directly. So far this method hasn't yet (again to my knowledge) been used in a PWAD as currently it makes more sense to work with a PWAD or PK3/.addon with a PWAD inside it. The main drawback preventing its use is that currently no level editors support the format (something I hope might change in the future) meaning that in order to use the system as intended you'd need to manually extract the level lumps from a PWAD and put them in a Lump Assembly. However its also valid to nest a PWAD inside a Lump Assembly (so now you've got a WAD inside a WAD)...

And on top of these you also have the -texdir option to change where Doomsday looks for original texture replacements, which can be used to instead work as a way of having a PWAD specific texture folder.

Now, I don't expect any other port to offer support for these features as if you examine how the system works in practice you'll notice that it is possible to combine container formats and virtual mappings in many dozens of different ways (eg PWAD in a PK3 in a .addon. Or in an extreme case: DD_DIREC + raw lumps in a Lump Assembly in a PK3 in a Lump Assembly in a -vdmap'd .addon).

The whole idea behind this complicated set of interwoven features is that you can design an aggregate container format for your mod, rather than having to make your mod conform to any one particular format. So for example you can have one addon with a dozen or so other addons nested inside it that can be configuredf in the addon's own options screen in Snowberry (we arn't talking simple stuff either as the meta data in an aggregate container can be set up to control which parts inside the addon are used, or to dynamicaly #include different DEDs from other nested addons in the container, or to change the virtual file hierarchy in the addons so different parts of the addon can be merged together dynamically).

Such is the complexity of the system I haven't had time to even scratch the surface, documentation-wise, as to whats possible... :(

So infact Doomsday in itself has at least a half dozen different ways to define custom texture replacements in a user-made level and then a few dozen more container format combinations.

[Ajapted]

The biggest issue with MAPINFO is that the format is fundamentally not extendable without creating incompatibilities. If there was a simple way to ignore unknown keys it could be so much easier. :(
There is a simple way: when you find an unknown key, ignore it :)

Perhaps you're talking about whole sections being unknown. For that I suggest we invent a special keyword for adding new sections to the format (e.g. "section legacyjiblets").

[Graf_Zahl]

There is a simple way: when you find an unknown key, ignore it :)


That works as long as you know that it only uses one parameter. Too bad that that is not the case for all keys. :( There are some without parameters, some with one, a few with two and even more. Keys aren't even limited to one line so not even that would work.


Perhaps you're talking about whole sections being unknown. For that I suggest we invent a special keyword for adding new sections to the format (e.g. "section legacyjiblets").

To be honest, if we really want compatibility we'd need a format where it is easy to ignore unknown content - but the current MAPINFO won't be suitable.

[Ajapted]

Looking at the ZDoom wiki, I thought MAPINFO was a line-based format. Is that true, or can you have multiple commands per line?

If it were line-based, the only obstacle would be commands that can span more than one line. In the examples I only noticed the finale texts, which are distinguishable since the string is not terminated on the line it starts on. What else is there?

[Graf_Zahl]

The format is completely token based, i.e. a newline is equivalent with a space - and newlines inside strings are part of the string. Example:


exittext
"Nuts! Somehow you cooked 'em all and
shut the place down! You check the
tower to see if there's a way to
contact your boss.

But nothing works! No satellite link,
no radio, not even a damn homing
pigeon--just shotgun-blasted consoles
and smoking wires. In disgust, you
start kicking everything in sight...

Suddenly there's a *SNAP* in the air,
the lights go out, and you hear the
low rumble of thunder that you slowly
realize isn't thunder at all.

Uh-Oh..."


This is one command with one string parameter.

[Ajapted]

Token based without delimiters = pain :-(

Only two options: try to make MAPINFO extensible (dictate special syntax for all new keys), or create a whole new format (in a new lump). First option won't fly unless all the hexen port authors get on board (seems unlikely).

Second option means duplicating code, old reader vs new reader, though we can try to minimise that in the design, for example: if new format was line-based, could do a fairly simple conversion from old to new -- collect tokens for each key and put them on a "logical" line (have a mechanism to extend lines like \ character in C).

[deepteam]

Typical. This is utter bullshit - warped beyond recognition so that it fits your argument.
Graf you always amaze me in how you get so upset and do exactly what you claim I'm doing - iow distort beyond recognition. It's NOT utter bullshit [stick to facts and please explain what part is bs]. Here's the proof that you can verify which follows:
Yes, there was a discussion about Hires textures. And in that discussion I said that I intend to support ZDoomGL's way of defining hires textures - a) because it is the method I consider the best and b) because that's the port I'm most interested in to have compatibility with.
Thanks you, that's exactly my point. You've rationalized a poor decision. It's NOT a good way since it's 100% NOT editing friendly. Just because ZDOOMGL choose a poor method is hardly a reason to recommend it. The only addition a text lump can have is for ADDITIONAL options, but not for the BASICS of a texture - size and scaling - and that's a reasonable compromise. There is little to no impact since few PWADs (maybe some demos) exist. So discard it for the sake of a simpler and more flexible solution.
And why can't PNGs between TX_START/END not be True Color? Simple! Because these textures are handled by the normal texture manager which can't do that (and I won't rewrite it to do so because it has to work in software mode as well.)
And again thank you. That's total BS Graf. It's relatively easy to accommodate this. So rather than your typical excuse that (those who don't know ignorantly accept) this is actually quite easy to do.

Sure it requires changes - to not do true color is missing the whole point of GL :) See R3Dedit for all the ways you can use Textures, patches, flats and PNGs interchangeably no matter where they reside between markers - IOW it's another counter to the argument that "ZDOOM can't do it because it's coded that way". All it means is that ZDOOM didn't think of a solution to the problem - NOT that it can't be done that way.

The real reason is that one you posted (not this one - brand new made up for this discussion). And that is that you don't have a true color decoder or converter and you didn't want to use a LIB. Hint: If your were openminded and actually looked at PNGLIB, you'd have realized what else it can do. And that solves the software claim.

How does it relate to compatibility? Well the problem with both of ZDOOM's authors is that both are extremely dismissive of ANY OTHER SOLUTION, esp when it comes to what other ports do. That's ignoring the denigration both display towards anything not ZDOOM should give everyone pause as to how flexible that attitude becomes in a discussion of "cross port compatibility".

Any criticism of how something is done shouldn't be reacted to in a violent manner. Nor should the reasons be accepted for what they are. Forget irrational statements and assumptions that are just not true. Once you support 32-bit color, then the rest becomes just details.

And that's how the standard should be: PNGs (paletted and 32-bit color or gray scale for that matter) should be allowed between TX markers. And same PNGs should be allowed as a patch (makes both editing and scaling trivial) AND simple AND consistent. Then fix the mistake RH made in not scaling a TX marker name to an existing TEXTUREx name (just like JDOOM does with external textures) and that makes it trivial to set the size and ignore the scaling values - although those could still be used. And then you can get rid of the"world" flag which was a poor attempt to fix the poor design choice made in the first place. IOW not needed at all had it been thought out more and listen to feedback :)

But see how even something like this (hires-truecolor PNGs) become wrapped in a discourse that doesn't allow for a discussion, but instead is detoured by false statements. Is that how you get compatibility/progress - not do it just because ZDOOM can't handle it?

Please look beyond ZDOOM as a barrier. The basics of some areas can easily be made the same - especially regards textures and editing ease of use.

[deepteam]

Token based without delimiters = pain :-(
I don't see a real problem here. I'm for the easiest most compatible solutions. MAPINFO works quit well as done- although a bit too wordy for some things:)

The topic should revolve around what else should it contain or perhaps syntax addtions, not whether it's tokenized or not.

[deepteam]

BTW Deep: I'm still very interested in the changes you made to Doomsday's texture manager for R3D/R3DEdit. I'd like to support both the TX and the Risen3D external folder methods for texture replacement in Doomsday. As you've already developed these then it makes no sense me starting from scratch when there is existing code that can be feasibly intergrated.
This is better done via email, since that will allow me to more accurately convey my thoughts. Not all people can converse as well as you. I hope I can clarify what I can probably do for you and what would be a problem.

[deepteam]

Well despite that, he has been generally supportive when he posts here.

This is the first time I have ever heard this, but I don't think it's a major factor people point out when complaining about Legacy. It doesnt crop up on the c++ version.
Of course - but that's the whole problem. He's not being HONEST when he posts here. Or how would you like to reconcile the denigration (putdowns of Legacy) vs the posts here?

And as to the crashes - why do you think Graf says he can't run Legacy? It appears to depend 99% on whether Zennode was used to build the nodes for levels with relatively complex areas. At a guess, most Legacy users use Zennode (since it was modified for Legacy and hence the best nodebuilder for Legacy) and thus will rarely see this come up.

In fact, I'd never seen this before (or I forgot) since I rarely did what I was doing for Danimetal - trying to see why some rendering artifacts were showing up. In the course of solving this, I had to rebuild nodes and presto - lockups. Then I tried some others of moderate complexity and had the same result.

All that I mean to convey is very factual information and express concern that it be solved. Not that Legacy is bad or anything like that. Stuff like that is pretty high up on the "to fix" list, that's all

[Graf_Zahl]

Thanks you, that's exactly my point. You've rationalized a poor decision. It's NOT a good way since it's 100% NOT editing friendly. Just because ZDOOMGL choose a poor method is hardly a reason to recommend it. The only addition a text lump can have is for ADDITIONAL options, but not for the BASICS of a texture - size and scaling - and that's a reasonable compromise. There is little to no impact since few PWADs (maybe some demos) exist. So discard it for the sake of a simpler and more flexible solution.


What 'simpler solution'? There is none! All 'options' I have require some kind of convoluted setup that is far too messy and error-prone.


And again thank you. That's total BS Graf. It's relatively easy to accommodate this. So rather than your typical excuse that (those who don't know ignorantly accept) this is actually quite easy to do.

Sure it requires changes - to not do true color is missing the whole point of GL :) See R3Dedit for all the ways you can use Textures, patches, flats and PNGs interchangeably no matter where they reside between markers - IOW it's another counter to the argument that "ZDOOM can't do it because it's coded that way". All it means is that ZDOOM didn't think of a solution to the problem - NOT that it can't be done that way.


You are completely missing the point. None of your 'suggestions' helps with the one big problem concerning Hires textures: There has to be a place where you specify the scaling factor! The only kind of texture where that can be done is inside the TEXTUREx lump! So flats, TX_ textures and anything else that's just dumped into the WAD is out. And I prefer to listen to the people who want to use all that stuff and so far the general consensus among the mappers I talked with is that ZDoomGL's HIRESTEX lump is by far the easiest way to do it. Just define a texture and the size in world coordinates. No dependencies on other stuff is needed - and it doesn't require the introduction of complicated new data structures, new file formats like PK3 or other ugly stuff that only serves to confuse mappers.


The real reason is that one you posted (not this one - brand new made up for this discussion). And that is that you don't have a true color decoder or converter and you didn't want to use a LIB. Hint: If your were openminded and actually looked at PNGLIB, you'd have realized what else it can do. And that solves the software claim.


Some people are unwilling to read, aren't they? I am already supporting Doomsday-style hires texture packs - and logically I needed an external library to handle them. (I am using DevIL, btw. so once all is set up it will be able to read nearly any graphics format.) The one time I was mentioning my reluctance to make it depend on such a thing was before the introduction of hires textures and only concerned the saving of screenshots. For that alone I saw no need to make the distribution almost 20% larger.


How does it relate to compatibility? Well the problem with both of ZDOOM's authors is that there are extremely dismissive of ANY OTHER SOLUTION, esp when it comes to what other ports do. That's ignoring the denigration he (and RH) display towards anything not ZDOOM should give everyone pause as to how flexible that attitude becomes.


Let's say that some developers get dismissive when you are starting to make 'suggestions'. Far too often they have the same quality as the stuff politicians are saying, i.e. it sounds nice but doesn't hold up when closer examinated. For example, in this thread you haven't proposed a simple, easy to use and mapper friendly method to define hires textures. You only attacked the one format that some people consider the best. Yes, it wasn't my own idea to support it. It was suggested by (gasp!) Mappers who would like to have it!


And that's how the standard should be: PNGs (paletted and 32-bit color or gray scale for that matter) should be allowed between TX markers. And same PNGs should be allowed as a patch (makes both editing and scaling trivial) AND simple AND consistent.


Once I have written the true color texture class I need anyway it is probably a matter of a few lines of code to handle additional formats between the 'normal' markers. The code is already set up for this extension but this doesn't have the highest priority for me since you couldn't scale them anyway.


But see how even something like this (hires-truecolor PNGs) become wrapped in a discourse that doesn't allow for a discussion, but instead is detoured by false statements. Is that how you get compatibility/progress - not do it just because ZDOOM can't handle it?


Again: How would you do it? Putting the lumps in the WAD isn't the problem. Only the scaling factors are. They have to be specified somewhere.


Please look beyond ZDOOM as a barrier. The basics of some areas can easily be made the same - especially regards textures and editing ease of use.

The fact remains that I based GZDoom on ZDoom - and as such compatibility to it is my paramount concern and I won't do anything that might jeopardize this. In a few instances it means that I have to limit myself in ways I don't really like but that's life. You can't have everything the way you like it.

[Graf_Zahl]

Of course - but that's the whole problem. He's not being HONEST when he posts here. Or how would you like to reconcile the denigration (putdowns of Legacy) vs the posts here?


And you are? Yeah, whatewer!


And as to the crashes - why do you think Graf says he can't run Legacy? It appears to depend 99% on whether Zennode was used to build the nodes for levels with relatively complex areas. At a guess, most Legacy users use Zennode (since it was modified for Legacy and hence the best nodebuilder for Legacy) and thus will rarely see this come up.


It's not the nodes. I'm not that stupid that I can't think of that. Legacy 1.42 just runs like shit on my computer. It prefers to crash randomly with no relation to the map or the nodes - and even if it runs it is so slow that I can hardly play it (think 10 fps.) This is more a compatibility issue between some low level software Legacy uses and my computer. I am suspecting Allegro to be the cause of the trouble because the 1.99 betas work much better - and are as stable as can be expected from them.

[deepteam]

Graf you are not READING what I wrote. I described EXACTLY the method for scaling, but since you are not much of a mapper you didn't pick up on it. FYI I mapped for many years and still do. It was my frustration with DEU that I wrote DeeP in the first place.

IOW, in light of that is how I view engine mods. It's ALL THERE. Covers ALL the various forms: TX, external, TEXTUREx and even FLATS (in the sense of using them on floors/ceilings). Read it again. It's not convoluted, it's simple, it follows ALL the existing standards. IOW, if it's convoluted then it was convoluted to begin with. But that doesn't really matter since everyone knows how it works. Plus the tools available now are duck simple compared to the archaic methods of yesterday.

It holds up 100% to close scrutiny. The argument you present (always the same one) is pretty specious [as a politician I think is what you call it :)]. Mappers have NEVER SEEN an easier method therefore they say they like the external text format (non-editor friendly that it is without any sort of scaling feedback). They just wanted a solution - so the first one they see they say they like, despite its obvious problem. Your coding problems are imaginary in the sense that (as I said before) you just don't have the code to handle what you perceive to be unsolveable because RH didn't figure it out *chuck*

The problem with your solution is real simple : If you can't SEE the texture in an editor in the size intended, then the solution sucks. I'm always amazed at how the basic editing POV is so readily ignored by port authors. Having a few diehards who are willing to forego feedback is hardly a convincing argument. There is a place for something like the text lump for graphics that are NOT involved in the texturing of a level - like fonts, sprites, etc, but don't force the most used part of editing into that awkward mode.

Any argument that you don't need to see the texture reminds me of the argument when I put texture feedback in DeeP and all the DEU guys posted that was not required. And guess what ALL the other editors ended up doing? And believe it or not, this can work for FLATS (again reread what I wrote about that), although that's now superfluous since FLATS and patches and Textures are interchangeable. IOW, even if you can't figure out the FLAT detection, it's a moot point.

What I described about textures and scaling fits easily into ANY format, internal or external formats WITHOUT the requirement of anything new. The scaling factors are obvious, they are either the texture size or you can use the scaling args already present. This means creating a TEXTUREx/PNAMES pair, but really that's trivial work with today's tools. Doing so immediately makes it editor friendly and also leverages a huge amount of existing code.

You said that true-color can't be done because of the software aspect of ZDOOM - isn't that what you said above.
And why can't PNGs between TX_START/END not be True Color? Simple! Because these textures are handled by the normal texture manager which can't do that (and I won't rewrite it to do so because it has to work in software mode as well.)
Seems it is. So are you now reneging on that? I can only go by what you say. That you now expand it (although I didn't see true color mentioned) is sort of like changing your position without making it sound like my main issue was really on target - that is, true color must be supported. Program size is hardly a material argument here. So what if it's 20% larger? Sounds like a convenient reply.
-----------------

I'm surprised you can't just take my remark about Legacy at face value and again guessing about Legacy. Your computer isn't that different from many others. I did my best to explain, but again you want to defend ("I'm not that stupid") vs accepting that there's a bug in the Legacy internal node "fixing" that causes all sorts of problems as I described. It may affect other systems differently, but pretty sure that's the source of the problem with nothing else intended. Don't be so hypersensitive :) No need to thrash Legacy because there's a bug in that area is there?

My point is that other ports don't need to be limited by your outlook. In fact, I find it amusing that you've gone over to the enemy (so to speak) in adopting "eye candy" *party* despite voluminous posts discounting same. Eventually I expect the MD2's to be "borrowed" from JDOOM and so forth. Indeed, it's the "eye candy" that becomes the appeal in further expansion of DOOM. Welcome to the future *smirk*

And yes I'm quite honest when I post about my ideas and concepts. Clearly you are dishonest since it's easy to find many post where you bash Legacy for example, although other ports qualify :) Or please point out where I'm being dishonest? Just to clarify: dishonesty is misrepresenting what you truly believe.

FYI you'll never be compatible with ZDOOM in the rendering dept - issues will always crop up - so forget that line of thinking. In fact, thinking like that will hinder advanced ideas and in fact you are already NOT compatible with ZDOOM as you well know. Again you've made a deceptive post. IOW, it's a fact that ZDOOM compatibility is gone *party*

[iori]

If you two weren't at odds 24/7 this thread might be a little easier to decipher. Now, the topic is - as stated in the title of this thread - compatability. Please keep the personal attacks and insults down to a dull roar, and focus on the topic at hand. Thank you. And Planky is a poopypants. That is all.


MOD: No YOU are teh pooper pants!

[Graf_Zahl]

Graf you are not READING what I wrote. I described EXACTLY the method for scaling, but since you are not much of a mapper you didn't pick up on it. FYI I mapped for many years and still do. It was my frustration with DEU that I wrote DeeP in the first place.

IOW, in light of that is how I view engine mods. It's ALL THERE. Covers ALL the various forms: TX, external, TEXTUREx and even FLATS (in the sense of using them on floors/ceilings). Read it again. It's not convoluted, it's simple, it follows ALL the existing standards. IOW, if it's convoluted then it was convoluted to begin with. But that doesn't really matter since everyone knows how it works. Plus the tools available now are duck simple compared to the archaic methods of yesterday.

It holds up 100% to close scrutiny. The argument you present (always the same one) is pretty specious [as a politician I think is what you call it :)]. Mappers have NEVER SEEN an easier method therefore they say they like the external text format (non-editor friendly that it is without any sort of scaling feedback). They just wanted a solution - so the first one they see they say they like, despite its obvious problem. Your coding problems are imaginary in the sense that (as I said before) you just don't have the code to handle what you perceive to be unsolveable because RH didn't figure it out *chuck*


Please enlighten me. You are right. I am not a mapper and I didn't pick it up. If you have something better than ZDoomGL's solution I wouldn't hesitate to implement it.


The problem with your solution is real simple : If you can't SEE the texture in an editor in the size intended, then the solution sucks. I'm always amazed at how the basic editing POV is so readily ignored by port authors. Having a few diehards who are willing to forego feedback is hardly a convincing argument. There is a place for something like the text lump for graphics that are NOT involved in the texturing of a level - like fonts, sprites, etc, but don't force the most used part of editing into that awkward mode.


Believe it or not. I fully agree with that. The same problem exists with ZDoom's way of rotating and scaling flats but to solve that we'd need a new map format. As long as we are limited to that all kinds of crap solutions will appear and disappear. If it was possible to set the texture scale on the sidedef this discussion wouldn't be necessary.



What I described about textures and scaling fits easily into ANY format, internal or external formats WITHOUT the requirement of anything new. The scaling factors are obvious, they are either the texture size or you can use the scaling args already present. This means creating a TEXTUREx/PNAMES pair, but really that's trivial work with today's tools. Doing so immediately makes it editor friendly and also leverages a huge amount of existing code.


Ah. If your solution is to keep everything as it is and force the mapper to use TEXTUREx/PNAMES to define their hires textures we have a problem - in fact a big one.

a) There is no fallback for software mode (maybe some mappers just want to add a few hires texture replacements that only get used when running the map in GL but they also want to keep compatibility with ZDoom.)
b) It's a matter of fact that some people hate this way of defining textures. They want something easier to use for this particular task - and that's where the text lump comes in. The requests I got cited exactly this issue.

So we are at a point we have been several times: You are advocating the way that makes it easier for you to keep your editor up to date. Sorry, I'm not in that business and prefer to give the people what they want.


You said that true-color can't be done because of the software aspect of ZDOOM - isn't that what you said above.


That's why I don't want to force solutions upon the mapper that inevitably make their WADs incompatible with software ZDoom just by using hires textures. For that I need a replacement option.


Seems it is. So are you now reneging on that? I can only go by what you say. That you now expand it (although I didn't see true color mentioned) is sort of like changing your position without making it sound like my main issue was really on target - that is, true color must be supported. Program size is hardly a material argument here. So what if it's 20% larger? Sounds like a convenient reply.


I am not changing anything - at least for now. I really don't see much of a gain to allow True Color textures everywhere. Most of the time they just eat up space without giving any noticable benefits. But what they do is create massive performance issues, e.g. when used in conjunction with Boom-style colormaps. The performance cost of remapping them is utterly prohibitive.



I'm surprised you can't just take my remark about Legacy at face value and again guessing about Legacy. Your computer isn't that different from many others. I did my best to explain, but again you want to defend ("I'm not that stupid") vs accepting that there's a bug in the Legacy internal node "fixing" that causes all sorts of problems as I described. It may affect other systems differently, but pretty sure that's the source of the problem with nothing else intended. Don't be so hypersensitive :) No need to thrash Legacy because there's a bug in that area is there?


So WADs like Nimrod, Icerial2 and Hi-Tech Hell are corrupt by your definition because Legacy crashes when I play them out of the box. Hmm... It can't be the nodes because they appear to work for everyone who happens to be able to run Legacy - and I don't experience these crashes with the 1.99 beta so something that was changed between these versions has to be the cause for the instabilities which btw. never happened on my previous machine.


My point is that other ports don't need to be limited by your outlook. In fact, I find it amusing that you've gone over to the enemy (so to speak) in adopting "eye candy" *party* despite voluminous posts discounting same. Eventually I expect the MD2's to be "borrowed" from JDOOM and so forth.


Sure I will add MD2's. Not because I like them but because I know perfectly well that others like to have them. It was the same with hires textures. I have absolutely no need for them - and my personal view is that these textures destroy the look of the game - but there are others who like them and who want to use them. Adding such features doesn't harm my personal gaming experience and if I was that narrow-minded I never would have considered a public release. If you do that you no longer work for yourself.


Indeed, it's the "eye candy" that becomes the appeal in further expansion of DOOM. Welcome to the future *smirk*


I doubt that very much. If that was the case ZDoom would die an agonizing death and everybody would use JDoom. But the amount of activity in the respective forums tells another story.


And yes I'm quite honest when I post about my ideas and concepts. Clearly you are dishonest since it's easy to find many post where you bash Legacy for example, although other ports qualify :) Or please point out where I'm being dishonest? Just to clarify: dishonesty is misrepresenting what you truly believe.


So what? Of all the ports available it seems to have the most issues. The general instability makes Legacy 1.42 (please note the version number!) an easy target to bash - if you are talking with the right people, of course.


FYI you'll never be compatible with ZDOOM in the rendering dept - issues will always crop up - so forget that line of thinking.


So what? Do you really think I'm that delusional to think that I can emulate everything that works in software mode? Of course there are maps that don't work that well but that was inevitable from the start. But that doesn't mean I throw it all out of the window.


In fact, thinking like that will hinder advanced ideas and in fact you are already NOT compatible with ZDOOM as you well know. Again you've made a deceptive post. IOW, it's a fact that ZDOOM compatibility is gone *party*

Well, I disagree. Even though I will add some 'eye candy' features my main focus will be what it always was - and what ZDoomGL unfortunately hasn't managed so far (due to performance issues): to offer a source port that allows to play as many ZDoom compatible maps as possible with hardware acceleration. That's why I started this project in the first place.

[Planky]

I wanted this discussion about Legacy's compatibility with other ports, but it's obvious you two aren't going to stop attacking every point each other makes trying to get one up on the other.

I also wanted more input from Smite, but he's either busy (or not interested:)). I have been using Legacy nearly since it started, I don't want to see it fall due to lack of direction/leadership and discussion with the users that are affected by the changes being made.

[Ajapted]

I don't see a real problem here. I'm for the easiest most compatible solutions. MAPINFO works quit well as done- although a bit too wordy for some things:)

The topic should revolve around what else should it contain or perhaps syntax addtions, not whether it's tokenized or not.
Without delimiters, you can't be sure where each keyword begins and ends, so it cannot be extended robustly.

A partial solution: if you find an unknown keyword, ignore everything to the end of the line. MAPINFO is generally used in a line-based way (from what I've seen), so this would prevent (most of the time) accidentally treating an argument as a keyword.

[iori]

I also wanted more input from Smite, but he's either busy...
Busy is correct :D

[Rellik_jmd]

Compatablity is good, but after a while you just end up with clones. I sleep now.

[sl4]

Compatablity is good, but after a while you just end up with clones. I sleep now.

This is true, but myself and other non-Windows-using Doomers (I would think) would definitely not mind a Zdoom-compatible port that runs on other operating systems. Imagine if at some point in the future Action Doom or RTC-3057 was playable in Doom Legacy on Mac OS X. I don't know about you, but I'd personally say that'd be a very nice thing to have. *smirk*

[Danimetal]

Regarding compatibility and features, I think that a "To Do" list of what Legacy must have to regain popularity and confidence (some new things and some borrowed ones) should be arranged by the team according to the suggestions made in the pertinent thread.

Delaying v2.0 because of implementing more things could really delay things for users a lot and be really inconsistent: the changes that are going to be introduced (as far as I know) into v2.0 justify another installement of Legacy as well as the number 2 before its name, but the development should not rest there and move forward quickly so it offers even more. Maybe we need some more coders and that´s hard to get.

Another thing we´re sure to need is active mappers. Hopefully this can be fixed.

[DaniJ]

This is better done via email, since that will allow me to more accurately convey my thoughts. Not all people can converse as well as you. I hope I can clarify what I can probably do for you and what would be a problem.Great. I believe you already have my email address? I look forward to hearing from you.

[smite-meister]

A partial solution: if you find an unknown keyword, ignore everything to the end of the line. MAPINFO is generally used in a line-based way (from what I've seen), so this would prevent (most of the time) accidentally treating an argument as a keyword.
To me this sounds good. I always assumed MAPINFO would be a line-based format, with only one keyword per line.
Anything else makes very little sense. Of course, if we were designing things from scratch, I guess
XML would be the way to go;)

[Graf_Zahl]

Of course, if we were designing things from scratch, I guess
XML would be the way to go;)



XML is fine for machine generated files with nested or complex content. (like levels)

But as soon as you have something that has to be done by the mapper XML is not such a good solution. I have seen it far too often already that people who aren't that familiar with more technical stuff are completely overwhelmed by XML's syntax. I have to use XML a lot in my job and trying to explain how it works to a 'normal' person (even a less experienced programmer) can be an exercise in futility.

[smite-meister]

In other words, you are not using an already established interface (i.e. ZDoom's - also used by Vavoom) for translating Boom's specials into Hexen format but instead are doing it differently. Thanks for proving my point!
The only thing you really needed something new for is FraggleScript and 3D-floors, nothing else.
This was not my intention, I did not realize ZDoom had the Boom stuff already transferred to Hexen format.
We'll switch to the ZDoom system before the 2.0 release.

I took a better look at ZDoom Wiki, and found corresponding Hexen types for everything except Boom's linedeftype 260 (translucency map). How do you do that?

[Graf_Zahl]

Zdoom doesn't do a proper translation of linedef 260. It just translates it to a standard TranslucentLine with an alpha of 66% which was Boom's default. In other words, translucency maps aren't handled by it. The reason for this is that apparently they can't be made to work with the current lighting/fog system (and of course the fact that there are only very few maps that use it.)

If you want to do it properly you can use one of the unused arguments of the special for this case.

If you need a complete list of how ZDoom translates all the specials in Doom and Heretic you can download the source and take a look at the files wadsrc/xlat/doomxlat.txt and hereticxlat.txt. That are the source files which get compiled into the linedef translation tables.

[deepteam]

I'm not going to drag this on and one - so let me clarify to the others that your viewpoint is contrary to editing friendliness AND port compatibility - a fact you acknowledge yet attempt to justify. In fact, I made exactly the same sort of post regards the Legacy tentative adoption of combining 2 args - something you also pointed out although for a different reason :)
Believe it or not. I fully agree with that. The same problem exists with ZDoom's way of rotating and scaling flats but to solve that we'd need a new map format. As long as we are limited to that all kinds of crap solutions will appear and disappear. If it was possible to set the texture scale on the sidedef this discussion wouldn't be necessary.
Randy said he didn't need me anymore - which I found interesting since ANY expanded map format requires the support and INPUT of utility authors. Having a hostile debate is not something I look forward to - but some BASIC compatibility is quite important. As I mentioned, the #1 unsettling thing about adopting this format is lack of accurate (or even caring) feedback from the community. That includes both port and utility authors as well as just users. Amazes me that authors refuse to ask anyone else if something that affects ALL the ports gets changed without a thought. But I can't change that *spin*
Ah. If your solution is to keep everything as it is and force the mapper to use TEXTUREx/PNAMES to define their hires textures we have a problem - in fact a big one.
Gah. There is absolutely no problem for software mode - but it does have to have the extra decoding added. The argument that the code isn't there is pretty much invalid. If that were a valid argument then ALL port coding must come to a complete halt.

As I've already explained, that's how I did it in R3Dedit. It's pretty much transparent as to which method they wish to use. JDOOM's external, TX internal, or implement the scaling in the method I described. The big mistake RH made is not defaulting the texture defined in TX to a size already defined in an existing texture. Once you do that, then the rest flows like jelly. In fact, you can also set a "thing" (or cvar) to allow for either hires flats (vs having to scale them via a special) or expanded to actual size. These are all things that were overlooked in the easiest general sense of friendly and flexible editing.

That some people hate this way of defining textures is not a cogent argument. All it tells me is that they don't realize it's a ONE step process and infinitely easier and more flexible than the external file. It's not like this is done over and over for god's sake. And don't forget, it's NOT required to do this. I can get you many more people used to the more sophistated tools that will tell you exactly the opposite of old diehards. They need to move on. Or if you like you can create a very lengthy document (made for JDOOM) on how to make these textures appear in the editor correctly since that for certain will be the #1 bitch to come out of this text thingy.

The scaling just reverts to full size (asis) or to the size of any texture it replaces. IOW, it's a combination of JDOOM and ZDOOM defaults. Then on top of that one can actually SCALE and get feedback in all cases since all textures are defined in the PWAD - not in some external file.
You are advocating the way that makes it easier for you to keep your editor up to date. Sorry, I'm not in that business and prefer to give the people what they want.
Graf, here you are again way off topic - getting all emotional vs rational discussion. It has absolutely NOTHING to do with the editor. In fact, I already support external textures in R3Dedit for editing, but I really don't agree with it (and have stated so in JDOOM discussions). In fact, the reason DeePsea has all those features is because I give people what they want.

If it comes to that sort of argument, who has more experience dealing with editing and feature requests - you or me? If you read my notes, you'd know that most of the tools in DS come from user request *crazy*
That's why I don't want to force solutions upon the mapper that inevitably make their WADs incompatible with software ZDoom just by using hires textures. For that I need a replacement option.
Geez - your solution already makes it incompatible and all my solution requires is a tad bit more code in ZDOOM. Or is ZDOOM somehow static all of a sudden?

Not allowing true color textures is basically the same thing as saying (as you did in the past) that GL mode wasn't required nor any of that fancy stuff. But in fact, users are asking for EXACTLY that sort of thing. So now you are going against what users want. You need to make up your mind Graf - either you listen to them or you don't *grin*

Factually, there is not much of a performance cost since the card does all the work once it's set up. Of course this excepts where textures are warped - but you already know that and users won't do this anyway knowing this. The colormap has a solution too - has no impact on R3D. I've run the complete hires replacement, many with 32bit textures and not noticed much of anything performance wise. But you do need a newer card. If you read what I said earlier, all you have to do is reduce the 32bit down to 8-bit which is supported by PNGLIB.

Eating up "space" is about as 20th century an argument as it gets. The future doesn't care about "space" and the future doesn't care about program size.
So WADs like Nimrod, Icerial2 and Hi-Tech Hell are corrupt by your definition because Legacy crashes when I play them out of the box. Hmm... It can't be the nodes ...
Here's some advice that will help you in programming: NEVER EVER ASSume that the first thing that pops into your head is the right one and get fixated on it. I noticed that Timmie basically told you the same thing where you wanted to blame the vid driver for the crashes. I agree with him 100% - some call you are doing is incorrect since it also crashes for me. Ditto for the dots - it's your CODE, not the driver. Hard to solve, but happens for the reasons already explained by that other user.
If that was the case ZDoom would die an agonizing death and everybody would use JDoom. But the amount of activity in the respective forums tells another story.
You take things completely out of context and didn't follow my drift. What I meant was that GL ports that have "features" is the ONLY way of the future. Following that line of thought - now that you mentiond it - ZDOOM software mode will die an agonizing death *spin*
So what? Of all the ports available it seems to have the most issues. The general instability makes Legacy 1.42 (please note the version number!) an easy target to bash - if you are talking with the right people, of course.
You amaze me. My point was that you are dishonest about your true feelings - having accused me of dishonesty yet you fail to point out where.

All I intend to convey to the Legacy coders is that you have little to no regard for other ports - do not provide helpfull feedback but instead restort to bashing (as you just admitted) and think that ZDOOM is the only guide to port coding. That's is what dishonesty is all about when you post in threads intended for compatibility when all you have in mind is doing it the the ZDOOM way or ways that are compatible with ZDOOM.

It's not helpful and it's not in the interest of all the ports. That much I hope is clear to the rest.
So what? Do you really think I'm that delusional to think that I can emulate everything that works in software mode?
Hehe, you get so upset over the obvious. You said that you wanted to maintain compatibility with ZDOOM. And that is already out the window with 3D stuff and the new specials and things. So it's not just maps but ALL the other elements that are coming into play now that you have GL to play with. IOW, maps made for GZDOOM are INCOMPATIBLE with ZDOOM.

And that means that your argument is specious - intending to disarm somebody wanting to do feature X by arguing that ZDOOM can't do that. When in fact, you've already done things that can't be done by ZDOOM. And since more and more users will start demanding eye candy, the rest ("eye candy") is going to follow and has nothing to do with your own likes or dislikes. IOW, it's non sequitur for the future.

[Graf_Zahl]

I'm not going to drag this on and one - so let me clarify to the others that your viewpoint is contrary to editing friendliness AND port compatibility - a fact you acknowledge yet attempt to justify. In fact, I made exactly the same sort of post regards the Legacy tentative adoption of combining 2 args - something you also pointed out although for a different reason :)




Randy said he didn't need me anymore - which I found interesting since ANY expanded map format requires the support and INPUT of utility authors.


Hey, it's Randy. To be honest, he is starting to drive me nuts as well. Half of the rewrites I'd like to do are endlessly postponed because it would make the transition to the new floating point code so much harder - especially since his progress information for the last month has been zero. :(


Having a hostile debate is not something I look forward to


Then let's stop this. It's not fun for me either. I very much prefer a style of discussion that leads to results, not pointless arguments about who is correct. If we just could agree that we have different standpoints on several issues and not having the need to endlessly defend them a lot is gained.


- but some BASIC compatibility is quite important. As I mentioned, the #1 unsettling thing about adopting this format is lack of accurate (or even caring) feedback from the community. That includes both port and utility authors as well as just users. Amazes me that authors refuse to ask anyone else if something that affects ALL the ports gets changed without a thought. But I can't change that *spin*



I think the problem with many people is that they conceive it as 'stealing' if someone takes a solution from another port and adopts it to his own.



Gah. There is absolutely no problem for software mode - but it does have to have the extra decoding added. The argument that the code isn't there is pretty much invalid. If that were a valid argument then ALL port coding must come to a complete halt.


That may be or that may not be. It sure can't hurt to add support for any graphics format to the regular textures. But the matter of fact is that I was specifically asked to add a simpler means of adding hires texture support - and ZDoomGL's HIRESTEX was the most obvious solution. You might discuss this with SlayeR - because he suggested it. ;)


As I've already explained, that's how I did it in R3Dedit. It's pretty much transparent as to which method they wish to use. JDOOM's external, TX internal, or implement the scaling in the method I described.


If you mean something else than TEXTUREx, could you post it again? I still haven't found it.


The big mistake RH made is not defaulting the texture defined in TX to a size already defined in an existing texture. Once you do that, then the rest flows like jelly.


That wasn't a mistake, that was a conscious decision based on community input. TX textures were supposed to be a completely independent means of adding textures that does not interfere with anything else in any way so such an approach was out. But it can still be added - by using a different marker. I was already thinking about something like this, maybe using HI_START/HI_END because for just replacing textures it is most definitely better than an external lump.


In fact, you can also set a "thing" (or cvar) to allow for either hires flats (vs having to scale them via a special) or expanded to actual size. These are all things that were overlooked in the easiest general sense of friendly and flexible editing.


It would still be a hack born out of the far too limited level format. I'd really like to make this stuff easier but for that we'd really need consensus about an enhanced map format, probably based on XML. I want a real solution here, not just another workaround.


That some people hate this way of defining textures is not a cogent argument. All it tells me is that they don't realize it's a ONE step process and infinitely easier and more flexible than the external file. It's not like this is done over and over for god's sake. And don't forget, it's NOT required to do this. I can get you many more people used to the more sophistated tools that will tell you exactly the opposite of old diehards. They need to move on. Or if you like you can create a very lengthy document (made for JDOOM) on how to make these textures appear in the editor correctly since that for certain will be the #1 bitch to come out of this text thingy.


With the current map format this argument will start again and again and again. Let's face it: The current texture system is a complete mess. All the old ways are necessary for compatibility so sadly enough they can't be dumped. TX was a step in the right direction but as this discussion shows it still suffers from the scaling problem. In a perfect world there shouldn't be any need to tell a texture how it is supposed to be scaled. IMO this should be the sole responsibility of the data that uses them, i.e. the sidedefs or sectors. For sprites it already works that way.
(again: We need a new map format.)


Graf, here you are again way off topic - getting all emotional vs rational discussion. It has absolutely NOTHING to do with the editor. In fact, I already support external textures in R3Dedit for editing, but I really don't agree with it (and have stated so in JDOOM discussions). In fact, the reason DeePsea has all those features is because I give people what they want.


So where's the problem with HIRESTEX? I needed half an hour to add support for it in the game. It can't be much more in the editor, right?


If it comes to that sort of argument, who has more experience dealing with editing and feature requests - you or me? If you read my notes, you'd know that most of the tools in DS come from user request *crazy*


Frankly, I personally don't care whether hires textures are defined this way or that way. I would have been perfectly content without HIRESTEX. For my purposes it did nearly everything I need but what shall I do if someone else tells me that he doesn't agree?
It's not that I invented something new here. The format already existed.



Geez - your solution already makes it incompatible and all my solution requires is a tad bit more code in ZDOOM. Or is ZDOOM somehow static all of a sudden?

Not allowing true color textures is basically the same thing as saying (as you did in the past) that GL mode wasn't required nor any of that fancy stuff. But in fact, users are asking for EXACTLY that sort of thing. So now you are going against what users want. You need to make up your mind Graf - either you listen to them or you don't *grin*


One thing after another. ;) Now that everything is in place I only have to figure out how to properly regognize the various graphics formats from Doom patches so that adding support for it doesn't screw up ZDoom's texture manager. Right now it would.


Factually, there is not much of a performance cost since the card does all the work once it's set up.


The biggest problem with hires textures is simply the amount of data that has to be transferred to the graphics card. It does show if for some reason the game has to use un-precached textures.


Of course this excepts where textures are warped - but you already know that and users won't do this anyway knowing this.


I completely prohibit warping of hires textures. Even the cost of constantly re-uploading one warping 256x256 texture is easily noticable - and 512x512 will probably kill the performance even on a good computer.


The colormap has a solution too - has no impact on R3D. I've run the complete hires replacement, many with 32bit textures and not noticed much of anything performance wise. But you do need a newer card. If you read what I said earlier, all you have to do is reduce the 32bit down to 8-bit which is supported by PNGLIB.


My biggest issue with the colormaps is that the textures start to look like shit rather quickly. What I did was to use an averaged color and use that to draw the image. It's not perfect but for the Boom standard colormaps it looks actually better than the actual remapping. It's an option of course.


Eating up "space" is about as 20th century an argument as it gets. The future doesn't care about "space" and the future doesn't care about program size.


We aren't in the future yet. On a computer itself space might not matter. But when it comes to up/downloading the saved MBs can make the difference between a WAD that only those with high-speed access can get and one that also appeals to those who only have ISDN or an analog modem. And there are still far too many people who don't have high-speed access. So size does still matter. And seeing how our national telecommunications company is fumbling around in that matter I don't see any change for the better.


Here's some advice that will help you in programming: NEVER EVER ASSume that the first thing that pops into your head is the right one and get fixated on it.
I noticed that Timmie basically told you the same thing where you wanted to blame the vid driver for the crashes. I agree with him 100% - some call you are doing is incorrect since it also crashes for me. Ditto for the dots - it's your CODE, not the driver. Hard to solve, but happens for the reasons already explained by that other user.


I still can't find anything there. The crash log doesn't tell me anything except that the driver didn't like the data for some reason.


Following that line of thought - now that you mentiond it - ZDOOM software mode will die an agonizing death *spin*


But not due to lack of interest by its users. That is still high. I see the bigger problem on the developer's side.


You amaze me. My point was that you are dishonest about your true feelings - having accused me of dishonesty yet you fail to point out where.


You want my true feelings about this issue: Ok *crazy*

IMO Legacy 1.42 is a hopeless cause (again note the version number!) The sooner it is dumped the better.
On the other hand the new 2.0 version looks quite promising but it obviously still needs some work (that's why it is still in the beta stage, right?)


All I intend to convey to the Legacy coders is that you have little to no regard for other ports - do not provide helpfull feedback


If I can help I do it (see my post above) but the fact remains that ZDoom is my favorite engine (I don't see any point in denying it) and I don't thorougly read all the threads here - especially in the port-specific sub-forums. I was pointed to this one by Planky. Most likely I wouldn't have noticed it otherwise. But at least I still discuss here - in contrast to one certain port developer (who should not be named here) who prefers to stay at his own private little forum.


but instead restort to bashing (as you just admitted)


It's still better than trying to discredit others.


and think that ZDOOM is the only guide to port coding. That's is what dishonesty is all about when you post in threads intended for compatibility when all you have in mind is doing it the the ZDOOM way or ways that are compatible with ZDOOM.


Sorry, is it my fault that most of the featues in discussion are already implemented by ZDoom? What else should I point to? MAPINFO from Vavoom? Sure, that could be done but the disproportionate amount of maps for Vavoom as opposed to ZDoom speaks against it. The same would be true for the implementation of slopes (although supporting both methods is still the best solution.)
For other features the same situation applies. In far too many cases there is no other choice to point to.


It's not helpful and it's not in the interest of all the ports. That much I hope is clear to the rest.


That's up for the port authors to decide. I still think it's stupid to do something differently when the problem has already been solved by another port. Because then we are back to square one: Mappers who want to be compatible have no choice but to restrict themselves to the lowest common denominator - and all the neat features go to waste in those maps. (Do I have to say that I like complex maps with extensive scripting. ;))


Hehe, you get so upset over the obvious. You said that you wanted to maintain compatibility with ZDOOM. And that is already out the window with 3D stuff and the new specials and things. So it's not just maps but ALL the other elements that are coming into play now that you have GL to play with. IOW, maps made for GZDOOM are INCOMPATIBLE with ZDOOM.


But not the other way around. If I wanted to start something radically different from scratch I wouldn't have stuck that close to ZDoom. My main goal from the start was to add my existing rendering code to ZDoom. The rest was just a plus. If people will map for it I'll be happy but that wasn't my main motivation.


And that means that your argument is specious - intending to disarm somebody wanting to do feature X by arguing that ZDOOM can't do that.


You know, there's my big dilemma. I know Randy too well and as a result have 2 choices:

1. move on and depart further from ZDoom. I'd really like to do that but that would make code upgrades quite hard as can be seen with Skulltag which is lagging several versions behind.
2. stick to it as closely as possible while restricting as many new features as possible to the GL side.

At least until the next release I will have to stick to 2. (which sucks.)

[rustyslacker]

look:

can't you just port the linedef types, effects, slopes, etc. and just call it a "zdoom-compatible mode" and use a separate "legacy-classic mode"?

then make a new doombuilder and deepsea config, and it's all good.

and that was one reallly long post.

[Ajapted]

If you need a complete list of how ZDoom translates all the specials in Doom and Heretic you can download the source and take a look at the files wadsrc/xlat/doomxlat.txt and hereticxlat.txt.
Excellent, just the info I was looking for.

Re: XML -- I'm not a fan of it. It's great as a flexible base for document formats, but lousy as a general purpose data container. Awful to look at and painful when you need to edit it by hand.

Re: Hires textures -- I don't like the "magic scaling" system (if the texture already exists then the hires one is scaled to the same dimensions, but new textures are left unscaled). It creates a dichotomy between replacement textures and new ones -- they work differently.

Graf's idea of HI_START and HI_END (presumably new textures are not allowed here) sounds quite good to me, and leave the ones between TX_START and TX_END unscaled by default, and a text lump to store "extra" info (scaling, perhaps other stuff).

One question is sprites: how to specify their OFFSETS in particular (but also scaling)? Presumably thing sprites default to being centred horizontally and standing on the ground. What about weapon sprites?

For comparitive purposes, EDGE does this: a text lump (DDFIMAGE) describes any hires images. It is required to use hires images (not a very user-friendly design choice I admit). By default the image is "unscaled" (one pixel = one world unit). There are commands for setting the scaling and offsets. Weapons are positioned relative to the bottom of the screen (mid X).

[iori]

stuff
This is coming however from a mappers/non-coders viewpoint, and while it might be valid, it's out of the scope of the conversation from the coding perspective. I think that would just add too much extra work to be done, as the configs would have to be updated and synced with every new release of X port..

[Graf_Zahl]

Re: XML -- I'm not a fan of it. It's great as a flexible base for document formats, but lousy as a general purpose data container. Awful to look at and painful when you need to edit it by hand.


That's why I'd never use it for manually generated files. I had to work with Java and Ant and maintaining these XML files was definitely no fun - not to mention that most people have no clue what to do with them.


Re: Hires textures -- I don't like the "magic scaling" system (if the texture already exists then the hires one is scaled to the same dimensions, but new textures are left unscaled). It creates a dichotomy between replacement textures and new ones -- they work differently.


Me neither. You are creating dependencies between WADs that are hard - if not impossible - to track down.



One question is sprites: how to specify their OFFSETS in particular (but also scaling)? Presumably thing sprites default to being centred horizontally and standing on the ground. What about weapon sprites?


Sprites are a real problem. For hires replacements I think the only way to do it is to scale the hires texture to the size of the original and then use the original offsets. Sprites need to be put into S_START/S_END anyway to work. For new sprites it isn't such a big problem as long as the actor definition format supports specifying a scaling value. But if you want to use PNGs as sprites you have to force them into the file somehow. For ZDoom there's a small utility called setpng. You can find it on the GZDoom download page. It's far from an optimal solution but what else can be done here?

[deepteam]

Re: Hires textures -- I don't like the "magic scaling" system (if the texture already exists then the hires one is scaled to the same dimensions, but new textures are left unscaled).
What did I write? Exactly that. What you do not realize is that the term "scaled to the same dimensions" includes the ability to RESCALE. That includes the actually superflous X/Y scaling bytes added by RH. The simple fact is that ALL you need to do is reset the X/Y size and you get EXACT scaling vs that somewhat troublesome method he devised since it's hard to get exact sizes. IOW it was not required. Since it exists, it can use it for resizing, but new stuff can safely just leave those fields alone, making it even more utility friendly.

Now do you see how this works? It's 100% compatible with the editing tools. It's 100% consistent. And it actually makes sense since it's exactly how users have learned how texture size works now :) It's called consistency.
It creates a dichotomy between replacement textures and new ones -- they work differently.
Of course. It's extremely simple and very easy to explain. But they actually don't work differently in concept. IOW, the size set in the TEXTUREx lump (if it exists) sets the display size.
Graf's idea of HI_START and HI_END (presumably new textures are not allowed here) sounds quite good to me, and leave the ones between TX_START and TX_END unscaled by default, and a text lump to store "extra" info (scaling, perhaps other stuff).
That's a reasonable compromise, although really not required. All TX hires textures I've seent DO NOT duplicate existing names, hence they scale ASIS (could be some exceptions - just haven't seen them). So we are inventing something here for really no practical reason. Remember, ALL the tools have to be changed to accommodate this, not just ports. And if there's really no cogent argument to do this, then why bother?
One question is sprites: how to specify their OFFSETS in particular (but also scaling)? Presumably thing sprites default to being centred horizontally and standing on the ground. What about weapon sprites?
Graf explained the offset stuff. You can already scale them in DEH patches- (not really the best way, but RH again dumped it in there) - already been done - guess Graf forgot. Should have also added scaling in addition to the x/y offsets for the PNG stuff. But remember, that's only for PNG not other formats. Personally can't see a problem reducing the number of formats to just PNG and ignore others for sprites since there's nothing to be gained. Sometimes too many formats is NOT a good thing.
For comparitive purposes, EDGE does this: a text lump (DDFIMAGE) describes any hires images. It is required to use hires images (not a very user-friendly design choice I admit). By default the image is "unscaled" (one pixel = one world unit). There are commands for setting the scaling and offsets. Weapons are positioned relative to the bottom of the screen (mid X).
Correct, not a very user friendly design for the same reason as the HIRESTEXT file. Now if Graf would quit trying to incent a flame war over at his forum (go look for yourself - that's what he considers constructive and intelligent commenting/advice I guess), the obvious simplicity AND cross-port compatibity AND utility friendliness jumps out like a bull out of pen.

IOW, if you try to incite a riot you'll get a riot. That's the problem with Graf. If some idea is contrary to his, yet simpler, more flexible and editing friendly, what comes back is what you see here and on his forum. [No amount of rationalizing can excuse that sort of attitude].

Anyone who thrashes port authors and thrashes GUI solutions to PWAD manipulation is really out of touch with how the majority of users do editing. Sad really. I'll probably add the PNG offset thing to DeePsea since the command line tool thing is a POS. But I'd like to see the sprite scaling added also since that's a logical place to put it.

For that matter, an alternate solution that could work is to put the resize info inside the PNG chunk - not as utility friendly but doable too. However, if it is used as a "patch", then the TEXTUREx resizing takes precedence. And if there is no resizing info, then the rules listed above take precedence. You can have your cake and eat it too *smirk*

[deepteam]

Then let's stop this. It's not fun for me either. I very much prefer a style of discussion that leads to results, not pointless arguments about who is correct. If we just could agree that we have different standpoints on several issues and not having the need to endlessly defend them a lot is gained.
LOL - then why do you post as you in your forum and ZDOOM's? Let's at least be HONEST.

Your interpretation is interesting and revealing. It's not really about who is "correct", it's about what solution is the most flexible, easy to describe and EDITING friendly. Go ahead, make an objective LIST and let's see what jumps out.
But the matter of fact is that I was specifically asked to add a simpler means of adding hires texture support - and ZDoomGL's HIRESTEX was the most obvious solution. You might discuss this with SlayeR - because he suggested it. ;)
Already answered this. It's a POOR solution. That you and Slayer have a nice sycophant relationship is nothing to commend it. He's hardly a relevant issue here.
That wasn't a mistake, that was a conscious decision based on community input. TX textures were supposed to be a completely independent means of adding textures
You are partially correct, but actually incorrect about the scaling part. He NEVER GAVE IT ANY THOUGHT. Remember, I was very much involved, but like all things NIV, you both are loathe to accept objective foresight when it goes contrary to your original design. Remember the duplicate discussion. Now remember your distaste for the multiple DECORATE issue in PWADs? Q.E.D. [As an aside, RH kept insisting tall textures couldn't go over 256, till I force fed him a PWAD example and then helped him fix the code for alpha segs - something he denies but that's how it happened]
- by using a different marker. I was already thinking about something like this, maybe using HI_START/HI_END because for just replacing textures it is most definitely better than an external lump./quote]
I agree 100% with having the textures inside the PWAD. Interestingly, JDOOM disagrees with me 100% :) Don't need new markers though - read what I told AJ.
[quote]about an enhanced map format, probably based on XML. I want a real solution here, not just another workaround.
That's the #1 chant when a problem comes up. It's not required for this case. In fact, having scaling on a sidedef extension would be a royal editing PIA. It's that port authors do not do much editing that a lot of "solutions" are very much editing junk.

The problem with a new format is that there will be endless debates. There are only a few things that are really important. Just key to those and not the infinite issues. That's how you do things professionally : you pick a target and DO IT.
TX was a step in the right direction but as this discussion shows it still suffers from the scaling problem.
There is NO problem. You just want to stick to that awful text lump. Be flexible and do some editing for a change with hires textures.
So where's the problem with HIRESTEX? I needed half an hour to add support for it in the game. It can't be much more in the editor, right?
Sigh. It's not the code, its just NOT REQUIRED. And what about all the other utilities? I gave you a simple solution that will actually work with all the editors (if x/y scaling is not set - which mostly it is not).

BTW I was talking about TRUE COLOR, not just hires. Why no true color?

My PNG conversion was merely a concession to software mode. It's NOT done for GL mode, hence nothing looks like SHIT, but instead looks way better than you can imagine. Again because you don't really edit what you look for as examples do not the true color world make.

And this is indeed the relative future. Nobody HAS to use these new tools. Better to be prepared than make something that is obsolete in 5 years. Space doesn't matter, download size is passe, and program size ditto. These are all excuses that matter little as time goes on. The lowest common denominator is a poor base to design to *ugh*

[iori]

IOW, if you try to incite a riot you'll get a riot. That's the problem with Graf. If some idea is contrary to his, yet simpler, more flexible and editing friendly, what comes back is what you see here and on his forum. [No amount of rationalizing can excuse that sort of attitude].

Anyone who thrashes port authors and thrashes GUI solutions to PWAD manipulation is really out of touch with how the majority of users do editing. Sad really.


Deep - his last two posts were civil, and they expressed desire to continue to be civil in this thread. Deep, now despite that, you're continually egging him on.

What I don't get, Deep, is that you're trying to tell US (everyone else reading this thread apart from you and him) what he is like. Well.. thanks? I don't give two shits what he may or may not be like in the real world, or what his secret underlying motives are, if any. I'm simply here to read the on topic parts of this discussion, like many others who can't rightly contribute. So -please- stop the mudslinging, take the high road, etc. No one here cares if you two mortally loathe each other's existance, and we won't listen to biased accusations about the other. So all you're accomplishing by flaming each other (graf has stopped, it seems) and trying to 'convince' us of the other's inherent burning hatred towards X, is that you're just making a fool out of yourself[selves].

Now, step up to bat, say your piece, and leave the personal opinions at the door. I don't want to read that shit.

[Graf_Zahl]

Correct, not a very user friendly design for the same reason as the HIRESTEXT file. Now if Graf would quit trying to incent a flame war over at his forum (go look for yourself - that's what he considers constructive and intelligent commenting/advice I guess), the obvious simplicity AND cross-port compatibity AND utility friendliness jumps out like a bull out of pen.


I didn't force anybody to comment in that way. All I wanted was some opinions regarding this issue as a base for further discussion. If other people which I didn't coerce in any way to post what they posted think that way about you I suggest you rethink your attitude.


IOW, if you try to incite a riot you'll get a riot.


You are 100% correct. But I didn't start this. I merely responded.


That's the problem with Graf. If some idea is contrary to his, yet simpler, more flexible and editing friendly, what comes back is what you see here and on his forum. [No amount of rationalizing can excuse that sort of attitude].


This seems to be more correct:

That's the problem with Deep. If some idea is contrary to his, yet simpler, more flexible and editing friendly, what comes back is what you see here. [No amount of rationalizing can excuse that sort of attitude].

I am actually listening to people's suggestions. The reason why I don't follow your suggestions here is rather simple: I don't see any good in here - to be honest, I haven't even understood everything. It's confusing, unintuitive and attempts to mix some resources together that aren't supposed to be mixed. Implementation-wise it would create one hell of a mess I just don't want to deal with. It isn't simpler and it isn't more flexible. For the uninitiated beginner it might be more user friendly because it may allow them to ignore the common pitfalls of Doom's texturing system but the cost would be too high.

If you can convince me that your system is really better I might add it - if I can make it compatible with what I have. Because that's the other big issue. I can't throw the original implementation out of the window. If I want to improve it it has to be done in a way that under no circumstances breaks existing WADs. And that rules out any interaction between the TEXTUREx lump and TX-textures (which I think is a bad idea in any case.)




Anyone who thrashes port authors


Well, look what you are doing here! Thoughout this entire thread there has been one person who constantly and persistently thrashed one port author - and that has been you! Regarding your constant and persistent attacks I think I stayed rather polite even though a 'Fuck you asshole!' might have been more justified. Now shut up, please!

(Apologies to anybody else here who is (justifiably) annoyed by this shit but I think this had to be said once.)


and thrashes GUI solutions to PWAD manipulation is really out of touch with how the majority of users do editing. Sad really.


Did I ever thrash XWE? I don't think so because I use it myself. It's a great tool for simple WAD editing but for building a WAD from a large set of resources I still prefer something more DEUTEX like (with the needed extensions for modern source ports of course.) If I say something negative about a tool it's because I have issues with it.

Sad really that you have to take a comment I made (my preference for command line tools) and completely warp it into something that fits your twisted way of arguing.



I'll probably add the PNG offset thing to DeePsea since the command line tool thing is a POS.


It definitely is. But since it is the only means to set the offsets at the moment it's better than nothing.


But I'd like to see the sprite scaling added also since that's a logical place to put it.


Feel free to do so. Because such a solution would make the HIRESTEX lump obsolete. But I will still leave it in. Why? Because some people happen to (gasp!) like it and why should I disappoint them? As unbelievable as it sounds: They find it easier to just dump their PNGs, JPGs and what else into the WAD file, take out notepad.exe and quickly write down the dimensions they want to scale their textures to as opposed to typing this information into some dialog box for each and every texture.

[rustyslacker]

please, keep your posts shorter. i'm here at school, and it's hard to concentrate.

seriously:

instead of syncing compatibility with other ports, just leave that in an "open-source" format for people to code in as they choose.

why no true color sprites?

1. nostalgia. i like the old colors, and wouldn't use new sprites if they were available.
2. nobody has made them yet. if you want to translate ALL of the sprites from doom and doom2, be my guest. if it does hapen, i bet it won't be done for years.

i would like to know: how much of this ridiculously long discussion will lead to any results in the new legacy? some of the ideas are interesting and i would like to find out how well they can be implemented.

[Graf_Zahl]

why no true color sprites?


It doesn't have to be True Color sprites. Just importing some stuff from Heretic and Hexen (and vice versa) into Doom would look much better if it could keep its original palette. If you play Hordes of Chaos or Resurrection of Chaos you might see that some of the Doom monsters in there don't look quite right.

Another example: I once made a recolored Baron with a brown body and sand-colored legs. It didn't map to the Doom palette but the Heretic palette was perfect for it.

[Graf_Zahl]

(Sigh, more lengthy stuff to comment. Will it ever end? *ugh* )

LOL - then why do you post as you in your forum and ZDOOM's? Let's at least be HONEST.


I am honest. What does this have to do with it?


Your interpretation is interesting and revealing. It's not really about who is "correct", it's about what solution is the most flexible, easy to describe and EDITING friendly. Go ahead, make an objective LIST and let's see what jumps out.


You think your solution is better, I think mine is better. Great. Now what?


Already answered this. It's a POOR solution. That you and Slayer have a nice sycophant relationship is nothing to commend it. He's hardly a relevant issue here.


I don't have any 'nice sycophant' relationship with SlayeR. I just treated his suggestion in an objective manner, assessed the work required to add it and then added it. The same process I will do with any reasonable feature request.


You are partially correct, but actually incorrect about the scaling part. He NEVER GAVE IT ANY THOUGHT. Remember, I was very much involved, but like all things NIV, you both are loathe to accept objective foresight when it goes contrary to your original design.


Let's not take this one out again. What's done is done and now it's too late to change it. But just because you alone disagree with that design decision doesn't mean it's wrong. It only means that you think it is wrong. Do you also remember that absolutely nobody agreed with you? Please let's stop it. If I dug out all relevant discussions they would just show one thing: Your view of how textures should be handled is quite different from everybody else's. There is absolutely no common ground to find so I won't even try.


Remember the duplicate discussion. Now remember your distaste for the multiple DECORATE issue in PWADs? Q.E.D. [As an aside, RH kept insisting tall textures couldn't go over 256, till I force fed him a PWAD example and then helped him fix the code for alpha segs - something he denies but that's how it happened]


Which is all completely irrelevant in the context of this discussion, don't you think?



I agree 100% with having the textures inside the PWAD. Interestingly, JDOOM disagrees with me 100% :) Don't need new markers though - read what I told AJ.


I won't go your way because it would create incompatibilities. So we do need new markers. Sorry.


That's the #1 chant when a problem comes up. It's not required for this case. In fact, having scaling on a sidedef extension would be a royal editing PIA. It's that port authors do not do much editing that a lot of "solutions" are very much editing junk.


So all the modern game engines which allow more precise texture positioning are crap? Good point! *crazy*


The problem with a new format is that there will be endless debates. There are only a few things that are really important. Just key to those and not the infinite issues. That's how you do things professionally : you pick a target and DO IT.


That's why I propose an open format. Any new map format that just extends the limits without breaking them is a waste of time IMO. And with an open format you can add everything that might be useful, including a complete and thorough set of texture properties for each part of each sidedef or sector. (But wait, this again would severely affect any editor programmer. How could I forget![/sarcasm])


There is NO problem. You just want to stick to that awful text lump. Be flexible and do some editing for a change with hires textures.

Sigh. It's not the code, its just NOT REQUIRED. And what about all the other utilities? I gave you a simple solution that will actually work with all the editors (if x/y scaling is not set - which mostly it is not).


There is a HUGE problem: Compatibility! Yet again: Every suggestion that proposes mixing TEXTUREx and TX is out. I won't consider it because it is not compatible with the way things work now and it might break some (at the moment hypothetical) ZDoom hires-texture WADs. Besides, what's so much better about TEXTUREx than a separate text based lump? TEXTUREx is some binary crap that is hard to edit and uncomfortable to use - even with a lump manager. Personally, I'd like to see it go away as a necessity to edit textures altogether.



BTW I was talking about TRUE COLOR, not just hires. Why no true color?


Did I miss something? Of course there's True color support - just not yet for regular textures. I have to sort out some code before I can add it there as well.


My PNG conversion was merely a concession to software mode. It's NOT done for GL mode, hence nothing looks like SHIT, but instead looks way better than you can imagine. Again because you don't really edit what you look for as examples do not the true color world make.


Again you take one comment out of context. I said that textures not matched to the base palette combined with Boom colormaps look like shit due to the two translation steps that are necessary to do it for real. There's no way around it and that's why I added another method that circumvents this step completely (but logically can't handle all colormaps in existence.)


And this is indeed the relative future. Nobody HAS to use these new tools. Better to be prepared than make something that is obsolete in 5 years. Space doesn't matter, download size is passe, and program size ditto. These are all excuses that matter little as time goes on. The lowest common denominator is a poor base to design to *ugh*

You really should make some closer investigations before complaining about issues that don't exist. Since True color support for hires textures already exists and I am working on it for regular textures this is a moot point. I just can't do a simple check with the graphics library I use because it can read Doom patches. But that's something I don't want it to do because I would like the existing code to handle them.

[DaniJ]

After reading all this I'm not sure what direction is the best way to go for Doomsday, which has already started down a path where new resources _ARE_ external, period. It makes little sense to adopt eg the HIRESTX lump stuff as people who mod for jDoom are used to working outside the restraints of the WAD format, without color depth/palette restrictions, without size restrictions (limited only at runtime where textures are resized to the limit set by the user/card), they can already use several different file formats (PNG,PCX,TGA,RAW in a variety of different color modes) and most importantly they don't have to open an addtional program to insert their textures into a WAD before they can use them, each and every time they change them.

Now, whatever happens, Doomsday will continue to expand its resource (management) features in that direction. AFAIC it makes little sense to continue to develop new ways of working within the restrictions of the WAD format. Working with real files is far more flexible. True its a completely different way of working (well within the Doom mod scene anyway) but if we are to continue to grow as a community and to attract new/old players (back) to Doom in order to mod then we need to start doing things the way people have gotten used to on other (more modern) mod platforms. The other big benefit of external files is that they are (potentially) completely bereft from port specific issues.

HOWEVER. I'm well aware that there is a large, existing back catalogue of levels (and mod makers *smirk*) in the old format. So I will endeavor to support at LEAST one method from those discussed here. So from my POV the last thing I want to see is ANOTHER method of defining hires textures with just as many restrictions as we already have in the various methods already imployed by the different sourceports.

As an (ex) level author I feel the best method regarding the sizing of textures is to have them automatically sized to Doom's pixel aspect in the case of new textures (ie new 128x128 textures are drawn at the same size as existing Doom textures and NEW hires textures are drawn with at a 1:1 pixel ratio unless set otherwise). REPLACEMENTS (hires or not) should be resized to the dimensions of the texture they are replacing unless set otherwise. It should be possible for BOTH the texture artist and the level author to set the dimensions of a texture within a level. As has been noted it would be a PITA for the level author to resize each texture for every sidedef/sector but this should still be possible (obviously it isn't at present without a "kludge" method via scripting/XG/whatever) and the values should be treated as offsets to either the original dimensions in the case of replacements or against the size set by the texture artist.

AFAICS the only issue here is how to offer a method of scaling a texture on a sidedef/sector plane and a way to set the dimensions of a NEW texture.

The problem with a lot of the methods mentioned (from what I've discerned thus far) is that they are counter-intuitive to the way Doom's existing (badly realised) texture system works. You might think its a PITA having to create lowres versions of a NEW texture and then put it into the WAD (in the time old fashion) before you can then replace it with an external hires version (how it works in Doomsday) but at least there is ONE absolute method for defining textures regardless of whether they are new/replacements/hires or otherwise. There is a lot to be gained from that.

So, when I think about it - it makes a lot of sense for Doomsday to allow TEXTURES1/2 to contain names of textures that don't exist in the PWAD itself and then assuming they will be supplied via external files. Thus removing the need for place-holders. Following on from that it is only logical that (given Doomsdays penchant for external files) that a simple external text file could be used to define new TEXTURES1/2 entires that is then merged into the internal list at runtime. Opps, hang on a second, Skyjake already wrote a program to do that years ago called texC. Hmm... *spin*
Which when you look at the pieces is not too dissimilar from the method Graf is proposing. The only difference being that in his suggested implementation the resources are lumps in a PWAD as opposed to real external files. The obvious similarity would mean that if I were to implement the same keynames it would be trivial to support Graf's proposed method also.

As I've not followed a good 75% of what has been said about the different methods (and not having researched them myself yet) I don't know what to do for the best at this time and can't really offer any real sollutions/ideas on the subject. I'll be in a better position to do so once I've done my homework and after I've seen the changes Deep made for Risen3D.

[Graf_Zahl]

After reading all this I'm not sure what direction is the best way to go for Doomsday, which has already started down a path where new resources _ARE_ external, period. It makes little sense to adopt eg the HIRESTX lump stuff as people who mod for jDoom are used to working outside the restraints of the WAD format, without color depth/palette restrictions, without size restrictions (limited only at runtime where textures are resized to the limit set by the user/card), they can already use several different file formats (PNG,PCX,TGA,RAW in a variety of different color modes) and most importantly they don't have to open an addtional program to insert their textures into a WAD before they can use them, each and every time they change them.

Now, whatever happens, Doomsday will continue to expand its resource (management) features in that direction. AFAIC it makes little sense to continue to develop new ways of working within the restrictions of the WAD format. Working with real files is far more flexible. True its a completely different way of working (well within the Doom mod scene anyway) but if we are to continue to grow as a community and to attract new/old players (back) to Doom in order to mod then we need to start doing things the way people have gotten used to on other (more modern) mod platforms. The other big benefit of external files is that they are (potentially) completely bereft from port specific issues.


It all depends on how you look at it. Sure, the WAD format is quite restrictive and imposes some limitations but on the other hand you get clean distributions. I have seen some Doomsday mods that were an organizational mess (not because it was necessary, just because it was possible.) The WAD approach prevents that at the root.


HOWEVER. I'm well aware that there is a large, existing back catalogue of levels (and mod makers *smirk*) in the old format. So I will endeavor to support at LEAST one method from those discussed here. So from my POV the last thing I want to see is ANOTHER method of defining hires textures with just as many restrictions as we already have in the various methods already imployed by the different sourceports.

As an (ex) level author I feel the best method regarding the sizing of textures is to have them automatically sized to Doom's pixel aspect in the case of new textures (ie new 128x128 textures are drawn at the same size as existing Doom textures and NEW hires textures are drawn with at a 1:1 pixel ratio unless set otherwise). REPLACEMENTS (hires or not) should be resized to the dimensions of the texture they are replacing unless set otherwise. It should be possible for BOTH the texture artist and the level author to set the dimensions of a texture within a level. As has been noted it would be a PITA for the level author to resize each texture for every sidedef/sector but this should still be possible (obviously it isn't at present without a "kludge" method via scripting/XG/whatever) and the values should be treated as offsets to either the original dimensions in the case of replacements or against the size set by the texture artist.


Exactly. Each texture should have a base size that is being used unless something in the map data tells it otherwise. Normally there should be no need to specify scaling but it's something many mappers wish to have - if only for scaling some switch texture to make it smaller.


AFAICS the only issue here is how to offer a method of scaling a texture on a sidedef/sector plane and a way to set the dimensions of a NEW texture.


A new map format. ;) When I have some time I'll work something out.


The problem with a lot of the methods mentioned (from what I've discerned thus far) is that they are counter-intuitive to the way Doom's existing (badly realised) texture system works. You might think its a PITA having to create lowres versions of a NEW texture and then put it into the WAD (in the time old fashion) before you can then replace it with an external hires version (how it works in Doomsday) but at least there is ONE absolute method for defining textures regardless of whether they are new/replacements/hires or otherwise. There is a lot to be gained from that.

So, when I think about it - it makes a lot of sense for Doomsday to allow TEXTURES1/2 to contain names of textures that don't exist in the PWAD itself and then assuming they will be supplied via external files. Thus removing the need for place-holders. Following on from that it is only logical that (given Doomsdays penchant for external files) that a simple external text file could be used to define new TEXTURES1/2 entires that is then merged into the internal list at runtime. Opps, hang on a second, Skyjake already wrote a program to do that years ago called texC. Hmm... *spin*

Which when you look at the pieces is not too dissimilar from the method Graf is proposing. The only difference being that in his suggested implementation the resources are lumps in a PWAD as opposed to real external files. The obvious similarity would mean that if I were to implement the same keynames it would be trivial to support Graf's proposed method also.


And that's what HIRESTEX is doing - apart from defining replacements. If it was just for the replacements I wouldn't have bothered with this lump. There are far better and simpler methods to get those textures recognized. But having a simple plain text lump where you can define the textures with their world size seems like a good idea to me. In the end it can be easily used as a complete replacement for TEXTUREx - as long as you don't want to use multipatch textures. But as Deep said - space doesn't matter *smirk*

[Ajapted]

After reading all this I'm not sure what direction is the best way to go for Doomsday, which has already started down a path where new resources _ARE_ external, period.
That is a philosophy I used to agree with. We were planning the same thing with EDGE: keep the "good" formats (PNG, WAV, etc) out of wads and in the better package format (pk3).

I no longer think that. DOOM == WAD. All the tools (editors etc) are wad based. You can't expect everybody to adopt another package format, even though it would be a much nicer system.

In the end it can be easily used as a complete replacement for TEXTUREx
That sounds good to me - a new text-based format for the TEXTUREx lumps. A superset of the current capabilities, but allow scaling and offset info for sprites and flats too. The name HIRESTEX wouldn't be appropriate though.

Edit: Regarding the use of dummy textures to set a specific scaling: that would be live-with-able, but it only works for textures -- you cannot do it for flats or sprites (in a single wad, requiring two wads would be bizarre). I hoping for a solution that covers all uses of PNGs. How about a syntax like this:

Texture STARTAN3
width = 128
height = 128
scale = 1
patch = FOOX 0 0
patch = FOOY 64 0
patch = FOOZ 0 64
end

Flat FLAT10
scale = 0.25
end

Sprite TROOA1
xoffset = -13
yoffset = -7
scale = 0.5
end

Graphic M_PAUSE
xoffset = -20
yoffset = 0
scale = 1.5
aspect = 0.5
end

[Graf_Zahl]

That is a philosophy I used to agree with. We were planning the same thing with EDGE: keep the "good" formats (PNG, WAV, etc) out of wads and in the better package format (pk3).

I no longer think that. DOOM == WAD. All the tools (editors etc) are wad based. You can't expect everybody to adopt another package format, even though it would be a much nicer system.


That sounds good to me - a new text-based format for the TEXTUREx lumps. A superset of the current capabilities, but allow scaling and offset info for sprites and flats too. The name HIRESTEX wouldn't be appropriate though.

Edit: Regarding the use of dummy textures to set a specific scaling: that would be live-with-able, but it only works for textures -- you cannot do it for flats or sprites (in a single wad, requiring two wads would be bizarre). I hoping for a solution that covers all uses of PNGs. How about a syntax like this:

Texture STARTAN3
width = 128
height = 128
scale = 1
patch = FOOX 0 0
patch = FOOY 64 0
patch = FOOZ 0 64
end

Flat FLAT10
scale = 0.25
end

Sprite TROOA1
xoffset = -13
yoffset = -7
scale = 0.5
end

Graphic M_PAUSE
xoffset = -20
yoffset = 0
scale = 1.5
aspect = 0.5
end


A generic text-based replacement for the binary TEXTUREx lump is definitely a good idea. But should all the other info go in there as well?
It all comes down to one question:

Is it preferable to have all this information in a separate text file or in the graphic itself? I think that the amount of manual work required to invest here should be kept to the barest minimum.

Regarding the distinction between flats and textures I think that should be dumped altogether. If we do something new that shouldn't be necessary anymore. A texture is a texture, no matter where it is used.

For sprites I really don't see the need to specify scaling externally. This shouldn't be a property of the sprite graphics (unless using a hires replacement.) It should be a property of the things that use the sprites. That way you can use the exact same graphic for different sizes. The biggest issue here is that the original things need some option to modify this information as well, especially for those ports which define all their actors internally (like ZDoom.)

[DaniJ]

At this stage I'm definetly favoring the above method. Although it requires a fair bit bit of work to remove the distinction between textures and flats in Doomsday I agree that should be removed also.

However I don't think the extra info should be placed in the graphics themselves as eg a new chunk in a png, as this would once again require another utility/editor to do the job. I'm much more in favor of a pure text file/lump.

As Graf mentions - I don't think its necessary to set scaling for sprites in this manner as they will (always?) be resized to the THING they are used on. Plus if we are going for a completely generic system here there would be no need to make that distinction anyway as a graphic resource could be used anywhere so in the case of sprites the scaling info could be discarded.

Surely the width/height info doesn't need to be specified and should be gleamed from the physical size of the resource. It would be better to have both X+Y scale too.

[Ajapted]

Is it preferable to have all this information in a separate text file or in the graphic itself?
The graphic is not a good place I think. PNG might be doable (new chunk) but what about JPEG? And modifying PNGs will require a special program -- won't that be painful for the user? Will that tool be available on all platforms (Win32/Linux/MacOSX)?

Regarding the distinction between flats and textures I think that should be dumped altogether.
I'd love to dump it, but I don't think we can. The flats STEP1/STEP2 conflict with the textures STEP1/STEP2 (in the iwad). If you hunt around your gigabytes of wads, you'll surely find more conflicts.

For sprites I really don't see the need to specify scaling externally. This shouldn't be a property of the sprite graphics (unless using a hires replacement.)
Why not allow both? Simply apply all the scaling factors from all sources.

The biggest issue here is that the original things need some option to modify this information as well, especially for those ports which define all their actors internally (like ZDoom.)
Sorry didn't understand you here.

[Ajapted]

As Graf mentions - I don't think its necessary to set scaling for sprites in this manner as they will (always?) be resized to the THING they are used on.
If you suggesting automatically scaling the sprite to the things "physics" height -- that's a very interesting idea, but some sprites are taller than their defined height (revenant, hell knight).

Surely the width/height info doesn't need to be specified and should be gleamed from the physical size of the resource. It would be better to have both X+Y scale too.
The width/height was there to implement the original TEXTUREx method of composing textures from patches. If the image came from elsewhere (like between TX_START/TX_END) then you could omit those fields and do what you suggest. (That's a bit hand-wavy I know, one of the nitty-gritty details to work out).

For X/Y scale I was using "scale" and "aspect". The former affects both X and Y, the latter just X (fatter or thinner). Having xscale/yscale is another possibility. I just prefer the first method since you don't need to change the aspect very often.

[Graf_Zahl]

What a mess, isn't it?

Somehow I doubt that we might find a solution that is clean, efficient and user-friendly without sacrificing something.

Regarding the texture duplicates, sure they are there in the IWAD (and maybe in some PWADs as well) But if we really do something new I strongly suggest we prohibit something messy like this in future extensions. There's no need for that. If someone wants to use these duplicates from the IWAD it should of course work but for newly defined data I see no good reason whatsoever to allow it again. Texture names should be unique to prevent unnecessary confusion.

[DaniJ]

If you suggesting automatically scaling the sprite to the things "physics" height -- that's a very interesting idea, but some sprites are taller than their defined height (revenant, hell knight).Doh. Yeah obviously that wouldn't work.
The width/height was there to implement the original TEXTUREx method of composing textures from patches.Something which Doomsday has abandoned in the case of hires texture replacements. It would be interesting if hires textures could be built in the same manner (from hires patches) but I wonder if its more trouble than its worth? However if we are going for a unified, generic system (that could replace TEXTUREx) then this SHOULD be allowed. This would also allow sprites built from patches which could be both very interesting and quite messy to boot *turvy*.

[smite-meister]

A generic text-based replacement for the binary TEXTUREx lump is definitely a good idea. But should all the other info go in there as well?
It all comes down to one question:

Is it preferable to have all this information in a separate text file or in the graphic itself? I think that the amount of manual work required to invest here should be kept to the barest minimum.

In a separate file, definitely. The graphics themselves should be in easy, standard picture formats such as PNG and JPEG.
This way you can also re-use the same graphic in different textures. Keep in mind that with the current map format,
the concept "texture" has to contain all the visual parameters except offsets.
Here's an example in a C-like syntax that I very much prefer to the MAPINFO-influenced one:
texture DOORTRAK
{
data = "doors/panel.png";
scale = 2.0;
}

texture WALL1 : inherits DOORTRAK
{
scale = 1.0;
shader = "shaders/glow";
}



Regarding the distinction between flats and textures I think that should be dumped altogether. If we do something new that shouldn't be necessary anymore. A texture is a texture, no matter where it is used.

Remember the STEP1/STEP2 namespace overlap, and AFAIR there is another in Hexen between a Wraithverge weapon sprite and a flat.

I myself took deepteam's hint and implemented a three-container system in Legacy to overcome these.
The first container is for flats, the second one for patches, graphics, doomtextures and "raw pages", and
the third one for the new "advanced textures". Each container is its own namespace.

The order in which these containers are queried depends on the intended use of the texture.
However, the "advanced textures" container is always checked first.
It will be populated e.g. using the new texture definition lump, so in essence you would have only
one namespace and only one type of "texture", and the first two containers can be regarded as historical curiosities.


For sprites I really don't see the need to specify scaling externally. This shouldn't be a property of the sprite graphics (unless using a hires replacement.) It should be a property of the things that use the sprites. That way you can use the exact same graphic for different sizes.
I agree (the game Rune, for example, utilized heavily the scaling of 3D models, which is the same thing).
The sprite system could just ignore any scaling instructions in the texture definition lump, and use the
DECORATE/whatever scaling factor or world dimensions instead.

BTW, here's how I was thinking of handling sprites in Legacy. Comments are welcome:

When the spriteframe lumps between S_START and S_END are loaded, Legacy first looks for an Advanced
Texture by that name, then a Doom Texture, and finally a patch (which normally is stored in that very
spriteframe lump). That's right, you can leave the spriteframe lumps empty if you supply the corresponding
textures somewhere else. The lumps are only needed to declare the existence of the particular frames.

[Graf_Zahl]

In a separate file, definitely. The graphics themselves should be in easy, standard picture formats such as PNG and JPEG.
This way you can also re-use the same graphic in different textures. Keep in mind that with the current map format,
the concept "texture" has to contain all the visual parameters except offsets.
Here's an example in a C-like syntax that I very much prefer to the MAPINFO-influenced one:
texture DOORTRAK
{
data = "doors/panel.png";
scale = 2.0;
}

texture WALL1 : inherits DOORTRAK
{
scale = 1.0;
shader = "shaders/glow";
}



I like that format. Although you could get rid of the '=' and ';' without any loss in readability.


Remember the STEP1/STEP2 namespace overlap, and AFAIR there is another in Hexen between a Wraithverge weapon sprite and a flat.


I mentioned the overlap. Ok, it's there but I'd leave it as it is. In the rare case that you'd really like to manipulate them with an external lump you'd have to duplicate them to deconflict the names. It's certainly nothing I'd let get in the way of a more flexible system that finally gets rid of the different namespaces when defining new resources.


I myself took deepteam's hint and implemented a three-container system in Legacy to overcome these.
The first container is for flats, the second one for patches, graphics, doomtextures and "raw pages", and
the third one for the new "advanced textures". Each container is its own namespace.

The order in which these containers are queried depends on the intended use of the texture.
However, the "advanced textures" container is always checked first.
It will be populated e.g. using the new texture definition lump, so in essence you would have only
one namespace and only one type of "texture", and the first two containers can be regarded as historical curiosities.


'Historical curiosities' is exactly the thing as which they should be written off. The system as it is is just a pain to work with. Of course I wouldn't touch them because old WADs still rely on them but I'd restrict any feature extensions to the new 'advanced' container as well.



BTW, here's how I was thinking of handling sprites in Legacy. Comments are welcome:
When the spriteframe lumps between S_START and S_END are loaded, Legacy first looks for an Advanced
Texture by that name, then a Doom Texture, and finally a patch (which normally is stored in that very
spriteframe lump). That's right, you can leave the spriteframe lumps empty if you supply the corresponding
textures somewhere else. The lumps are only needed to declare the existence of the particular frames.


You could even remove the necessity to put it between S_START/S_END altogether by adding a keyword 'sprite' to the advanced texture lump and then handle it appropriately when creating the texture object. Then you don't have to split the needed definitions into two places.

But for sprites I'd only look at the 'advanced textures' data, not Doomtextures and if that fails use the sprite lump itself. Checking 'doomtextures' might create problems because for old WADs it is unexpected behavior and though unlikely cannot be ruled out completely.

[smite-meister]

I like that format. Although you could get rid of the '=' and ';' without any loss in readability.

They are there to facilitate parsing. Especially the semicolon. If we can agree on a nice freeform format,
we could save lots of effort by writing a Flex/Bison -based parsing system that all the source ports could use
to implement the new texture lump in a standardized and easy way. Just an idea:)


I'd restrict any feature extensions to the new 'advanced' container as well.

Yeah, that is the simplest and most efficient way to do it.

You could even remove the necessity to put it between S_START/S_END altogether by adding a keyword 'sprite' to the advanced texture lump and then handle it appropriately when creating the texture object. Then you don't have to split the needed definitions into two places.

There's just the dichotomy between Doom sprites (which are complex "presentation" objects like 3D models)
and textures, which are simply instructions how to render a surface.
Sprites _use_ textures just like 3D models, but they are not to be confused with them. That's why I still use
the old S_START/S_END method for defining sprites.

[DaniJ]

I like that format. Although you could get rid of the '=' and ';' without any loss in readability. Yes to the ';' but I think we should keep assignment opperators. It may be that at some point in the future we would have a need to use others.

I too would prefer a single "texture" namespace. One thing we should consider is other resources. For example things like detail textures/decals etc, should they ALL exist in the same namespace? This is where the benefit of physical files in (virtual) folders comes in.
You could even remove the necessity to put it between S_START/S_END altogether by adding a keyword 'sprite' to the advanced texture lump and then handle it appropriately when creating the texture object. Then you don't have to split the needed definitions into two places.No I don't think thats a good idea. Doomsday used to do the same with external hires flats (existed in the textures/ folder and where prefixed flat-) which just makes it a pain for the users rather than the port programmer. I believe Graf didn't like that either *smirk*.

But for sprites I'd only look at the 'advanced textures' data, not Doomtextures and if that fails use the sprite lump itself. Checking 'doomtextures' might create problems because for old WADs it is unexpected behavior and though unlikely cannot be ruled out completely.
Agreed.

[Graf_Zahl]

No I don't think thats a good idea. Doomsday used to do the same with external hires flats (existed in the textures/ folder and where prefixed flat-)



Under no circumstances should it be possible to misinterpret a non-sprite texture as a sprite.

What I meant is that it is unnecessary to force an empty lump between S_START/S_END just to tell the engine that the sprite is there if you want to define it in a text lump.

It all depends on how the engine runs through the resources to collect all sprite frames. If you do it the old fashioned way and check everything between S_START/S_END directly it is logical that you still need it. But if you flag all textures used by sprites as such you might as well run through all the textures and get the information from there. Then it could also find sprites defined by other means - if you really want to allow composite sprites out of multiple patches. Otherwise it might be best to leave sprites completely where they are - without any interaction with any other texture type.

[deepteam]

I see a lengthy academic solution mixing up 2 totally different requirements: SPRITES and TEXTURES are different design elements. To make it work for all is resulting in the car designed by committe: the Ford Edsel :) Me disagreeing and pointing out how stuff got the way it was is not exactly the same as bashing *bang*

Sure some text thingy works but it sure as hell isn't user friendly. A text based definition of textures is for diehards only. The tools out there with visual texture feedback require very little modification to work as I have described. You need to think of compromise here, not the ultimate do-all format. It needs to do the #1 most common editing goal - resizing and using new hires/color textures easily.

There are NO TX PWADs where what I described causes an incompatibility problem. These all contain new textures, hence no problem with what I described. They work as they always did. I never said they had to be defined in TEXTUREx. But if you feel better with a new namespace, have at it :)

As I already said, a texture is a texture and the "flat" distinction is no longer required. The only thing required for the ports is to smartify their code so DOOM format flats accidently put in the wrong spot don't blow up the engine :) The step thingy is a non-starter if you organize as Smeit described - solves it instantly. Current code in ports is just not very smart for finding resources that's all. Smartify the code and you'll find that a lot of issues go away. But if you assume that the code for "searching" stays the way it is, then yes you'll find problems.

Interestingly, the very reason given in favor of PWAD packaging vs external files is really the exact same logic I'm using for keeping all the scaling relative to the TEXTUREx lump. It's not that other solutions can't work, just doesn't flow with how DOOM was layed out.

What everyone is forgetting is that EVERYONE has to learn the DOOM set of rules for texturing, including all those name spaces. So what the new stuff does is ignore all that learning and presume that it will all just flow. It won't. Just pay any attention to the problems that newcomers and even more accomplished users run into.

I have an idea - AJ needs to attempt to edit for JDOOM and ZDOOM and do NEW stuff. And Graf needs to actually do the same for JDOOM and EDGE. Now report back on what the stumbling blocks are when you tried to use the "new" features. Some have already been mentioned - what is revealing is that the underlying reason for the dislike is not recognized (it's nothing technical).

Now I doubt that you'll do this - however the reason you won't is enough for my point: It's not very easy to learn the nuances of the "mods" made since it's all brand new incompatible methods of doing similar things and it's pretty labor intensive work.

Now to the most important issue here: PORT COMPATIBLITY. Will ZDOOM, LEGACY, EDGE and JDOOM all use the SAME method at least at a basic level? If not, then that's the whole problem. Everyone sticks to their "solution" when when what I have described fits easily into the methods already chosen for those ports ( and others ).

All ports can still addon whatever they want - there's no way of stopping that. All I'm asking is that you consider a wide base to start with.
I no longer think that. DOOM == WAD. All the tools (editors etc) are wad based. You can't expect everybody to adopt another package format, even though it would be a much nicer system.
EXACTLY - that's precisely the gist of my overview. It "would be a nicer system" only if you had all the right visual feedback and editing tool and it follows the learning that has already taken place.

Make an OBJECTIVE list for TEXTURES only (SPRITES are just a different problem) - here's mine for rescaling the TEXTUREx way (some minor coding mods implied):

1. It's easy to do using existing tools. Wintex, XWE or DeePsea are familiar to anyone who creates new textures. XWE and DeePsea have 1 step methods for creating "fake" resources or for that matter using the "hires-truecolor" as a patch" ala the DOOM method. This is NOT required - default is 1-1 scaling.

2. The patch method (if used) gives you the ability rescale the SAME texture using exactly the same patch. Yes this is sometimes neat to do as amply demonstrated somewhat with the original levels - also applies to scaling hires. I made a level showing how this feature works. Very space saving for hires-truecolor textures. Why waste space if you don't have to:)

3. Existing tools give visual editing feedback even if the actual texture isn't there (aka a "fake" is created - see a JDOOM document on same. Not that I would do it this way, just a reference).

4. It's compatible with BOTH internal and external textures (as done by JDOOM and ZDOOMGL)

5. ALL solutions proposed require modifying ZDOOM and the other ports. Just because the text method has been done in some so you don't have to rethink the code that's there is more possibly more work, but I know for sure that for JDOOM the mods fit right in. Actually ZDOOM too once you understand how the whole system works and realize that the lookups require modification.

6. It's a universal "container" for all the texture elements that a user sees in editing. It's very easy to use (unless one is used to obsolete tools). Could even be used for sprites - I see an easy dismissal of concepts extending a familiar concept that is actually easy to implement. It is quite simple to create a resource for this - have done this for other reasons already - can do all the sprites in about 1 minute. I think you'd be hard pressed to make a lengthy text file for the same.

7. Other desired features have nothing to do with rescaling and should be put in some text file just as described. It's just that you don't require the scaling parms *alien*

[DooMAD]

Most of the coding stuff here is going way over my head, so I'll just stick with what I know.

I've been testing my latest Legacy map in GZDoom and have to say I'm impressed. With the exception of FS (which wasn't implemented in the original release of GZDoom I downloaded, but apparently is now supported or being added) and coloured sector lighting, everything seems to be compatible.

I noticed a difference with the projectile speed in GZDoom, which I defined in DeHackEd. I can only assume this is due to a removal of the projectile speed limit vanilla doom has. I have no idea what that value is, so I just set it to a high number. These projectiles are now moving extremely quickly in GZDoom, but that's easily corrected. Also, GZDoom appears to have fixed the age old problem of enemies trying to shoot through 3D floors.

I know these are very minor issues, but these are the kinds of things that mappers are going to choose what ports to base their project on and what people are going to choose to play maps in, so it's important to decide just how far compatibility needs to be taken. At the moment, it would seem that my map runs almost identically in both ports, so I don't really have to worry, but I'm sure there are other minor details like this that will affect other peoples' maps.

[smite-meister]

Otherwise it might be best to leave sprites completely where they are - without any interaction with any other texture type.
You must mean sprite frames. I'd say that a Doom sprite is a composite object, which consists
of several sprite frames (8 directions, N animation frames each).
The individual sprite frames are certainly textures, but the sprite itself is a different thing, and should not
be defined in the texture definition lump.

As an example, you could define a texture called PLAYA1 in the texture definition lump,
but to make it part of the PLAY sprite, you would also have to include a lump named PLAYA1 in the
S_START/END wad section.

[deepteam]

Most of the coding stuff here is going way over my head, so I'll just stick with what I know.
To bad I'm way too long in posts (sorry about that), but I think that it's not really over your head. Simply put, I'm saying that everything you know about texture sizes follows the same rules you already know when it comes to hires/color textures. The size is set the same as you do now when you create textures - just set the X and Y size in Wintex/XWE/DS and you are done. The size of the "hires/color" image automatically scales to the size set (as you do with regular textures) with nothing else for you to do.

From my POV, your input is what I think we are really after *alien* Do you think that manipulating yet another text file with new rules that you have to insert inside a PWAD that may or may not be supported by whatever editing tools you use is easier than setting texture sizes as you have been doing?

I'm imposing a bit on you here and if you are uncomfortable - don't worry about it.

Of course, I'm assuming that you've created new textures. If not then someone else who is not in the coding area but has created mods can reply. My interest is 100% as to what experienced non coders will say (and I hope that we don't get a bunch of trolls sent here - so please refrain from linking to this forum just to get artificial feedback) Anyone who is brand new won't count *grin*

[deepteam]

You must mean sprite frames. I'd say that a Doom sprite is a composite object, which consists of several sprite frames (8 directions, N animation frames each).

The individual sprite frames are certainly textures, but the sprite itself is a different thing, and should not be defined in the texture definition lump.

As an example, you could define a texture called PLAYA1 in the texture definition lump,
but to make it part of the PLAY sprite, you would also have to include a lump named PLAYA1 in the
S_START/END wad section.
But you could have a lump named PLAYA1 in S_START and have a texture called PLAYA1 too. Just clarifying what can and can't be. Some ports make a mistake here though. There's a legacy PWAD that demonstrates this "patch" lookup problem for ZDOOM, but not for LEGACY. (maybe some others too can't remember). And technically, ZDOOM allows you to have a patch called PLAYA1 outside of the S_START. IOW in addition to the sprite one. [wonderful system *spin* ]

The term "texture" and "patch" are more appropriate terms here so the distinction is crystal clear. A sprite frame is really a "patch". Then when you get to a text file for scaling, you've pointed out the issue that "patches" and "textures" can indeed have duplicate names and thus you need to reconcile that. Another reason to keep these 2 sort of things independent from one another. So make a HIRESPRT lump *spin*

[Graf_Zahl]

I see a lengthy academic solution mixing up 2 totally different requirements: SPRITES and TEXTURES are different design elements. To make it work for all is resulting in the car designed by committe: the Ford Edsel :) Me disagreeing and pointing out how stuff got the way it was is not exactly the same as bashing *bang*


*diablo*

I'd avoid mixing them as well. But since ZDoom allows sprites on walls it can't be done completely. Just check out Super Sonic Doom. (Do I need to mention that I wouldn't have allowed it without some texture definition referencing the sprite lump?)


Sure some text thingy works but it sure as hell isn't user friendly. A text based definition of textures is for diehards only. The tools out there with visual texture feedback require very little modification to work as I have described. You need to think of compromise here, not the ultimate do-all format. It needs to do the #1 most common editing goal - resizing and using new hires/color textures easily.


The 'visual feedback' tools could write into the text lump so that is hardly an issue. The problem with the current methods is more that their options are so painfully limited.


There are NO TX PWADs where what I described causes an incompatibility problem. These all contain new textures, hence no problem with what I described. They work as they always did. I never said they had to be defined in TEXTUREx. But if you feel better with a new namespace, have at it :)


But incompatibilities are easily created. Imagine the following simple case.

Someone creates a hires texture pack that uses TEXTUREx scaling to define hires versions of a larger number of textures, including, say, SKY1.
Ok, let's assume that someone sets up that wad to autoload whenever Doom is being launched. So as a result SKY1 is now a hires texture.
Now the user loads a PWAD that happens to place a new SKY1 between TX_START/TX_END. Since your method had to assume that SKY1 is scaled the new texture is displayed incorrectly.

I'd rather keep these namespaces completely separate as it removes one cause for potential errors.


Interestingly, the very reason given in favor of PWAD packaging vs external files is really the exact same logic I'm using for keeping all the scaling relative to the TEXTUREx lump. It's not that other solutions can't work, just doesn't flow with how DOOM was layed out.


Imagine why this issue is causing such headaches. None of the solutions presented here are perfect. They all have some more or less severe shortcomings.

I'm still in favor of a text based replacement of TEXTUREx. If you are using a WAD management tool to manipulate it it's not that bad but I'd like to see full floating point scaling factors or better, being able to specify a destination size instead of the current rough and unprecise fixed point scaling values (like HIRESTEX allows.) Plus, being able to manipulate it from the outside is still a plus. If you just have to do some minor tweaks it is much faster to load a text file into an editor than to manipulate binary data.


What everyone is forgetting is that EVERYONE has to learn the DOOM set of rules for texturing, including all those name spaces. So what the new stuff does is ignore all that learning and presume that it will all just flow. It won't. Just pay any attention to the problems that newcomers and even more accomplished users run into.


Nobody is forgetting these things. But relaxing them to a point where they don't matter anymore is a worthwile goal.


I have an idea - AJ needs to attempt to edit for JDOOM and ZDOOM and do NEW stuff. And Graf needs to actually do the same for JDOOM and EDGE. Now report back on what the stumbling blocks are when you tried to use the "new" features. Some have already been mentioned - what is revealing is that the underlying reason for the dislike is not recognized (it's nothing technical).

Now I doubt that you'll do this - however the reason you won't is enough for my point: It's not very easy to learn the nuances of the "mods" made since it's all brand new incompatible methods of doing similar things and it's pretty labor intensive work.


Correct. *smirk* I was about to say the exact same thing. Getting an understanding of other people's code can be quite time consuming.


Now to the most important issue here: PORT COMPATIBLITY. Will ZDOOM, LEGACY, EDGE and JDOOM all use the SAME method at least at a basic level? If not, then that's the whole problem. Everyone sticks to their "solution" when when what I have described fits easily into the methods already chosen for those ports ( and others ).


The only thing that might become reality is just a lowest common denominator, as unfortunate as it is. What we have here are ports with vastly different design phiolosophies that are hard - if not impossible - to get together. But what to use as the lowest common denominator. The requirements are:

- it has to be compatible with all existing implementations. And believe it or not - ZDoom's texture management is probably the biggest obstacle in here.
- under no circumstances should it create interdependencies between different texture types. I still think that having TEXTUREx scaling affecting textures in other name spaces is a very bad idea.


All ports can still addon whatever they want - there's no way of stopping that. All I'm asking is that you consider a wide base to start with.


Aren't we doing this already? Right now it's just ideas being tossed around. Hopefully something usable comes out of it.



I no longer think that. DOOM == WAD. All the tools (editors etc) are wad based. You can't expect everybody to adopt another package format, even though it would be a much nicer system.

EXACTLY - that's precisely the gist of my overview. It "would be a nicer system" only if you had all the right visual feedback and editing tool and it follows the learning that has already taken place.


Except for the TEXTUREx issue I agree with that.


Make an OBJECTIVE list for TEXTURES only (SPRITES are just a different problem) - here's mine for rescaling the TEXTUREx way (some minor coding mods implied):

...



Your whole set of suggestions essentially means 'leave it as it is', right? I'm having no problem with that. For 90% of the stuff that works fine. If you are dealing with a standard set of resources there really is no necessity to add more complicated solutions. As soon as true color graphics in the standard namespaces are supported that should be enough to handle everything - except optional hires texture replacements.

For me the best solution is a separate WAD namespace (TX_ is out because it already has a defined set of properties I am unwilling to alter so for me it's HI_START/HI_END.)

That should be easy enough to handle once the grahpics initialization code is able to recognize all data formats without the need of an extension.

The HIRESTEX lump I added was more or less a concession to the people demanding it but I wouldn't have much problems to deprecate it later once a good common solution has been worked out. The one thing it is good at though is that it allows more precise scaling than TEXTUREx as the scaling is expressed as a destination size, not a low-precision scaling factor.

[Graf_Zahl]

I noticed a difference with the projectile speed in GZDoom, which I defined in DeHackEd. I can only assume this is due to a removal of the projectile speed limit vanilla doom has. I have no idea what that value is, so I just set it to a high number. These projectiles are now moving extremely quickly in GZDoom, but that's easily corrected.


You are right. Doom originally capped the maximum speed of projectiles. ZDoom has removed that limit quite some time ago so logically GZDoom uses the newer method which allows much larger projectile speeds.


Also, GZDoom appears to have fixed the age old problem of enemies trying to shoot through 3D floors.


Courtesy of ZDoom's much better trace code which was far easier to adjust than Doom's original. *smirk* Also note that monsters can't see through 3D-floors as well.

[Ajapted]

As Graf said, this is very messy. In an attempt to boil it down, here are four specific problems and potential solutions. Let's see if we can agree on a single solution for each one.


Problem 1: offsets for PNG sprite images

Assume the default is to center sprites horizontally (xoffset = -width/2) and standing on the ground (yoffset = height).

Solution A: modify the PNG files somehow to include the offsets. I don't think any of us want to do this.

Solution B: require dummy sprites in patch format, and use the offsets from them. For new sprites (e.g. for DECORATE/DDF) this would require two wads, one with the dummies and one with the PNGs, making this a poor solution I think.

Solution C: specify the offsets in a text lump. The lump only has the scope of the wad it is in (doesn't affect earlier/later wads). An editing tool which allows inserting PNG sprites should update this lump (invisibly to the user).


Problem 2: scaling of large/PNG sprites

Assume that default scaling is 1:1 (one pixel = one world unit). The ability to change aspect is implied in this discussion.

Solution A: require scaling to be specified in thing's "definition" (DeHackEd, DECORATE, DDF etc).

Solution B: require a dummy sprite and automatically scale to match it. (Only makes sense with PNG sprites). Bad for new sprites for the same reasons given above (need two wads). Will give strange effects if a user replaces an existing monster (TROOxx) with his own hires sprites.

Solution C: in addition to A, allow the scaling to be set in a text lump (same lump as for problem 1). The editor/tool will update the scaling in the lump when the user inserts a PNG image (e.g. via on-screen scaling fields).


Problem 3: scaling of PNG flats

Solution A: scale it to match the existing (non-png) flat, or leave unscaled (1:1) if it doesn't exist. To control the exact scaling, you need have a dummy flat, requiring two wads (one for dummies, one for PNGs). That makes it a poor solution imo.

Solution B: specify scaling in a text lump. Default to unscaled (one pixel = one world unit) if not present in that lump.

Solution C: specify scaling in the map format. Requires a new map format (which I think is very unlikely to be adopted).


Problem 4: scaling of textures between TX_START and TX_END

I'm assuming that patch format textures and PNG format textures should be treated the same.

Solution A: scale it to match existing (non-TX) texture of same name, or unscaled (1:1) if it doesn't exist. Requires a dummy texture to get precise control over scaling (but at least you don't need two wads).

Solution B: specify scaling in a text lump. Default to unscaled if not present.

Solution C: leave unscaled, and specify scaling in the map format. Requires new map format (very big change, so less likely to be widely adopted).

[Graf_Zahl]

Problem 1: offsets for PNG sprite images

Assume the default is to center sprites horizontally (xoffset = -width/2) and standing on the ground (yoffset = height).

Solution A: modify the PNG files somehow to include the offsets. I don't think any of us want to do this.

Solution B: require dummy sprites in patch format, and use the offsets from them. For new sprites (e.g. for DECORATE/DDF) this would require two wads, one with the dummies and one with the PNGs, making this a poor solution I think.

Solution C: specify the offsets in a text lump. The lump only has the scope of the wad it is in (doesn't affect earlier/later wads). An editing tool which allows inserting PNG sprites should update this lump (invisibly to the user).



If you use a tool to maintain the offsets solution A isn't any more problematic than C. The tool that maintains the data can as easily insert the new chunk into the PNG instead of using a separate text file. But if you want to support other formats C is really the only solution. Anyway, since ZDoom already supports A) I can't make it go away.



Problem 2: scaling of large/PNG sprites

Assume that default scaling is 1:1 (one pixel = one world unit). The ability to change aspect is implied in this discussion.

Solution A: require scaling to be specified in thing's "definition" (DeHackEd, DECORATE, DDF etc).

Solution B: require a dummy sprite and automatically scale to match it. (Only makes sense with PNG sprites). Bad for new sprites for the same reasons given above (need two wads). Will give strange effects if a user replaces an existing monster (TROOxx) with his own hires sprites.

Solution C: in addition to A, allow the scaling to be set in a text lump (same lump as for problem 1). The editor/tool will update the scaling in the lump when the user inserts a PNG image (e.g. via on-screen scaling fields).


A is a requirement so that you can create differently sized objects from the same sprite. But if you absolutely need pre-scaled graphics it's again either C) or modifying the PNG.
But do we really need it? For creating new objects method A) is enough if you can dynamically change the scale inside the object by calling a code pointer.
Of course that leaves out the option of hires sprite replacements for the original things. Is it really worth thinking about? Those who like hires data are much more likely to use models instead so the chance that this is ever needed is rather slim.


Problem 3: scaling of PNG flats

Solution A: scale it to match the existing (non-png) flat, or leave unscaled (1:1) if it doesn't exist. To control the exact scaling, you need have a dummy flat, requiring two wads (one for dummies, one for PNGs). That makes it a poor solution imo.

Solution B: specify scaling in a text lump. Default to unscaled (one pixel = one world unit) if not present in that lump.

Solution C: specify scaling in the map format. Requires a new map format (which I think is very unlikely to be adopted).



Frankly, I'd ignore this issue. Flats can't be scaled. Period. It really isn't necessary to allow all available texture formats to support all options. If regular textures can be scaled they should be used instead.


Problem 4: scaling of textures between TX_START and TX_END

I'm assuming that patch format textures and PNG format textures should be treated the same.

Solution A: scale it to match existing (non-TX) texture of same name, or unscaled (1:1) if it doesn't exist. Requires a dummy texture to get precise control over scaling (but at least you don't need two wads).

Solution B: specify scaling in a text lump. Default to unscaled if not present.

Solution C: leave unscaled, and specify scaling in the map format. Requires new map format (very big change, so less likely to be widely adopted).

I don't like A) because it creates dependencies where none should be.
As with the flats the question is whether this is really needed. One scalable texture format should be enough.


The problem I see here is that it always requires a control lump that modifies the properties of the other data.

I think it'd be better to actually define the texture in such a lump and let it only reference the actual graphics (like TEXTUREx) but improve the format. If TEXTUREx wasn't binary and had a better method to express the scaling factor it'd be enough for 90% of all cases.

How about this:

-For sprites only Doom patches and PNGs can be used if special offsets are needed. These are the only formats that allow easy integration of the offset into the file itself and have a decent means to define transparent areas. JPGs are out by default because they can't specify transparency in a decent manner so the rest isn't worth thinking about. The same is true for most other formats. If they are used anyway use default offsets so that it can do at least something but full support isn't a necessity IMO.
-If you absolutely feel the need to specify scaling for sprites use the same method but then it'd be restricted to PNGs.
-Flats and TX-textures are raw data that define all their properties themselves. That means if you have a graphics format that supports scaling it'd be used, otherwise they are unscaled.
-TEXTUREx textures work as they do now but allow an alternate text-based definition file to get around the limitations of these binary lumps. Most importantly this means that the scaling factor should be a full precision float or a destination size. And of course it should combine the TEXTUREx/PNAMES data in one place to eliminate one of the biggest resource-related cause for errors.

This way the need for external control lumps is reduced to the minimum extent possible while offering nearly everything that is needed to support the features being discussed here - except optional hires replacements.

That's probably the messiest issue of all. How much of that is needed and how should it be done? Personally I have to admit that I don't particularly like it but to support Doomsday's hires texture packs it can't be simply ignored.

Questions:

1) Do we need internal WAD support for these or should the WAD's creator be forced to pre-define his textures as hires by some of the other means? For GL-only ports this might be a non-issue because they'd most likely have no problems using the hires textures but what if someone wants to make something that is compatible with low-end machines and software rendering that can't handle them?
2) Assuming we need them, how should we do it? I think a control lump to define them should only be a method to maintain compatibility with existing methods (like HIRESTEX.) A separate namespace would be an option but that could create issues with ports that don't know about this namespace (so the replacement textures might needed to be put into a separate WAD.) But this problem is certainly solvable.

Frankly, the more I think about this issue the less I like it. These replacement textures are almost guaranteed to create a mess - no matter how you do it. Every thing I thought about in the last few days only showed new problems which in the end would make such a mechanism quite unstable.

It really should be enough to offer the mapper a convenient means to define such textures properly with the existing methods (i.e. TEXTUREx or a suitable replacement.)

As for such a replacement, how about something like this:


TEXTURE mytexture
{
Width 128
Height 128
DestWidth 64 - (I think specifying the world size is preferable to specifying a scaling factor)
DestHeight 32
UseWorldOffsets / UseTexelOffsets - (to accomodate ZDoom's different methods of placing textures)
Patch mypatch1 0, 0
Patch mypatch2 64,0
}


The format should be strictly line based so that it is easily extended without breaking a parser that doesn't know all the keywords. Then it can be extended without problems should there be any need for it.

I think with such a solution everybody could be satisfied. For both engines and editing tools it only means minimal additions to the existing functionality while offering the possibility to get rid of these binary texture definition lumps.

[smite-meister]

In an attempt to boil it down, here are four specific problems and potential solutions.

My solution would be
1C,
2A,
3B, except that the new "advanced textures" defined in the text lump shouldn't be flats or doomtextures, simply textures,
4B, with the same precondition as the previous one.

The format should be strictly line based so that it is easily extended without breaking a parser that doesn't know all the keywords. Then it can be extended without problems should there be any need for it.
It does not have to be line-based, "freeform" is just as extendable. It's just that if you define newline to be
whitespace, you need some other separator token for the declarations (in C it's the semicolon).
Furthermore, C grammars and token definition files are AFAIK freely available, and you can easily strip them
down to suit our simple needs. This is the main reason I suggested the C-based syntax.

Here's another shot at the format, extending Graf's example:

texture MY_TEX_1
{
// unnecessary with all modern graphics formats, but OK for overriding?
Width = 128; Height = 128;

// scaling is done most easily by giving the target world dimensions, but we can allow both ways:
DestWidth = 64; DestHeight = 32;
// or Scale = 2.0; Aspect = 2.0;

// OK, since the texture offsets can indeed be interpreted in two different ways
UseWorldOffsets; // or UseTexelOffsets;
// XOffset = 0; YOffset = 10; // you could define offsets here, too, see below

// just for the heck of it, we should allow arbitrary linear transformations (rotating, scaling, shearing)
// between texel space and world space:
// TransformationMatrix = {{0.6, 1}, {-1, 0.3}};

// I see no real reason to support textures built from several data files anymore,
// but OK if you want to completely replace TEXTUREx.
// since patch_t has no magic numbers, it's probably good to have a specific keyword for it:
Patch "mypatch1" 0 0;
// maybe you could do detail textures with a similar construct?
}

texture ANOTHER1 inherits MY_TEX_1
{
// just to show off inheritance and some possible advanced features
shader = "some_path/shader1.cg";
}

texture FLOOR1_1
{
// this one overrides a flat in doom2.wad and demonstrates that all "advanced textures" are equal

// normally we just specify a single graphics file (usually a lump in the WAD)
Data = "PNGLUMP1";
Scale = 3.0;
}

texture PLAYA1
{
// this texture overrides a sprite frame
Data = "PNG_A1";
// no scaling here, because it is defined in DECORATE or equivalent

// why not give offsets for the sprite frames right here?
XOffset = -20; YOffset = -2;
}

[Graf_Zahl]

Now we are getting somewhere. Most of these suggestions are exactly why I'd like an extendable format instead of sticking to the horrendously limited TEXTUREx.

A few comments:

My reason why I don't like the idea of specifying scaling for flats/TX textures in a text lump are simple: When there is an advanced definition method it isn't needed. These formats should be considered deprecated and only be supported for backwards compatibility with the options they offer now. If you need advanced features for a texture just define it as an advanced texture. If we strictly limit the advanced features to this new definition method we could easily circumvent a lot of very work-intensive issues. Having to scan text lumps for modifying data and tracking it across WADs is something I'd very much prefer not to do. It wouldn't offer anything that couldn't be achieved by better means.


The UseWorldOffsets/UseTextureOffsets is to specify how the linedef offsets are to be interpreted. I could easily live without them but ZDoom already makes this distinction.

I don't quite see the need for texture transformation matrices. Are you suggesting that texture rotations should be possible with this?

Regarding multiple patches, it could be done without them. But that can easily create huge files if you want to define textures with some signs on them and have to duplicate all the same base data over and over again. In such cases the ability to combine base textures with an overlay would come in handy. After all it's not a requirement, just an additional option.

The inheritance option is a really interesting idea.

Regarding replacement of flats, that doesn't need to be an explicit option. Just define it as a normal texture and it should automatically override the flat which should have lower priority.

The one thing I am not happy with is the override option for sprites. This is the part where it might get really messy. In almost any case there is no real need for this unless you need some very specific options.

[Ajapted]

This new way to define images (a replacement TEXTUREx) is looking promising.

But I'm stuck on the name-conflict issue. If all advanced textures are equal, and you create a STEP1 (or STEP2), then the same texture will be used on both walls and floors. Maybe you need to see it for yourself -- I have (when making the Doom Retexturing Project work with Edge) and it looks bad. Even worse can happen if sprites are in the mixed bag too.

Maybe the benefits far outweigh the potential for name-clash problems, but it still makes me a bit uncomfortable.

Regarding syntax: I'm not too fussy, but prefer line-based because it's easier to parse.

[Boingo the Clown]

I guess I am a little bit late entering into this, although I guess what I have to say on it could be important.

A few months ago, Smite Meister was talking to me about the changes in Legacy that would render my Heretic based hacking useless. It is not this itself that worries me, because it is all nonstandard hacking, but he did mention a couple of things at the time that do bother me a little, because they do render some standard hack editing useless.

The first thing he mentioned was the fact that the strings for the text at the end of episodes would no longer be hackable, and would required a different way of changing them. This is a concern, because many older TCs do change the end of episode text.

The second was the removal of the ability to change the sprite names. This is less common, but I am certain there are TCs out there that do change the sprite names, becuse it is also a standard hack, and it is quite possible that some modders, like me, would want to change the sprite names to more decriptive one for convenience sake.

[Graf_Zahl]

But I'm stuck on the name-conflict issue. If all advanced textures are equal, and you create a STEP1 (or STEP2), then the same texture will be used on both walls and floors. Maybe you need to see it for yourself -- I have (when making the Doom Retexturing Project work with Edge) and it looks bad. Even worse can happen if sprites are in the mixed bag too.


If you use it to replace the originals it might create a problem. For strict hires replacements of the originals there has to be another option (like using an external directory like Doomsday. Remember, hires replacements are not an editing feature. They are more a convenience for people who don't lile lo-res. I wouldn't want to let this get in the way of making texture editing more streamlined.
Sprites should not be part of this. That could complicate matters to a point where all user-friendliness could get lost.


Maybe the benefits far outweigh the potential for name-clash problems, but it still makes me a bit uncomfortable.


If all else fails let's define a new keyword 'replace'. Although then we'd be at the same point as with HIRESTEX - which some people don't like. But if merely used to get around this one particular pitfall I could live with it. But it shouldn't be an issue that's just annoying baggage in the entire system.


Regarding syntax: I'm not too fussy, but prefer line-based because it's easier to parse.

That depends on the code you are using. I don't really care. Hexen's SC_MAN with ZDoom's extensions which I'd use is flexible enough to handle this.

[Graf_Zahl]

I guess I am a little bit late entering into this, although I guess what I have to say on it could be important.

A few months ago, Smite Meister was talking to me about the changes in Legacy that would render my Heretic based hacking useless. It is not this itself that worries me, because it is all nonstandard hacking, but he did mention a couple of things at the time that do bother me a little, because they do render some standard hack editing useless.

The first thing he mentioned was the fact that the strings for the text at the end of episodes would no longer be hackable, and would required a different way of changing them. This is a concern, because many older TCs do change the end of episode text.


Sometimes sacrifices have to be made in order to improve things. Since there aren't that many projects doing this it'd be a minor issue at most and would be worth it if the benefits ourweigh the concerns.


The second was the removal of the ability to change the sprite names. This is less common, but I am certain there are TCs out there that do change the sprite names, becuse it is also a standard hack, and it is quite possible that some modders, like me, would want to change the sprite names to more decriptive one for convenience sake.

Bad idea!
Just check out Strain for a WAD that does alter the sprite names. This was something ZDoom had also some issues with and they had to be fixed afterward.

[smite-meister]

A few months ago, Smite Meister was talking to me about the changes in Legacy that would render my Heretic based hacking useless. It is not this itself that worries me, because it is all nonstandard hacking, but he did mention a couple of things at the time that do bother me a little, because they do render some standard hack editing useless.
Not to worry, you _can_ still hack sprite names, and I think we eventually find a way to support hacking
the endtexts too, although it's harder.
I also have made a small program for converting your Heretic hacks so they will work in the new version.

[smite-meister]

But I'm stuck on the name-conflict issue. If all advanced textures are equal, and you create a STEP1 (or STEP2), then the same texture will be used on both walls and floors. Maybe you need to see it for yourself -- I have (when making the Doom Retexturing Project work with Edge) and it looks bad. Even worse can happen if sprites are in the mixed bag too.

I've seen it, and what's worse, it may break some maps (the STEPx textures and flats have different sizes,
so if you have a "raise by SLT" linedef, for example, you are in trouble).

This simply means that you can't use the new texturedef lump for full retexturing projects
(but if you leave the STEPx's out, it should work!). When creating new maps, the authors
will know to avoid namespace conflicts.

BTW, if you really want to do a full retexturing pack using the new lump, you can make STEPx textures that
have map dimensions equal to the original doomtextures, and draw something which looks good both on wall and floor :)


Regarding syntax: I'm not too fussy, but prefer line-based because it's easier to parse.
I was thinking of writing a Flex/Bison -based parser for the new format when it's ready,
I'm sure you can use the same grammar files with small modifications in EDGE.


I don't quite see the need for texture transformation matrices. Are you suggesting that texture rotations should be possible with this?

Yes, and shearing and scaling. Could be useful on floor textures at least.

[Graf_Zahl]

Yes, and shearing and scaling. Could be useful on floor textures at least.


Maybe. But for flats I'd prefer an approach like ZDoom which allows scaling and rotating per sector, not per texture. But considering the work involved here, why not? In OpenGL at least texture transformations are easy enough to do.

[DaniJ]

I must say I'm (nicely) surprised to see this thing progressing as far as it has done already. I think its telling exactly which authors are actively participating too.

As far as hires replacements I think that they should be treated completely seperately from the originals. IE at no point should a replacement figure in this new system. However, if a new texture is defined using this new system - logicaly the replacement feature should work for them also eg:

IWAD texture (can be replaced with a hires version ala Doomsday)
IWAD texture : replaced in a PWAD (IWAD hires replacement not used)
NEW texture in a PWAD (can be replaced with a hires texture of the same name)

texture transformation matrice
I don't see the benefit of that in a texture declaration. How would that be useful?

[Graf_Zahl]

I must say I'm (nicely) surprised to see this thing progressing as far as it has done already. I think its telling exactly which authors are actively participating too.

As far as hires replacements I think that they should be treated completely seperately from the originals. IE at no point should a replacement figure in this new system.


Better not. Hires replacements are already giving me a headache. *ugh*


However, if a new texture is defined using this new system - logicaly the replacement feature should work for them also eg:

IWAD texture (can be replaced with a hires version ala Doomsday)
IWAD texture : replaced in a PWAD (IWAD hires replacement not used)
NEW texture in a PWAD (can be replaced with a hires texture of the same name)


How exactly does Doomsday decide whether to use a hires replacement or not? For compatibility purposes I'd like to use a logic that is mostly the same to avoid confusion.



I don't see the benefit of ( texture transformation matrices) in a texture declaration. How would that be useful?

I don't consider it a necessity. But who knows? Maybe someone has good use for it. But this really isn't essential. I think it should be postponed for later but kept in mind. First we'd need a working system everyone agrees upon.

[DaniJ]

How exactly does Doomsday decide whether to use a hires replacement or not? For compatibility purposes I'd like to use a logic that is mostly the same to avoid confusion.
Well, presently it doesn't... Theres a couple of command-line flags that tell Doomsday to use texture/patch/etc replacements with PWADs which the user must turn on/off as required depending on whether they want to use them or not with a certain PWAD. Its something that REALLY bugs me and I plan to change, so that Doomsday makes this decision on a per resource basis rather than the user. The reason it isn't in place already, I believe, is due to the amount of work required to overhaul the resource manager. Its a job that I'm planning on doing soon (it would also be cool to have an automatic system that says which resources can receive what extras (extras meaning decor lights, lightmaps, detail textures, multipass effects and ultimately shaders) and to remove the distinction between flat/texture).

[deepteam]

How is duplicating what is already there in text form (re patches) making the scaling solution simple? More importantly, this discussion is missing the most important feedback - the typical user. Seems that would be the #1 goal here. At least in the ZDOOM forums that was some user feedback, but so far there's no user feedback at all relative to scaling. Oh well.

Aside from the deceptive notion that since a text file is easy to edit, then it's easy to use, the real truth is that text stuff is difficult and more awkward for the user than what I'm talking about. The user has to learn the syntax, can make mistakes, etc. Much trial and error. What is so quickly glossed over (not even discussed) is the contradition to existing methodology and the lack of consistency. Now if you used a lump like this for something NEW (as has been tossed around), great, but not for the basics of scaling.

And since we are talking about cross port compat, all the ports here need to copy the ZDOOM scaling method anyway. Perhaps this isn't realized or perhaps a few don't really know how it already works? Once you go to that work it's a minor addon to go 1 step further.

I'd avoid mixing them as well. But since ZDoom allows sprites on walls it can't be done completely.You misunderstood my statement. I mean don't mix a texture solution with a sprite solution in this discussion. Of course sprites are legit "textures" on floors and walls, but that's not what I meant.

Let's address scaling and only scaling for now. That is a very simple decision. I agree that other attributes suit a different system. You have an existing system that is actually quite efficient at doing this. Not everyone here may know the fastest way to do this, but it is very fast and FOOLPROOF (no typo's ever) for both the user and actually the code.
But incompatibilities are easily created. Anyone can make up lots of incompatible combinations using TODAYS methods and FUTURE methods - again not a cogent argument. What if you have 2+ hires text files with duplicated names? What if they combine conflicting resource types? Duplicated names (in any form) actually cause a problem no matter what you design. You see, an exception list goes on and on. One example does not a logic make :)

It's ALWAYS the users responsibility to combine resources in the correct manner and that includes autoloaded stuff.
I'd rather keep these namespaces completely separate as it removes one cause for potential errors.If you gave some examples of existing PWADs with a serious problem, maybe. But as you point out for others issues, who cares for the very very few that are this way? Lets be consistent in the way we argue and not jump back and forth on both sides of the fence.

For that matter, the original TX didn't have to exist either - as was pointed out by others at the time. The philosophy was that some users never understood the texture system and had a low tolerance for learning. They just wanted to dump it in there without any of the TEXTUREx/PNAMES bs:) In the process, it was assumed they didn't care about scaling. Immediately that prompted a question for those more knowledgeable and a request for a new lump exactly like this one (you can reread the posts to verify) but probably ignored because TEXTUREx already easily did this. So why create a solution for something that was already solved? It's been a long time and RH decided against it :) There's a good reason for that. The only flaw was not matching existing replacements so a hires-color pack could be done instantly.

The only real problem with TEXTUREx scaling is that it's not absolute, hence a tad awkward to use. Why it wasn't done the JDOOM way is either a case of not realizing how JDOOM did it or something else *l7* Anyway what I'm describing is absolute resizing to the existing size - which can include the old scaling. It's a TRIVIAL matter to create these resources. In fact, for the 2 most widely used tools, what happens is they can become real TEXTUREx (a 1 step process and can be carried out enmasse with DS if I add that for PNGs like it is for BMPs- you see this is new code for me no matter what happens).

This is a heck of a lot faster than any text file solution. And it automagically works for existing editors that are used, even if they don't show the correct image.
None of the solutions presented here are perfect. They all have some more or less severe shortcomings.Well the #1 shortcoming of the text system is that it's not user editor friendly. The #2 problem is that ALL the ports need to use this. And that means adopting the rest of the ZDOOM system. Without that, the whole exercise is meaningless.

ALL the current ports and utilities already have TEXTUREx/PNAMES decoders. This decoding is pretty trivial since the data is very explicit as binary data. So if you just tweak some fields, it's very easy to add to any program. That's probably why RH did what he did. You get automatic enforcement of rules with no chance of a "decoder" screwing up or the user getting messed up. I'd be interested for you to ask RH why he didn't use a text file - seems such a simple thing to do :)

You can use the spare bits in the TEXTUREx lump to also add new control info. Leave it to you to imagine what could be done.
I'm still in favor of a text based replacement of TEXTUREx. If you are using a WAD management tool to manipulate it it's not that bad but I'd like to see full floating point scaling factors or better, being able to specify a destination size instead of the current rough and unprecise fixed point scaling values (like HIRESTEX allows.)Precisely - that's EXACTLY what I'm proposing. Not only isn't WAD management tool that bad, TEXTUREx is way faster and foolproof, giving the user immediate visual feedback as well as size. The scaling done by RH should not to be used (however it could be). What's also possible is to use the spare "flag" byte (just 1 bit used for world offset now) and say that the X/Y size determines the destination size exactly. Scaling factors are for the birds since the user doesn't really know the final size. That also applies to sprites. At least be CONSISTENT no matter what solution is chosen.
Plus, being able to manipulate it from the outside is still a plus. If you just have to do some minor tweaks it is much faster to load a text file into an editor than to manipulate binary data.That's absolutely NOT true. It's comments like this that derail and confuse all the others. Minor tweaks are much faster directly to binary data. Again you are describing a short coming of tool familiarity, not an inherent flaw. For a text file, you have to search for the data, hope you make no typos, save the data back and hope it looks ok. For a binary chanbge, you see the feedback instantly - you can't screw up *rolleyes*

For FLATS, as I've stated, the only problem with actual doom format FLATS is that none of the ports have bothered to add code to deal with them as "patches". It can be done. Not part of what has to be done, just pointing out a case of lack of code. Personally, it's a "worthwile goal" to make it so stuff doesn't blow up because of this relatively frequent user mistake.
Correct. *smirk* I was about to say the exact same thing. Getting an understanding of other people's code can be quite time consuming.Yeah, but not doing so is arguing from a vacuum base. The port authors are somewhat notorious for being out of touch with editing regards other ports much less their own. Adding features is not the same as actually using those features.

So if everyone is too consumed to bother, fine, but how "not knowing" something as a basis to design something and argue from is not very convincing. As I told Fred a long time ago, you can talk about sex all you want, but if you've never had sex ....

My perspective has always had to be way broader than any single port author - I hope that's clear. Hence, I've run across way more oddities in how quick and dirty solutions were done in an ad hoc fashion really because no utilities were available. In those cases, a text solution solves the problem, but played hell with their ports acceptance in the sense of modification.

Think about it, in the general sense, ZDOOM is popular because more features require little to no knowledge about the basics. Sure people code scripts and decorate, but those are really a minority. What gets NEWCOMERS into this is that they can do all these fantastic things directly from an editor. So that goes back to my original POV - ease of use and learning. New users should be right at the top of the goalsl since without them DOOM editing will shrink to nothing.
- it has to be compatible with all existing implementations. And believe it or not - ZDoom's texture management is probably the biggest obstacle in here.
- under no circumstances should it create interdependencies between different texture types. I still think that having TEXTUREx scaling affecting textures in other name spaces is a very bad idea.
ZDoom's texture system is NOT a problem. The scaling TEXTUREx affects is only for those entities that are already considered a texture. Same as the text file approach since it has to address the exact same set of data.

I think the problem is code familiarity. The main name space priority scheme is good (even overkill re PNAMES and SPRITES) just cumbersome. What needs to be done is what I explained to Smeit. Add an additional layer that organizes the data. The other thing I do is to identify each and every lump as to type. That helps a LOT further on down the road in the code. And NO, that doesn't take very much time [I tested/timed this]. This was well worth it since the code simplification that results since you now know the lump types ahead of time.
Except for the TEXTUREx issue I agree with that.But you really haven't given a valid counters, esp not regarding the list I made. What is faster and foolproof about the text system vs TEXTUREx? It's not on both counts.
Your whole set of suggestions essentially means 'leave it as it is', right? I'm having no problem with that. For 90% of the stuff that works fine.Not exactly. It's not leave it as it is since it doesn't default scale like it should right now. That either means it's not being understood or? If you read what I said, you'll see that there are a few minor mods required. You can have the new namespace if that makes it better for you. It works 99.99% of the time. Remember, I've already played around with this. In fact, in R3Dedit, you can toggle between ZDOOM method of scaling for TX (always 1-1) and JDOOM's (resize scale to existing name if found - don't know why DJ said what he did - vars are not the same as basic behavior). This makes it very useful for the hires-color texture packs. All I have do do was load them into a single PWAD(s), surround them by TX markers (can be H_ markers) and it all worked out of the box with NO FURTHER information required.

For replacement textures, nothing can beat what I just described. In fact, you can do partial replacements and add them as time goes by. NOTHING else has to be done as you add new replacments. Instant feedback, works with existing tools or existing tools only need minor changes for the new defaults I'm describing.
If you are dealing with a standard set of resources there really is no necessity to add more complicated solutions. As soon as true color graphics in the standard namespaces are supported that should be enough to handle everything - except optional hires texture replacements. "standard set" is too vague. To me it's all the same and it's all handled. I've never made any distinction here. In fact, the data doesn't even have to be PNG, but instead can be regular DOOM patch format. I hope everyone understands that those are also legit in the TX and H_ name spaces *alienate*

For me the best solution is a separate WAD namespace (TX_ is out because it already has a defined set of properties I am unwilling to alter so for me it's HI_START/HI_END.)It's interesting that you presume that's a problem. Please show me a PWAD where what I describe it's a problem. Let's assume you find one. Is that really a logical reason to object? There are many things already that you are finding out you can't do for whatever reason. Your answer there has been "I won't/can't do that" or "hey it's an isolated case, so no biggie". So the answer to the few you find is the same - PWAD needs to be modified. But go ahead and make a new space - this is just an objective observation.
The HIRESTEX lump I added was more or less a concession to the people demanding it but I wouldn't have much problems to deprecate it later once a good common solution has been worked out. The one thing it is good at though is that it allows more precise scaling than TEXTUREx as the scaling is expressed as a destination size, not a low-precision scaling factor.
Well they demanded the same from RH at the very start :) Don't you wonder why he didn't do it? Anyway, precise scaling is EXACTLY what I'm describing - so this tells me again you are not following my concept. Happens a lot when people read something that's close to something else, but actually quite different. Yes, destination size is required and that is the actual size set in TEXTUREx. "Inheritance" is actually a part of the original DOOM design if you think about it.

[Graf_Zahl]

Well, that's a little too much text to comment paragraph by paragraph. So I'll make it short.

1. Using a flag in TEXTUREx to specify the scaling method would eliminate one of the issues I currently have with TEXTUREx. But not the other, i.e. the separation in a TEXTURE and a PNAMES lump. And it's not particularly extendable, like Smite-Meister's suggestion of inheritance and use of shaders or other hardware rendering effects.

2. If you mix scaling info in TEXTUREx and TX_ you are mixing unrelated resources that most likely come from unrelated WADs. In other words: WAD#1 influences how WAD#2's textures are scaled. I'm sorry but I don't call that intuitive. This is not about actual WAD conflicts. It's just a needless cause for potential errors. Plus, it wouldn't serve any purpose. You could as well put the newly defined scaled texture into a TEXTUREx lump. Then you get well defined behavior that does not depend on WAD interdependencies.


3. For the beginner it might not be interesting to be able to edit a texture definition lump as plain text. But for more experienced users it might well be. I know for sure that I can work faster with such options.

4. Why should a tool that edits a binary file and a tool that edits a text file be different? Let's just say we go the text file approach. There's nothing that would prevent a WAD editor from using it the same way as the current TEXTUREx lumps so for the 'normal' user there wouldn't be any difference. But it sure would give the port authors better options to add new features.

[DaniJ]

can toggle between ZDOOM method of scaling for TX (always 1-1) and JDOOM's (resize scale to existing name if found - don't know why DJ said what he did - vars are not the same as basic behavior).The reason being - users don't want to have to manually toggle a command-line option ie (-pwadtex). Doomsdays default behaviour is that it DOESNT use ANY hires textures if any loaded PWAD contains at least ONE replaced texture. Usage of this option tells Doomsday to disregard the existance of replaced textures in the PWAD and use the hires versions instead. I'm not knocking the availability of the option but doesn't it seem silly to disable ALL the hires replacements just because a PWAD contains one modified flat?.

I must agree with Graf on his fourth point. It makes no difference to the user as an editor can just save in a readable text format instead of binary. Obviously its just as extendable in a binary format (a named, png-chunk-like format could be used to prevent being tied to a fixed structure) but not nearly as flexible as plain text.

Why would the other ports need to adopt Zdooms texture system?

[Ajapted]

Aside from the deceptive notion that since a text file is easy to edit, then it's easy to use, the real truth is that text stuff is difficult and more awkward for the user than what I'm talking about. The user has to learn the syntax, can make mistakes, etc.
You've misunderstood. It's not text format because we want users to edit it themselves, but because it is more extensible. Assuming it becomes a cross-port standard, I expect (hope) that editing tools will support it natively like they support TEXTUREx.

For FLATS, as I've stated, the only problem with actual doom format FLATS is that none of the ports have bothered to add code to deal with them as "patches". It can be done.
It can't be done 100% reliably, a patch that is exactly 4096 bytes will fool it, but fortunately that should be pretty rare. BTW do you check larger sizes too (8192, higher powers of two)?

[Graf_Zahl]

Why would the other ports need to adopt Zdooms texture system?


They don't. There are some issues with the system that aren't really what I'd call robust. For example, its handling of miscellaneous graphics (like menu screens etc.) is far from perfect and might interfere with other data in extreme cases.

When someone is talking about ZDoom's system it doesn't mean its implementation details but more likely the effects:

- No more separation between different texture types. Flats can be used on walls and vice versa.
- The TX_ namespace
- Patches can be used directly as textures if they have a name that doesn't conflict with something else.
- Sprites can be used as wall textures (admittedly the worst idea of it.)

[Graf_Zahl]

It can't be done 100% reliably, a patch that is exactly 4096 bytes will fool it, but fortunately that should be pretty rare. BTW do you check larger sizes too (8192, higher powers of two)?


And let's not forget Heretic's scrolling flats which are 64x65 pixels. Although you can check a lump for validity as a patch (which 99.99% of all flats will fail) it's still not 100% foolproof even though I haven't found a single flat yet that would have passed as a patch.

[Ajapted]

What do you guys think about having a new forum for discussing cross-port compatibility? Newdoom seems like a good place, and if we ask nicely....:) The forum could be called:

Source Ports -> Cross-Port Compatibility

and each thread would discuss a particular issue (MAPINFO, hires texture, etc) -- ideally anyway ;)

[smite-meister]

What do you guys think about having a new forum for discussing cross-port compatibility? Newdoom seems like a good place, and if we ask nicely....:) The forum could be called:

Source Ports -> Cross-Port Compatibility

and each thread would discuss a particular issue (MAPINFO, hires texture, etc) -- ideally anyway ;)
I'm all for it. After all, there are people who don't read the Legacy development subforum daily *smirk*
For the name, I think "Joint Doom Standards discussion" would gather more audience.

To make the discussion more concrete, I think someone of us should compile a list of
required features and issues to keep in mind for the new texture lump, and later on expand it into
a first draft (I'm currently doing this for the new MAPINFO).
Admittedly the texture lump stuff will be more involved, though ;)

[deepteam]

Man you guys really presume too much. To think I don't pick up on "extensible" is like telling me I don't know how to code :) Extensible is a topic all by itself and really has nothing to do with scaling. IOW, that's NOT the point I'm making. A text file is much HARDER to use. But fine, use it for extensible stuff - think that's the 4th time or so I've said that - so clearly you are not reading what I'm writing *winky*

If you don't read (or understand?) what I write, it's an endless loop. NO single example is a valid nor logical argument. No matter what you devise, duplicated resources (including the text stuff) will cause problems - period. So please don't use that non sequitur example. And I've not yet seen a SINGLE example to back up the claims made about incompatiblity with ZDOOM.

Avoiding my questions is not the same as discounting them. PWAD interdepencies are a legitimate design element. If the user screws it up - too bad. They can do this in all cases. In fact, the ease of adding a hires PWAD is the appeal of what I'm describing. You can add this new hires PWAD to ANY pwad and it automagically makes it "hires". The order of PWAD loading determines precedence, just like it does now. Meaning that custom graphics remain custom. If the user loads it backwards, well too bad, that happens in all cases and is not a design issue but a user issue.

No matter how many times someone claims that a text file is easier, the truth is that it's NOT. Let's time this : make a text file of the existing hires-color graphics and I'll convert it my way. Takes me about 1 minute - depending on how fast I can select it in the open dialog. THAT's the difference. Why should the utility authors duplicate what is allready an effective system well understood by all? I can spend the same time and make a much better and even easier system using what I'm describing.

If you look carefully at JDOOM, what I said is true - and I think I understand since I modified it. The cvar stuff (or any other "option") for controlling textures is missing the inherent graphic design of JDOOM. Trees and forests :) I just leveraged what was there by reorganizing the methodology. In fact, it can still duplicate JDOOM behavior completely. JDOOM clearly has operational issues as you noted, but that's a different topic and has nothing do with the original intent.

And indeed you can 99.99% figure out FLATS as it relates to usage in a level. Only 99.99 since it's possible (due to user error and the fact that name duplication is allowed) to grab the wrong one. However it will NEVER blow up. I really like how it's decided that it can't be done, when in fact I've done it *evilol*

Essentially, stuff become a "FLAT" when it has exhausted all other possibilities. The key is organization and smart lump checking. That includes context. Flat size is NOT the key here - but yes I detect any flat up to 2048 and it's highly unlikely that I'll flag it as a "patch" - I'll say 100% unlikely since my check is pretty foolproof :) It's preconceived thinking like that that has kept everything in such an unstable state when the wrong resource is used by a user.

And indeed the ZDOOM basic system has to be adopted [and ZDOOM itself has to adopt whatever mod is decided - that will be interesting:)]. To not do so is a complete contradiction to the term "cross port compatibility". There's nothing wrong with doing this. In fact to argue that you don't have to conform to ZDOOM's existing system is again not logical in the context of this thread. [see last part below since I see that this is being totally misunderstood too)

The key is also what 99% of the users will want to do (not what is technically "cool"). What users want to do is just use hires-color images rescaled to whatever. What you are talking about is the 1%. IOW it's a poor return for the time spent - but as I'll say again, the extensible part can provide that in the text form, but not for the raw work horse.

Indeed I'm amazed at any argument that attempts to convince that TEXTUREx does not belong in this solution. It's the logical anchor point for ALL DOOM editing. I can explain my system (as I've done) easily in a few sentences. Now look at what it takes for this text thing? KISS [As an aside, proof of the failure of "extensible" text files is easily demonstrated by a few ports. They took features everyone needs to use and made them "extensible". Now how many actually used it? How many users like it? If nothing else, GZDOOM user comments are demonstrating this in spades. And indeed, is an indirect rebuttal of other (text) ways of doing things. Nice job Graf.

But instead of offering me valid counters, I see a predisposition to a complicate solution vs a simple solution with arguments I've clearly refuted.

In conclusion - it's this simple (repeats of basic elements that appear to be totally misunderstood):

1. Scaling and extensibility are TWO different topics. It's clearly being confounded by these "extensible" features. Easy user friendly scaling that needs very little explaination is the key.

2. I NEVER said not to have a text file - just not for the basic scaling feature. Extend it all you want in it's appropriate place. IOW, there's NOTHING in my discussion that limits any port author to whatever they want to add.

3. Yes you need to adopt the basic ZDOOM way of handling textures in all cases. The "effects" as noted for "textures" as they are used in floors/ceilings/wall. The only addition that has to be added is an extra layer and revised lookups since ZDOOM is a bit weak in those areas.

Or is this "cross port" thing just an oxymoron *wave*

[Ajapted]

Here is a draft spec which hopefully summarises the existing systems (except JDoom's external packs). The H_START namespace covers what Jack is on about -- ability to easily add hires resources. Quite a few questions remain to discuss.


JDS Texture Standard (draft)


Namespaces

- TEXTUREx: composes textures out of patches. Some scaling ability (using a ZDoom extension).

- PNAMES: names of patch lumps for the above.

- P_START: patch lumps themselves. [1][2]

- F_START: flat lumps. Normally raw 64x64 bytes. Heretic allows 64x65, Hexen has some 64x128 (scrolling floors). Other powers of two allowed (128x128 upto 2048x2048) but occupy 64x64 world units [3]. PNG or JPEG will always be 64x64 world units. Could also be patch format, but must be the correct size for a flat.

- S_START: sprite lumps. Patch format or PNG format. Normally 1:1 scaling, but changeable in thing definition (Dehack, DDF, DECORATE, etc). Offsets for PNG inside PNG itself (use special tool to modify). [4]

- TX_START: patch format or PNG [5] format images. Always unscaled (1:1).

- H_START: hires versions for existing textures/flats [6]. Scaled to match the texture of the same name (in TEXTUREx or F_START namespaces). Requires an existing texture, if none, then the hires version will be ignored. [7]

- NTEXTURE: new whiz-bang text format. Actual name and features not yet decided.


Lookup order:

Wall textures: NTEXTURE, H_START, TX_START, TEXTUREx, PNAMES, F_START. [8]

Flats: NTEXTURE, H_START, TX_START, F_START, TEXTUREx, PNAMES.

Sprites: NTEXTURE ?, H_START ?, S_START, P_START.

Graphics: NTEXTURE ?, H_START ?, rest of wad, P_START, S_START.


NOTES

[1] P_START and PNAMES could be considered a single namespace.
Some ports use P_START as the first place to look for a patch lump
(looking elsewher if not there).
[2] do we allow PNG in the P_START namespace?
[3] or do 128x128 flats (etc) stay unscaled (1:1 world units)?
[4] this is not ideal. Another solution may be possible later.
[5] allow JPEG in TX_START too?
[6] allow sprites in H_START too?
[7] i.e. H_START cannot be used for _new_ textures (without adding one in the old format).
[8] ZDoom also checks S_START, but this not recommended.

[Graf_Zahl]

That's looking good. A few further notes:

1. P_START/P_END should not be used for anything. Since Doom didn't use them they are not guaranteed to be there so requiring them for finding patches might create problems. The PNAMES lump or its NTEXTURE equivalent should be enough to load them.
2. Sprites should be taken from H_START and S_START exclusively and if you really want to be able to define them in NTEXTURE they have to be explicitly marked as such because otherwise it could become quite chaotic. Hires replacement sprites should be allowed but use the offsets from the original unless we allow something like ZDoom's PNG offset option to override it.
3. Regarding JPEGS, I'd make it an option. I am using DevIL to load hires graphics which makes supporting them a non-issue but for other ports that might be different.

[smite-meister]

- F_START: flat lumps. Normally raw 64x64 bytes. Heretic allows 64x65, Hexen has some 64x128 (scrolling floors). Other powers of two allowed (128x128 upto 2048x2048) but occupy 64x64 world units [3]. PNG or JPEG will always be 64x64 world units. Could also be patch format, but must be the correct size for a flat.

You should not allow anything but raw paletted flat-type data lumps here, because flats cannot be
reliably identified from other possible formats. What are the existing scaling conventions, i.e.
is it scale = 1 or targetworldwidth/height = 64?


Lookup order:

Wall textures: NTEXTURE, H_START, TX_START, TEXTUREx, PNAMES, F_START. [8]
Flats: NTEXTURE, H_START, TX_START, F_START, TEXTUREx, PNAMES.
Sprites: NTEXTURE ?, H_START ?, S_START, P_START.
Graphics: NTEXTURE ?, H_START ?, rest of wad, P_START, S_START.

I think this could be simplified. This is what I use currently:

Containers (populated during startup):
C1 = NTEXTURE, H_START, TX_START
C2 = TEXTUREx
C3 = F_START

Lookup order:
Walls: C1, C2, C3
Floor/ceiling (flats): C1, C3, C2
Sprite frames: C1, C2?, S_START (the logic here is a bit different, since all the frames of a given sprite are loaded at once using S_START info)
other graphics (menu patches, raw pages...): C1, C2, C3

If x is not found, we search the wad for a lump named x. If it has no clear magic number
or size equal to a raw page (320*200), we assume it is a patch_t.
It is then inserted into C2.

I have not yet found any conflicts with this system. Possible weak points:
- Do we have raw page images whose names conflict with TEXTUREx stuff?
- Ditto for menu patches and TEXTUREx?


[4] this is not ideal. Another solution may be possible later.
[5] allow JPEG in TX_START too?

[4]: I'd prefer to define hires sprites in NTEXTURE along with their offsets.
[5]: Why not, JPEG has a decent magic number.

[Graf_Zahl]

How about:

- adding C4 (patches used in PNAMES) It has lowest priority for walls and flats but can be used as well. Zdoom allows it and there are some WADs already which use this method (I think Void.wad was the first one) Having all patches as their own texture object would also make the system a little more efficient because multipatch textures don't need to reference the patches as raw data, they could use the texture objects themselves which would serve as an additional level of abstraction (but that's not required although I have implemented it this way.)

- sprite frames should not get anything from outside S_START/S_END (or a H_START/H_END replacement) unless it is specifically allowed. If you require a S_START/S_END lookup it doesn't make sense anyway.
-other graphics should default to C4 first but then all the known graphics had to be preloaded to avoid conflicts. ZDoom is doing that but is using a different category but I don't think that separation is really necessary.

[Ajapted]

You should not allow anything but raw paletted flat-type data lumps here, because flats cannot be reliably identified from other possible formats.
PNG and JPEG have "magic bytes" you can check for. The odds of a false positive are so low that is reliable in practice.

Patches are harder. By doing strict validity checks on the header info (width, height, etc) and that all the offsets are in a valid range, I think it would rarely produce a false positive. Personally I'd keep patch format out of the F_START area.

I think this could be simplified. This is what I use currently:

Containers (populated during startup):
C1 = NTEXTURE, H_START, TX_START
C2 = TEXTUREx
C3 = F_START

Well the NTEXTURE, H_START and TX_START namespaces have different characteristics. Keeping them separate in the spec makes it clearer I think. The namespaces in the spec don't have to correspond to containers in the implementation.

adding C4 (patches used in PNAMES) It has lowest priority for walls and flats but can be used as well
The spec already has PNAMES in the lookups for wall and floor textures.

Regarding sprites in H_START: this mostly makes sense to me, but scaling will be "wonky" if every frame is scaled to it's matching frame. Choosing a single scale value across the whole sprite (all frames) would be more reliable, but how to do it? (Average height of all frames?)

[Graf_Zahl]

Regarding sprites in H_START: this mostly makes sense to me, but scaling will be "wonky" if every frame is scaled to it's matching frame. Choosing a single scale value across the whole sprite (all frames) would be more reliable, but how to do it? (Average height of all frames?)


Well, I'd rather skip it because it's too error-prone anyway. Those who want hires are less likely to bother with hires sprite replacements and rather opt for models anyway.

[smite-meister]

How about:
- adding C4 (patches used in PNAMES)

Are the menu patches also listed in PNAMES? If not, you will still need some load-on-demand
mechanism for textures that are not found during normal C1,C2,C3 lookup.


- sprite frames should not get anything from outside S_START/S_END (or a H_START/H_END replacement) unless it is specifically allowed. If you require a S_START/S_END lookup it doesn't make sense anyway.

My current system works like this:

First the engine decides that it wants a sprite named PLAY.
If not already in sprite cache, a sprite object is built by searching all S_START namespaces
for lumps beginning with PLAY, and interpreting the animation/direction info.
Each individual sprite frame (for example PLAYA1) is then queried from the texture cache
and attached to the sprite object, using the order C1, C2, WAD search.
The WAD search normally will return the very PLAYA1 lump inside S_START which prompted
the search in the first place, which will be interpreted as patch_t and inserted into C2.

Do you see a problem with this system?

[smite-meister]

PNG and JPEG have "magic bytes" you can check for. The odds of a false positive are so low that is reliable in practice.

True, but why should you allow PNG and JPEG (or, heaven forbid, patch_t) inside F_START?
Even if some port already does this, there is no reason to include this in the "standard".
The preferred (and only :)) standardized way to do PNG/JPEG floor textures should be NTEXTURE.

[Graf_Zahl]

I can understand why PNGs shouldn't be allowed between F_START/F_END. But apart from that any supported graphics format should be freely usable wherever a graphic lump is loaded.

[Ajapted]

True, but why should you allow PNG and JPEG (or, heaven forbid, patch_t) inside F_START? Even if some port already does this, there is no reason to include this in the "standard".

If ports are allowing PNG for in S_START, then allowing them in F_START seems natural to me. But yeah, it doesn't have to be in the spec.

The preferred (and only :)) standardized way to do PNG/JPEG floor textures should be NTEXTURE.
Disagree here. I'd say allow H_START for hires replacements. And probably TX_START too.

[Graf_Zahl]

My current system works like this:

First the engine decides that it wants a sprite named PLAY.
If not already in sprite cache, a sprite object is built by searching all S_START namespaces
for lumps beginning with PLAY, and interpreting the animation/direction info.
Each individual sprite frame (for example PLAYA1) is then queried from the texture cache
and attached to the sprite object, using the order C1, C2, WAD search.
The WAD search normally will return the very PLAYA1 lump inside S_START which prompted
the search in the first place, which will be interpreted as patch_t and inserted into C2.

Do you see a problem with this system?

I think it'd be better to do it the way ZDoom is doing because it allows more flexibility with future extensions:

1. All lumps between S_START/S_END are loaded into the texture manager as type sprite
2. When a sprite animation is built the engine looks up all the textures of type sprite with matching names and not the lumps directly.

That way you are free to define your sprites by other means without the need of inserting a dummy lump between these markers - and you don't have interference with other texture types - which might be critical for sprites more than for anything else.

It would even make hires replacements easier to handle because all the sprite textures are there from the start so the replacement is easier to handle.

[smite-meister]

If ports are allowing PNG for in S_START, then allowing them in F_START seems natural to me. But yeah, it doesn't have to be in the spec.

Is some port allowing PNG in S_START?


Disagree here. I'd say allow H_START for hires replacements. And probably TX_START too.
Oh, I would certainly allow them for compatibility too, just not recommend them.
If we have a working NTEXTURE, there should be no reason to use TX_START or H_START anymore.


Well the NTEXTURE, H_START and TX_START namespaces have different characteristics. Keeping them separate in the spec makes it clearer I think. The namespaces in the spec don't have to correspond to containers in the implementation.

Sure, but in my proposal each container is also a single namespace. The idea was that
when C1 is populated, H_START overrides TX_START and NTEXTURE overrides them both.

[smite-meister]

1. All lumps between S_START/S_END are loaded into the texture manager as type sprite
2. When a sprite animation is built the engine looks up all the textures of type sprite with matching names and not the lumps directly.

That way you are free to define your sprites by other means without the need of inserting a dummy lump between these markers - and you don't have interference with other texture types - which might be critical for sprites more than for anything else.

It would even make hires replacements easier to handle because all the sprite textures are there from the start so the replacement is easier to handle.
In my system, it's not really important where you define the contents of a sprite.

The main difference between these is that the ZDoom system only looks for the sprite frames
in the pre-populated S_START container (so to speak), whereas my system first checks C1, then C2,
and finally tries loading the lump as patch_t and storing the result in C2.

If you think there will be conflicts between TEXTUREx names and S_START names, one could
incorporate the ZDoom logic by adding a new container CS = S_START and changing the
spriteframe lookup order to C1, CS.

[Graf_Zahl]

If you think there will be conflicts between TEXTUREx names and S_START names, one could
incorporate the ZDoom logic by adding a new container CS = S_START and changing the
spriteframe lookup order to C1, CS.


That's one issue I have with it. But it's more that I'd like to avoid the dummy lumps. If all sprites are pre-inserted into the texture manager you can easily define new ones with any new method and explicitly set their type.

Because if you define a new sprite with such a system it'd be enough to define it like a texture, just with a different keyword ('sprite' as opposed to 'texture') and since sprites automatically get their own texture type they don't get in the way of anything else or vice versa.

[Graf_Zahl]

Is some port allowing PNG in S_START?


ZDoom does. It allows any supported graphics format anywhere a graphics lump is loaded - except flats.


Oh, I would certainly allow them for compatibility too, just not recommend them.
If we have a working NTEXTURE, there should be no reason to use TX_START or H_START anymore.


People will always use the most convenient means to do stuff. If it just means to dump a larger number of PNGs between TX_START/TX_END without explicitly defining a texture object for each one of them, let them.


Anyway, how about this (based on AJApted's draft and my (positive and negative) expreriences with ZDoom's texture management:


Namespaces

N0: raw graphics: Tricky to determine because there isn't much to recognize them. Two options:
1) Preinitialize all known graphics at startup and first use (ZDoom's method, probably not the best)
2) Each time a raw graphic is needed the texure manager is checked for the presence of a correctly named texture and if it fails looks up the lump and dynamically adds it to this namespace.

N1: TEXTUREx: composes textures out of patches. Some scaling ability (using a ZDoom extension).

N2: PNAMES: names of patch lumps for the above.

(- P_START: patch lumps themselves. [1][2] This one should be avoided because it is not guaranteed to be defined properly)

N3: F_START: flat lumps. Normally raw 64x64 bytes. Supported sizes are squares of powers of 2 only - no special graphics formats. If the size is <= 64x64 it is used unscaled, otherwise automatically scaled to 64x64. Incorrectly sized graphics are automatically truncated to the next smallest square of a power of 2. This should take care of irregularly shaped flats from Heretic and Hexen automatically.
Questions: Allow easily recognizable formats or not? How to handle scaling and resizing for them?

N4: S_START: sprite lumps. Patch format or PNG format. Normally 1:1 scaling, but changeable in thing definition (Dehack, DDF, DECORATE, etc). Offsets for PNG inside PNG itself (use special tool to modify). [4]

N5: TX_START: patch format or PNG [5] format images. Always unscaled (1:1).

(not a separate namespace) H_START: hires versions for existing textures/flats [6]. Scaled to match the texture of the same name (in TEXTUREx or F_START namespaces). Requires an existing texture, if none, then the hires version will be ignored. [7]
These textures will not create a new namespace. Instead they reassign the graphics used by the texture they replace and completely take over the existing texture object.

N6: NTEXTURE: new whiz-bang text format. Actual name and features not yet decided. Allow definition of special type 'sprite' in here. Those textures will be added to the same namespace as S_START/S_END


Wall textures: NTEXTURE, TX_START, TEXTUREx, PNAMES, F_START, S_START. [8]

Flats: NTEXTURE, TX_START, F_START, TEXTUREx, PNAMES (, S_START - which only makes sense for transparent 3D-floors though.)

Sprites: S_START (with this setup there's no need to look for other types.)

Graphics: Raw graphics, NTEXTURE, (TEXTUREx, F_START), P_START, S_START, if all fails look for the lump and add it.

Just for comparison, this is how ZDoom is doing it at the moment:

Wall textures: TX_START, TEXTUREx, dynamically added raw patches, F_START, PNAMES, statically added raw patches, S_START

Flats: TX_START, F_START, dynamically added raw patches, (TEXTUREx/PNAMES, whichever defines the name last), statically added raw patches, S_START

Sprites: S_START

Raw graphics: Almost no interaction with other types, it might create a duplicate texture object if it requires a sprite to be used as such (e.g. for key icons etc.)

[smite-meister]

But it's more that I'd like to avoid the dummy lumps. If all sprites are pre-inserted into the texture manager you can easily define new ones with any new method and explicitly set their type.

Because if you define a new sprite with such a system it'd be enough to define it like a texture, just with a different keyword ('sprite' as opposed to 'texture') and since sprites automatically get their own texture type they don't get in the way of anything else or vice versa.

The drawback would be that this would split NTEXTURE into two namespaces (sprite-textures and normal textures),
which I think should be avoided.
The only case I can think of where this would be needed would be creating a full texture and sprite replacement pack using NTEXTURE, assuming you have namespace overlaps between
(TEXTUREx, F_START) and S_START, but this was deemed not an important issue in the STEPx case too.

The dummy lumps would be required only if you
1) change the name of an existing sprite, or
2) introduce a totally new sprite (e.g. in DECORATE)
In either case, I'd prefer not to define the new sprite object (animation, rotations) in NTEXTURE,
but rather somewhere else, since it is not a texture in itself.

[Graf_Zahl]

I don't like the interdependencies your method creates. Essentially it's the same reason why I don't like Deep's suggestion to let TEXTUREx scaling affect TX_ textures.

What's the problem with putting NTEXTURE content into 2 namespaces if they clearly represent different data as in this case? Sprites are one of the trickiest things in the Doom engine and as such far too sensitive to any potential naming conflicts.

[smite-meister]

I don't like the interdependencies your method creates. Essentially it's the same reason why I don't like Deep's suggestion to let TEXTUREx scaling affect TX_ textures.

What's the problem with putting NTEXTURE content into 2 namespaces if they clearly represent different data as in this case? Sprites are one of the trickiest things in the Doom engine and as such far too sensitive to any potential naming conflicts.
I understand your concern about the name conflicts, but you can always avoid them by
renaming the entire sprite (i.e. PLAY -> X_%2).
However, textures and sprite-textures are not really different kinds of data, they're both textures.
The actual sprite object is clearly a different thing, it merely uses (several) textures, just
like a 3D model uses skin textures.

Ideally, we would have NTEXTURE for defining textures and another lump for defining sprites,
referencing the texture definition lump:
sprite PLAY
{
frame[0].rot[0] = "PLAYA1";
frame[0].rot[1] = "MY_TEX5"; // etc.
// and no, I'm not suggesting we create a lump like this :)
}
Currently, this function is performed by the special naming convention of the S_START lumps.
The interdependency is no different from the interdependency between NTEXTURE and the
SIDEDEFS lumps.

If you wanted to create a completely new sprite XXXX, defining the spriteframes in NTEXTURE, how would you do it?

[Ajapted]

However, textures and sprite-textures are not really different kinds of data, they're both textures.
They are different because their names have special meaning to the engine. So I agree with Graf here, they shouldn't be mixed with other image types. Having NTEXTURE be two namespaces (or having a separate NSPRITE) seems reasonable to me.

P.S. Smite, you're posts would look nicer if you didn't press return after each sentence.

Other thoughts:

The term "namespace" has got a little muddled (in-wad vs in-engine). H_START is a valid WAD namespace, but as Graf points out you don't need an extra container for it. I'll try and make the spec clearer about this.

Regarding PNG/JPEG: I'm now prefering the idea that they can be used anywhere. They are all just image formats (bunch of pixels). Of course this will mean a huge amount of work to fully realise, but a spec can specify an ideal behavior -- doesn't mean everything has to be implemented straight away.

[Graf_Zahl]

Regarding PNG/JPEG: I'm now prefering the idea that they can be used anywhere. They are all just image formats (bunch of pixels). Of course this will mean a huge amount of work to fully realise,


Not really. When creating a texture object you have to analyze the lump format anyway and then you can create one that matches the data - or you can defer it until the texture is being used and just load the graphic into a buffer.

[Ajapted]

I was thinking of TEXTUREx composition, a bit harder if the patch lumps can be any format. I guess ZDoom is setup fairly well to handle any format anywhere, other ports are going to need quite a lot of code reworked.

[Graf_Zahl]

I really don't see the problem. To handle textures uniformly throughout the game they have to be converted into some suitable format in any case because raw flats are practically unsuitable to render walls (as are PNGs) in software mode. You have to write some conversion code for PNGs and flats to render them as walls so what's keeping you to compose your multipatch textures the same way and then use the routines you need to have for the other formats to handle them as well? With hardware rendering it's even simpler.

This is all the code I use in GZDoom to do specific handling of multipatch textures to create the texture data:


void FMultiPatchTexture::CopyTrueColorPixels(BYTE * buffer, int buf_width, int buf_height, int x, int y,
int cm, int translation)
{
for(int i=0;i<NumParts;i++)
{
Parts[i].Texture->GetWidth();
Parts[i].Texture->CopyTrueColorPixels(buffer, buf_width, buf_height,
x+Parts[i].OriginX, y+Parts[i].OriginY, cm, translation);
}
}

[DaniJ]

Crap, lots to catch up on I see... I don't have time atm but I'll try to in a day or so and post my comments then. Plus I need to (re)familiarize myelf with Doomsday's texture manager *spin*

[Ajapted]

I've updated the spec based on recent discussion. Rather than clog up space in this forum, you can view it here:

http://glbsp.sourceforge.net/JointTextureSpec.txt

Please read through it carefully and note any problems or things you disagree with. Some things in there are only tentative, such as:

- Flats in F_START being unscaled, e.g. a 128x128 flat will occupy 128 units on the map. Rationale: This is consistent with what happens when a flat lookup uses a texture (TX_START or TEXTUREx) via the fallback method.

- No sprites in H_START. I don't think it makes much sense unless all images were exactly the same sizes, which is not useful. The suggested NSPRITES is a better method.

- No graphics in H_START. I wasn't sure about this. Like sprites, many graphics have odd sizes that you wouldn't want to scale to. For ones like TITLEPIC, you don't need H_START because the engine can just scale it to fit the whole screen.

- Whether to allow raw lump as a lookup location for unknown sprites, and unknown patches in TEXTUREx composition. Some existing ports do this, but it doesn't have to be in the spec (i.e. consider those ports as going beyond the standard).

- No sprites for texture lookups. ZDoom does this, but it doesn't seem worthwhile to put into the spec (again, just consider ZDoom as going beyond the standard).

[Graf_Zahl]

The only issue remains the handling of large flats.

Do any ports aside from ZDoom already support large flats and how do they handle them?
In general I am in favor of your spec but there are already maps using the automatic scaling (nothing critical though.) so if we make this the standard, is that acceptable? (IMO yes.)

P_START/P_END should not be used at all though. These lumps don't have any meaning for any port in existence and we shouldn't start now.

[Ajapted]

EDGE has supported large flats (128..1024) since V1.26, released Oct 2001. They are always unscaled. It's not a feature I've actually seen anyone use though, and it didn't influence my decision about the spec, which is based on the observation that everything else in a WAD (textures, sprites) is normally unscaled, so forcing flats to be 64x64 is rather inconsistent.

In general I am in favor of your spec but there are already maps using the automatic scaling (nothing critical though.) so if we make this the standard, is that acceptable? (IMO yes.)
Yes from me too. It's probably inevitable that something will break, we're really having this discussion a year or three too late, and the ports have made their own systems. Standards don't usually please everybody, but it's better to have one that is "mostly" followed than none at all.

[smite-meister]

I've updated the spec based on recent discussion.

Looks quite good. Here are my comments:

F_START scaling: I think it it should be 1:1 by default (analogous with TX_START), and I think this is how Legacy already does it. Dunno if many Legacy wads use it.

Suggested H_START handling seems fine to me.

I agree with Graf that all references to P_START should be removed. Besides, the HUD and menu patches in the IWADs are not included in that group for some strange reason.

Generally I think you should use the word sprite-texture instead of sprite, to make things clearer.

On lookup orders:
I assume that by "raw lump" you mean a full WAD search using the texture name as the lumpname, assuming that the recovered lump
1) has a clear magic number (PNG, JPEG, ...), or else
2) has size 320*200, which makes it a raw page, or else
3) is a patch_t
If this is correct, you should add this definition to the draft.

- Why do you include "raw lump" for sprites (all sprite-textures should be in SPRITES) ?

- TEXTUREx composition: I think the order should be (NEW_TEX, maybe), PNAMES patches. (although probably S_START patches would not actually hurt), no "raw lumps".

- In fact, the only place where you really need "raw lump" search is Graphics.
The question is, after finding out the format of these lumps (loading them on demand), can you safely add them to one of the defined containers, or do we have known namespace overlaps between them and, say, TEXTURES ?
If not, you could change the order to

Graphics: NEW_TEX -> TEXTURES -> raw lump search, inserting the found textures into TEXTURES.

[Ajapted]

F_START scaling: I think it it should be 1:1 by default (analogous with TX_START)
That was implied in the spec (by default, all images are unscaled), but I'll update the F_START part to make it clear.

I agree with Graf that all references to P_START should be removed.
OK. (I've seen a wad where a patch had the same name as a flat, but I reckon it was an isolated case).

Generally I think you should use the word sprite-texture instead of sprite, to make things clearer.
I'll use the phrase "sprite image". (I associate textures with wall textures, so "sprite-texture" sounds a bit weird to me).

On lookup orders:
I assume that by "raw lump" you mean a full WAD search using the texture name as the lumpname, assuming that the recovered lump
1) has a clear magic number (PNG, JPEG, ...), or else
2) has size 320*200, which makes it a raw page, or else
3) is a patch_t
If this is correct, you should add this definition to the draft.

OK.

- Why do you include "raw lump" for sprites (all sprite-textures should be in SPRITES) ?
I've seen some wads to do this. I think DosDoom allowed it, and EDGE inherited this from DosDoom. If most other ports don't allow it, then we can remove it from the spec (and consider this a port-specific oddity).

- TEXTUREx composition: I think the order should be (NEW_TEX, maybe), PNAMES patches. (although probably S_START patches would not actually hurt), no "raw lumps".
Disagree with NEW_TEX, I think leave TEXTUREx alone (no real benefit for the extra complication).
For S_START: I'm sure I've seen a wad doing this (with a baron sprite IIRC). Thought for a minute it was the DOOM IWAD, but just checked and couldn't find it. I've got a feeling it's fairly common.
No rawlumps: OK

- In fact, the only place where you really need "raw lump" search is Graphics.
The question is, after finding out the format of these lumps (loading them on demand), can you safely add them to one of the defined containers, or do we have known namespace overlaps between them and, say, TEXTURES ?
Good question. I'm not keen on the idea of mixing graphics and textures, due to potential name clashes. I'm thinking a GRAPHICS namespace would work best. Like you say, the lumps are loaded on demand (so we don't need to identify the format of every single lump in the wad).

The spec says to look in NEW_TEX for graphics too. I'm not 100% sure about that either, but seeing it's new stuff, a map-maker can workaround any clash (in contrast to TEXTURES, where clashes would exist in existing wads). Having an new NGRAPHIC lump (akin to NTEXTURE) is a possibility. Is it overkill though?

[Graf_Zahl]

For S_START: I'm sure I've seen a wad doing this (with a baron sprite IIRC). Thought for a minute it was the DOOM IWAD, but just checked and couldn't find it. I've got a feeling it's fairly common.


There are some WADs which use sprites in texture definitions. I can remember an old WAD that used the entire Cyberdemon explosion animation on a texture. Support for this must be a requirement. But since the name has to appear in PNAMES anyway it's only a matter of looking up the lump correctly so that it isn't missed if it is a sprite and a namespace sensitive lookup scheme (like Boom) is used.

Having an new NGRAPHIC lump (akin to NTEXTURE) is a possibility. Is it overkill though?


Yes, it is. That really would go too far. There is no need for it.

[smite-meister]

I'll use the phrase "sprite image". (I associate textures with wall textures, so "sprite-texture" sounds a bit weird to me).

Okay. Using the word texture as a synonym for "bitmap graphic" comes from OpenGL, that's where I picked up this habit.


The spec says to look in NEW_TEX for graphics too. I'm not 100% sure about that either, but seeing it's new stuff, a map-maker can workaround any clash (in contrast to TEXTURES, where clashes would exist in existing wads). Having an new NGRAPHIC lump (akin to NTEXTURE) is a possibility. Is it overkill though?
Yes, I see absolutely no need for that one. NTEXTURE will do fine.
A new uninitialized namespace/container GRAPHICS is OK by me, now we would have the lookup order

Graphics: NEW_TEX -> GRAPHICS -> raw lump search, inserting the found textures into GRAPHICS.

[Ajapted]

A new uninitialized namespace/container GRAPHICS is OK by me, now we would have the lookup order

Graphics: NEW_TEX -> GRAPHICS -> raw lump search, inserting the found textures into GRAPHICS.
Yep. The last bit could be described as a property the GRAPHICS container (keep the lookup logic easy to read).

Another small issue just came up. For TEXTUREx composition, the name of each patch is a lump name, so the idea of a "lookup" for TEXTUREx composition probably doesn't make sense. That means each patch is just a raw lump resource.

P.S. have a think about animations, and what the implications might be. Does TX_START support them? Anything special needed for NTEXTURE?

[Graf_Zahl]

P.S. have a think about animations, and what the implications might be. Does TX_START support them? Anything special needed for NTEXTURE?

They should work the same as normal animations. Of course the handling depends on the features being available. But that should not be part of the texture spec itself.

I can't say too much about this because I don't have an overview over the definition formats used by various source ports. The only ones I am familiar with are Boom's ANIMATED and SWITCHES and Hexen's ANIMDEFS.

[Ajapted]

Draft #3 of the spec is up: http://glbsp.sourceforge.net/JointTextureSpec.txt

I reckon it's time to get some more eyeballs on it :).

[smite-meister]

Draft #3 of the spec is up:
I reckon it's time to get some more eyeballs on it :).
Good. Some minor details:

- TEXTUREx: "unused fields" -> "unused, zero fields" (I actually once checked this on Doom, Heretic and Hexen IWADs)
(of course, this is why the extension works in the first place :))

- PNAMES: each TEXTUREx lump should only use the PNAMES lump in the same WAD.

- TX_START: not only wall textures but any non-sprite graphics, since these go into NEW_TEX container.

And one minor inconsistency: What happens if you have a H_START lump named STEP1, for which an original exists in both TEXTURES and FLATS?

[Graf_Zahl]

- PNAMES: each TEXTUREx lump should only use the PNAMES lump in the same WAD.


Except for the last one. To be compatible it must logically use the last PNAMES lump even if it is from another WAD. This issue caused problems when it was implemented in ZDoom. There appear to be a few WADs which have a TEXTUREx lump and not a PNAMES lump or vice versa.

[Ajapted]

TEXTUREx: "unused fields" -> "unused, zero fields" ... (of course, this is why the extension works in the first place :))
Good point.

PNAMES: each TEXTUREx lump should only use the PNAMES lump in the same WAD
That is mostly implied by the sentence "The PNAMES lump should exist in the same wad as the TEXTUREx lump." While there are wads that have a TEXTUREx without PNAMES, they are tied to the IWAD and don't work with another IWAD, so those wads are basically broken. A wad with PNAMES without TEXTUREx -- what an interesting beast *eek* *eek*.

TX_START: not only wall textures but any non-sprite graphics, since these go into NEW_TEX container.
As a wad resource, I think the intent for TX_START was mainly wall textures (Graf?). Of course the namespace rules and lookup order mean that flats and graphics will work too.

And one minor inconsistency: What happens if you have a H_START lump named STEP1, for which an original exists in both TEXTURES and FLATS?
As the gl specs often say: "the results are undefined" :)

[Graf_Zahl]

As a wad resource, I think the intent for TX_START was mainly wall textures (Graf?). Of course the namespace rules and lookup order mean that flats and graphics will work too.



This issue is only of concern if scripting is involved that draws these textures directly on the screen but not for intermission screens etc.

ZDoom only looks in raw lumps if it concerns a known graphic. For icons on the HUD it also looks in S_START/S_END and for pictures displayed on the HUD through scripts it looks everywhere.

[iori]

Something that was brought up a long time ago was the possibility of algorithmic textures for water, fire, lightning, etc. as seen in the First-Gen Unreal games, among others. Thoughts?

[MR_ROCKET]

That would be sweet for hi-res textures, wouldn't that require a sorta shader or definition script for the effect?

[Graf_Zahl]

It either requires some vertex/fragment programming or alternatively constant recreation ans uploading of the textures. This is non-critical for a small number of flats but just one 256x256 texture may kill the frame rate depending on the complexity of the algorithm being used. So software algorithms are mostly out, especially if larger textures are concerned. With fragment programs (a.k.a. pixel shaders) this could become something really interesting though.

Just an example: Warping a 256x256 texture in true color with ZDoom's algorithm showed a duration of 10 ms per frame on a 3.2 GHz P4. This is an amount that can easily bring down the frame rate by half.

[DooMAD]

Any chance of Voxel support (http://www.doomworld.com/vb/showthread.php?s=&threadid=21726) while we're standardising things? Graf clearly loves the idea, heh. *crazy*

http://www.teamhellspawn.com/evenmorevoxels.gif

[Graf_Zahl]

Voxels and hardware rendering don't mix well so don't expect any support from me (and probably neither from Ajapted and DaniJ!)

[DooMAD]

It was worth a try. :D

Shame no one ever did develop an OpenGL renderer for Voxels, they fit Doom so perfectly. I'll probably still continue with the development of converting doom sprites to voxel format, even if it is a lost cause. *ugh*

[Danimetal]

So you´re the guy who´s doing it???.

[MR_ROCKET]

If he told you, well then he would have to kill you.:P

[Ajapted]

Regarding PNAMES, how does this sound:


- PNAMES: list of patch names for TEXTUREx. The PNAMES lump should exist in the same wad as the TEXTUREx lump. If no PNAMES lump exists, the one in the IWAD is used.

For a PNAMES-only wad, I'm assuming they are so rare that there is no real benefit mentioning them in the spec.

I want to say something about the palette in the spec. Should the rule be: "there is a single palette which comes from the last wad containing a PLAYPAL lump" ? (An alternative could be to use the PLAYPAL lump in the same wad as the texture/sprite/etc).

Regarding Voxels: monsters and sphere shapes don't work well (harder to make than models I'd say), that only leaves boxy shapes like ammo (all the images in that shot were rectangular), and models are probably easier for those too. Maybe for a S/W port without models they would be nice, but they don't make sense for GL ports.

[Graf_Zahl]

I want to say something about the palette in the spec. Should the rule be: "there is a single palette which comes from the last wad containing a PLAYPAL lump" ? (An alternative could be to use the PLAYPAL lump in the same wad as the texture/sprite/etc).


Yes, it should be that. Otherwise palette replacements wouldn't work as intended (see RTC-3057 as an example)


Regarding Voxels: Maybe for a S/W port without models they would be nice, but they don't make sense for GL ports.

I've tried to tell the people demanding them countless times but they seem to be locked in software mode without a chance of getting out. *smirk*

[smite-meister]

Yes, it should be that. Otherwise palette replacements wouldn't work as intended (see RTC-3057 as an example)
The main PLAYPAL which the software renderer uses has to come from the last loaded WAD that has one, but why shouldn't the palettes of the individual paletted graphics (flats, patches, raw pages) be taken from the PLAYPAL lump which is in the same WAD as the graphic? If you are in software rendering mode, you can always quantize them to the actual PLAYPAL.

Do you mean that RTC-3057 (haven't seen it) introduces a new, different palette for the IWAD graphics, and they still all look good? *confused*

[MR_ROCKET]

http://www.nautrup.com/3057/

[DooMAD]

So you´re the guy who´s doing it???.Only partially. GhostPilot was making the most progress, but he dissapeared back in February. I should have asked him to send me a copy of his finished items, but I guess it's a bit late for that now.


Regarding Voxels: monsters and sphere shapes don't work well (harder to make than models I'd say), that only leaves boxy shapes like ammo (all the images in that shot were rectangular), and models are probably easier for those too.I began work on the red skull key, which isn't at all rectangular, but it is taking longer than I thought to finish:
http://www.teamhellspawn.com/not_a_box.gif

[Graf_Zahl]

Do you mean that RTC-3057 (haven't seen it) introduces a new, different palette for the IWAD graphics, and they still all look good? *confused*


It alters the blue range to a slightly muted blue - and all grahpics are affected by it.

On a more extreme note, you can find a WAD called 'Zen Dynamics' at the ZDoom forum which turns the blue range into cyan. These wads only work as expected if the palette remains global. This has been expected behavior for 12 years and IMO it shouldn't be changed. If you absolutely need other colors use PNGs instead.

[smite-meister]

On a more extreme note, you can find a WAD called 'Zen Dynamics' at the ZDoom forum which turns the blue range into cyan. These wads only work as expected if the palette remains global. This has been expected behavior for 12 years and IMO it shouldn't be changed. If you absolutely need other colors use PNGs instead.
It does not seem very intuitive or logical to me, but if it's the expected behavior then so be it.

I was thinking of the problems you get when including more than one IWAD in the resource list (e.g. doom.wad and hexen.wad). In this case you should use the PLAYPAL from the same WAD as the graphic, but I guess you can make this behavior optional (using a cvar or sth.)

[Graf_Zahl]

It does not seem very intuitive or logical to me, but if it's the expected behavior then so be it.

I was thinking of the problems you get when including more than one IWAD in the resource list (e.g. doom.wad and hexen.wad). In this case you should use the PLAYPAL from the same WAD as the graphic, but I guess you can make this behavior optional (using a cvar or sth.)


I think you shouldn't allow this at all.

[Ajapted]

I was thinking of the problems you get when including more than one IWAD in the resource list (e.g. doom.wad and hexen.wad).
Fwiw, EDGE already works this way, but I don't consider it the right way (for cross-port compatibility) because it's a pain for a S/W port, plus those existing wads which replace the global palette.

A compromise might be that each IWAD has its own PLAYPAL, and later PWADs replace that. Though personally I'd rather keep it simple (a global palette).

[Danimetal]

Has this discussion stopped or moved to another forum?.

I don´t see a lot of movement around this thread lately and well, you seemed to be setting the base to some agreement and that had to be good.

[Graf_Zahl]

I think the spec is finalized except for the syntax of the new texture definition lump. For that we had some suggestions but we haven't reached an agreement how to do it.

[Ajapted]

Apart from the syntax, there's the question of where in the WAD to put the new graphics. Either allow them anywhere, or yet another start/stop marker is needed. I don't think allowing them anywhere is a good idea (gut feeling, haven't given it much thought yet).

[Graf_Zahl]

Not more markers! They are fine to structure resources that need to be grouped (like flats or sprites) but for everything that is read through a lookup table anyway it only makes the mapper's task more complex.

I think you worry too much. Let's keep this thing as simple as possible. The more restrictions we add the less likely it is to be used. Besides, I'd like to have access to all the IWAD graphics for texture definitions - as in the TEXTUREx lump.

[Ajapted]

:) You're right, new markers won't be needed.

Time to make up some syntax. I think a token-based syntax has been preferred, something like this:

Texture NEWNAME
{
keyword arg1 ... argN ;
keyword arg1 ... argN ;
}


for sprite definitions the word "Sprite" is used instead of "Texture".

Keywords and their arguments are delimited by whitespace. Double quotes can be used to surround something containing whitespace. Every keyword must end with a semicolon.

Basic Keywords
lump LUMPNAME -- the source of the image. This keyword is compulsory.
destsize WIDTH HEIGHT -- the destination size of the image (in world units). Values can be floating point.
offset DX DY -- for sprites only (maybe graphics), the offset values (IN PIXELS).
texeloffsets -- textures only: sidedef offsets are in pixels. By default this property is off (sidedef offsets are in world units).

Notes
1. Lump is needed to differentiate other possible sources, e.g. the file system and/or non-WAD packs (e.g. PK3). I presume we'll want to put at least one of these into the spec.

----
What else is needed?

[Graf_Zahl]

How about qualifying the lump's name so that you could specify 'IWAD.TITLEPIC' if for some reason you want to use the original title pic but your WAD contains a replacement?

Another idea: Palette translations like the ones available in ZDoom with CreateTranslation. That way you can do simple recoloring without the need of duplicate graphics. It shouldn't be too hard to implement. Of course this could also be just an optional extension but I know it's something that has been repeatedly requested on the ZDoom forums. (Don't worry, I already have a fully working parser for this.)

[Ajapted]

How about qualifying the lump's name so that you could specify 'IWAD.TITLEPIC' if for some reason you want to use the original title pic but your WAD contains a replacement?
Doesn't seem very useful to me, but syntax-wise I'm thinking "iwad_lump TITLEPIC" (i.e. a special kind of source).

Regarding palette translations: I'm comfortable with them. EDGE has the code in place to handle them in GL mode. Presumably the table is from a lump?

For images.ddf I had a few ideas: a "palette" keyword to specify the palette, and color conversion equations (e.g. specify a hue rotation in HSV space -- but no good for a S/W renderer).

Another idea is a "nextanim" keyword to specify an animation sequence. A bit simplistic though: each texture can only be in a single sequence, and cannot occur more than once.

[Graf_Zahl]

Doesn't seem very useful to me, but syntax-wise I'm thinking "iwad_lump TITLEPIC" (i.e. a special kind of source).


Works as well. But I'd like to have the option


Regarding palette translations: I'm comfortable with them. EDGE has the code in place to handle them in GL mode. Presumably the table is from a lump?


I'd rather specify them directly using the same syntax as ACS. Creating binary lumps for this seems like a little needless work to me. Since I have fully working code for this that doesn't depend on anything I wouldn't consider the parser a problem. Feel free to use my code for it (you can find it in GZDoom's source, file thingdef.cpp, function AddToTranslation.) The only thing that could be changed is the palette matching for color ranges because GL ports don't really need to restrict themselves like that.


Another idea is a "nextanim" keyword to specify an animation sequence. A bit simplistic though: each texture can only be in a single sequence, and cannot occur more than once.

I already have ZDoom's ANIMDEFS which is much better for this so I don't really see the need. One thing I don't really like is to track resources for links like this. I'd rather have such stuff separated to another place.

[DaniJ]

Ok, I've spent the time looking at Doomsdays resource management and rereading this thread. While there would need to be considerable changes to Doomsday to handle this, I can't really see any problems with supporting this new resource definition method, as per the latest spec.

Doomsday has it's own DED definition stuff for animation sequences (and jHexen has ANIMDEFS) so personaly I'd prefer to leave them out of the spec (plus I don't really think they belong here).

Palette translations shouldn't be a problem either.

[Graf_Zahl]

Doomsday has it's own DED definition stuff for animation sequences (and jHexen has ANIMDEFS) so personaly I'd prefer to leave them out of the spec (plus I don't really think they belong here).
.


Maybe another spec later? Right now the only cross-port compatible solutions are either sticking to the few original animations or using Boom's ANIMATED lump.

[smite-meister]

Basic Keywords
lump LUMPNAME -- the source of the image. This keyword is compulsory.
destsize WIDTH HEIGHT -- the destination size of the image (in world units). Values can be floating point.
offset DX DY -- for sprites only (maybe graphics), the offset values (IN PIXELS).
texeloffsets -- textures only: sidedef offsets are in pixels. By default this property is off (sidedef offsets are in world units).

Some points:
- Does the image data (lump) have to have magic numbers and a header with width/height info? If so, using TITLEPIC here would be outright not possible;)
- I suggest replacing Destsize with Worldsize, to minimize confusion.
- Also, we should add an alternative scaling keyword, e.g. Scale SCALE [ASPECT = 1].
- Do we need the build-from-several-subtextures feature (mimicing TEXTUREx) ?
- I too think that animation definitions should be somewhere else (ANIMDEFS is quite adequate).
- Allowing a palette translation seems reasonable, but specifying the palette here seems useful only for graphics that have none attached. Do we allow them here?

[Graf_Zahl]

1. 'Lump' means something that can be identified as a graphic. And how should that affect TITLEPIC? It's a regular patch in Doom. Only in Heretic and Hexen it's a raw graphic and since these have to be loaded into the texture manager anyway, where's the problem?
2. Scale would be nice but not necessary
3. Of course it should support multipatch textures. All the functionality is already there so why not use it?
4. About translations, I was thinking the same. It should only work for graphics data that uses the base palette but not for PNGs. A warning to the console should be output if the user tries to assign a translation to a graphic that doesn't support it.

[smite-meister]

What is the image format identification logic here?
Magic numbers -> use them, otherwise assume patch_t?

[Graf_Zahl]

Plus doing a few sanity checks, yes.

[Ajapted]

I suggest replacing Destsize with Worldsize, to minimize confusion.
Okidoke.

Also, we should add an alternative scaling keyword, e.g. Scale SCALE [ASPECT = 1].
It would keep the spec simpler to only have one method. OTOH, users will probably need to edit the definitions themselves (who knows when or even if the various wad tools catch up), and in that case the scaling keyword could be useful.

Do we need the build-from-several-subtextures feature (mimicing TEXTUREx) ?
Personally I don't see a big need for this. It does complicate things, e.g. what resource/namespace is used to find the patch image (perhaps each patch must be defined by an previous def in the NTEXTURE lump).

[Ajapted]

4. About translations, I was thinking the same. It should only work for graphics data that uses the base palette but not for PNGs. A warning to the console should be output if the user tries to assign a translation to a graphic that doesn't support it.
You can apply translations to RGB images, it's just awfully slow. This is how I do it:

pal_idx = FindColor(rgb);
if (translation[pal_idx] == pal_idx)
// no change, so keep original rgb color
else
rgb = palette[translation[pal_idx]]

[Graf_Zahl]

You can apply translations to RGB images, it's just awfully slow. This is how I do it:

pal_idx = FindColor(rgb);
if (translation[pal_idx] == pal_idx)
// no change, so keep original rgb color
else
rgb = palette[translation[pal_idx]]



You could but it would hardly be worth it, don't you think? It would only make sense if you want to transform the color with some formula but not with a 256 entry index table.

[Graf_Zahl]

Personally I don't see a big need for this. It does complicate things, e.g. what resource/namespace is used to find the patch image (perhaps each patch must be defined by an previous def in the NTEXTURE lump).


Same as everything else. Global namespace, just where the TEXTUREx entries reside as well (and where the single patch textures here supposedly come from as well.) Without the multipatch capability I honestly don't see much use of this new method. That would only force the users back to TEXTUREx rendering the supposedly 'improved' way to define textures obsolete.

This has to offer the mapper some new possibilities (like the translation feature) but if you could combine this flexibly with multiple patches you could use it to put the same yellow 'danger' sign on many translated versions of the same texture or put lots of translated versions of the danger sign on the same base texture.

You have to maintain a multipatch texture handling anyway for TEXTUREx so what keeps you from reusing that code?

[Ajapted]

Without the multipatch capability I honestly don't see much use of this new method.
I'm not seeing much benefit in the text lump at all. Mainly the ability to make hires sprites with correct offsets. The text lump doesn't really solve a problem, more a vehicle for "future cool stuff". We need something cool now. Translation and texture overlaying are features that I think are better done in a new map format, but I'm pessimistic about that, so doing it with the texture system may be the only viable option.

[smite-meister]

I'm not seeing much benefit in the text lump at all. Mainly the ability to make hires sprites with correct offsets.
Don't forget it also offers the first really transparent way of creating arbitrarily scaled textures.
Besides, have there been _any_ other viable ideas how to do hi-res sprites?
The virtually unlimited extendability with "cool new stuff" is also an important factor in favor of the new text lump.

Regarding whether some texture-related things would be better defined in a new map format, I don't think that's a good idea. Even if a new map format were actually necessary (I don't think it is), we would be better of adopting some existing modern format (Quake 3 bsp or something similar) instead of defining our own :)

[Ajapted]

The spec now includes a draft format, something to discuss anyway (whipped up fairly quickly).

Draft #5 is here: http://glbsp.sourceforge.net/JointTextureSpec.txt

[Graf_Zahl]

Regarding whether some texture-related things would be better defined in a new map format, I don't think that's a good idea. Even if a new map format were actually necessary (I don't think it is), we would be better of adopting some existing modern format (Quake 3 bsp or something similar) instead of defining our own :)


What's the use of Q3's map format in Doom? As I see it none. But that doesn't mean that having more properties to set isn't a good idea. Just a few things that can be done right now only in a very awkward manner (or not at all):

- different light level for floor and ceiling
- colored light
- sector floor and ceiling texture rotation and scaling
- there are no different texture offsets for the 3 parts of each sidedef
- texture scaling per wall
- Setting a line's id in Hexen map format is rather messy because it requires a separate line special.
- if the capabilities of all ports are considered the line and thing flag fields are already full which makes implementing new features here impossible.

But that is getting a little off-topic right now. Establishing a new level format is most certainly a much bigger task than establishing a new means to define textures.

But I have to agree with Ajapted in one point. The new format is pointless if there isn't something that clearly shows that it is useful because otherwise people will continue to use the old methods and the tools they know.
So far the patch translation option is the only thing that fits that criteria. Arbitrary scaling to any size isn't really because it'd be very rare that you'd need it. Normally it's just scaling by a power of 2 because that's the one easiest done (and the only textures that tile properly on most software renderers.)

[Graf_Zahl]

The spec now includes a draft format, something to discuss anyway (whipped up fairly quickly).

Draft #5 is here: http://glbsp.sourceforge.net/JointTextureSpec.txt


Looks good but IMO needs a few minor adjustments:

1. Like LUMPIWAD there should also be a PATCHIWAD command.
2. A palette based translation that maps to a defined range in the palette, not RGB colors.
3. Translations should be settable per patch, not per texture (or do you think the user should just reference a translated texture if he needs to?)

[smite-meister]

Looking good. Comments and suggestions:
(brackets indicate optional parameters)

lump, lumpiwad, file: could be replaced with a single keyword,
data NAME [SOURCE=any];
with the other, nondefault options for SOURCE being iwad and file.
Perhaps a better alternative: disallow a single character in the texture lump names (no big deal), and use it to define an optional source prefix to dataitems. Example (using the colon):
data iwad:TITLEPIC;

Similarly, the keyword patch could be
patch SOURCE:NAME DX DY;
and it should be allowed with both "compose" and "data" -initialized textures (why not?).
Note: You can add thepatch texture to the current "canvas" in many different ways, especially if it has an alpha channel. Cf. the blending modes in OpenGL, for example... Another parameter?

scale:
Isn't the current TEXTUREx-based scaling factor defined exactly the opposite way, i.e.
image_coord = world_coord * scale? Note that this is how the renderer probably uses it, calculating the proper bitmap stepping from a world-distance.

offset:
The default unit for the offsets should be the same as for the texture offsets defined in sidedefs, i.e. world units. For the original (unscaled) graphics they are in any case equivalent. The Texeloffsets flag should affect this keyword, too.

As a side note, I implemented the first part of the texture draft (containers, lookup logic) in Legacy 2.0, and it really does work *thumbs*

[deepteam]

Mmm, where are the authors of ZDOOM and JDOOM? VAVOOM would be nice too. RH and SJ need to input here otherwise this is NOT a cross-port standard since 1/2 of the authors are missing.

I see one issue that is not apparent unless one actuall creates hires levels. The FLATs need to be scaled down to 64x64 proportions as a default - not expanded 1-1. Why?

Just make a hires level now put in hires flats doing it the way proposed. Looks like crap*crazy* JDOOM scales down which is inherently more logical if you think about it. That's consistent with how hires textures are also scaled. The whole idea of "hires" is to get beautiful detail. IOW, the specs should be geared toward that goal NATURALLY and not have to be forced.

See this site for some awesome level hires graphics http://sitters-electronics.nl/Game.html

For non-square graphics I scale them proportionally, but in all case hires stuff looks hires and not 1-1 lowres. There's an option for 1-1, so I can tell instantly how it looks 1 way vs the other. That's what I meant way back about letting it be an easy user option.

[DaniJ]

We'll I'm here anyway but I'll invite Skyjake once I've spent a bit more time deciding what exactly needs to be done with Doomsday (we have an agreement that since Skyjake isn't really interested in editing features - that is what I plan to work on) and I've briefed him on the changes.

Yes flats should be scaled down by default. IMO we should try to steer users away from flats in anycase, if we are going to allow any resource to be used anywhere it makes more sense to use a uniform world scaling for all resources (except sprites of course) when applied to the world. Meaning that if a TEXTURE is used on a plane it is NOT scaled to 64x64 world units. Would this brake any existing PWADS (thinking ZDoom mainly)?

BTW - Deep I still haven't heard from you regarding the texture stuff we talked about.

[Graf_Zahl]

Mmm, where are the authors of ZDOOM and JDOOM? VAVOOM would be nice too. RH and SJ need to input here otherwise this is NOT a cross-port standard since 1/2 of the authors are missing.


ZDoom is not an issue. If I present Randy with a working implementation I doubt he will ignore it. And if he doesn't contribute to this discussion it can't be helped. But that's not my (or anybody else's) problem and should not keep us from discussing it. Maybe something good comes out of this, maybe not. But not even trying will get us nowhere at all.



Yes flats should be scaled down by default. IMO we should try to steer users away from flats in anycase, if we are going to allow any resource to be used anywhere it makes more sense to use a uniform world scaling for all resources (except sprites of course) when applied to the world. Meaning that if a TEXTURE is used on a plane it is NOT scaled to 64x64 world units. Would this brake any existing PWADS (thinking ZDoom mainly)?


ZDoom scales flats that are larger than 64x64. But the handling is rather primitive because ZDoom only allows raw flat lumps with power of 2 squared sizes here so any advanced format is out anyway and nothing broken. Maybe we should retain F_START/F_END merely as a compatibility fallback option that is to be considered deprecated. I surely wouldn't want to invest too much work here because it won't give any benefits for future expansion. The preferred method for single patch graphics should be TX_START/TX_END if unscaled and one of the methods that allow specifying a scaling factor otherwise.

[Ajapted]

Just make a hires level now put in hires flats doing it the way proposed. Looks like crap*crazy* JDOOM scales down which is inherently more logical if you think about it. That's consistent with how hires textures are also scaled.
It is truly not logical or consistent. All other resources are (by default) unscaled. If a flat lookup finds the image in TEXTUREx or TX_START/END, it will be unscaled. But put an image in F_START/END and it is suddenly forced to 64x64 ??

The spec has a mechanism for hires flats (and textures), put it between H_START/END markers (which you yourself proposed). If the flat is new, then add a normal size version in F_START. Simple.

[DaniJ]

But put an image in F_START/END and it is suddenly forced to 64x64 ??
I'm pretty sure that is NOT intentional in Doomsday as it doesn't fit in with the core logic. Doomsday doesn't handle non 64x64 flats in any special way so its probably an oversight somewhere. As Ajapted pointed out it makes no sense to force a regular flat to 64x64. This would also mess with the scaling of hires replacements for the non-64x64 F_START/END flat so I doubt its intended.

[smite-meister]

Andrew, in the last draft you did not include the "texture" keyword in the NTEXTURE definitions.
It is not redundant, because later we might want to add other toplevel data structures to the same lump, such as material properties, parameterized shaders etc.
I think the keywords "texture" and "sprite" should go back in.

[Ajapted]

Andrew, in the last draft you did not include the "texture" keyword in the NTEXTURE definitions.
It is not redundant, because later we might want to add other toplevel data structures to the same lump, such as material properties, parameterized shaders etc.
Yeah, been thinking the same thing. Will fix it, though I'm tempted to use a single keyword for sprites and textures, since they are in different lumps.

[deepteam]

It is truly not logical or consistent. All other resources are (by default) unscaled. If a flat lookup finds the image in TEXTUREx or TX_START/END, it will be unscaled. But put an image in F_START/END and it is suddenly forced to 64x64 ??

The spec has a mechanism for hires flats (and textures), put it between H_START/END markers (which you yourself proposed). If the flat is new, then add a normal size version in F_START. Simple.
First off, I didn't really propose H_START, except as a alternate to TX_. In fact, I still propose it's totally superfluous and adds nothing to the spec. To argue from your own definition is not a valid argument :) Btw, I never mentioned F_START - we are having too many preconceptions interfering.

I never said a FLAT lookup (meaning a texture found in TEXTUREx or TX..) has to be unscaled. In fact, I said the opposite. If a "flat" finds a match in TEXUREx, it is scaled from the size in TEXTUREx relative to 64x64. Normal real Flats implicitly imply a size of 64x64. That means all hires flats automatically self-define to the target size. Doesn't really matter where they are found, although if you really wanted 1-1 sizing then the F_START stuff could be 1-1 and the others would rescale. That would be a workable compromise since it accomplishes both goals easily and is easily explained.

The spec is actually confusing and not logical in the sense that it has more rules than required and is inconsistent with current editing usage and rules. Plus all this needs a reality check for simplicity. The one dislike about JDOOM is the relative complexity for simple stuff (ditto some other ports). That's what this is turning into. This is starting to remind me of 1994 when texture composition was a royal PIA - back then was pretty close to what is being described here (minus some stuff of course).

The conclusions being reached by what I said are are way offbase. First off, when I talk about JDOOM hires, I'm talking about the EXTERNAL files since by definition that's what that means for JDOOM for pete's sake.

For EXTERNAL files, JDOOM rescales to the original image size (if found). That's what HIRES is all about. It means packing more pixels into the SAME area. For flats that happens to be 64x64 [so YES, that's deliberate code in JDOOM]. However, if it's a "texture" (not powers of 2 square), it should scale in proportion (that's not something JDOOM can do ATM, but that's what I have done for hires textures used as flats).

IOW, JDOOM's method is intentional and completely logical. It's real simple. If you have hires graphics replacements, it would look very odd to have the walls at hires and then have the flats displayed low res (expanded to full size). Like I said, you need to make some levels to see how odd this looks. It's completely unbalanced.

Now we take this basic idea and instead of having the JDOOM directories and names, we put exactly the same files INSIDE the PWAD between TX_ markers. Now the same rules apply as they did for external files. This coincidentally makes JDOOM happy, although they were very resistant to this type of packaging;)

Unless someone gives a single PWAD example of why TX_START can't be scaled to the dimensions of a TEXTUREx, it's an empty argument. IOW, something is being added that is not required - the HI_ section. It's true that ZDOOM is 1-1 (and I guess Edge) for flats, but I see that as a mistake in not recognizing the hassle it takes to get it back to 64x64 so it looks ok (there are specials to take care of that)

If you are going to ASSUME that something is a problem with not a single fact to back it up, then this is not an objective discussion but merely a contest of wills. I have a feeling this has something to do with stock ZDOOM since it can't handle true-color, but that's a weak reason. ZDOOM is going to have issues with any true-color stuff (unless he adds code), so that's not a valid concern.

I'm not interested in ego battles. Give me a PWAD where this actually breaks something. I think it would be much simpler to tell a user that if he adds hires-color images in-between TX_ markers then they scale to the size TEXTUREx has defined. Any such image used as a flat scales to 64x64 proportionally. It no match then they are 1-1. The text files are optional.

To force a user to create all these endless text files just for common scaling is a royal PIA. It's so easy and simple to avoid this by merely following the simple rules I defined. For other attributes, fine, that's what I said before. But I see nothing user friendly as it relates to editing and scaling in this spec.

The less there is to learn to get the job done, the better.

[deepteam]

ZDoom is not an issue. If I present Randy with a working implementation I doubt he will ignore it. And if he doesn't contribute to this discussion it can't be helped. But that's not my (or anybody else's) problem and should not keep us from discussing it. Maybe something good comes out of this, maybe not. But not even trying will get us nowhere at all.
Saying No input is not a valid argument. It is indeed our problem. If he doesn't contribute to this, clearly he has no interest in other ports. IOW, lack of input shows lack of interest. Same goes for JDOOM. Must not care. JK's put a hell of a lot of effort into a completely different system.

Meaning that it has to made palatable to other ports. That means that making it relatively easy for them to incorporate.

JDOOM can do this real easy. All it means is using exactly the same code (for scaling) that is already in place for the external textures and using them for TX_ graphics. JDOOM's routine for adding TX markers is duck simple to extend.

Keeping it in TX_ is actually a benefit for ZDOOM. All he has to do for true-color is dump his own code and adopt a library to handle the conversions. I've already described a simple method to get absolute scaling. And the rest of the texture build code is already all there. The argument you gave before makes no sense since essentially it's still tied back to TEXTUREx, but with still more namespaces.

This also makes it attractive to VAVOOM. It's much better to start with a more MODEST goal and see how it's accepted. Then address some other concepts. There is a reason for some of JDOOM's complexity - he's has a boatload of features that only now are being recognized are cool features.*monkey*

[DaniJ]

So you weren't talking about autoscaling F_START/END flats (I thought you were refering to those also). In which case forget what I said as it is definetly intentional for hires replacements to be scaled to the size of the original automatically.

[Ajapted]

I never said a FLAT lookup (meaning a texture found in TEXTUREx or TX..) has to be unscaled. In fact, I said the opposite. If a "flat" finds a match in TEXUREx, it is scaled from the size in TEXTUREx relative to 64x64.
Well that's definitely better than what I thought you meant. Although it does create another inconsistency (different scaling depending on whether you use it on a plane or a wall).

Plus all this needs a reality check for simplicity.
I wish it were simple, but it's not. This long thread proves it.

The spec is just a draft. Nothing is set in stone, yet :).

For EXTERNAL files, JDOOM rescales to the original image size (if found). That's what HIRES is all about. It means packing more pixels into the SAME area.
Yep that's cool. In reference to the spec, JDOOM's external files are equivalent to the H_START resource.

For flats that happens to be 64x64 [so YES, that's deliberate code in JDOOM]. However, if it's a "texture" (not powers of 2 square), it should scale in proportion (that's not something JDOOM can do ATM, but that's what I have done for hires textures used as flats).
How exactly do you scale "in proportion"? (I can think of four different ways: force width to 64, force height to 64, force MIN(w,h) to 64, or force MAX(w,h) to 64).

Unless someone gives a single PWAD example of why TX_START can't be scaled to the dimensions of a TEXTUREx
My objection to that is the lack of consistency: new textures in TX_ will be unscaled, but if the name happens to match an existing texture then it gets scaled to match that texture. It is a dependency issue.

If you said that textures in TX_ (new or old) get scaled to 128x128 (like flats get scaled to 64x64) (possibly with an "in proportion" rule), then I'm warming up to it. But I'm not sure that will be workable in practice.

The H_ (or HI_) resource may be new, but at least it is well defined (only for hires replacements).

[DaniJ]

So you allow NEW textures to be mixed in with replacements in TX_? That doesn't sound like a good idea to me. What happens about all the other features Doomsday has for resources in that scenario (eg decor lights, reflections, particle generators etc etc)?

[Ajapted]

Updated the spec (same old place) (http://glbsp.sourceforge.net/JointTextureSpec.txt). Main change is the SOURCE argument for the 'patch' command (same sources as non-composed textures can use).

Going back to earlier comments:

3. Translations should be settable per patch, not per texture (or do you think the user should just reference a translated texture if he needs to?)
The latter. The syntax for 'patch' would otherwise get more complex (e.g. have "{ }" with sub-commands in there -- possible, but overkill imo).

Note: You can add thepatch texture to the current "canvas" in many different ways, especially if it has an alpha channel. Cf. the blending modes in OpenGL, for example... Another parameter?
IMHO that's going too far. But it could be done using a separate keyword like "blendmode" that affects later patch commands.

scale: Isn't the current TEXTUREx-based scaling factor defined exactly the opposite way, i.e.
image_coord = world_coord * scale?
I don't know. For me the most intuitive way is that larger scale values mean larger in-game images.

offset: The default unit for the offsets should be the same as for the texture offsets defined in sidedefs, i.e. world units. For the original (unscaled) graphics they are in any case equivalent. The Texeloffsets flag should affect this keyword, too.
Although that would be consistent, I think sprites are different and world-unit offsets don't really make sense, since their offsets are closely bound to their image.

As a side note, I implemented the first part of the texture draft (containers, lookup logic) in Legacy 2.0, and it really does work *thumbs*
Our first satisfied customer - cool :).

[smite-meister]

Updated the spec (same old place) (http://glbsp.sourceforge.net/JointTextureSpec.txt).

It's a good idea to divide the texture def to two parts, of which the source part must come first.
The "previous" keyword is not so good, I think the C++-like inheritance does this better (and is easier to implement in the parser).

Do we really need the source selection for the "patch" keyword? Is it not enough to look for the
patch-texture in the current texture containers, using a given lookup order (most likely "wall"), like this:
patch EXISTING_TEXTURENAME DX DY;

This way you could either use the PNAMES patch_t's (the old way) or first define some new patch-textures in NTEXTURE and then use them in composing another new texture.


Although that would be consistent, I think sprites are different and world-unit offsets don't really make sense, since their offsets are closely bound to their image.

So NTEXTURE and NSPRITES would have similar syntax but different default behavior?

BTW, I decided to learn myself some Flex and Bison (which turned out to be much crappier programs than I thought, probably because they want to be backwards compatible with lex and yacc *mad*).
Anyway, here is a working Flex scanner for parsing NTEXTURE lumps:
http://users.tkk.fi/~vberghol/doom/ntexture.flex
I also wrote a Bison parser, but it' s still somewhat unfinished.

[Boingo the Clown]

Doing something with a C++ like syntax would be difficult for newbies to learn, just like the way fraggle script's C++ like syntax has stymied a lot of newbs.

Just an observation.

[Danimetal]

Surely someone could make a tool to make these things easier for people with no knolegde of the sintax. I think Wadaholic made a tool for FraggleScript, maybe he could be ask about this unless someone else wants to make it.

[smite-meister]

Doing something with a C++ like syntax would be difficult for newbies to learn, just like the way fraggle script's C++ like syntax has stymied a lot of newbs.

In FS it's not the syntax, it's the actual task of programming that takes some time to get a grasp on:)
More to the point, the mappers are not required to know the syntax. No doubt there will be editor programs that do it for them.
The syntax only has to be easily extendable, easy to parse and preferably human-readable.

[iori]

I agree on the C syntax. FS isn't challening to people who take the time to learn the syntax, way functions work, etc, even for newbies. In fact, the ones that take the time to figure it out might even push out a decent product because of it? :p

[Rellik_jmd]

If I can learn it then anyone can. :p It's just tricky in the beginning till you get a handle on how it all works together and the basic theories behind the structure. After that the learning curve gets pretty steep.

[Danimetal]

...even for newbies. In fact, the ones that take the time to figure it out might even push out a decent product because of it? :pHey, stop looking at me while you say that :P.

[rustyslacker]

Surely someone could make a tool to make these things easier for people with no knolegde of the sintax. I think Wadaholic made a tool for FraggleScript, maybe he could be ask about this unless someone else wants to make it.

I believe his tool is known as "Frag" and it should be at http://www.wadaholic.tk/ .

[Ajapted]

The "previous" keyword is not so good, I think the C++-like inheritance does this better (and is easier to implement in the parser).

Do we really need the source selection for the "patch" keyword? Is it not enough to look for the patch-texture in the current texture containers
Those were an attempt to unify the sources of textures and patches (especially the IWAD ones). The simpler way was probably better. Personally I don't think the IWAD stuff is worth the hassle.

So NTEXTURE and NSPRITES would have similar syntax but different default behavior?
Yes. If worldoffsets don't make sense for sprites (and I'm sure they don't) then making texeloffsets implied for NSPRITES seems reasonable to me.

[Aliotroph?]

I believe his tool is known as "Frag" and it should be at http://www.wadaholic.tk/ .

Although, I like Wad'a'holic's idea, he has neither the programming ability or the focus to pull that off in any way that would make it more worthwhile for newbies than just learning FS. If they can figure out the programming ideas required to make anything complex with it then they won't have trouble with the syntax, and if not then at best they can make very limited use of it. Limited scripts like spawning items are the kind of thing that should be implemented in a map editor if you want a tool.

[deepteam]

I'm busy ATM with some customer code. Will probably take me a few days to find time to think clearly and explain some more :) Meanwhile Graf is defaulting to the ZDOOMGL system, which is what I alluded to earlier. There has to be a willingness by most of the authors to compromise, even at the expense of having to change their code. If that's not there, then all this ends up being useless.

Hence, my basic point is this: Don't get into all these details without first resolving just ONE issue: how to scale. Talking all of these at once makes for something that is difficult to get concensus on. I recommend a look at JDOOM for some his ideas, you'll see that there are many other concepts that have only been skirted.

Later*wave*

[Ajapted]

Hence, my basic point is this: Don't get into all these details without first resolving just ONE issue: how to scale.
Okidoke. There are two parts:

1. scaling for TX_START/END.
2. scaling for flats.

In my view, TX_START textures should be unscaled because the original implementation (ZDoom) does this, and because new textures are allowed there (AFAIK) and would behave differently than scaled replacements.

Flats should be unscaled to be consistent with everything else in the WAD format. If a flat loopup finds a texture, and then scaled, it would look different to the walls using the same texture.

I recommend a look at JDOOM for some his ideas
I've scoured the jdoom site, cannot find any information on whether PNG is supported in WADs, or even if TX_START/END is supported by JDoom. The Wiki is broken.

[MR_ROCKET]

Well I hear Skyjake's back from the graduation parade, so he might be able to comment on this stuff now, granted I'm sure he wants to get settled back in, maybe kick his shoes off and have a beer first. :)

[smite-meister]

In my view, TX_START textures should be unscaled because the original implementation (ZDoom) does this, and because new textures are allowed there (AFAIK) and would behave differently than scaled replacements.

Flats should be unscaled to be consistent with everything else in the WAD format. If a flat loopup finds a texture, and then scaled, it would look different to the walls using the same texture.

I agree on both points.
Although the flat scaling would not be that big a problem, since the scales of individual texture objects can be fixed when the containers are populated. Lookups are only performed later, so if you do find a doomtexture during flat lookup it should look precisely similar as the same texture found in a wall lookup.

[smite-meister]

Damn, accidental double posting.

[DaniJ]

I've scoured the jdoom site, cannot find any information on whether PNG is supported in WADs, or even if TX_START/END is supported by JDoom. The Wiki is broken.No TX_START/END is not supported currently in Doomsday. All formats Doomsday supports are supported in WAD but not directly as lumps between the various markers. Historicaly there has been little incentive for Doomsday to extend the WAD format so all its new features are mostly geared towards external files. However, it is possible insert ANY data file format (PNG, TGA, PCX, WAV, MUS, MP3, IT, MD2, DMD, DED etc etc) into a PWAD (lumps should be placed "loose" in the PWAD outside of any markers) using the command line tool wadtool which creates a special lump called DD_DIREC . This lump contains a name-to lump conversion table which Doomsday uses to find the different resources by external file name (as referenced in DED definitions) rather than lump name.

As you've probably discerned by now, Doomsday works on the assumption that NEW resources ARE external files. Hence why the DD_DIREC mechanism is in place to tell Doomsday to use a lump instead of a file. Now that we have the PK3 format though it is much easier to simply place your files in a PK3 than a WAD so the DD_DIREC feature doesn't AFAIK get used anymore.

I shut down the Doomsday Engine Wiki at deng.sf.net/dew/. This was done because of a change in SourceForge's website hosting setup and a vulnerability in TWiki. The wiki will become available at a new location sometime in the coming weeks. Other website-related changes are also being planned.

[Planky]

According to zdoom.org, Randy is looking at replacing ACS with something more expandable (which is kind of annoying, considering Legacy is only just starting to support it). Perhaps it's a good time to look at starting a common scripting language between ports.

[Rellik_jmd]

I was thinking the same thing when I read it this morning. This would be the perfect time to develop a universal language. Maybe "DoomC" like the quakes have "QuakeC".

[smite-meister]

This would be the perfect time to develop a universal language. Maybe "DoomC" like the quakes have "QuakeC".
No. No new languages! *eek*
The only sensible choice nowadays would be to pick an existing scripting language (Pawn/Small, Python, Lua, Ruby etc.) and design a standardized game interface for it.

Either way we will need an ACS interpreter also if we want to have Hexen support, so it's not wasted code. Extending ACS is a different thing though.

[Aliotroph?]

lol Inventing another new language would drive several dozen people insane. Smite's idea sounds neat though.

I have yet to learn ACS.

[janka]

I just got familiar with latest version of the spec. Here are my comments:

1. F_START/F_END should allow only raw flat lumps, so in the beginning you should say "... can be used anywhere except F_START".

2. H_START should also contain hi-res versions of TX_START textures.

3. How multile NTEXTURE and NSPRITES lumps are handled? Should it parse only the last one or all of them? I prefer the latest to be consistent in the way ZDoom and Vavoom handle ANIMDEFS lumps.

Talking about scaling, Vavoom implements TX_START the same way ZDoom does it, i.e no scaling. Currently Vavoom has no support for flats larger than 64x64, proposed behavior is fine with me.

[Ajapted]

I just got familiar with latest version of the spec. Here are my comments:

1. F_START/F_END should allow only raw flat lumps, so in the beginning you should say "... can be used anywhere except F_START".
Why not jpeg or png? Yes there is a small chance of misdetection (a flat which happens to start with the same magic bytes), but it's so tiny that it's not worth worrying about (to summarise the general consensus here).

2. H_START should also contain hi-res versions of TX_START textures.
That is possible, yeah. It might be a bit of a pain (because the spec says to put TX_START and NTEXTURE into a single container), but I think it makes sense.

3. How multile NTEXTURE and NSPRITES lumps are handled? Should it parse only the last one or all of them? I prefer the latest to be consistent in the way ZDoom and Vavoom handle ANIMDEFS lumps.
That part of the spec is still quite raw (in flux), but I suggest: allow one lump per WAD and parse them all. That's how I handle TEXTUREx lumps (and other ports too).

[Ajapted]

No. No new languages! *eek*
The only sensible choice nowadays would be to pick an existing scripting language (Pawn/Small, Python, Lua, Ruby etc.) and design a standardized game interface for it.
For many people Lua (etc) would still be a completely new language to learn.

I have doubts whether existing languages are suitable for Doom, which can have 1000s of monsters in a level (extreme example: DeusVult MAP05). Each actor needs it's own execution context (including a stack), that could use a lot of memory, and make savegame files a lot bigger.

[janka]

Why not jpeg or png? Yes there is a small chance of misdetection (a flat which happens to start with the same magic bytes), but it's so tiny that it's not worth worrying about (to summarise the general consensus here).
They should go into TX_START.

That part of the spec is still quite raw (in flux), but I suggest: allow one lump per WAD and parse them all.
I don't think there's a reason we should limit it to only one per wad, simply parse them all.

That's how I handle TEXTUREx lumps (and other ports too).
AFAIK all other ports handle only the last TEXTUREx lump.

[janka]

For many people Lua (etc) would still be a completely new language to learn.

I have doubts whether existing languages are suitable for Doom, which can have 1000s of monsters in a level (extreme example: DeusVult MAP05). Each actor needs it's own execution context (including a stack), that could use a lot of memory, and make savegame files a lot bigger.
For me VavoomC works just fine.*smirk*

[Danimetal]

Either way we will need an ACS interpreter also if we want to have Hexen support, so it's not wasted code.
And, speaking of that... Wouldn´t it be possible to precompile FS so it´s more reliable?.

[smite-meister]

For many people Lua (etc) would still be a completely new language to learn.

So are FS and ACS, but the difference is that a non-Doom-specific language can be useful also elsewhere.


I have doubts whether existing languages are suitable for Doom, which can have 1000s of monsters in a level (extreme example: DeusVult MAP05). Each actor needs it's own execution context (including a stack), that could use a lot of memory, and make savegame files a lot bigger.
The purpose of the scripting language is not to replace the existing AI code, but to complement it in some cases (individual NPC's, "smart monsters" etc.) and enable all kinds of location-specific scripted game events. Besides, I don't think we can design a decisively more efficient language than the people who do it for a living :)

[smite-meister]

And, speaking of that... Wouldn´t it be possible to precompile FS so it´s more reliable?.
The right way to do the FS interpreter would be to write a new, reliable lexer and a parser, compile the FS source into an abstract syntax tree (AST or something like it) when the map is loaded and then use the tree to execute the scripts. This would make FS many times faster and more reliable.

[Danimetal]

And... Would it be possible?. Most people complain about FS skipping their functions and stuff (not that happens to me) and well, we´re having ACS, more reliable and (they say) more powerful but still we have FS too not only for backwards compatibility purposes but also as a scripting language that, as far as I know, has some unique functions. Making this FS interpreter you talk about would be a great addition. Sure.

[smite-meister]

Why not jpeg or png? (in F_START)
The question here should be "Why _should_ we allow any extra stuff in F_START?"
Not everything that is in principle possible should be included in the standard.
I think we should provide a minimal set of backwards-compatibility features, and preferably only
a single, well-designed new extendable method for introducing advanced textures (this would be the NTEXTURE lump).

The same argument applies to redefining TX_START textures with H_START textures. Why _should_ it be allowed, when you can do this using NTEXTURE just as easily?
(The rationale for introducing H_START in the first place would be hi-res texture packs for replacing the original graphics)

[janka]

The question here should be "Why _should_ we allow any extra stuff in F_START?"
Exactly!

The same argument applies to redefining TX_START textures with H_START textures.
I'm not talking about redefining, but about providing hi-res versions of TX_START textures.

[Ajapted]

The question here should be "Why _should_ we allow any extra stuff in F_START?"
Allowing any recognisable format (jpeg,png) anywhere is a nice, user-friendly system. Disallowing them in F_START but allowing them elsewhere is just an arbitrary limitation.

The spec cannot be the lowest-common denominator, that would be plain DOOM.EXE. The spec has value because it documents stuff like how pngs work in F_START, for ports that want to implement it.

[smite-meister]

I'm not talking about redefining, but about providing hi-res versions of TX_START textures.
That's what I meant, and it can be done better using NTEXTURE. The hi-res texture pack argument does not apply here because there are no existing IWADs with loads of lo-res TX_START textures:)

[janka]

But there are levels using them, and authors of those levels might want to provide a hi-res textures for hardware accelerated engines and have low-res ones for software renderers.

[MR_ROCKET]

Man all this talk about texture stuff..before its all said and done,I could imagine the convo's at work with you guys.

um scue'z me, mind if I ask what time it is?
sure about.. TX_12:45..
K..THX.
F_NP..
Oh so when ya gonna be done with that??
After F_END.
Ah..oh, ok
But then what?
NTEXTURE!
what?
F_STFU
:(

[Danimetal]

LOL @ Rocket.

Nah, they´re doing a nice work putting together some standards. Not exacly slopes, but surely to bring nice things :).

[MR_ROCKET]

Yes.. :)

[smite-meister]

But there are levels using them, and authors of those levels might want to provide a hi-res textures for hardware accelerated engines and have low-res ones for software renderers.
That would be completely new functionality. The current spec says that also software renderers should use the hi-res stuff in H_START, not just the hardware ones. If this option is really needed (I can't really say), the easiest way to do it is again NTEXTURE with a single new keyword:

"hardware": if using software renderer, ignore this texture definition.

[Ajapted]

There is a discussion about a new map format occurring on a Doomworld forum (Source Ports). To summarise it briefly: Quasar wrote a spec for a new binary map format, there was talk about text formats, the ExtraData system, chunked formats (like PNG), parsers, etc. The current proposal (by Graf Zahl) is a text format extra-data system.

[Danimetal]

Wasn´t Graf also talking about a new map format in these forums too?.

[Nuxius]

"32-Bit Map Format Proposal" thread at Doomworld:
http://www.doomworld.com/vb/showthread.php?s=&threadid=34323

"Extradata definition" thread at the GZDoom forums:
http://forum.drdteam.org/viewtopic.php?t=623

[Planky]

I think we better start looking at having a seperate forum for all these specs, rather than having them spread across various websites.

Perhaps a new forum on drdteam.org?

[Nuxius]

I've actually been thinking that myself. Would make this all a bit easier to follow.

But I imagine it's a bit late for that now, though...

[Planky]

I dont see why, all we do is have seperate threads for each spec (texture handling, map format) with a link to these original threads. If we had the webmasters support we should be able to copy the entire thread into the new forum.

[smite-meister]

I dont see why, all we do is have seperate threads for each spec (texture handling, map format) with a link to these original threads. If we had the webmasters support we should be able to copy the entire thread into the new forum.
I second this motion. Having all JDS-related threads under the same forum would be much easier.

I quickly skimmed through the map format thread. In one of his posts, Quasar pointed out a parser library called Confuse *confused* (I just had to use that smiley)
http://www.nongnu.org/confuse/

It seems to me that it is almost exactly what we want for NTEXTURE, if we are willing to drop the semicolons and re-introduce the assignment operators:
http://www.nongnu.org/confuse/test.conf
Also, you get a bunch of new goodies such as lists for free. And it's easier than bison :)

[Ajapted]

It seems to me that it is almost exactly what we want for NTEXTURE, if we are willing to drop the semicolons and re-introduce the assignment operators
Is the libConfuse syntax line-based or token-based? Dropping the semicolons makes sense in a line-based format, but in a token-based format it makes skipping unknown keywords harder. Also the strict "name=value" syntax seems a bit limiting for NTEXTURE (e.g. the patch keyword needs at least 3 values).

[smite-meister]

Is the libConfuse syntax line-based or token-based? Dropping the semicolons makes sense in a line-based format, but in a token-based format it makes skipping unknown keywords harder.

Don't know. The manual is a bit thin (just a Doxygen interface description!)
It would seem it is at least in part line-based (max. one command per line).
Of course the library should have good error recovery before it can be considered an option.


Also the strict "name=value" syntax seems a bit limiting for NTEXTURE (e.g. the patch keyword needs at least 3 values).
For some items we could quite naturally use lists, for example
worldsize = {100, 200}
for other uses, like the patch keyword, one could use the "function" construct:
patch("PAT1", 10, 50)
It actually makes sense, because "patch" is not a property of a texture, but more an operation that is performed on the texture.

[deepteam]

Okidoke. There are two parts:

1. scaling for TX_START/END.
2. scaling for flats.

In my view, TX_START textures should be unscaled because the original implementation (ZDoom) does this, and because new textures are allowed there (AFAIK) and would behave differently than scaled replacements.

Flats should be unscaled to be consistent with everything else in the WAD format. If a flat loopup finds a texture, and then scaled, it would look different to the walls using the same texture.

I've scoured the jdoom site, cannot find any information on whether PNG is supported in WADs, or even if TX_START/END is supported by JDoom. The Wiki is broken.
Why should TX_START textures be unscaled? Because ZDOOM forgot about this? So what. As I've asked a billion times, SHOW ME A PWAD where this new rule creates a problem? There isn't one. Therefore it's safe to do this. Even if there was ONE, BFD, you are going to make life difficult because of 1 friggen PWAD?

The crux of my argument for duck simple scaling is actually derived from the way JDOOM does scaling:

JDOOM automatically scales external textures to the size found in TEXTUREx and in fact does not support any sort of hires PNG/etc inside of a PWAD (same goes for flats, except those scaled to 64x64). That is a royal PIA for editing and something Graf and I agree on :)

So what I said wayyyy back in this thread is that there is no ZDOOM pwad using TX_START that duplicates an existing texture name. Hence, if you use the exact same logic that JDOOM uses, for hires textures found INSIDE a PWAD (delineated by TX_START and FF_START), you get automatic scaling with absolutely NO EXTRA EFFORT required.

Historically the reason the way ZDOOM does what it does is because RH figured you'd use TEXTUREx control to scale, so why bother scaling TX_START? Meaning if a ZDOOM user wanted to scale the hires, he'd use the existing TEXTUREx scaling system..

RISEN3D and my modification R3DEDIT both support either external or internal HIRES textures. The key element is if it finds an existing match in TEXTUREx. IOW, it's proof that this works:)

As to the repeated statements that FLATS can't be automatically rescaled - not true. You can either make a different area or inside of FF_START. There is absolute no reason (arbritary to me means confusing and a PIA) why you can't have any format image in any name space. In fact, if the ports put in the code I described you can have graphic ANY format in any name space. That's the way it should be. The end result is easy for the user, creates foolproof code in the port (can't blow up as they do now). If user doesn't read, no harm done, they can still use the "old" rules.

Whether FLATS are uses on WALLS or FLOORS is not relevant. The rules for scaling for FLATS apply only when used on the 64x64 implied surfaces. Remember, textures (the TEXTUREx kind or the TX_START kind) can also be used for floors/ceilings.

Plus you can have it BOTH ways. Open your mind here please. ZDOOM actually did a very poor implementation of scaling - RH never considered or realized that what he did has some serious shortcomings. Luckily this is easily overcome since very few (if any) levels really used what could be done.

These texture/namespace "rules" that exist are antiquated and the result of piss poor support code - nothing else.

Rather that say "we can't do this", say instead "what are the rules we need to make this work" as easy as possible. For flats it's easy, take the largest side and use that to scale referencing 64. [I also have an option for "fullsize" the ZDOOM way since it's trivial to do it either way]. You could have a different name space for this if that makes you feel better, still using the same rules (and you can still have the text files for more info). However, in no case should the spec say that you can't have a certain format in any of the texture namespaces. There is absolutely no reason for that.

Devise acceptable and easy rules on how scaling works. Using what I described (meaning it's a WORKING SYSTEM), I took ALL the hires textures and FLATS that JDOOM has as external files and put them all into a PWAD using the TX_START and FF_START markers. End result was automatic scaling exactly the same way JDOOM uses all in one easy to manipulate PWAD.

As for OTHER stuff in JDOOM, guys there is MUCH MORE to JDOOM than you realize. The very long list of how he has defined textures, models, lighting (and so forth) is very useful. It is actually quite powerful - JDOOM just hasn't made the most use of what he created and has made some things a bit too abstract via named chaining. For example, it took me a tiny bit of code to support the GZDOOM lights. Mostly this was adding an external definition and then using some dynamic "map" settings (still to do since I'm still pretty busy atm).

[DaniJ]

As for OTHER stuff in JDOOM, guys there is MUCH MORE to JDOOM than you realize. The very long list of how he has defined textures, models, lighting (and so forth) is very useful. It is actually quite powerful - JDOOM just hasn't made the most use of what he created and has made some things a bit too abstract via named chaining.I agree 100%. Doomsday's infrastructure when dealing with it's OWN stuff is superb (much credit to Skyjake). Exposing the power of these systems to the user in an user-editable, friendly manner is something I plan to focus on in the 1.9.X series.

For example, it took me a tiny bit of code to support the GZDOOM lights. Mostly this was adding an external definition and then using some dynamic "map" settings (still to do since I'm still pretty busy atm).Heh. Yeah I noticed that as well :) Expect support in Doomsday for GZDOOM lights soon too.

I remember we talked briefly about DECORATE support too. I've spent a bit more time comparing it with DED and it is ASTONISHING how similar the two are. In fact, Doomsday's internals are actually MORE flexible than what is offered in DECORATE but due to the long winded DED syntax it has had much less widespread use.

BTW Deep - What happened to that email about the Doomsday texture system?

[smite-meister]

Why should TX_START textures be unscaled?
The logic here is that scaling behavior should be consistent within a namespace. Otherwise, some map authors WILL be confused over having two seemingly similar PNG textures within TX_START, one named DOORTRAK and another MYOWNTEX, one scaled for no apparent reason and the other one not. This is why we have the H_START namespace. IMO TX_START is not at all necessary since we have NTEXTURE, but it is supported for backwards compatibility.


As to the repeated statements that FLATS can't be automatically rescaled - not true. You can either make a different area or inside of FF_START. There is absolute no reason (arbritary to me means confusing and a PIA) why you can't have any format image in any name space.

Not true! Flats and patch_t's cannot be reliably told apart. There are even two such clashes in hexen.wad: CHLYA0 and CHLYG0, which both have size 8192. This is why patch_t cannot be allowed in F_START and flats cannot be allowed anywhere else.

All in all, this is how I think the texture namespaces should be used in future WADs:

TEXTUREx: unscaled patch_t based textures
F_START: unscaled (or maybe scaled, I don't really know what the current usage is) flat-type textures
H_START: hi-res texture packs for original IWADS
TX_START: unscaled PNG and JPEG textures
NTEXTURE: everything else, arbitrarily scaled, arbitrary-size hi-color textures with bells and whistles

[Ajapted]

As I've asked a billion times, SHOW ME A PWAD where this new rule creates a problem? There isn't one. Therefore it's safe to do this.
For me it's never been a question of safety. Rather consistency. Your plan is not consistent and hence not user-friendly, because a texture in TX_START that matches an old one is scaled and a new one is unscaled. No port (except Risen3D) is using TX_START like that, and hence the better system for hires replacements (H_START) should be promoted.

For flats it's easy, take the largest side and use that to scale referencing 64.
Seeing that some ports already scale large flats, I will add that rule into the spec. I don't have to like it though :). I will follow Smite-meister's suggestion and say that the scaling is fixed at load time (i.e. presence of the image in F_START sets the scale). The alternative of scaling floors differently from walls is just fucked up imo.

@Smite: it might be good to make the NTEXTURE syntax compatible with libConfuse. I'll take a closer look at it.

[smite-meister]

Seeing that some ports already scale large flats, I will add that rule into the spec. I don't have to like it though :). I will follow Smite-meister's suggestion and say that the scaling is fixed at load time (i.e. presence of the image in F_START sets the scale). The alternative of scaling floors differently from walls is just fucked up imo.

BTW, does anyone know how the Hexen 128*64 flats are supposed to be handled? Because this affects them too.


@Smite: it might be good to make the NTEXTURE syntax compatible with libConfuse. I'll take a closer look at it.
OK. I just hope libConfuse is robust enough to handle syntax errors in a meaningful way.

[Ajapted]

BTW, does anyone know how the Hexen 128*64 flats are supposed to be handled?
They are suppose to scroll (render a 64x64 portion and move that portion in time). That's not really feasible in GL, so what you can do is truncate to 64x64 and scroll the floor/ceiling in the normal way.

[MR_ROCKET]

Bump, or has the current dev convo been moved to a different location?
Sorry I guess I was just getting used to poppin in here every few days to see what the low down was.. :)

[deepteam]

For god's sake. The underlying premise of ANY idea is that the author reads and understands the rules. IOW, nothing anyone has said logically negates my suggestion.

How do you think JDOOM users know how to "scale" their textures? This is so obvious to me the only thing I can think of is lack of editing and mod experience.

KISS (Keep It Simple Stupid) is the underpinning of what I said. No extra namespace, no text files, just a very consistent method to scale. Exactly the opposite of what you guys are saying. In fact, your criticism applies 100% to your ideas. It's weird, it's not consistent, not friendly to existing tools and TaaDaa, the user has to READ your rules, otherwise .. he has no idea what to do.

Scaling has always been controlled in TEXTUREx. That simple statement nullifies the argument that what I said is inconsistent. That's so obvious that not seeing this makes me wonder that anything easy will ever come out of this.

[deepteam]

The logic here is that scaling behavior should be consistent within a namespace.
It is. Can't you see that? Rules are rules and this is no different. Mine are different from yours but even more consistent since it follows much closer the original design. The problem is simple: none of you understand or have used the ZDOOM rules to see how this works.
Otherwise, some map authors WILL be confused over having two seemingly similar PNG textures within TX_START, one named DOORTRAK and another MYOWNTEX, one scaled for no apparent reason and the other one not. This is why we have the H_START namespace. IMO TX_START is not at all necessary since we have NTEXTURE, but it is supported for backwards compatibility.
Circular logic. Only shows you haven't followed the TX_START from the beginning nor have used all the texture possibilities possible now. No confusion here at all - user understands this already. You do NOT need NTEXTURE. It's like inventing 1994 all over again. Needless, complicated and most of all user and editor unfriendly. A real PIA.
Not true! Flats and patch_t's cannot be reliably told apart. There are even two such clashes in hexen.wad: CHLYA0 and CHLYG0, which both have size 8192. This is why patch_t cannot be allowed in F_START and flats cannot be allowed anywhere else.[/b]
Wonder how I do it then :) Tell you what, run R3Dedit and put some patches in F_START and see what happens. Also duplicate the name as a patch (or texture). All this tells me AGAIN is that you are not reading what I've written [I've said this at least once]. Which makes this a thread of pre-conceived ideas where nothing is being read or understood?

There is absolutely no reason to continue the nonsense of restricting texture types to specific namespaces. It's just a nuisance for users. These formats CAN reliably be distinquished and it works - just try what I described.

If you look at the priority scheme of floor use vs wall use you'd also see that they can both use the same name and yet come up as 2 different textures. [As an aside I argued strongly against duplicate names, but Graf and others were blinded by the argument itself and kept saying that was a good idea - hence we have lots of PWADS with ridiculous duplicates that do nothing at all]

In fact, what's funny is that I showed exactly how this follows what JDOOM already does and yet you argue it's inconsistent? So I guess JDOOM is inconsisent*book*

[smite-meister]

The problem is simple: none of you understand or have used the ZDOOM rules to see how this works.
Hmm? http://www.zdoom.org/wiki/index.php?title=TX_START
It does say "no scaling" here.


You do NOT need NTEXTURE. It's like inventing 1994 all over again. Needless, complicated and most of all user and editor unfriendly. A real PIA.

It's easy enough to parse using the appropriate library, and also the only feasible way (presented so far) to have fully extendable texture definitions.


Wonder how I do it then :) Tell you what, run R3Dedit and put some patches in F_START and see what happens. Also duplicate the name as a patch (or texture). All this tells me AGAIN is that you are not reading what I've written [I've said this at least once].

You tell me. I don't have a working Win32 installation, so I can't test R3Dedit.
How would you handle a 4096-byte patch in F_START?

[Ajapted]

I've just updated the Texture Spec, which can be found here:

http://glbsp.sourceforge.net/JointTextureSpec.txt

I've simplified the NTEXTURE definitions (e.g. removed the iwad source type). Another thing changed was the flat scaling.

Regarding libConfuse: I didn't take a close look at it, it just doesn't seem very suitable for this task. But I'm planning to add some sample parsing code to the spec.

[MR_ROCKET]

Ah nice, you guys are back to contemplating code fusion ;)