256x256 textures?

[cycloid]

for the outdoor areas in my megawad i've put together a couple of new cliff-face textures. as an experiment i

1. made them 256x256
2. loaded them as patches into XWE - no problem
3. set the corresponding texture entry to 256x256 - no problem
4. saved, quit, loaded wad in doombuilder - no problem
5. 3d mode, selected cliff, selected texture, pasted, tiled and aligned - no problem
6. saved, quit, tested in prboom 266, cliff texture there, tiled in 256x256, no problem

that's like, bigger than 128x128, and it just worked. is that normal? can i carry on, or was every step some kind of quirk, what about the other engines i'm targetting, specifically:

base port: WinMBF
best port: eternity
compatible: zdoom,prboom,glboom

[Graf Zahl]

All the ports you are targetting support larger textures. There was a limit of 128 in Doom.exe but all advanced portd have fixed this.

[cycloid]

oooh! geez, no one told me before now did they :-)

[XDelusion]

How do you make a Floor texture that is larger than 64x64?

[fiend-o-hell]

Either a) Rip the texture from doom and resize it with a paint program, then load it back into that wad or b) Make your own textures.

Im pretty sure every port supports any texture size.... but know someone out there will say something to the contrare. I just use gzdoom 100% of the time, so its been the longest time since ive touched any other port.

[Graf Zahl]

fiend-o-hell said:

Im pretty sure every port supports any textures (floor or wall) of any size....

Actually not. Some ports still require a flat to be 64x64.

[Fusion]

Actually, i was wondering similarly.. Is any port loaded with Boom capable of this? From what i remember, boom didn't remove this limitation, and it was more zdoom, legacy, jdoom specfic. Elaborate please ;)

[Graf Zahl]

Large flats are a bit of a problem because different ports treat them differently. ZDoom scales anything larger than 64x64 to fit into 64x64 map units but AFAIK other ports do not.
Also, ZDoom can freely interchange flats and wall textures but I can't say which other ports are capable of that. This is a feature that is more likely supported by hardware rendering only ports because it requires a complete rewrite of the texture management.

[XDelusion]

How do you load up an image so that it can be used by the editor as either a flat or texture.

Also still...


...how to make flats larger than 64x64?

[Quasar]

Eternity only supports flats in the following sizes (as of the newest release):
64x64
128x128
256x256
512x512

Anything else will be treated as 64x64 for compatibility purposes, with possibly disasterous looking results.

[XDelusion]

Sorry, forgot I was not in the GZDOOM forums.

[cycloid]

eternity broke (though cant remember the version number, it's not THAT old) my 256x256 texture, made from a patch of the same size had a two-line mini medusa effect where it should have vertically wrapped. i.e. it seemed like it might be wrapping at 258?

[hawkwind]

Risen3d suppports "any" flat size and also interchanged flats\textures.

[Quasar]

This isn't a good place to file a bug report; you're lucky I even saw it. That being said however, are you sure your graphic is a flat?

Flats must be linear blocks, not patches. Eternity does not support drawing patches on floors now, nor is there any plan to add that in the future.

I'll check out the code in the meantime, but I find it unlikely there's an error like that because the flat drawing code uses shifts and power-of-two bitmasks to make itself extremely fast. It couldn't be off by simply two pixels because of this.

[cycloid]

it's not a flat, it's a 256x256 texture, on a wall, made from a single 256x256 path. eternity v 3.3.31 probably. and there are two pixel lines of tuttii fruity where it should vertically wrap them.

[Ebon]

@Quasar: does it have to be 256*256 (65536) bytes long to be recognized as a 256x256 flat?

@Cycloid: does your 256x256 flat have this size as well? if so, then maybe that's how your pic actually looks from a flat point of view! I mean that Doom Eternity is actually reading the "header" of the flat into a picture!

[Quasar]

Yes. Large flats must be the exact size for a raw 8-bit picture lump of those dimensions, or the game engine will fall back to 64x64 drawing for compatibility (some old wads contain larger graphics of odd size that still render properly as 64x64 flats -- I believe hexen.wad falls into this group coincidentally).

Ebon: Proper flat graphics do not HAVE a header. DOOM flats are raw, linear blocks of data. Whatever other ports have added, those aren't DOOM flats. They're more likely non-linear patch-format graphics with columns and posts. Patches have a header on them that contains info like width, height, xoffset, yoffset, etc.

In order to make large flats, it may be necessary to use a paint program that can save to raw format, where a dialog pops up and asks you how to save the data. Paint Shop Pro supports this AFAIK.

Anyways, it sounds like you might have found a bug in the texture engine; either that or this is a limitation of all BOOM-based ports. Does it do this in prboom also, or is it correct there? How about in WinMBF?

[cycloid]

havent tried winmbf but prboom was the first one i tried it in on a whim. will do some experiments tonight whilst packing my beta together

[Joe]

XWE allows you to "convert to doom flat", thus removing the header and suchlike. I used this when testing out large flats and it worked fine.

[cycloid]

ahem:

it's not a flat, it's a 256x256 texture, on a wall, made from a single 256x256 path

and

my 256x256 texture, made from a patch of the same size had a two-line mini medusa effect where it should have vertically wrapped

where, exactly, do i use the word "flat" in those two posts?

[Joe]

Err, true, heh. Well i suppose my post is still sort of valid in respect to Quasar's post, in that it suggests another method for getting the raw image data :P.