tech/stone/concrete texture pack

[Hambourgeois]

Hello all,

I made a bunch of textures that I had been intending to use in something, but life has me too busy. They are obviously very heavily inspired by textures from BTSX, and were made specifically to avoid textures with very obvious tiled elements (i.e. like metal2-7 or whatever range they cover) just because I always find it difficult/limiting to try to work in increments of 32/64 map units and I hate having discrete elements cut before an obvious seam.

Anyway, they are just sitting around so they might as well go to good use. Feel free to take them for whatever!

Creation/Programs Used:

Spoiler

The non-light textures were made with a combination of NeoTextureEdit 0.6.4 (available here: http://sourceforge.net/projects/neotextureedit/?source=navbar) and GIMP (greatly expedited by GIMP's Batch Image Manipulation Plugin, available here: http://registry.gimp.org/node/26259). Light textures were made solely with GIMP.

e: Almost forgot! The .wad was created with SLADE, which was also used to convert the images to Doom's index, since GIMP is very bad in that regard.

Link here <------

What's what:

• hamtextures.wad: .wad file with TEXTURE1 and PNAMES defined. textures are converted to doom's colormap
  
• Ham_RGB.7z: the .pngs imported to create hamtextures.wad, for use with ZDoom, etc. also includes .xcf (GIMP) files where they were used to create said .pngs
  
• and if you feel like untangling the hellscape that is the NeoTextureEdit files, neotextureedit/flat.tgr & neotextureedit/texpat.tgr: source files for the flats and patches, respectively (warning: these files are basically a monument to my disorganization)
  

Demo room screenies (taken in Chocolate Doom):

Spoiler

computer screen detail

combine seamed and seamless elements for wide apparent textures

view of the demo room

wall light detail

ceiling light detail

Unfortunately, that only features a small subset of what I made. I also am assuming that everyone has 7zip these days, but if a ton of people want a .zip of the non-indexed .pngs let me know and I'll throw it in drop box.

[AD_79]

Cool stuff here.

[gaspe]

There are some really nice stuff. Thanks for sharing it!

[Doomkid]

Love the look!

[dg93]

Smexy textures

[Gez]

Hambourgeois said:

e: Almost forgot! The .wad was created with SLADE, which was also used to convert the images to Doom's index, since GIMP is very bad in that regard.

I think it's because SLADE works (by default*) in RGB space, whereas GIMP does its color matching in CIELAB space.

*You can change the way SLADE does color-matching but RGB is what gives the best results for Doom. Plums and others ran some comparisons here.

Anyway, nice textures. :)

[Hambourgeois]

yeah that thread partially informed my decision, but last time i saw it there were only a few of plums posts in it.

i wonder if gimp would give good results if you could similarly select the colorspace used for color conversion. on the other hand, in cases like this where i was mostly converting images output by a different program the batch converting capability of SLADE is probably too attractive from a workflow perspective to not use, so i am glad it is comparatively better.

i'm glad the response is positive so far!

[scifista42]

I suspect that some ports won't be able to find the patch graphics, because they are not in the proper namespace. They should all be between P_START and P_END markers (or between PP_START and PP_END).

Great textures!

[Gez]

scifista42 said:

I suspect that some ports won't be able to find the patch graphics, because they are not in the proper namespace. They should all be between P_START and P_END markers (or between PP_START and PP_END).

Vanilla does not actually make use of the patch namespace markers, despite them being present in the IWADs, so it shouldn't be a problem.

[Hambourgeois]

yeah i was under the impression that really only F_END was an important marker as far as custom textures are concerned?* either way if it is mostly for organizational purposes since i have categorical markers it shouldn't be a huge issue

* i feel like i read on either here or in the SA thread that custom flats use a kind of hack-y trick where anything can technically be "read" as a flat and replacing F_START with a PWAD actually causes problems (hence the use of FF_START), so you specifically only replace F_END. at least for vanilla compatibility. let me know if this is a misconception.

[scifista42]

I know that it's not a problem in vanilla itself, but I was under an impression that certain ports do enforce proper namespacing. I wasn't able to see the custom patches in Smdoom2.wad in PrBoom-plus until I moved the patches into a correct namespace. (see here) I thought that proper namespacing is a necessity to make everything safe independently on source port.

[Hambourgeois]

ok i added PP_START and PP_END, i wasn't really sure what best practice was on this front, so its good to know that patch namespacing is important in some ports.

[Foxpup]

Hambourgeois said:

* i feel like i read on either here or in the SA thread that custom flats use a kind of hack-y trick where anything can technically be "read" as a flat and replacing F_START with a PWAD actually causes problems (hence the use of FF_START), so you specifically only replace F_END. at least for vanilla compatibility. let me know if this is a misconception.

The problem with F_START is that it must replace all the flats, since it starts a new flat list from scratch rather than adding to the IWAD flats. Sprites work the same way (with S_START and S_END), with the added wrinkle that you can't define the same sprite in both the IWAD and a PWAD, so either all the sprites must be entirely replaced (with S_START) or only new sprites added (without S_START) and a DeHackEd patch used to reference the new sprites.

The P*_START and P*_END markers were used by some old texture utilities (not the game itself) to automatically populate the PNAMES lump so that the patches can then be used in textures, however there's nothing stopping patches outside those markers from being added to PNAMES manually. PNAMES itself is only referenced by the TEXTURE1 and TEXTURE2 lumps; modern alternatives such as TEXTURES don't use PNAMES at all.