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

ukiro

Members
  • Content count

    288
  • 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

    : That exact setup won't work since Eviternity requires complevel 11, meaning MBF compatibility. More on the difference between Boom and MBF: https://doomwiki.org/wiki/MBF
  2. ukiro

    [WIP] Eviternity - A Boom Format Megawad

    There are levels and areas in Eviternity that push Boom format levels rather far, and an older computer might struggle. I think my map in particular might cause some problems, but for the most part I think you should be fine.
  3. You could have MAPINFO override the MBF sky transfer and point to a different texture that has a baked-in offset that caters to GZDoom. I'm painfully aware of how stupid this is, but at least it's sort of a solution?
  4. GZDoom sky rendering is broken You can add a MAPINFO to set different parameters for that engine.
  5. I ended up focusing on textures instead. I needed a creative outlet and wanted it to be Doom, but since the very beginning I have been tripping myself up by setting insane expectations when it comes to mapping. I've said this before: I was slotted to do Memento Mori II map01, but failed to deliver. So this mappers block hell started in 1996, and I have not released a level since 2000. Watching Dragonfly stream his mapping sessions has been interesting, as he has a fascinating intuition for preserving creative momentum. Embracing "good enough" rather than "every sector should be worthy of a Nobel price" is a big part of it. For my textures I have an endless list of requests and themes I need to do, but I often just make yet another sky or more corroded metal or more bricks simply because it comes easier for me and I'd rather get something done than sit stuck in front of what feels like a punishing chore. Ultimately, doing something, even if it's not Teh Bestest Evar, is what should be embraced. One last thing: If a texture (or part of a level for that matter) doesn't feel quite up to my standard I often move on from it rather than stay and fight it. It's often easier to come back to something later and see its potential than to try to get it to perfection in one single go. And maintaining a constantly output will make you better at whatever it is you do.
  6. Today marks 50 days to release. While I'm scrambling to wrap everything up, here's some additional info, with assorted screenshots. As stated, the set WILL be given a free-for-all sort of license soon enough, but I'll let the first period post release be sort of a public beta phase. I'm still discovering little tiling issues etc and want that ironed out before I completely release my grip on this. There will also be feedback around needs for "texture X with a trim from texture Y" etc, and it'll be nice to get some more of that in before restrictions are loosened. A custom COLORMAP lump might be useful since I do a lot of stuff with orange, pink and yellow that the vanilla COLORMAP doesn't fade very gracefully. Undecided still on whether to include this, as people might want to make their own and I don't want to discourage that. Untitled map by Scotty. He's boosted light levels around the orange to avoid the IWAD COLORMAP butchering the texture. I'm approaching 2000 texture entries and 1000 FLATs. Some of this boosted by multiple frames in animations, but it's still a decent chunk of stuff. In total I've probably made around 6000 textures and 3000 FLATs, but I try to filter very heavily for quality and consistency. Some words on how I made these With Otex I’ve strived to capture that original DOOM art vibe. But the inspiration comes from elsewhere too: I’ve opted to borrow styles and techniques from later Adrian Carmack game art rather than from Raven or 3D Realms games, as the latter were either more cartoony due to being entirely hand drawn, or less polished photographic sources. I’ve also mostly avoided 3D modeled source material. All of those styles are fully valid for texture set, just not what I personally chose to pursue. PHOTO SOURCES To achieve the grit and organic feel that the original textures have, many (but far from all!) are in some way based on photos. This is also the case with many of the IWAD textures, and I have deliberately tried to stay true to them in terms of vibe. Too often, I find photo based textures made by the Doom community to be poorly adapted to Doom's resolution and palette. I find that to make photo sources work well it's important to do all scaling very carefully to maintain detail while avoiding artifacts, to keep contrast quite low in each texture without causing banding, and to exercise extreme care with palette utilization. Many source photos are my own, while others are stuff I've collected from the web over the past two decades. Had I been a professional making a commercial game I'd have kept good track of sources and usage rights, but this has been more of a guerilla effort and I've thought of this as visual sampling. (Notably, it seems even id didn't have usage rights to all of their sources!) That said, there's also plenty in here that is hand drawn from scratch, and hopefully it'll be a bit tricky to tell what is what, at least in some cases. Again, I'm aspiring to achieve the same overall aesthetic as the vanilla assets, where it's often hard to say what is based on a photo and what isn't. Eviternity map by Joshua "Dragonfly" O'sullivan. This project uses a modified palette to desaturate the blue range. Mostly (but not exclusively) photo sources here, but all heavily edited and overpainted. DITHERING Dithering was very rarely used in any vanilla assets so I’ve avoided it almost entirely, with only a small set of exceptions. It can look good on occasion, but I find that too often it looks overly noisy at DOOM’s texture resolution and with its bold palette. You could get away with more of that in the far more subdued Quake 2 palette. Texture filtering on GPU rendering is almost a must to make dithering look good but DOOM should be played without texture filtering in my opinion, so that is what I’ve designed for. Map by Kristian Nebula, previously shown here. TOOLS I’m still mystified as to how Adrian achieved some of his techniques using Deluxe Paint, but I’ve almost exclusively used Photoshop instead of going fully retro. The tools affect the work of course, so this alone accounts for some key differences in style. I have a wacom tablet and some stuff is drawn using that, but for the most part this is all done with a mouse or, more often, the trackpad on my laptop since texture work has mostly happened when I've been traveling for work. Eviternity map by Joshua "Dragonfly" O'sullivan. Most textures seen here are hand drawn. A NOTE ON SKIES There's close to 50 skies included in OTEX, and they are mostly 200 pixels tall. Some are taller—240 or 256—but since I'm an old geezer who thinks Doom should be played without mouselook, that is mostly what I've designed for. So if you want to use this for some fancy GZDoom project, you might want to supply a different sky. More thoughts from me about sky rendering in this thread. Eviternity map by me.
  7. ukiro

    Things about Doom you just found out

    Also: the flat is drawn digitally in deluxe paint, the wall is a scanned drawing. This means the wall might have come first, and the flat is a “flattened” version made later, for the reasons Dragonfly points out.
  8. During the time after release where I still consider OTEX to be in active development, I am very unlikely to grant embedding permission for single levels, regardless of author. I have explained why elsewhere in this thread. For more ambitious projects, chances improve. Factors I will consider are who's on the team (i.e. track record of participants), intended theme, realistic chances of getting completed, special requests, and more. If I am not given sufficient reason to think the project will amount to a basic level of quality, I reserve the right to not grant distribution permission. This is in part because projects that I do give permission will also get my support, where needed, and I don't want to get tied up in crap projects. Also very much worth noting: Considering the development time of an ambitious project, something that begins production now is unlikely to be out in less than a year. (Few people, or even full teams, are @Dragonfly fast—Eviternity was started in March of this year.) This means that for such projects you can feel more certain that when it comes time to release, I will consider OTEX done and distribution permissions will be much more lenient. Basically, when the textures are out and you feel that this is something you want to use and you feel strongly that distributing the textures with the level(s) is paramount, drop me a line to discuss. If you are fine with your text file saying "requires OTEX" then you can just dive in right away.
  9. There's a difference between a texture WAD and a texture repository; They might both come in WAD form but their intended use is different. I hear you, and other in this thread, loud and clear on your objections, but calling this approach "rediculous nonsense" [sic] is not an argument, and saying texture ripping is something I "must accept" reeks of a rather unflattering kind of entitlement. I recommend you re-read what I've said in this thread, as a bit more nuance might tamper your outrage.
  10. “Refine” in the paragraph you quoted refers to tweaking and updating existing textures.
  11. That might be possible, but the concern to me is that a seemingly Boom and MBF compatible source port will render those wads incorrectly if they use a non-standard sky height (and arguably anything Y aligned to a regular 128 px sky will also break). So instead of mappers making special concessions to the engine, I suggest it's updated to allow for a more turnkey compatibility with Boom format content.
  12. This post is a deep dive into sky rendering, specifically when using sky heights different from the default 128. The level I built to run these tests is available here. Doom's original sky rendering had horizontal stretching towards the edges of the display, but draws a pixel row of the sky texture as a pixel row of the output resolution. This means that for the original renderer, targeting 320x200, a 200 px tall sky should always be sufficient even with the status bar turned off. Adding the status bar crops the viewport at both top and bottom, so pixel row 1 of the sky texture is no longer drawn at the top of the screen, but there should still be no scenario in which a 200 pixel sky can repeat vertically. Here I'll mention I'm aware that Doom's renderer was originally 320x200 (a 5:4 ratio) for 4:3 displays, meaning it did not have square pixels. Running on modern screens that use square pixels can compensate for this in various ways, and it's possible there is some variant of this compensation that I have not fully accounted for. But the problems I'm about to highlight are worse than that. Based on the reasoning above, I have made a lot of skies that are 200 pixels tall. Assuming no mouselook and ignoring the pixel aspect ratio for now, my thinking is that this should be sufficient for all correctly implemented classic style Doom renderers. A 16:9 output should not affect the height, but instead add a wider FOV on the sides (which admittedly causes the warp/stretch of the sky to worsen at the edges). But in testing, I always get vertical repetition with these skies. So I decided to try to figure out what is going on. I created 4 different sky textures, with the heights of 128, 200, 240, and 256 pixels. They have colored bands that are 8 pixels tall each, and has numbers that denote the bottom pixel row of each band. So a band that says 48 means the lowest pixel row of that color is row 48. My expectation would be that all skies are rendered with the same upper starting point, and extend further down if they are taller. For some reason, this is not the case, and instead it seems the skies are cropped equally at the top and bottom similar to how the overall viewport is treated when toggling the status bar on and off. The skies are added to the level using MBF sky transfers, line special 271. The originating line has no Y offset and the sector that the sky transfer is coming from is 128 px tall but it seems this sector height doesn't affect sky rendering. First, a look at prboom-plus-2.5.1.5.r4518-win32 at 640x480, show the expected pixel row 1 right at the top of the screen when the status bar is turned off: When the full width status bar is added, we see 13 pixels of cropping at the top: When setting the status bar to render in "doom format", meaning the renderer compensates for non-square pixels by stretching the status bar to how it would have look on a display capable of non-square pixels, this changes to 16 pixels cropping: So far this is all pretty reasonable, and the above is presented primarily as a backdrop to the testing of other sky heights. As I laid out earlier, in a correct renderer 200 pixel tall skies should fit in the viewport without any shifting or cropping, and is indeed exactly what we get here. But we are now cropped 72 pixels at the top, which incidentally is 200-128: Adding the status bar crops another 13 pixels, as with the 128 sky (or 16 with the aspect ratio corrected status bar, not shown here): Next is a 240 pixel sky. For a 4:3 aspect ratio (rather than the 5:4 of 320x200) with square pixels, retaining the 320 px width of the original renderer would have meant 240 pixels vertically, hence the test at this specific resolution. This now causes a 112 pixel vertical offset, which is 240-128: And with the status bar, we lose another 13 at the top: Lastly, going to 256 pixels since it's a nice even doubling of the original 128. This causes a 128 pixel offset, as we should expect by now: Staying consistent, adding the status bar crops another 13: There are some display modes that alter this behavior slightly. 16:10 modes, like 1280x800 here, crops 16 pixels at the top instead of 13 when displaying the status bar: This remains true with the alternative setting for the status bar since it now pads the sides rather than stretching it upwards: By setting the Y offset of the sky transfer line to -72, -112, and -128 respectively, the skies become positioned like a default 128 pixel sky. My question here is why skies taller than 128 aren't drawn top down? Has this never been considered, or is there some deeper reasoning? Eternity (I used Eternity-x64-4.00.00-435-g30b3a79d) seemed to be mostly consistent with PrBoomPlus in casual testing, so I did not pursue it further. Next up is GZDoom (gzdoom-bin-3-5-1-x64). Its software renderer behaves largely like PrBoomPlus', with some slight deviations caused by how it handles the status bar. But this accounts for only a few pixels, so I won't dive into that. However, the SoftPoly renderer is just straight up broken when it comes to skies. First of all, sky transfers don't work in this mode, so you only see SKY1 in my test level, and with the sky mirrored since that's how the default sky works. (Linedef special 271 does sky transfers without the mirroring.) It also insists on the barrel rendering for the sky (which exists to limit edge stretching artifacts) with no way to switch mode. It also looks like it crops the sky even at the center at 8 pixels, so that our top band isn't visible here, but this is because the softpoly renderer smears the bands together (but only at the top—see where it repeats further down) by adding the "capped" sky render mode even when it's set to Normal: Moving on to OpenGL mode, there doesn't seem to be any way to force non-barrel sky rendering like there is for software mode. This is what we get with the regular height sky: For the 200 px sky, PrBoomPlus showed us the lowest 3 pixels of the 88 band (see further up in this post), but here we get the lowest 6 of the 104 band (and only in the very center), a discrepancy of 13 pixels that then gets gradually larger towards the edges. This mode also means that a 200px sky is not enough to cover the viewport vertically, as the 104 and 112 bands appear twice here. Notice, also, that the vertical stretch is much less pronounced than in the 128 sky above—look at "16" in that picture and "104" in this one: Since the barrel rendering isn't even on average similar to the regular renderer, there is no way to get a sky to look largely the same in PrBoomPlus and OpenGL mode GZDoom unless you add a MAPINFO sky definition that compensates for this. The inconsistent vertical stretch makes designing skies for this mode in GZDoom infuriating. But it gets worse! A 240 px sky somehow renders with almost the same Y offset as the 200 sky, breaking the consistency we saw in PrBoomPlus: Moving on to 256, the offset starts to move again, showing us the bottom 4 pixels of the 120 band, indicating a 116 px crop in the center: When applying the same Y offsets that made all sky heights render the same way at the top in PrBoomPlus (-72, -112, -128 respectively), we get no consistency at all in GZDoom's barrel sky mode (which again is mandatory in OpenGL mode): While it might look like 240 and 256 are similar-ish, they are not and what's worse is they stretch differently: The scaling setting for the status bar will affect how much cropping it incurs, but overall I found no wild anomalies in this behavior. Due to the amount of possible setting combinations I could have missed something though. I also found GZDoom to be fairly consistent in sky Y offset across resolutions and aspect ratios, so that's good. The exception was 5:4 modes which showed 4 more vertical pixels of sky (at the top) compared to all other aspect ratios. TL;DR: GZDoom, fix your shit. PrBoomPlus, I would love if you drew skies top instead of aligning them to the bottom of where a 128 px sky ends.
  13. I won't make changes that cause errors in maps based on a prior version. If I change an existing texture it will be to fix a flaw or otherwise improve it, but it will retain its overall look in terms of pattern, luminosity, dominant colors, and so on. And, yes, once I feel it's time to move away from updating OTEX (a point I hope to reach soon, to be honest—this has been going on long enough) usage rights will be updated. As for some of the other comments here: Yes, I realize some people will inevitably feel entitled to do whatever they want with these, and I'm not taking pleasure in arbitrary restrictions. I feel that I have a pragmatic justification for this approach and I can only hope people take a few seconds to try to understand my reasoning. To help my cause, I fully intend to incentivize this and not just declare these to be the rules. By working with me, instead of just snatching the textures and running off like a hungry racoon, you should be getting something more out of it. For example, if you're needing some texture variant or combination that isn't included, I can add it for you if it's not too specialized (again, trying to avoid bloating the wad with one-off trick textures). Since I can do this from the Photoshop source files, the quality will be higher than if you try to frankenstein something together based on the patches in the wad. Additionally, I actually can help with one-off textures for projects where we've agreed the textures can be bundled. Eviternity will have some examples like that, and it should serve as the model example of how to use OTEX in a major production.
  14. No, it did not. It's very different, in fact. This is what the original darken2.txt said: Please do NOT extract textures from darken2.wad and do NOT create levels that are depending on darken2.wad to run. This effectively meant nobody else could use the textures. (This restriction was eased years later.) What I am saying here is that I do want people to make levels using these, and that embedding the textures in the level wad can be permitted under certain circumstances. But I am also saying that I don't want that to be the default use because I intend to continue to refine and add to OTEX for a while longer, which I hope is to the benefit of everyone. You are free to believe that this is still to restrictive, of course, but I'd like to offer a counterargument: I'm not disputing that from purely a players viewpoint it's more convenient to have everything as a single file, but I'm not so sure I buy this "hassle" argument. I'd argue it's not a lot to ask of a player, as it's not much more demanding than specifying a specific source port. I'd also point out people play with all sorts of mods all the time, and those too are "additional files". Sure, for single maps that you don't know whether they're crap or not, having to include a second wad might be enough of an obstacle for some, but that just tells me you weren't exactly itching to play that wad anyway. Lastly, this: As stated, I can grant permission for this where it seems reasonable. Eviternity will be released in this way, for example. But it seems silly to do this for single maps or smaller projects, especially while this remains a living project under development.
  15. When I write this on September 1st 2018, we have 100 days left until Doom's 25th birthday. I have been playing and modding Doom—on and off, admittedly—for 3 months short of that milestone, and feel I should do something to celebrate the occasion. I decided my best way I could commemorate Doom would be to release the set of textures I have been fiddling with for the better part of two decades, (although honestly 95% of them are made in the last 3 years). Somewhat surprisingly, after 25 years of Doom there still seems to be room in the "market" for a comprehensive, high quality texture set that isn't a collage of assets ripped from other games, feels like Doom in style and spirit, and that is universally useful across a range of projects. OTEX aims to be exactly that. Intended to be part of Eviternity map31, by me. To those who don't know me (and that's probably most of you by now) I released my first map publicly in 1996 (though it was completed in the fall of 1995), called Tantrum, contributed textures to Gothic DM 2, and ended up being the project lead and texture designer for The Darkening Episode 2, among other things. After that I was involved in several failed projects, and haven't released anything for Doom since 2000. Untitled map by Derek "afterglow" MacDonald, who has very patiently been testing my textures for the last 15 years or so. While I don't consider myself an artist, Doom's limited palette and resolution makes it possible to just throw shit at the wall until something sticks (literally and figuratively), so very patiently I have kept making textures for the last 18 years until some of them turned out quite alright (if I may say so). I'll do a full write-up on my process and philosophy for making textures at some later point, but for now I'd just like to set the expectations for this release. OTEX currently sits at around 1700 textures and 850 Flats, and it's all made for the vanilla palette and resolution. The target is Boom compatibility, with no special concessions for engines like GZDoom. Hence it comes in a WAD and not a PK3, but mappers are obviously entirely free to map for whatever Doom engine they want with these. All screenshots here are taken with GZDoom actually. Eviternity map17, by Joshua "Dragonfly" O'Sullivan. This Wad uses an altered palette for the green and blue range, so the original textures here are green and not teal. The idea is to make OTEX all-encompassing enough that it can serve as the single texture resource even for a fairly ambitious project, essentially to be for new textures what something like CC4-TEX is for remixes and extensions of IWAD textures. I've prioritized making textures that are universally useful over one-off specialized use. There's a lot left that I want to do that is unlikely to make it in by December 10, and of course there are always going to be themes and custom textures that someone wants but that aren't included. But it's my hope that the breadth and consistency will prove to be a step up from other options. For now, OTEX will be intended as an external resource rather than something you merge into (and distribute with) your projects. There are two main reasons for this: First, it's still a living project that I will keep refining and adding to, meaning that embedding the textures into another project robs it of future refinements. Second, it's a rather bulky file and while modern bandwidth and disk sizes makes that point mostly moot, it's inelegant to strap a big chunk of duplicate data to every level. There are exceptions to this where inclusion in a Wad is permitted, and I can grant more such exceptions if they are justified. But I ask that those interested in using OTEX please respect my wishes in this regard, and reach out if they want to discuss distribution options. Untitled map doodle, by me. I gave some people early access to OTEX so that I could get testers beyond my own map doodles, and so that there would be some nice levels released in conjunction with the textures themselves. The selection process for this was quite haphazard, and I sincerely hope nobody felt dismissed by not getting the nod. Ultimately I do want as many people as possible to make maps using these, but it had to reach a certain state of maturity as a set before broad distribution felt like a good idea. Dragonfly's ambitious Eviternity project is already announced, but there are some other smaller things being built as well. More on this later. It's my hope and aspiration that these textures will inspire mappers and players alike to continue keeping the original Doom alive for many years to come. In the coming weeks I will use this thread to share some details and answer questions.
×