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


  • Content count

  • Joined

  • Last visited

About ketmar

  • Rank
    Senior Member

Recent Profile Visitors

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

  1. thank you for improving Eureka! i really love it, and i am really happy that you found time and inspiration for it. btw, banded OpenGL lighting looks really interesting. somehow i never thought about doing it that way. thanks for the inspritation too! ;-)
  2. yeah. usually, most of the things works, but it is still worth checking if something works the same across all sourceports. yet UDMF is easier to work with (like, you can do some things directly instead of putting special things into a map), and there are some things that simply cannot be done outside of UDMF (at least not without dirty hacks). i'd say, go with UDMF if your map is not strictly vanilla/boom (or you don't care).
  3. ketmar

    The story behind your custom avatar

    just the official logo of my doom sourceport. i still have to create a lore for it. ;-)
  4. ketmar

    Community Rules for mapmakers/modders?

    usually it is quite easy: if you looked at how somebody did something, but end up writing your own thing, just drop a "thanks to/inspired by" in credits file. if you're planning to take something and use it (mostly) unmodified, try to ask a permission from the author first. or at least fully credit the author. basically, people will be ok if your work is original enough. like, if you'll do some compilation project like infamous "doom rtx" (just throwing together parts ripped from other mods), people will find *every* thing you forgot to credit, and will name it "stealing". but if your work is your own, and you used some "ripped" things to make it even better, people will usually say something like: "great work! but you forgot to credit the author, fix it, please".
  5. ketmar

    Is Marathon Trilogy worth playing today?

    absolutely worth it. you will prolly have to spend some time to get used to the game, though, because aleph devs seems to value "original feel" more than some quality-of-life improvements. but then you'll find quite interesting game inside, with its own feel/mood/atmosphere. just don't expect it to be doom, because it isn't (obviously ;-).
  6. i want to say that Andrew resumed Eureka development, and added OpenGL 3d view, and basic UDMF support! yay!
  7. ...and found some bugs in new lightmap update code. quickfix is coming soon. don't worry, i'll try to break texture mapping to compensate lightmap fixes.
  8. ketmar

    Best FPS game (Aside from Doom)

    but... Powerslave Ex...
  9. and some PR: two quite huge maps (WIP), k8vavoom version of the first map is lit mostly with dynamic light sources: topic. very impressive effort, especially for a novice mapper, i believe.
  10. and of course right after i pushed the last build, i made D4V.wad work without hidden CLI args, and fixed "floating corpses" issue with it. maybe it worth a minor update. we'll see. ;-)
  11. we should punch and kick such people until they understand that we are very peaceful by our nature.
  12. let there be light! this new build has alot of changes in lightmapping code, and the engine is able to cache built lightmaps now. that is, no more lightmap recalculation on each game load. also, no more engine crashes on big maps with alot of dynamic lights (this could happen, for example, on a map with open space and hordes of imps, all throwing fireballs). the new code is experimental (as always), but hey, everything in k8vavoom is experimental anyway. ;-) also, i switched to GCC 9.2, because GCC 5.4 is unable to build k8vavoom code (internal compiler error, no less!) WARNING! networking code is completely broken for now. i know it, and i will try to restore it later. * oops: "zmapinfo" was never used due to a typo * partially implemented "sky_exmx" hack (thanks, steinkrauz) * alot of meaningless code changes nobody will notice anyway (tech debts, cleanups) * always sort weapon slots (otherwise overridden weapons can be put into the wrong place, regardless of Weapon.SlotPriority) * added "DOOMWADPATH" envvar support * it is now possible to change weapons after morphing/unmorphing * the engine will prefer Shadow Volume Renderer for "autoselect" (if it is supported by GPU) * added "am_show_keys_cheat" automap cheat cvar * added "am_keys_blink_time" automap cvar (so known/cheat keys may blink for better visibility), and UI menu option * added option to draw DoomGuy face in horizontal screen center in fullscreen HUD * better masked wall rendering in lightmap mode (there should be no more occasional "fringes" on masked walls... i hope) * more VavoomC gfx API (rects and lines! yay!) * some small optimisations in shadow volume renderer code * slightly faster lightmap chain rendering * better lightmapped surface management; the engine should not bomb out with "surface cache overflow" anymore (experimental!) * implemented first draft of lightmap cache (both for initial map loading, and for savegames); it is not finished yet, but sometimes it works ;-) * added optional BSP lightmap tracer -- see Advanced Video Options (BSP lightmap tracing is ~3.5 times slower than blockmap, but produces less light leak artifacts) (thanks to TerminalHash for test maps) * perform partial lightmap atlas updates (in theory, this sends less data per frame to GPU) * fixed glitch with glowing walls in lightmap renderer (missed some glow parameter updates sometimes) * made stealth fist and chainsaw modes optional * added some more "compat_XXX" tokens to mapinfo parser * some 3d floor rendering hacks (garden fences in Golden Soul MAP01 should not glitch now, for example) * fixed dynamic sprite lighting bug for lightmap renderer and 3d floors
  13. ketmar

    FPCDoom (Updated Nov 12, 2019)

    but this limits you to pure screen-space solutions, no? or you have to create enormous lightmap that covers the whole sector bounding box (to cache it), which is very wasteful. actually, Quake (and Vavoom) maps one lightmap texel to 8*8 (or 16*16) texture texels. that's why i asked about texture mapper: such lightmaps must be filtered to produce lights without clearly visible jagged edges. there are several ways to do that, depending of textuing code. still, your approach seems to be... somewhat unconventional, and i am very interested to see how far you'll be able to push it. after all, seeing people doing things the same way again and again is boring. ;-)
  14. i am starting to completely ignore people right at the moment they say that i should adjust my tastes according to their views. oh. actually, one question later, i want to be sure that i got them right.