Korshun

Members
  • Content count

    9
  • Joined

  • Last visited

About Korshun

  • Rank
    Newbie
  1. Yay finally Doomworld works again! From having watched the video, I think that PSX Doom's lighting is not faithful and is simpiler than in vanilla doom. To me it seems to work like this: 1) there's min and max light levels defined by sector's light level, max light level may be overbright (max sector light level results in 2x overbright max light level). 2) there's a gradient from max to min light level and this gradient is always at the same distance regardless of light level. Keep in mind that I have never played PSX Doom :/. Okay, someone found out about my abandoned plans :). I guess I should explain it properly. Back when I was planning swlight, I thought that light levels on indivudual colormaps in the COLORMAP lump do not fade linearly (now I know they do (except for minor palette artifacts)). Also there may be custom colormaps that can be used, for example, to implement colored lighting or fog in vanilla doom and Boom. Especially Boom, because it can switch colormaps by map triggers. My useless plan was to implement colormaps' effects in true color OpenGL in a better way than in GZDoom (for example the fog on the first map of FreeDoom doesn't look like fog at all in GZDoom, with my way it would look like fog). For every colormap: 1) Somehow find the difference between original and remapped color. 2) Average the differencies. 3) Put the averaged value into one pixel of the special 1D texture. Every texel of this special texture represents the color every colormap is supposed to fade to. Then just use light level as the texture coordinate and multipy the color by the color from texture. Then I found out that all IWAD colormaps actually represent linear gradients from white to black and that light level correction is only needed when lighting is uniform and not when lighting is like in software renderer so I don't need to implement all this for the software lighting to look good :/. And why bother with implementing such a complex thing just for some very rare examples of custom colormaps in wads I don't even know about? That's too much work for too little gain. Forget it, it is just an idea about custom colormap implementation in true color renderer. It is useless. It is not at all needed for software renderer's lighting in OpenGL. And I am absolutely sure this is not anything like what EDGE does.
  2. Nice news! (but weapon flashes are way too bright for some reason) Yes, exactly. In the later versions of my shader it is moved to #define DOOMLIGHTFACTOR, and changing this constant results in effects similar to changing r_visibility. With pixel shaders you can implement ANY lighting formula. Just replace R_DoomLightingEquation in the shader, it is the function that defines the dependency between distance, sector light level and on-screen light level. I am completely unaware about lighting in PSX Doom (except that PSX Doom has colored lighting unlike vanilla) but if it is not so different from vanilla doom, you may get away with modifying EDGE's formula.
  3. Daaaamn. The lighting constant is still 192 in the release so the lighting is too dark :(. It should be 232 to match the software renderer exactly! (actually it is my fault, I should have tested my hack more before first release with wrong constant :( )
  4. Oh well, looks like RapeFactor isn't known outside the Russian Doom Community. Googled up some download links that are not dead yet: RapeFactor Heretic addon. (Just add it after rapefactor.wad) Only works on Skulltag/Zandronum. You can control the global multipier using the "rapefactor" CVar. And you can control multipiers for every individual monster and item using the <itemname>Factor CVars (for example: ZombieFactor, ClipBoxFactor). I thought I should credit the author (Hexa]ASTS aka HexaDoken) because the downloads don't have any documentation.
  5. 10x seriously sucks... RapeFactor is better at everything compared to 10x. It is configurable (you can make everything 100x WITHOUT editing the wad) and monsters don't through each other. I just don't get the point of playing 10x when there is RapeFactor. So 100x.wad is even worse than it is because it is completely pointless.
  6. Not everything but only what is close. Distant dark sectors fade to pitch black :(. Software renderer's fog is highly nonlinear. It fades from fullbright to dark very quickly (giving the "glow" effect to the player) but at some distance it almost doesn't fade so sectors appear lit regardless of distance. In contrast, GLBoom's fog fades linearly (or at least it looks linear, I dunno) and as a result closer areas appear too bright and distant areas appear too dark. My confession: that's one of the main reasons why I prefer GZDoom to PrBoom for classic dooming. PrBoom's software renderer is full of prescision bugs, unlike ZDoom's perfectly accurate software renderer. PrBoom's opengl renderer still can't get lighting that's close to GZDoom's "Doom" lighting mode (although both are far from EDGE). Now that I can't live anymore without freeaim, finitely tall actors and general polish of ZDoom (no annoying micro bugs everywhere), I am spoiled :/.
  7. Software renderer interprets light levels as fog density of a sector. Most OpenGL ports interpret sector light levels first and foremost as a COLOR of a sector and only then add some fog. GZDoom tries to fix the light fading by brightening up near areas with shaders (sector light mode "Doom") but sometimes ends up way off compared to the software renderer because it is only an approximation that can't replace the use of exactly the same lighting formulas as in software renderer. The only port I know that seems to replace software renderer's lighting EXACTLY is EDGE. Too bad EDGE sucks at everything else :(. Yeah, that's the bad side of palette. But there is a good side too: * Bloody-red textures have added detail because of too different fading of different colors. * Colormaps allow to implement some kind of brightmaps that preserve the saturation of darkened textures. Probably the best example is Heretic/Hexen lava that always looks saturated in software renderer but looks washed-out in OpenGL renderer unless sector light level is 255. * Marble green is warmer and wood is brighter for the reason above but this may be a matter of preference.
  8. Long ago I tried to make one (command line dedicated utility) and failed/got bored. But I did plan animated texture support from the start :). I have never seen a wad require external texture packs before cc4-tex.wad showed up :). Wow. Didn't know. It is like in 50% of cases when someone asks "how do I do that with wads" the answer is "use SLADE3" :).
  9. Hello. How are wads released when they use texture packs? In case of a project with a predefined texture pack it is clear but it is not clear in other cases. Say if I make a map that uses only like 10% of a texture pack, what do I do? Copy the unused 90% of the texture pack? Manually and tediously delete unused textures? And what if there is a lot of them?