Jump to content
Search In
  • More options...
Find results that contain...
Find results in...

ukiro

Members
  • Content count

    265
  • Joined

  • Last visited

About ukiro

  • Rank
    That's Bjorling with two funky dots over the o

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. ukiro

    [WIP] Eviternity - A Boom Format Megawad

    This is one project that is using my texture set ahead of the public release (and honestly probably the most ambitious one), but it’s not the only one. Whether any others come out in time for Doom’s 25th birthday is uncertain, so I won’t announce anything. But hopefully this and/or some others make it in time so the release of the textures is accompanied by some examples of expert use. Eviternity is Boom and there’s also vanilla and UDMF stuff in the works. I’ll start a separate thread about the textures later in the fall I think.
  2. You didn't find the yellow key on map12? Considering where the shot is from, you were so close!
  3. ukiro

    PNAMES/TEXTURE1/2 sucks.

    This also reminds me that negative Y offsets are not supported in vanilla (Patched Up uses this frequently). Are there any source ports, other than chocolate I guess, that retains this bug?
  4. ukiro

    Things about Doom you just found out

    Well, European mains hum. In the US it'd be 60.
  5. ukiro

    Post Your Doom Picture (Part 2)

    Why did I do this
  6. ukiro

    PNAMES/TEXTURE1/2 sucks.

    One more note on ANIMATED vs ANIMDEFS: The latter, being the zdoom version, brags about additional features over Boom's ANIMATED: But it is in fact perfectly possible to reference an ANIMATED texture in a SWITCHES definition in Boom: https://imgur.com/9oZ1P7k Edit: But not to have the transition itself be a separate animation, which is perhaps what they're referring to.
  7. ukiro

    PNAMES/TEXTURE1/2 sucks.

    Managing a community project where participants provide their own resources in all imaginable formats and naming conventions probably highlights the challenges of the format better than anything I've ever done. That said, I do have experience juggling large sets of assets, and have some recommendations for how to deal with current limitations, and some thoughts on possible future formats. In defense of patches I will not defend PNAMES as a lump (more on that later), but rather patches as a means to create textures. In 1993 I'm assuming it was primarily motivated as a way to save on memory and disk space, but 25 years later it's still neat to be able to combine things to create new textures without adding any new pixel data. Additionally, this ensures consistency across textures that use a certain trim, for example. It's easy to accidentally alter some setting that triggers a slight variation when exporting multiple textures from whatever source you're working with, and if there's something I want to fix in that trim I only have to do it once, not in all its instances. For a true 3D engine like Quake and onward, it's not necessary to do this—You can merely chop up your brushes to create the blend of texture elements that you want. The additional support for rotating and scaling textures makes patch based textures even less useful, and modern engines with proper normal maps will ensure your shadows from rivets and other bumps in the surface are accurate regardless of rotation. Doom however doesn't have any of that, so while you can chop up a line to create vertical columns of different textures and even to squeeze or extend the width of a texture with some careful aligning, vertically you're often stuck. A sector with ceiling and floor of the same height allows you to use upper and lower texture rather than middle in order to combine two, but if the lower texture of a ledge needs a trim, you're out of luck. Because of these constraints in Doom I have personally opted to divide my textures into patches based on how they are segmented vertically. A 128x128 texture with four 32px wide columns of support beam will be a single patch, since I can always just make a 32px line if that's all I want to use. But the horizontal version with four 32px tall bands of the same support will be four patches, so that I can create combinations with other materials without adding more pixel data. Lastly, a drawback of this approach. In my avatar here, the gargoyle face casts a shadow on the iron pentagram behind it, which in turn has a little shadow onto the wood planks. Since we have binary transparency for patches—a one bit alpha channel, essentially—I can't create these delicate shadows using patches. In the IWAD textures I feel the switches suffer a bit from this, for example. So personally I have opted to be somewhat lenient with my reliance on patches, rather than striving for maximum efficiency and modularity. How to make a texture WAD Assuming you will want to be BOOM compatible, you will need to use the TEXTURE1 or TEXTURE2 lumps in conjunction with PNAMES. I've used most tools for this over the years, and Slade 3 is by far the easiest and most stable. So while you kids have it easy, it has some weird behavior. I won't write a full tutorial here, but the basic steps I use seem to work consistently for me. As of this post my texture WAD has 3485 lumps and TEXTURE2 has 1623 textures, so I must be doing something right. Prepare your assets as much as possible outside of Slade. Make sure you are in the correct palette, and that the format is an 8 bit bitmap. As a legacy from earlier days of Doom editing I use the BMP format but 8 bit PNG works just as well. Also make sure pixel dimensions are correct, so no 128x129 images or similar errors. Basically I never do any recoloring, palette conversion, or editing in Slade. Don't import textures/patches into the main lump list. Instead, go to PNAMES and use the "New Patch from File" button. Make sure you are 100% certain what the patch name should be, as changing it later can be problematic. Staying consistent with this approach have lead me to only have a very small number of issues with patch references, and in those cases it was always human error and not because of the format or tools. Create your textures using your new patches. I use TEXTURE2 so there are no IWAD textures clogging up the view, allowing me to dodge the alphabetical sorting issue Jimmy mentioned. But I also prefix every texture name with O (no IWAD textures start with O) so even in an alphabetical list with IWAD + OTEX.WAD, it's easy to know what's what. Convert the image format to Doom's own. Before you can save your new textures into the TEXTURE1 or TEXTURE2 lump, you need to convert them to the correct image format. (You can do this before the texture creation step above if you want, but this is the order I use.) If you imported multiple patches, select them in the main lump list view and click the "Convert Gfx To..." button that appears in the lump view pane. "Doom Gfx (Paletted)" should be the default choice and you can just click "Convert All" and be done. But if you only had one patch, it gets trickier: You need to right click the lump and select "Graphic" —> "Convert to..." to invoke the same view, and after conversion you need to deselect the lump to be prompted to save the changes to it. This is unnecessarily convoluted and inconsistent, something I hope a future version of Slade could fix. Save TEXTURE1/2 before you save the WAD. That there is a difference between saving of lumps inside the WAD and then saving of the WAD itself is not immediately obvious to all users. Bonus: I try to keep my lumps in alphabetical order. Sorting them gets insanely slow once you're in the thousands, but somehow it's MUCH faster on MacOS! There are some other very minor differences versus the Windows version too, and in my opinion they're almost all in favor of the mac version. Don't forget FLATs have a different graphics format from patches and sprites. So when you have imported them (which is done straight into the lumps list view and not via "New Patch from File" since FLATs don't use patches), make sure you have the correct setting for Gfx conversion. Suggestions for a future format I'm trying to think of things we could theoretically implement in ports that value backwards compatibility, which means we can't really change the level format and it should remain patch based. Kill PNAMES: It seems logical to do away with PNAMES as Jimmy indicates: Just referencing patches by lump name should be the way to go. Not sure how easy it will be for that to coexist with the IWADs which obviously retain the vanilla structure. Categories: In a PK3 you can have subfolders for textures themes which helps a lot when browsing large texture sets in the editor. A way to achieve something similar in a system that uses a patch based texture definition list would be very welcome, and ideally it should allow for multiple categories. I guess it'd be easiest to create a texture category definitions lump that references textures rather than having a few extra bits per texture (as the latter would break the map format I guess), but it'll be important to make this robust enough that if a texture is removed or renamed, stuff doesn't crash. Names: Texture name lengths have implications in the level format too, so while more than 8 characters would be very useful, it's not a battle I'll be fighting. Make stacking resource WADs less painful: In theory one resource WAD could use TEXTURE1 for its own as well as the IWAD's definitions, while another use TEXTURE2 and only defines its own textures, allowing them to be run together for maps that use textures from both. In reality this is broken in Boom ports, and even if it worked it'd limit us to two sets. Allowing any WAD to define its own textures might lead to naming conflicts at some point, but if the level is from X.WAD then it should look for its texture references in X.WAD before looking in Y.WAD or Z.WAD. So if I have defined a texture called DOOR9000 in all three WADs, the one in the same WAD as my level would be used. If the levels are separate from all resources, it should go by loading order I guess. There are use cases where you'd want to reference a patch from a different WAD, such as altering an IWAD texture or wanting to avoid duplicating pixel lumps, but I wonder if that gets too messy in this scenario? ANIMATED / SWITCHES: Currently, even though GZDoom can load textures accumulatively, it only loads the last ANIMATED and SWITCHES lumps. A way to stack these would be very helpful, with a last-loaded priority for resolving conflicts. Testing Boom here is pointless as it can't even handle TEXTURE1/TEXTURE2 combinations in separate WADs, and I'm aware GZDoom uses ANIMDEFS. (...Which might still not be possible to combine across several WADs loaded at once?) No fancy shit: As an old timer I don't recommend messing with the resolution or bit depth, nor with texture rotation/mirroring or alpha channels. Part of the charm for me is that Doom is Doom. If you're in the camp of people who want to combine PBR textures with Doom enemies, weapons, sounds and behavior (well, an approximation of it at least) there's gzdoom and you don't need to care about this thread really. Palette woes: Even if we avoid high resolution, 24 bit textures in this future format, we might encounter situations where two different WADs define their own palettes. This currently means at least one set will look wrong in game, but since we don't need to worry about VGA display modes these days, we could render each texture based on the PLAYPAL in its parent WAD, and if no PLAYPAL is present we assume IWAD. This would allow BTSX and Ancient Aliens textures to coexist in a software renderer, I guess. I'm not sure whether there are pitfalls with COLORMAP, where for example BTSX defines a purple range as fullbright. But I think it'd work?
  8. ukiro

    GZDoombuilder slow down on big maps

    Yes, there's something going on with large amounts of lines, it's like it's having to shift an array or something and it does so in a very slow way. Another, related performance problem: Using the ellipse tool also slows down tremendously when there's a lot of other linedefs. But it seems worse when drawing in the void than when drawing inside an existing sector, so for this particular problem I can draw inside a big square sector and then delete the outside bits once I'm done.
  9. ukiro

    what are you working on? I wanna see your wads.

    Being an old fart I always did curved stuff by hand, but decided it's time to learn the modern tools. So here's a curve exercise:
  10. ukiro

    Post Your Doom Picture (Part 2)

    Fractals? Oh god the nodes, they hurt
  11. 1.1 is what a piracy-savvy kid at my school gave me in early February 1994, and what I played for a very long time as I didn't know there were updates. I'm generally not a fan of collecting or memorabilia these days, but I'd probably pay pretty good money for that set in nice condition.
  12. In general I don't recommend the apps geared towards 'pixel art' unless you're going for an aesthetic that is pre-doom, but some people are making really nice stuff in that style (like Fuzzball, recently). And it's VERY useful to learn the fundamental principles of shading and how to give the illusion of different types of surfaces and materials from the ground up this way rather than starting with photo based sources. When the pixel art craft started to die out in the late 90's we had some of the worst game art in the history of gaming, because you got kids coming in without that background that just threw 90 photoshop filters at blurry source materials. Learn the basics! That said, I do almost everything in Photoshop: A few smaller things are done in illustrator but that's rare. This would be my #1 recommendation but it's a very complex piece of software. I've had a license since 1996 and I still learn new tricks every week. For maximum authenticity you could use some sort of deluxepaint clone or derivative but I think it's hard to justify these days. If you're good at 3D it could make sense to model some geometry and render that out to Photoshop. I have dabbled very briefly in Quixel but decided against buying it for now. Unlike Photoshop Gimp is free but arguably not quite with the same breadth of tools. Some people seem to like paint.net but it's much simpler (which I guess can be part of the allure).
  13. ukiro

    Post Your Doom Picture (Part 2)

    It's from my texture set which will be released publicly for Doom's 25th birthday. Until then, some select people have access so that the textures can be accompanied with some nice levels demonstrating good use.
  14. ukiro

    Commissioning mods?

    My texture WAD currently has maybe 250 distinct materials (not counting recoloring or pattern variations) for close to 1500 textures in total. I expect on average I spend 2-3 hours per material from start to all being finished with all pattern variations, chopped up into patches, and added to the WAD. (Sometimes this number is 20 minutes, sometimes it's 20 hours.) This does not account for gathering materials (when I'm in a new city I often spend hours walking around taking pictures of stuff I can use) or for when I decide a texture isn't up to the quality I want so I re-do it from scratch (this happens quite often lately). So a lowball estimate is still that I've put 600-700 hours worth of work into the WAD as it stands now. If someone wanted to pay me $15 an hour for that, almost $10k, I'd still say no. To give a buyer/financier exclusive rights to it, they'd have to pay way more. $50 per hour, a reasonable freelance rate, I'd consider.
  15. ukiro

    kmetal 2018

    There’s a learning curve of course, but I’d strongly recommend taking a few hours to get up to speed on gzdoombuilder. (I used to be a wadauthor guy too.)
×