Randy: Texture/Flat preference ?

[randomlag]

I meant as "regular" behavior. I wasn't really thinking about 2S. His sentence was phrased with a double question: "Should they tile vertically or not, like regular wall textures?"

I see now that he meant as applied to 2S, but that's not the way I interpreted

[HotWax]

[EDIT] Whoops, didn't see the 2nd page button. You may safely disregard this post. [/EDIT]

FLATs should tile vertically, otherwise there will be way too many other problems to worry about.

Even on the middle of 2S lines?

I certainly agree that they should tile on 1S lines and lower/upper sidedefs, but not tiling/repeating on the middle of 2S lines is standard for regular textures. I seen no reason why flats should behave differently to traditional textures when being used as textures.

Nor do I. If you really need a 2S line to appear tiled, you can always copy the flat to a patch and make a texture out of it to the height you need. This allows you to do it either way, rather than being stuck with all your 2S lines tiling.

[Cyb]

flats used as textures are converted to textures, thus they behave exactly as textures (64x64 textures).

[randomlag]

[Nor do I. If you really need a 2S line to appear tiled, you can always copy the flat to a patch and make a texture out of it to the height you need. This allows you to do it either way, rather than being stuck with all your 2S lines tiling.

You gotta read all the posts before you carry on, otherwise you are continuing a needless track.

[randomlag]

flats used as textures are converted to textures, thus they behave exactly as textures (64x64 textures).

To clarify, we are talking about high-res FLATS, not stock ones. Is this from actual testing or misinterpreting?

If Randy is making high-res FLATS 64x64 (?), that would not make much sense and partially defeats the very reason for even doing any of this. Almost a waste of time, since then it would have been much better to just stick with textures (pnames, sprites) only since FLATs can be instantly converted to textures. Then one doesn't give up the high-res aspect.

[randi]

The scaling of flats is done during the loading process. If you have a 128x128 flat, then it's going to be scaled to 64x64 no matter where you use it. This is exactly the same as specifying a 16,16 scale for a 64x64 wall texture. The renderer has no idea where a particular image came from; it doesn't care. It's the image's responsibility to load itself. As far as the renderer is concerned, there is zero difference between a flat and a wall texture. They are stored differently on disk, but both get converted to the same format in memory.

[HotWax]

Hmmm, I agree with RL on this one. If you have one behavior for textures/patches/sprites and another behavior for flats, that could be a bit confusing. What if the editor wants to use a different scale aside from 64x64? Do they have to use a different scale system for flats only, or recalculate the current system based on the fact that a hi-res flat is already being scaled to one degree or another (based on the image resolution), or can they scale it at all? The convenience of being able to use the same image everywhere is kinda negated by the fact that you need to treat them as different resources anyway.

IMHO, hi-res flats should be scaled as-is by default, just like textures, and then optionally be scaled down to 64x64 (or 64x128, or 128x64, or 32x32, or whatever) as a FLAT, and then the same behavior should be done on the walls. I understand that this would break compatibility with some older maps though.

Eh, just had a thought. With this system it seems more likely that people will tend to use textures on the floors/ceilings more often than vice versa anyway, so maybe this is just a moot point.

[randomlag]

The scaling of flats is done during the loading process. If you have a 128x128 flat, then it's going to be scaled to 64x64 no matter where you use it.

I can see why you did this (it's already there and easy to do), but not very useful (and in addition confusing ...).

To use BUILD as an example (since that's what inspired you?), you don't run into all sorts of graphic sidenotes (we already have enough of those in DOOM). IOW that's the kind of unfriendly extensions that cause nothing but endless questions and confusion.

The natural tendency is to believe that the FLATs will be actual size, thus that is what should be done. Just split up/add some code in the load process to convert to actual size - which you also know otherwise the flats could never be expanded to full size.

If someone wants 64x64, they can easily convert to a texture.

[Graf Zahl]

The scaling of flats is done during the loading process. If you have a 128x128 flat, then it's going to be scaled to 64x64 no matter where you use it.

I can see why you did this (it's already there and easy to do), but not very useful (and in addition confusing ...).

I disagree. From an editing standpoint it makes a lot if sense.
Imagine the following:

You have a 64x64 flat that you both use on walls and floors. After finishing your level you decide to replace the flat texture with a hi-res version. If the actual size was used on the wall and not 64x64 you'd be screwed because the level no longer looks right.

[Sphagne]

Good point, it is the best behaviour, the way it is, the question is when we can use these features, I am getting very high.

[Enjay]

I think I like the idea of flats remaining scaled when they become textures too, mainly for the reasons Graf Zahl cites.

If you've included a 128x128 flat, it is going to behave as a 64x64 hi res flat. IMO it should always behave as a 64x64 hi res graphic - be it on the floor or on a wall. It's simply consistent. Having the same graphic, with the same name, behave differently depending on where you put it would be confusing IMO. A difference in behaviour should involve the user at some point saying I want this to look different on a wall...

If someone wants 64x64, they can easily convert to a texture.

That's true, but it is equally true that if someone wants the hi res flat to appear as 128x128 (or whatever) on a wall, they can convert to a texture to achieve that too.

[randomlag]

That's true, but it is equally true that if someone wants the hi res flat to appear as 128x128 (or whatever) on a wall, they can convert to a texture to achieve that too.

That's exactly what I said and for exactly the opposite reason

The bit about replacing FLATS so they always stay 64x64 is not cogent. Ignoring the assumption that a person used them on floors and walls (contrived argument) all you have to do is make sure the new FLAT is the same size for god's sake. All this is in the realm of USER control (since they don't exist unless the user created them). If a person is really going for hi-res walls, then FLATS are not the way to go anyway - too little control right now.

Even if the original argument were true, it's trivial to just replace the wall (or floor) names with a search/replace and use new names. One has to think of ALL the editing options available.

Besides that, I don't agree at all with always 64x64 hi-res FLAT default on floor to begin with. If that made sense then the textures used on the floor should be 64x64 too spinning a similar argument - what if I replace the floor (real) texture with a FLAT?

Just think some more about the editing argument you and Graf presented in the actual context of making a level. There is no problem the level designer is presented with that isn't instantly solvable. He/she is the one making all the graphics.

The issue is probably driven by an earlier decision I also don't agree with: that hi-res FLATS (on floors) default to 64x64 since all that does is make is MORE work to get them to stretch out to the actual size desired - one big reason people like them (not just for better resolution). This illustrates the reverse logic used by others, LEGACY did it just the opposite, so certainly it's not a technical issue.

Because of the other changes with the textures on floors this is now not difficult AND it makes it more consistent in how a person starting out would tend to think it would work - despite the arguments. It really depends on what side you start from, what you assume and what is more important doesn't it

If you really want to allow for flexibilty, then FLATs need to have more control at level loading time. This addresses both types of opinions.

[Xaser]

All this is getting Super Confusing!

I guess I'll stick to using textures the traditional way...

[Graf Zahl]

That's true, but it is equally true that if someone wants the hi res flat to appear as 128x128 (or whatever) on a wall, they can convert to a texture to achieve that too.

That's exactly what I said and for exactly the opposite reason

The bit about replacing FLATS so they always stay 64x64 is not cogent. Ignoring the assumption that a person used them on floors and walls (contrived argument) all you have to do is make sure the new FLAT is the same size for god's sake. All this is in the realm of USER control (since they don't exist unless the user created them). If a person is really going for hi-res walls, then FLATS are not the way to go anyway - too little control right now.

Even if the original argument were true, it's trivial to just replace the wall (or floor) names with a search/replace and use new names. One has to think of ALL the editing options available.

Besides that, I don't agree at all with always 64x64 hi-res FLAT default on floor to begin with. If that made sense then the textures used on the floor should be 64x64 too spinning a similar argument - what if I replace the floor (real) texture with a FLAT?

Just think some more about the editing argument you and Graf presented in the actual context of making a level. There is no problem the level designer is presented with that isn't instantly solvable. He/she is the one making all the graphics.

The issue is probably driven by an earlier decision I also don't agree with: that hi-res FLATS (on floors) default to 64x64 since all that does is make is MORE work to get them to stretch out to the actual size desired - one big reason people like them (not just for better resolution). This illustrates the reverse logic used by others, LEGACY did it just the opposite, so certainly it's not a technical issue.

Because of the other changes with the textures on floors this is now not difficult AND it makes it more consistent in how a person starting out would tend to think it would work - despite the arguments. It really depends on what side you start from, what you assume and what is more important doesn't it

If you really want to allow for flexibilty, then FLATs need to have more control at level loading time. This addresses both types of opinions.

I'd agree - if (and only if!) hi-res flats weren't scaled when used as flats. Having them scaled when used on floors/ceilings and not if used on walls is probably the worst thing that can be done because this WILL cause problems for mappers because it's simply inconsistent. (Ok, I'm repeating myself...)

[Enjay]

I guess I can see both sides of the argument, and I'm not really bothered which way it turns out. If it goes the way currently planned, I can make a bigger texture if need be, if it goes the other way, I can make a hi res one, again if need be. Essentially the same task required, so ultimately it's pretty immaterial from my POV.

It really depends on what side you start from, what you assume and what is more important doesn't it

I suppose that's really the critical thing. I'm used to all flats being 64x64 even if they are actually a bigger graphic, so I'd expect them still to be 64x64 if I used them on a wall. That's my personal starting point, and it colours my opinion and preference. I'm not sure what I would expect them to do if I were coming at this for the first time, but if someone were to tell me they expected flats to be their original (unscaled) size when used on a wall, I'd happily believe them and understand why they expected that.

I suppose the more significant thing to come out of this is that people will now start to make WADs for Zdoom where there are no flats or textures as such, just a bunch of included graphics that can be used anywhere (put in a WAD as patches but without pnames entries I suppose). No confusion over whether they are flats or textures, they're just graphics.




Hmmm, thought.... If people are just including graphics like that, will they be able to be used in lumps such as ANIMDEFS as animations or switches, or will those still need to be clearly defined as textures and flats?