Jump to content

TDRR

Members
  • Posts

    58
  • Joined

  • Last visited

1 Follower

About TDRR

  • Rank
    Mini-Member
    Mini-Member

Recent Profile Visitors

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

  1. Fair enough, that's reasonable. Either way I just decided to lower the resolution and played around with some of the shadowmap and light filtering features, and squeezed some more performance out. Looks pretty and runs acceptably, so I'm happy! :p I wonder, though- are there any other options? Going back to Windows for this PC is an absolute no for me, those drivers are horrible and crash exceedingly often. And in Linux, well the other ones I know are practically ancient Mesa versions under a different name, AFAICT. Either way, I'll stick with this, so thanks anyways.
  2. Hey man! Hope you're doing alright, good luck out there. I've recently tried to compile and run k8v on Puppy Slacko 8.3.2 beta, which was shockingly, really easy! Didn't expect the only requirement to be SDL2, that's awesome. But I've run into an issue. While shadowmaps work fine, neither stencil shadows nor lightmaps work. Stencil shadows just behave as if dyn lights had been disabled, and lightmapping looks like... this: I assume that's due to this: Init: OpenGL: Intel Open Source Technology Center / Mesa DRI Intel(R) G41 (ELK) / 2.1 Mesa 21.1.1 Error: OpenGL: your GPU drivers are absolutely broken. Error: OpenGL: reported OpenGL version is NOTHING, which is a nonsense. Error: OpenGL: expect crashes and visual glitches (if the engine will run at all). Any workaround for that? (and, I'd stick with shadowmapping, but performance decays really, REALLY quick on this old iGPU)
  3. K8Vavoom even has a help parameter? That one's very rare in Doom ports :p Ah, great to know then. The idea is to help with K8Vavoom support, not kill it, so I'll definitely keep that in mind, heh. And, this isn't an issue or bug per se, but it'd be nice to have. You know how there's two multiplier CVARs for light size and brightness in GZDoom? Could K8Vavoom get that too? It might sound a bit niche, but given Heretic and Hexen have almost no custom maps it's hard to fully appreciate all of K8Vavoom's lighting enhancements in them, and that'd help a lot, even more so with Hexen which has many light-casting objects around but their light is often too dim or small to be really noticeable. EDIT: Oh, seems like Hexen MAP04 crashes on enter, with the following error:
  4. Same! Very glad to see you never stopped improving this more and more, either. That is very true :p I guess that's fine enough, I've already patched D4T v1.0.1.1 to work better with current K8V, so maybe I'll do the same, albeit with current QC:DE, given it's not likely to get updates anymore. Would be cool to play those awesome mods with a matching awesome port! Good thing it's just a warning then, lol I'll try to keep that in mind for my own stuff, thought there wasn't any workaround for a bit. Oh, that's actually fine then. I was mostly reporting that after thinking there probably was no parameter to do that (tried with -ignore-menudef because I recalled there's a -ignore-zscript which did work, so :p), but now it's not a big issue, thank you. That's reassuring, good to know it'll stay then. Ah, that's very useful! Is the one parameter necessary or optional? I'll try to continue testing and report any other inaccuracies and such. One I forgot, ACS Warp seems to not return a value, but in ZDoom it returns whether the warping failed or not.
  5. Hey, it's been a while :p It's really awesome to see the shadowmapping, and in particular that it works with sprites! One thing I always wanted was sprites to cast dynamic shadows, but of course that wasn't reasonable with the old methods. Very neat to see this, which creates a lot of pretty eye candy even in vanilla Doom maps. Besides that, I've noticed some small problems with DECORATE, ACS and MODELDEF. [DECORATE] 1. Gotos jumping to non-existing states are a fatal error. This is reasonable, because it makes no sense to do that. However, some mods do it even if they have a virtual jump before it, which is the "right way" to do it, so perhaps those cases should be replaced with a Stop or Goto Null and let go with a warning? 2. A_ZoomFactor requires two arguments, but the function in ZDoom actually doesn't require any. A call with no parameters resets the FOV back to 1.0. 3. Weapon.SlotNumber has priority over Player.WeaponSlot, but in ZDoom this is the other way around. This might break a few mods having all the weapon slots jumbled around. 4. Projectiles, when bouncing on the floor (at least those of BounceType Hexen), won't count towards the counter that would put them into the death state, so at one point they'll just slide along the floor until they hit walls enough times to explode. 5. "Spanish Inquisition says: in decorate, thou shalt use `|` to combine constants." has some false positives. As in, not even that it's called in places where flags are used properly or something, I mean stuff that uses ||, logical OR! :p Like this example from D4T: "MARM A 0 HealThing(!(velx || vely || velz))" [ACS] 6. The layer flags in HUDMessage aren't supported. Not a big deal or very high priority, it's a seldom used feature but just in case you're not aware. 7. SetMusic only supports 8-character long names, not full paths. [MODELDEF] 8. INHERITACTORPITCH is broken. Like, very broken. The models using it display upside down and facing backwards, and don't respond to any changes in pitch at all. Oh yeah, and MENUDEF. Why not ignore unknown option values? In ZDoom they're left as "unknown", but you could very well just gray them out or remove the entry completely. Surprisingly often, mods include shortcuts to various ZDoom options, but anything K8Vavoom doesn't have will cause an error. 1 and 2 in particular would be nice to have solved. They're the only things stopping QC:DE and D4T from booting up in K8Vavoom (and in fact at least D4T does play pretty nicely in K8V once that's resolved). Also, since you can check if an actor exists using SpawnForced in ACS, could one K8V-exclusive actor that is always guaranteed to be there, be added to help detect K8Vavoom reliably? I'm currently using K8Gore_Blood for that purpose, but given that's been changing from a "mod" to a built-in feature, I'm kinda afraid it'll change in the future, again.
×
×
  • Create New...