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

ukiro

Members
  • Content count

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

    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.
  2. 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.
  3. 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.
  4. “Refine” in the paragraph you quoted refers to tweaking and updating existing textures.
  5. 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.
  6. 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.
  7. 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.
  8. 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.
  9. 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.
  10. ukiro

    Post your Doom textures!

    Yep, this will Be in otex. Just over 100 days to release!
  11. ukiro

    Post your Doom textures!

    I baked some ambient glow into the texture itself to give it that effect. The gif is captured in gzdoom but thanks to being made up of 4 animation sequences it's boom compatible, with the caveat of the flat edge bleed issue in software rendering.
  12. ukiro

    Post your Doom textures!

    Made a 128x128 teleporter:
  13. Heh, I was going to say… The Darkening episode 3: Somehow these keep getting brighter
  14. ukiro

    [WIP] Eviternity - A Boom Format Megawad

    Ah you seem to be right. Loading otex with doom 2 makes all vanilla textures point to otex patches, but that's because the IWAD's TEXTURE1 points to numbers in PNAMES, and if it reads the otex pnames it in turn points to otex patches. So if on R_Init the engine did this, we'd be in a better place: IWAD: Read TEXTURE1 (and/or TEXTURE2 if available) and PNAMES to compile "map textures", ignoring PWADs for now PWAD(s): Read TEXTURE1 (and/or TEXTURE2 if available) and PNAMES to compile "map textures", appending these to the "map textures" created in step 1 If a NumForName error is thrown within the scope of the latter, expand search to the IWAD patches. This is to allow PWADs to define new textures using IWAD resources. Would this work? Are there scenarios where this would break things that work today?
  15. ukiro

    [WIP] Eviternity - A Boom Format Megawad

    You’re right I should have gone into more detail on the PNAMES route, but you’re also right in that it wouldn’t achieve what I wanted. If someone with with a good eye for the source code could verify my other theories here I’d appreciate it—specifically that all PNAMES entries get merged before textures are compiled.
×