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

ketmar

Members
  • Content count

    2026
  • 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. shadowmapping experiments. don't expect it to get into the engine, tho. at least not soon. there are still alot of problems, including messed up cubemap -- this one works only because the light is at (0,0) (and the orientation is still not right). and something that is much worse: moire and peterpanning. while i may try to combat moire with dynamic comparison bias, peterpanning is much, much harder (if possible at all) to get rid of. peterpanning is that light bleed you can see behind the vines. the problem is that our geometry is paper-thin, and shadow maps really hates such geometry. i guess that it is possible to do something with it, but i don't have any ideas yet. anyway, even if i won't be able to make this thing work right, it was worth trying. i'm not really a gfx guy, and i'm still learning. so failed attempt is fine too -- there is no learning without failing. ;-)
  2. it should work regardless of that option (and it worked some time ago). this is definitely the bug that should be fixed, thank you!
  3. i always thought that this is how it should work. but i can change it, no big deal. then the function will simply return `false`, even forced spawn one. i haven't done that because it may break some scripts, and generally, "-nomosters" should prevent spawning map things, but don't touch others. and i somehow don't feel like putting another config option for this is good -- we already have too many options, i think. ;-) dunno, i can change it, and we'll see. i have to think about it. as @Gez wrote, you may still have to fix the scripts, because some things may not spawn even if you forced that. it may break boss sequences and such. in the end of the day it may do more harm than good. also, in k8vavoom cvar is named simply "NoMonsters". for now, i added the check and pushed it to the repo. we'll see it if will stay, tho. but that's exactly how it should work. the difference is that setting cvar (+nomonsters) is "local change" (i.e. you can play single-player game, and then set "nomonsters" and create a server), but "-nomonsters" in command line affects everything right from the start, including sp games.
  4. ketmar

    1995 called. They want their Doom levels back.

    dead player near the switch? nobody would be able to resist trying it! at least not me.
  5. and the new build, as i promised. it might be slightly buggy and unstable due to some major incoming VavoomC changes, but shouldn't really break anything. at least it "works for me", as usual. ;-) brief changelog @-TDRR- nothing really interesting this time, but still... ;-)
  6. just give us (me, specifically) several days to play it again first. ;-) yeah, it looks ok. it was enough to simply append empty clusterdef, tho (i specifically checked that it works). but offseting all cluster numbers works too. i mean, you could do less work for the same, and avoid converting mapdef to "new" format. don't get me wrong, please, this conversion is a good thing, it is my laziness talking. ;-) p.s.: and upload fixed "map05.wad", please, so we can avoid manually fixing bytecode. ;-)
  7. ketmar

    1995 called. They want their Doom levels back.

    but it really looks cool! almost everybody does that on the floor, it is so... usual...
  8. @Gunrock ok, the bug with script 12 is in the condition: while (monstercount[0] + monstercount[1] + monstercount[2] + monstercount[3] + monstercount[4] <= monstertotal[0] + monstertotal[1] + monstertotal[2] + monstertotal[3] + monstertotal[4]) here, it should be "<", not "<=". because with "<=" we still entering the loop when all monster counts are saturated, and that second "while" will never find something that is not spawned to the limit. so k8vavoom is completely right here. ;-) (GZDoom aborts this script much sooner, and it's not fatal to abort the script in GZDoom by default, that's why you prolly never seen anything wrong there.) and with map03: by default, all Doom2 maps are belong to clusters 5 and higher. GZDoom resets cluster number on the replacement map, but k8vavoom doesn't do that. so when the player moves from map03 to map04, in k8vavoom it also moves from cluster 5 to cluster 1. and cluster 5 has "infested starport" exit text, so k8vavoom shows it. the easiest way to fix this both for k8vavoom and for GZDoom is to add dummy cluster 5 defition with empty exittext: clusterdef 5 exittext ""
  9. @Gunrock yay! i'll try to find out what is wrong there. thank you for updates, and for your bugreports! p.s.: it's good that i decided to delay a new build a little. ;-)
  10. your maps are looking great, so post more of those, please! people love to see cool screenshots, and i can use those shots to make people think that k8vavoom is really that stylish! ;-) p.s.: i still hope to implement proper shadow maps one day, so we could have those transparent textures to cast shadows too. it would look great, i guess.
  11. just write it right here, this is Teh Official Place for now. ;-) the first one does nothing at all, i just forgot to remove it. and the second one is fixed. thank you!
  12. also, k8vavoom is not dead. no wai! ;-) a new build is just around the corner. nothing really ground-breaking, mostly small bugfixes here and there. but alot of research work is happening behind the scenes. it's not the time to announce anything, but the project is alive and well, and i hope that my research work will eventually land into k8vavoom, bringing you even more half-finished buggy features you can complain about! ;-)
  13. ketmar

    1995 called. They want their Doom levels back.

    i always knew that computers were invented for this!
  14. ketmar

    DOS Doom Code Execution

    but... it always had this ability! just look at the topic we're commenting...
  15. ketmar

    The Doom Confessional Booth

    it uses multiple cores in renderer and audio subsystems, but it is impossible to use multiple cores for playsim. like, totally, physically impossible without completely throwing away Doom compatibility, and rewriting all playsim code from the scratch, in completely incompatible way. this is the limitation of the original Doom architecture -- it is impossible to run thinkers in parallel, because they can modify alot of global state, and state of any other thing in the level. if we'll put "lock guards" around each such data change, everything will be even slower (think about vanilla engine on 386DX or something, a perfect slideshow). PrBoom is fast because it has no scripting hooks, all monster AI and physics code is compiled into optimised native code from C source. but GZDoom cannot do that, because scripts can change almost everything (including physics). GZDoom still does JIT compilation (i.e. compiles scripts into native code on the fly), but the code is much more complex, and it cannot be as fast as PrBoom's. this is the price we have to pay for GZDoom highly advanced modding features. in simple words, due to modding support, GZDoom has to execute alot more code for each monster AI/physics. it tries hard to make it fast, but there is only so much it can do -- you cannot execute more code in the same time as less code. ;-) so, GZDoom is still highly optimised, but it has to do alot of things PrBoom was never designed to do. sadly, there is no such thing as a free lunch. this is also true for GZDoom renderer: it has to support alot of things glboom simply cannot do, so even if you will turn off most "advanced gfx features", the renderer will still perform more work, due to more complex internal data structures.
×