Questions about texture/sprite limits

Yes, yes, yes, not sure what's the exact limit but I know it's quite big, yes

What are the vanilla limits for these things?

for reference, all of these questions are completely unrelated to udmf and entirely related to what port you're aiming for

I know the answers to some of those questions:

You can use skies taller than 128. I have used 512x512 skies. Now, that is a texture larger than 256x128, but I don't know whether the sky is a special exception to a texture limit of 256x128. I do know that you can make hi-def textures that are then applied in-game as if they were "normal" sized textures.

I don't know if you can make flats larger than 64x64 (other than hi-def), but I know you can make textures larger than 64x64 and use them on a floor or ceiling.

I don't know the size limit of sprites.

I hope somebody will come along with more answers for you.

My mistake. I'm interested in making a texture/sprite pack and I'm trying to think of whether it should be vanilla compatible. 

Simply put, in GZDoom, texture/sprite dimensions don't have any limits low-enough to care about.

I think I'm getting a better idea of what I want to do. It's basically a wad that you could use as a resource for standard Doom 2 projects—more or less a texture/sprite add-on for standard Doom 2 spaceport/city/hell/maybe Wolfenstein themes. What I would like to figure out is whether this should be a vanilla compatible project, or if it's best suited as some kind of pk3 for "fancy" source ports. Some of the things I would like to add, such as new explosive objects, might be hard to do in vanilla, which makes me think I should just go for pk3 and take advantage of fewer texture size restrictions.

57 minutes ago, GoatLord said:

new explosive objects, might be hard to do in vanilla

Depends on how exactly you want them to work like. Or are you still talking just about replacing sprites (of barrels) without any behavior or animation structure changes?

35 minutes ago, scifista42 said:

Depends on how exactly you want them to work like. Or are you still talking just about replacing sprites (of barrels) without any behavior or animation structure changes?

Well, I envision a resource add-on that does not replace any of the original assets, so it would have to be an entirely new thing which has similar behavior to a barrel. Can that be contained in a vanilla .wad without the need for a batch file, or should I just aim for pk3? Also, would objects like a new explodable object be something you could place on the map, like other things?

The only way to have custom things in vanilla is by replacing existing things and animation states. A DEHACKED patch included inside a wad will take effect automatically when playing in most source port, require a "-dehlump" command line parameter in Chocolate Doom, and wouldn't work in vanilla executable - for that, a custom executable would have to be generated from the patch using Dehacked.exe and the wad would have to be played in that executable.

5 hours ago, GoatLord said:

Well, I envision a resource add-on that does not replace any of the original assets, so it would have to be an entirely new thing which has similar behavior to a barrel. Can that be contained in a vanilla .wad without the need for a batch file, or should I just aim for pk3? Also, would objects like a new explodable object be something you could place on the map, like other things?

To make new things that don't replace existing things, you need something like DECORATE. It doesn't have to be in a pk3, but you might as well because as far as I know, any port that supports DECORATE also supports the PK3 format.

I think PK3 may be the way to go. Which sucks for vanilla mappers. Hmm. This whole idea was inspired by the wealth of assets over at Realm 667. Each one is a separate file, so mixing and matching can be difficult. My goal is to use my pixel art and Photoshop skills to create a wealth of new assets that stay in line with Doom 2's themes, that you can just drop into your map, or save into via Doom Builder, without having to mix and match. It's starting to sound like it's going to HAVE to be a PK3.

On 11/3/2017 at 10:13 PM, bzzrak said:

Yes, yes, yes, not sure what's the exact limit but I know it's quite big, yes

The correct answer would be 'no' to everything because none of these features is neither related nor dependent on UDMF. :P

29 minutes ago, GoatLord said:

My goal is to use my pixel art and Photoshop skills to create a wealth of new assets that stay in line with Doom 2's themes, that you can just drop into your map, or save into via Doom Builder, without having to mix and match. It's starting to sound like it's going to HAVE to be a PK3.

Just like map format (Doom/Hexen/UDMF) was unrelated to texture/sprite dimensions, file format (wad/pk3) is unrelated to what you're talking about now.

I guess I'm a bit confused. This idea I'm talking about, what form what it actually be in? I'm pretty sure I'm going to have to find a second person to help me with this, because it's sounding like my area of expertise is going to be the art, and not the compiling of it.

All ports support wad format. Only some ports support pk3 format. There is no port that supports pk3 but not wad. If you want to make something working in vanilla engine, you must use wad format, because vanilla engine supports only wad. If you want to make something working in GZDoom, you can choose whether to use wad or pk3 format, because GZDoom supports both. You never must use pk3. The real problem with your idea in regards to its vanilla compatibility is that it's impossible to add new thing types into vanilla without modifying existing thing types. Not because of file format, but because vanilla engine doesn't support any such feature. It's all about capabilities of the engines, not about the files that you give to these engines to process.

55 minutes ago, scifista42 said:

It's all about capabilities of the engines, not about the files that you give to these engines to process.

teeeeeeechnically it is, considering DECORATE, DDF, EDF, etc. are the only ways to define wholly new actors without overriding built-in actors or states, so the lack of support for any of these files would mean that a port can't support what he wants

22 minutes ago, Arctangent said:

support for any of these files...

...is a capability of engines.

I guess it comes down to whether or not the average person who would be interested in a texture/sprite resource would be like to map for vanilla, or something more advanced. I suppose I could make a wad with a DECORATE patch, or something in that direction, that would ensure compatibility across all ports?

DECORATE no, it's ZDoom specific. DEHACKED basically yes, it's the standard and only way to implement game behavior changes with widest possible compatibility - although, still, exploiting some of DEHACKED's more obscure features can lead to different behavior in different ports.

What are some of these "obscure" features?

Hitscan/projectile weapons with unlimited ammo, chaingun/plasmagun muzzle flashes, projectiles with zero duration first frame, the two unused state properties, misc health/armor related properties, certain state codepointers being used on things with vastly different stats than the codepointers were made for, probably others.

@GoatLord To the average Doomer, texture packs are generally vanilla compatible (presuming they're not HD) but new Things/Actors are just expected to be Decorate, and thus (G)ZDoom only.  While you *could* try to make them in Dehacked, it's just pretty unexpected at this point.

If you did want to make a bunch of new Things for people you to use that would be amazing! Doom can always benefit from more decoration and things to interact with.

It's sounding to me like I'm going to need a second person on this. I'm definitely not well versed enough to make a pk3. 

21 minutes ago, GoatLord said:

It's sounding to me like I'm going to need a second person on this. I'm definitely not well versed enough to make a pk3. 

https://zdoom.org/wiki/Using_ZIPs_as_WAD_replacement

They don't have to be in pk3, nothing on Realm667 is as far as I know for example.  It's just a neater, more modern format than WAD.  It's only needed for very advanced things like models.  If you're just doing sprites/textures then WAD is fine. If you're comfortable using Wads, just use that.

2 hours ago, Bauul said:

They don't have to be in pk3, nothing on Realm667 is as far as I know for example.  It's just a neater, more modern format than WAD.  It's only needed for very advanced things like models.  If you're just doing sprites/textures then WAD is fine. If you're comfortable using Wads, just use that.

I agree. Nothing you are wanting to do requires a pk3. What you want to do does require DECORATE, but that can be in a wad just as easily as a PK3. The page I linked earlier describes the advantages of the pk3 format, as well as how to do it, but it is totally optional.