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


  • Content count

  • Joined

  • Last visited

About ketmar

  • Rank

Recent Profile Visitors

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

  1. ketmar

    PrBoom-Plus, ver.

    this is may be due to some pwads you're loaded, with replaced colormap.
  2. yeah, k8vavoom does it The Old Way. realtime with shadows. as for "why doom"... i thing this is due to lower mental entering costs. i.e. people looking at doom and thinking: "ok, it is still 2d, like simply drawing on a paper" (it is not quite true, but it looks like that). and for Q they seen it as Hard 3D Architecting. besides, it is quite easy to write a doom automap-style renderer. and WOW! i am working with engine data already! writing even wireframe view for Quake looks harder. so, in the end, people did more for doom 'cause it looks easier to do. also, there is anoter very important factor: Quake and Quake 2 are boring games. each in its own different sense, but boring. i am still playing vanilla doom episodes, but i hardly can remember when i played quakes last time. i mean: "ok, i want to play it, from start to finish". so when you're doing, for example, DooM sourceport, you will immediately have at least two great games to play with it. for Quakes... "yeah, looks impressive. now, can we have some REAL game to play?" ;-) p.s.: just in case. people, i didn't said that quakes were bad! let's not start it all again here. ;-)
  3. ketmar

    DISCHARGE! - My Endgame

    with Quake (and Source is based on Quake), things are even worser, actually. while doom engines are able to do clipping when the wall is solid (they are using 1D clipper for that; yes, 1D -- that's why vertical clipping is not there ;-), Quake is unable to dynamically clip based on geometry at all. that's why Quake tools precomputes PVS (potential visibility set), which indicates subsectors (in doom terminology) that are visible from the given one. kinda like reject table, actually, but it is used not only to speedup line traces, but in renderer too. still, due to "real 3d" nature of the engine, "subsectors" are 3d too, and tools are able to determine that most of the second yard is not visible from the first one even if there is a "leak" from one to another, and clip statically with PVS. (of course, real implementation is much more complex, and quite different for software and hardware renderers, but the basics is like what i wrote.) when building a complex doom map, it is always good to remember that doom does only 1D clipping. so if there is some vertical leak, renderer will do more work. also, clippers are smart enough to clip with (most) closed doors, so strategically placing doors in your map can help too.
  4. ketmar

    k8VaVoom: no good thing ever dies!

    heh. that last build was extraordinarily buggy: due to alot of internal changes many things are unreliable. even save/load can crash unpredictably (especially on fast SSDs). i am really sorry. i already fixed alot of bugs and crashes, but i prefer to delay new build until i'll finish new save/load system. this is somewhat big task (i have to write a new chunked storage manager, a new named value manager, and rewrite almost all serialisation code), and it may took more time than i estimated. so if you found some bug in current build, please, wait until i'll upload a new one, and re-test before reporting. maybe i already fixed it. sorry for inconvenience! (meh! nobody except me is using k8vavoom as their primary sourceport, so it prolly doesn't matter; but then, being polite costs me nothing ;-)
  5. i found two small bugs in SmoothDoom. first, `DoomImp` is replaced twice: first time with `SmoothDoomImp`, and second time with `ImpDice`. while not fatal, first replacement is unnecessary. and second, more subtle bug: `ImpDice` never spawns `ImpV2`, due to this line: TNT1 A 0 A_Jump(256, "Standard") it should be this instead: TNT1 A 0 A_Jump(256, "Standard", "Variant2") it is hard to notice in-game, as two imps are very similar. that is prolly why nobody noticed yet.
  6. ketmar

    k8VaVoom: no good thing ever dies!

    also, just found and fixed "decorate loop replacement bug" (this is when one actor replaced several times in mod's decorate). smoothdoom does this, for example, and endlessly spawns "ImpDice" instead of real imps. the hard part is that if you'll load several mods, later mods should replace old mods replacements, not original -- this way mods can stack gracefully. but if one mod replaces the same actor several times, endless spawn loops are possible. usually this is some kind of copy-paste bug in mod code, so k8vavoom shows all the relevant info to fix it: Warning: DECORATE error: already replaced class 'DoomImp' replaced again with 'ImpDice' (current replacement is 'SmoothDoomImp') Warning: current replacement is at SmoothDoom-2018-12-18.pk3:deco/monsters/imp.txt:1 Warning: new replacement is at SmoothDoom-2018-12-18.pk3:deco/variants.txt:99 Warning: PLEASE, FIX THE CODE!
  7. ketmar

    Crispy Doom 5.4 (Update: December 17, 2018)

    you may create another shortcut to Crispy, with "-file" in command line. this is required argument to load custom pwads. then you can d-n-d your pwads onto this new shourtcut, and it should work. i hope, it was a long time since i used any DE. but i think it should work as expected.
  8. meh, this is the easy one: you have unicode BOM chars there, right after the number. remove them, and you'll be fine. p.s.: note that those chars may be invisible in some editors. so you can just delete the whole line and retype it. don't copy-paste, retype it from scratch.
  9. ketmar

    DISCHARGE! - My Endgame

    yeah, the map looks great, and it is still playable. anyway, i think that in next 10 years or so hardware will be able to render it with silk-smooth 60 FPS anyway, so it is better to have nice-looking one today, with some FPS drop. ;-) it is still possible to do some heavy trickery (make a solid wall with sky toptexture, and use ACS triggers to remove it when the player is close or something), but meh... the map is still perfectly playable in its current form. we, engine authors, should optimise our code instead. ;-)
  10. ketmar

    k8VaVoom: no good thing ever dies!

    i am still not happy with checkpoint system (too much manual work), but let it be like that for now. it producing very small (~1kb if you're playing without alot of mods) saves that should survive most save file format changes i'd make in the future. it may glitch with some complex mod, but as far as i can see -- it shouldn't. sadly, Strife and Hexen are hub-based, and they're complex enough to be first targets of this feature, and oops. what a cruel world! still, i am working on better save format. i remember my RAGE AND HAET when GZDoom breaks its saves, and this is the rare case i happy that k8vavoom doesn't have huge userbase. people will lynch me for losing their progress. ;-)
  11. ketmar

    k8VaVoom: no good thing ever dies!

    thank you! i always thought that Vavoom is overlooked gem. i waited for years for someone to pick it up and continue developement, but nobody came. so i basically had no other choice than to do it myself. and it is great that people still remember Vavoom, even if it is just for some nostalgia or curiosity. ;-) welcome, and i hope that k8vavoom will work for you. maybe someday it can even become your sourceport of choice. ;-)
  12. ketmar

    k8VaVoom: no good thing ever dies!

    so, to make this back on topic: i implemented PoC of checkpoint saves at map start, and it seems to work. it even autodetects mapsets with hubs, and silently reverts to full saves in this case. now i have to throw all that code away, and write it for real. ;-)
  13. ketmar

    k8VaVoom: no good thing ever dies!

    it is a tool for people who mostly knows nothing about internal structure of wads and zips. so creating invalid zips and barely valid wads should be hard. user should be forced to turn on "expert mode" to get rid of checks, not to do something to perform those checks. that is how tools for non-programmers should work. but tbh, i have little interest in talking about slade anymore. i won't going to fix it myself, and fix for zips for the next major release is not enough. so it will be broken for a long time, and i will be forced to keep workarounds for its files. while i am accepting it, sometimes i am so annoyed that it leads to public rant. sorry for that. i myself not free from errors and bad design too. that is, slade is a good tool. the sole reason i am so enraged is that it is a good tool with some warts. i only enraged about things i really care about. yeah, i know that it is not the best attutude to get things fixed. sorry about that.
  14. ketmar

    k8VaVoom: no good thing ever dies!

    oh, yeah. vanilla had some bugs, so let's repeat the same bugs with our tools. now instead of only detect and workaround that for vanilla iwads (their signatures are well-known, and it is easy to workaround), let's declare it as "feature", and carry it with us to the end of times. definitely a good way to create a toolset, what could possibly go wrong? p.s.: note that you can ignore duplicates in iwads. it is not so for other duplicates slade loves to create. try to ignore duplicate decorate lumps, for example. or pnames. but you have to ignore some other duplicates. that is what i am whine about: it is all inconsistent, and not really well documented. slade was in position to fix that, ignoring the way broken zdoom loader works, and forcing the right layout... but it choose to not do that.
  15. ketmar

    k8VaVoom: no good thing ever dies!

    @-TDRR- also, i must confess that networking is somewhere at the bottom of my TODO list. that is, it works, and it has good design (by Janis), but it needs more love (finish some things, and polish other things). as i am not playing mp games, i only fixed some obvious bugs, and that's all. there is only so much time one man can spend on coding, so i have to manage priorities. ;-) i will prolly implement `A_FireSTGrenade`, but `A_Warp` is HUGE. i looked at it several times already, but it is so full of various flags and other crap, that it is a PITA to implement (it should be several different code points, but it is too late, of course). as k8vavoom replaces unknown code pointers with NOP, omiting `A_Warp` should not be fatal.