Gez Posted February 7, 2019 I'd suggest using a different lump name for the texture, and you can keep the same texture name in TEXTURE1. Look how most textures in vanilla have names different from their patches. 0 Share this post Link to post
Krull Posted February 7, 2019 (edited) . Edited September 2, 2023 by Krull 0 Share this post Link to post
Aquila Chrysaetos Posted February 7, 2019 I suggest renaming your flats, so Choco or PRBoom don't get confused. While the Doom IWADs have textures named step1 and step2 and flats named step1 and step2, I think it's bad practice, as it's not only a potential problem, but it also can confuse the mapper. To answer your question directly, you don't have to have to, but its probably for the best to rename your flats. 1 Share this post Link to post
Gez Posted February 7, 2019 The other advantage is that you don't clutter your warning/error reports. Alternatively, depending on what ports you're targeting, you can also avoid duplicating the texture for flats and walls. The ZDoom ports, Eternity, and EDGE all allow to mix to mix flats and textures. 2 Share this post Link to post
Jaska Posted February 9, 2019 What is maximum texture resolution in.. -prBoom+ -Boom -GZDoom I've had 1024*512 in prBoom+ and it worked. Will 4096*1024 work? 0 Share this post Link to post
Nemrtvi Posted February 9, 2019 (edited) I noticed this topic after already making another one related to my question, but it seems I can’t delete posts on this forum. So I’ll just link this post here. 0 Share this post Link to post
Gez Posted February 9, 2019 1 hour ago, Jaska said: What is maximum texture resolution in.. -prBoom+ -Boom -GZDoom I've had 1024*512 in prBoom+ and it worked. Will 4096*1024 work? It should. One thing to keep in mind is that for OpenGL renderers (GLBoom+, GZDoom, etc.) there's a maximum resolution. It depends on your system, not on the software you run. You can find it with any sort of benchmarking software, or even just by looking at the SLADE console (Ctrl-2). For example I get this: Initialising OpenGL... OpenGL Version: 4.6 Max Texture Size: 16384x16384 That means that if I try to load a bigger texture (even if it's only bigger in one dimension, e.g. 1024x32768) then it'll be downscaled to fit (in my example, to 1024x16384). For software renderers, there's no real limit. The original Boom can only load Doom's native picture format, so technically you're limited to 65535x65535. Given the way the renderer works, you can't really use heights greater than 128 without some fussing around, though with composited textures you can work around that. And width isn't a problem, however. Keep in mind, though, that the texture data is not stored in memory in a compressed way like modern engines usually do, so if you have a lot of textures that are that big, you'll get a large memory footprint. 2 Share this post Link to post
holaareola Posted February 9, 2019 I did search but couldn't find anything. I want to load in a custom palette in my wad, but if I have a PLAYPAL lump, even one copied from an iwad, doom2.exe freezes on startup (init playloop). Chocolate Doom gives me a "R_installspritelump: bad frame characters in" error message. Is PLAYPAL order sensitive (I have it first, as in IWAD) Anyone got any experience with this? 0 Share this post Link to post
Kappes Buur Posted February 9, 2019 (edited) 2 hours ago, holaareola said: I did search but couldn't find anything. I want to load in a custom palette in my wad, but if I have a PLAYPAL lump, even one copied from an iwad, doom2.exe freezes on startup (init playloop). Chocolate Doom gives me a "R_installspritelump: bad frame characters in" error message. Is PLAYPAL order sensitive (I have it first, as in IWAD) Anyone got any experience with this? https://doomwiki.org/wiki/PLAYPAL Spoiler Playpal used Could be the last lump as well Spoiler PrBoom+ Spoiler Chocolate Doom Spoiler GZDoom Edited February 9, 2019 by Kappes Buur 1 Share this post Link to post
holaareola Posted February 10, 2019 12 hours ago, Kappes Buur said: https://doomwiki.org/wiki/PLAYPAL Reveal hidden contents Playpal used Could be the last lump as well Reveal hidden contents PrBoom+ Reveal hidden contents Chocolate Doom Reveal hidden contents GZDoom Ah, I should have tested that myself. OK. I could get it working in a map-only wad like you did. But it kept crashing my wad with map, sounds, music, blah blah in it. Anyway, you gave me a bump in the right direction: positioning it as the very last lump worked. Who knows why, but thanks! 0 Share this post Link to post
Gez Posted February 10, 2019 16 hours ago, holaareola said: I did search but couldn't find anything. I want to load in a custom palette in my wad, but if I have a PLAYPAL lump, even one copied from an iwad, doom2.exe freezes on startup (init playloop). Chocolate Doom gives me a "R_installspritelump: bad frame characters in" error message. Is PLAYPAL order sensitive (I have it first, as in IWAD) Anyone got any experience with this? The message tells you that you have a lump that doesn't respect the sprite lump naming conventions. So it seems you put your PLAYPAL lump within the sprite namespace, and that's what is causing the problem. Make sure PLAYPAL isn't between S_START and S_END! 1 Share this post Link to post
valkiriforce Posted February 12, 2019 (edited) Anyone know if it's possible to give the pistol unlimited ammo without affecting the chaingun in DeHackEd? It seems to work just fine but I get some odd issues where the pistol's shots take away the shotgun's total ammunition instead of being a limitless weapon. Currently it looks like this for me: Spoiler Misc 0 Initial bullets = 100 Weapon 1 (Pistol) Ammo type = 5 Weapon 3 (Chaingun) Ammo type = 0 EDIT: Should mention this problem is happening specifically in PrBoom+. Edited February 12, 2019 by valkiriforce 0 Share this post Link to post
Grazza Posted February 12, 2019 Explanation here. There may be ports that handle it differently, but in that case they won't be emulating dehacked accurately. 0 Share this post Link to post
4everDoomed Posted February 14, 2019 (edited) I'm making a dark outdoor area and wanted to include some dynamic light effects but the testrun doesn't seem to show the same ingame results, it's confusing. In visual mode you see almost the whole area flooded with light, but when you start playing.... Why are dynamic lights shown so much brighter in visual mode ? 1 Share this post Link to post
Jaska Posted February 15, 2019 What would be maximun visible linedef count considering performance to average user? I kind a like large open areas so where should I stop? 20 000 linedefs? 30 000? What commands I can use to see how much stuff is in a gameplay view? On gzdoom, or prBoom? I'm working on a prBoom-compatible-project. 0 Share this post Link to post
Koko Ricky Posted February 16, 2019 How do you check which sectors are tagged as secret if you're working in vanilla Doom, editing with GZDoom Builder Bugfix? 0 Share this post Link to post
Aquila Chrysaetos Posted February 17, 2019 You can use the automap mode in the builder and enable the setting "Show secrets" that should be at the top of the taskbar. 1 Share this post Link to post
Empyre Posted February 17, 2019 You could also go into Find and Replace mode and search for Sector Effect, choosing Secret. In UDMF, Secret doesn't appear in the list to choose from, so for that you type 1024, but that is moot, since you are asking about vanilla. 2 Share this post Link to post
Kappes Buur Posted February 17, 2019 (edited) 4 hours ago, GoatLord said: How do you check which sectors are tagged as secret if you're working in vanilla Doom, editing with GZDoom Builder Bugfix? In Sectors Mode it should display the sectors set to secret as E9, 9 being the effect for secret. Edited February 17, 2019 by Kappes Buur 1 Share this post Link to post
AJOgames Posted February 20, 2019 On 2/1/2019 at 3:36 PM, Gez said: Technically, there's nothing engine-dependent here; it's just a question of how the developers arranged the palettes. In fact, for example, Heretic and Hexen use dark-to-light range progressions while Doom and Strife use light-to-dark. See the examples here. Oops...should've looked at that before. 0 Share this post Link to post
Bauul Posted February 20, 2019 On 2/15/2019 at 1:35 AM, Jaska said: What would be maximun visible linedef count considering performance to average user? I kind a like large open areas so where should I stop? 20 000 linedefs? 30 000? What commands I can use to see how much stuff is in a gameplay view? On gzdoom, or prBoom? I'm working on a prBoom-compatible-project. On GZDoom at least, in my experience you start to see noticeable drops in frame rates when you get above about 10,000 visible lines (presuming a map includes all the other bits and pieces that go along with a typical 10,000 linedef scene). This is true for both UDMF and PRBoom-compatible projects. Anything north of 15,000 linedefs will start to get problematic. Generally I would try to say below 10,000 to maintain decent FPS in a given scene. 2 Share this post Link to post
Jaska Posted February 22, 2019 Have to keep this in mind on future maps. This view has only like 7000 linefeds and framerate drops. But, there is a lot of middletextures representing the vegetation. I've seen some rendering videos how same pixels get drawn multiple times when translucent middletextures are in screen. So that is a problem. 3 Share this post Link to post
Kappes Buur Posted February 22, 2019 On 2/15/2019 at 1:35 AM, Jaska said: What would be maximun visible linedef count considering performance to average user? I kind a like large open areas so where should I stop? 20 000 linedefs? 30 000? What commands I can use to see how much stuff is in a gameplay view? On gzdoom, or prBoom? I'm working on a prBoom-compatible-project. On 2/20/2019 at 1:32 PM, Bauul said: On GZDoom at least, in my experience you start to see noticeable drops in frame rates when you get above about 10,000 visible lines (presuming a map includes all the other bits and pieces that go along with a typical 10,000 linedef scene). This is true for both UDMF and PRBoom-compatible projects. Anything north of 15,000 linedefs will start to get problematic. Generally I would try to say below 10,000 to maintain decent FPS in a given scene. Yap, too many linedefs = low framerate Spoiler 1 Share this post Link to post
Doom_Dude Posted March 1, 2019 (edited) Using GZDoom and UDMF is it possible to have two entry / player start points in a map? I was hoping to make a different starting area for when you come back from a secret map. So if you have a secret exit in map 06 that takes you to a map33, then when you exit map33 you start map07 in a diff spot than you would if you went through the normal exit in 06. [edit] Also is ThrustThingZ not working anymore or something. I was trying to set up a climbable ladder but that refuses to work. Last thing I tried was Dragonfly's example --> https://www.dfdoom.com/create-a-climbable-ladder-in-doom/ 0 Share this post Link to post
Aquila Chrysaetos Posted March 1, 2019 It is! And I've used it before. What you need to do is assign the player start coming from the secret map a "position" in its first special argument (1, for example). Then, when setting the End_Normal line in the secret map, in the position field, write the number matching what you put in the player start's first argument. This will make ZDoom check for a player start with a matching first argument and will start you there instead of the default when the map ends. Also, ThrustThingZ, the first thing I'd check is if the line action is "player bumps" and is repeatable. After that, it should work by default with whatever value you put in the force field. 1 Share this post Link to post
Doom_Dude Posted March 1, 2019 Thanks Aquila, got both of those things working! Man, that playerstart position thing was so easy to set up and I thought I was going to have to do some weird script deal.. So glad to get the ladder working too. 1 Share this post Link to post
Wahrnehmungskrieg Posted March 22, 2019 I: Is there any editor (or method in GZDB/DBX) which allows for gradient colour to represent floor height in a view mode (e.g. as WadC viewer is able)? Or are there tricks I can do to have, say, tzhe sector lighting be affected by tzhe floor height as a crutch? Or, worse, is there no possibility of this? II: To those who work with highly-off-grid/ultra-detailed geometry, what are your strats for identifying node builder fuckups (e.g. slime trails, sidedefs not rendering right (in software), etc.) out of just playing tzhe level + IDMYPOS? I have trouble getting much out of tzhe nodes viewer mode? 0 Share this post Link to post
Krull Posted April 10, 2019 (edited) . Edited September 2, 2023 by Krull 0 Share this post Link to post
Aquila Chrysaetos Posted April 10, 2019 Not sure. Your dehacked strings can be edited directly in Slade, and I can tell you the string you need to write so it shows up properly. Quote GOTREDSKULL = You found a red eagle key. GOTREDSKUL is incorrect (for some reason, maybe to keep an "even" number of characters or something), it turns out the proper name for this string is GOTREDSKULL with two L's. Even the ZDoom Wiki has it written improperly (which is beyond strange), in its Strings page which tells you the name of each string so you can modify it in DHE. 0 Share this post Link to post
Empyre Posted April 10, 2019 1 hour ago, Aquila Chrysaetos said: Even the ZDoom Wiki has it written improperly (which is beyond strange), in its Strings page which tells you the name of each string so you can modify it in DHE. If you are sure of that, why not edit the page to correct the error? That is how wikis work. 0 Share this post Link to post