[Feature Request] High res textures?

Nuxius · Post by **Nuxius** » Thu Sep 15, 2005 3:09

That guy has some serious problems.

Glad to know I'm not the only one that realized that. :lol

TheDarkArchon · Post by **TheDarkArchon** » Thu Sep 15, 2005 18:53

He obviously just wants ports to be as close as possible to make DeePSea's development easier. (Also see the old GL nodes issue)

Post by **Graf Zahl** » Thu Sep 15, 2005 19:26

Sigh!

I really didn't want to start a discussion about his attitude. I'd rather like to see some opinions about hires textures as a base for discussion. Which methods do you prefer?

-Deep's sugggestions
-HIRESTEX
-or something else

What I'll add for sure is a HI_START/HI_END section that serves as an automatic hires texture replacement. Any texture in there will be used automatically by the GL renderer in place of a texture by the same name in any other section. The software renderer will still use the lo-res textures instead of course.

BetaSword · Post by **BetaSword** » Thu Sep 15, 2005 23:12

I personally prefer HIRESTEX, as I find Deep's way of doing things waaaaay more compicated than it should be. And frankly, if it can be made easier, it should be.

Now, this HI_START and HI_END things that you are adding... Will those act like TX_START and TX_END, except being automatically Hi-res? And if so, will they all be scaled exactly the same, or just according to what's in the HIRESTEX lump?

Post by **wildweasel** » Fri Sep 16, 2005 0:00

Can HI_START and HI_END be used to create scaled flats? I may convert my project, The Vision, over to GZDoom.

Post by **Graf Zahl** » Fri Sep 16, 2005 0:57

HI_START/HI_END will only be used for replacements, that is, there has to be a regular texture with the same name which specifies the internal size. You can replace normal textures, sprites, flats and TX-textures. The only problem will be duplicate names (as STEP1 and STEP2 in Doom.) but for that one special case I don't think it's worth to complicate this.

If you want new exclusive hires textures it won't be of much use because you can't specify the scaling factor so the only means to do it is through HIRESTEX (or TEXTUREx if you like.)

MartinHowe · Post by **MartinHowe** » Fri Sep 16, 2005 12:37

Graf Zahl wrote:HI_START/HI_END will only be used for replacements, that is, there has to be a regular texture with the same name which specifies the internal size. You can replace normal textures, sprites, flats and TX-textures. The only problem will be duplicate names (as STEP1 and STEP2 in Doom.) but for that one special case I don't think it's worth to complicate this.

How about this: HT_START/HT_END, HS_START/HS_END, HF_START/HF_END and HX_START/HX_END for (respectively) textures, sprites, flats and TX textures?

Also, can anybody point me to a good introductory level reference (i.e., not the Wiki necessarily; I need something with an overview for total n00bs) for high-resolution textures and the lumps that control them? I take it these different methods being referred to are from different source ports, but would like to know more.

Post by **Graf Zahl** » Fri Sep 16, 2005 13:08

I don't see any need for different hires namespaces. In Doom1 and Doom2 there are exactly 2 collisions, in Heretic, Hexen and Strife there are none at all. I think one can live with the fact that in this particular case some special handling by the mapper is necessary but I don't want to blow it out of proportion. One namespace is enough.

You need documentation? There isn't much to say. If you just want to replace a texture dump it between HI_START/HI_END and the engine will take care of it.

For new hires only textures you need the HIRESTEX lump. For each texture defined there you have to add a line:

define texturename width height width and height specify the size in world units the texture is scaled to.

The graphic has to be put into the WAD outside any namespace.

So far the only port I took something from is ZDoomGL. All the others are mostly out due to a completely different approach to maintaining data - preferring to store the data outside the main WAD - which really goes against my wish to keep the distribution simple. The end user really shouldn't be bothered with stuff like this so I'll keep my all-in-one-WAD approach.

MartinHowe · Post by **MartinHowe** » Fri Sep 16, 2005 13:24

Graf Zahl wrote:I quite agree. DOOM is fundamentally a namespace-oriented engine and that makes things so much simpler.

Having to have separate directory hierarchies and such like that is a pain; one file (the PWAD) is better.

That's the point. I really don't understand what's so great about complicated directory trees. There's no need for it and the few new types of resources (e.g. models) that have to be added yet are certainly doable inside the WAD. In the end they only shift a lot of the burden to maintain the data from the mapper to the end user - hardly a consumer-friendly method. I prefer to start a WAD by clicking on it so that it runs.

It's really too bad that it's too late for a unified approach here.

Doomsday is completely built around DED and a thorough circumvention of the WAD format that it hardly serves as a guideline - and Vavoom is organizing its data in a fashion that is completely tied into VavoomC. So what should I do once I add model support? It's impossible to keep compatibility with these engines unless I go their way completely. BUt then I'd have to inherit all the problems that come with it.

Also, the "virtual directory" hacks that some engines that use to allow the inclusion of a directory hierarchy in a (all-in-one) PWAD are quite something - doable, but messy.

Since the namespaces essentially serve as directories inside the WAD I don't see any need to add something like this. Although I wouldn't mind to use .ZIP as a substitute - especially when model support is concerned. But then the .ZIP had to be a complete replacement of the WAD, not just another resource file that has to be taken care of.

BetaSword · Post by **BetaSword** » Sat Sep 17, 2005 8:57

Graf Zahl wrote:The graphic has to be put into the WAD outside any namespace.

Forgive my ignorance, but does that mean the graphic to be scaled needs to be outside of TX_START/TX_END or any of those other markers?

Post by **Graf Zahl** » Sat Sep 17, 2005 9:42

Exactly. It is like the titlepic for example.

Although I have decided to hold HIRESTEX back for a while until I know the outcome of that discussion over there at Newdoom. If we can agree to something usable there I will use that in favor of HIRESTEX. Don't worry. That doesn't mean the feature will go away. But if it can be done by a means that is more widely accepted everyone will profit from it.

timmie · Post by **timmie** » Tue Sep 27, 2005 9:33

God, that thread over at Newdoom is one of the main examples of why I'm taking an extended break from ZDoomGL. My head hurts after reading that shit. deep is a retard, I think. He likes to use big words to make himself look smarter, too, I noticed.

Anywho, GZDoom is looking pretty awesome so far. I'll probably use it as the base of the next iteration of ZDoomGL. Also, if you need any information on ZDoomGL's shader system, just fire an email my way. It's actually not too complicated a system.

BetaSword · Post by **BetaSword** » Tue Oct 04, 2005 8:33

Eh, while I'm fine with everyone working out some sort of standard that can be used in every source port (that wants to, that is), I also kinda wish everyone would just make up their minds so we can finally be able to use hi res textures more easily. Personally, I think the last such way posted in that NewDoom thread,

Originally Posted by Ajapted
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).

would work rather well. But of course, I'm no expert on this, and could only toss in my opinion as to ease of use from the editting perspective (something that still should be kept in mind for this).

Post by **Graf Zahl** » Tue Oct 04, 2005 9:12

As long as you use 8 bit PNGs there's nothing to keep you from using TEXTUREx to define your textures.

BetaSword · Post by **BetaSword** » Tue Oct 04, 2005 17:56

Yeah, I know that, but I always found that to be an incredible hassle, and was only ever able to pull it off with DeepSea (something of which I'd rather keep my use of as minimal as possible). But yeah, as long as something is eventually worked out, I'm fine waiting.