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

k8vavoom: no good thing ever dies!

Recommended Posts

23 hours ago, Lila Feuer said:

Ha, KDiZD doesn't load in k8vavoom, at all, it just locks up.

yep, it was a bug with cameras rendering. thank you, fixed. i will prolly do a maintenance release later (i got some other such small things to fix, and hope to release a build with those minor annoyances removed).

Share this post


Link to post

I've tried using k8vavoom for the first time ever and it seems to be a pretty cool port.

 

My favorite k8vavoom feature so far, is that is only lists savegames relevant for the specific combination of mods and wads that you used when saving... It is VERY confusing that all savegames are in one big pile in GZDoom

Edited by CBM

Share this post


Link to post

@ketmar What follows is probably a really stupid question, but i am going to ask it anyway.

 

So. Things like Arcane Dimensions have utterly amazing lighting, which is achieved through modified versions of good old LIGHT.EXE which was used to lit up Quake. Ofcourse many years have passed, so these modified versions can do a lot more now, multithreaded rendering, bounce lighting, ambient occlusion, and so on.

 

Dumb question; Given K8Vavoom (and Vavoom) are based off Quake and understand the Quake principles (BSP, VIS, etc): Would it be possible to use these tools to bake lights for K8Vavoom maps?

Share this post


Link to post

@CBM thank you! hope you'll find even more k00l features inside. ;-)

 

18 hours ago, Redneckerz said:

Dumb question; Given K8Vavoom (and Vavoom) are based off Quake and understand the Quake principles (BSP, VIS, etc): Would it be possible to use these tools to bake lights for K8Vavoom maps?

technically, yes. realistically, no. first, they need properly prepared Quake BSP to work. second, even if you will manage to somehow make them work with Doom BSP, it won't help. because k8vavoom rebuilds BSP for each new map (it always ignores any pwad nodes), and on top of that, it does more surface subdivisions to better fit lightmaps. neither of algorithms are fixed and predictable. and on top of that, all the hard work on precalculating light will go directly to the trash bin with volume shadows/shadowmap renderers anyway, because they aren't using lightmaps at all.

 

so, while all technical problems are solveable, i don't see good enough reasons to invest any time in that.

Share this post


Link to post
1 hour ago, ketmar said:

@CBM thank you! hope you'll find even more k00l features inside. ;-) 

Nice and I'm sure I will :-D

I really like the effect shown in Freaky Panties IV with the moving 3D crate for example!

 

And I am glad I could help in uncovering the bug that caused the playerTID to be 0 each time resurrect is used

 

Does k8vavoom also work as a quake engine,

ie. does it support loading of Quake maps (could we mix and match Doom and Quake with this engine)?

You added support for MD3 (my favorite format for animated models),

does it support OBJ (could be usefull) & MDL (since vanilla Quake uses MDL models) & MD2 (not really needed and is just trash) as well?

And how is the 3D floor performance (since Quake is a 3D game I suspect it is much better than in GZDoom)?

Finally, could a special BSP map format targeting the union of modern Doom and Quake become a thing in k8vavoom, such that we get the 3D level performance of Quake and the gameplay of Doom in a single map format (much like GZDoom has the UDMF map format)?

 

The poor 3D performance and all the tricks needed to save on the use of 3D floors like using portals in conjunction with 3D floors etc really is the biggest hurdle in GZDoom and keeps classic Doom from truly ascending to new heights IMO

 

Now I'm off to play all the stuff mentioned in the first post in this thread! :-D

 

EDIT

 

just played an old vanilla map of mine and the sky looked weird at one place... like a quilt sewn together in a cross... I haven't found a way to take screenshots so I cant show a picture of it but it looks odd... also, windows 10 doesnt seem to be able to minimize the window, atleast not in fullscreen mode

 

also tried my WIP 40k mod and the models seem to load but without textures, odd... however k8vavoom would be a port where I would be very interested in making 3D model packs for once I know what differences it has compared to GZDoom that would prevent textures from loading... nothing in the debug log suggests it should have issues

 

I really like that hitscanners automatically has visual tracers on their shots

Edited by CBM

Share this post


Link to post
1 hour ago, CBM said:

Does k8vavoom also work as a quake engine

no. it was explained in another thread, afaik, why this is totally impossible. it's like trying to combine a truck and a formula bolid: sure, they both have tires, but it doesn't mean that you can make a truck formula bolid. ;-)

 

1 hour ago, CBM said:

does it support OBJ (could be usefull) & MDL

no and no.

 

1 hour ago, CBM said:

MD2

yes.

 

1 hour ago, CBM said:

And how is the 3D floor performance

the same as in any other idTech1 engine.

 

please, undestand that idTech1 is NOT idTech2, and they cannot be mixed. whatever you do, idTech1 will remain idTech1, with all its limitations. there is no magic way to run it in "full 3D", it wouldn't work. k8vavoom is not different from others, it simply does some visual tricks to make it look like it's something more. but it's still good old idTech1 at its core, the same tech that powers all other Doom sourceports.

 

1 hour ago, CBM said:

and the sky looked weird at one place

Vavoom is using "sky sphere" to render vanilla skies, and it's quite obvious if you'll look extremly up or down. it may look… hm… unusual, but i like it, so i kept that sphere effect.

 

1 hour ago, CBM said:

I really like that hitscanners automatically has visual tracers on their shots

those are not simple tracers, those are actual projectiles. by default all standard hitscanners shoot projectiles now, so the tracers you see are actual projectiles flying, no cheating! ;-)

Share this post


Link to post
57 minutes ago, ketmar said:

the same as in any other idTech1 engine.

 

please, undestand that idTech1 is NOT idTech2, and they cannot be mixed. whatever you do, idTech1 will remain idTech1, with all its limitations. there is no magic way to run it in "full 3D", it wouldn't work. k8vavoom is not different from others, it simply does some visual tricks to make it look like it's something more. but it's still good old idTech1 at its core, the same tech that powers all other Doom sourceports.

 

Vavoom is using "sky sphere" to render vanilla skies, and it's quite obvious if you'll look extremly up or down. it may look… hm… unusual, but i like it, so i kept that sphere effect.

 

those are not simple tracers, those are actual projectiles. by default all standard hitscanners shoot projectiles now, so the tracers you see are actual projectiles flying, no cheating! ;-)

ok, well would it be possible to somehow make the engine or a preprocessor do optimizations to maps such that it can figure out the best way to gain the same effect but slightly change how its done... like a map with excessive 3d floors being changed to a structure where it actually uses portals etc to achieve the same effect with less performance overhead?

 

I like that everything uses actual projectiles, but some people seem to think something is lost if hitscanners are no longer hitscanners.. I had an idea to make a gameplay mod like this for GZDoom so that we could finally get rid of hitscanners :-)

 

I guess I could just decide to not use hitscanner mechanics in my maps and mods

Share this post


Link to post
2 hours ago, CBM said:

The poor 3D performance and all the tricks needed to save on the use of 3D floors like using portals in conjunction with 3D floors etc really is the biggest hurdle in GZDoom and keeps classic Doom from truly ascending to new heights IMO

fwiw... I've found that doing 3d stuff with portals tends to kill the experience as far as smooth performance goes, while using actual 3D floors has very little performance impact.  Even on a modern system that is not "a potato" (i7 + 1080 at the time, i9 + 1080 now), the more portals visible, the more sluggish the input feels in GZDoom, and (eventually) the quicker the FPS drops.  I can't say for sure if this is a Linux-specific or nvidia-specific thing, but it's one reason I never use portals for 3d stuff in my maps.  All my 3D stuff is just plain old 3D floors, or the occasional 3D polyobject, and so I never have the performance issue as far as 3d architecture goes.

 

But afaik, K8Vavoom doesn't support portals in the first place :-P

EDIT: I'm sure the big performance killers in my maps are lots of on-screen geometry and far too many lights :-P

Share this post


Link to post
Just now, Remilia Scarlet said:

fwiw... I've found that doing 3d stuff with portals tends to kill the experience as far as smooth performance goes, while using actual 3D floors has very little performance impact.  Even on a modern system that is not "a potato" (i7 + 1080 at the time, i9 + 1080 now), the more portals visible, the more sluggish the input feels in GZDoom, and (eventually) the quicker the FPS drops.  I can't say for sure if this is a Linux-specific or nvidia-specific thing, but it's one reason I never use portals for 3d stuff in my maps.  All my 3D stuff is just plain old 3D floors, or the occasional 3D polyobject, and so I never have the performance issue as far as 3d architecture goes.

 

But afaik, K8Vavoom doesn't support portals in the first place :-P

Ok, well I've made some maps that really tanks FPS due to the use of 3d floors... maps like castle of secrets (a castle made out of 3d floors where needed) and navy (just used 3d floors to make some 'floating ships')

Share this post


Link to post
59 minutes ago, CBM said:

but some people seem to think something is lost if hitscanners are no longer hitscanners

…and that's why we have the option to turn it off. any such gameplay-breaking change has the corresponding option to "undo" it.

 

1 hour ago, CBM said:

like a map with excessive 3d floors being changed to a structure where it actually uses portals etc to achieve the same effect with less performance overhead?

first, portals are ALWAYS slower than 3d floors. and second, k8vavoom doesn't support portals, and this won't change. portals is a misfeature, and i won't going to implement it.

 

43 minutes ago, CBM said:

Ok, well I've made some maps that really tanks FPS due to the use of 3d floors...

and this is usually the clear sign that you're using the wrong engine. not wrong sourceport, but the wrong tech. idTech1 is a bad choice for any kind of complex 3d geometry, it simply wasn't designed for that. there is no magic trick that will suddenly make idTech1-based engine to process complex maps lightning fast. it is simply impossible. not "hard to do", but impossible. GZDoom is one of the fastest idTech1 engines out there (and that includes rendering), so if it doesn't work ok on GZDoom, you can abandon all hope of finding some another sourceport that does it better. if your maps really need that complex geometry, you'd better switch to some real 3D engine, like Quake or Unreal. this is the only practical solution. ask any sourceport dev, and they all will tell you the same. it's not because we all so stubborn, it's because you're asking for impossible things.

Share this post


Link to post
3 minutes ago, ketmar said:

and this is usually the clear sign that you're using the wrong engine. not wrong sourceport, but the wrong tech. idTech1 is a bad choice for any kind of complex 3d geometry, it simply wasn't designed for that. there is no magic trick that will suddenly make idTech1-based engine to process complex maps lightning fast. it is simply impossible. not "hard to do", but impossible. GZDoom is one of the fastest idTech1 engines out there (and that includes rendering), so if it doesn't work ok on GZDoom, you can abandon all hope of finding some another sourceport that does it better. if your maps really need that complex geometry, you'd better switch to some real 3D engine, like Quake or Unreal. this is the only practical solution. ask any sourceport dev, and they all will tell you the same. it's not because we all so stubborn, it's because you're asking for impossible things.

 

hm, that might be true.

If only Doom 3 had the same traction as Doom 1 and 2.

 

I would loved it if there had been the same amount of sourceports, tools and community around Doom 3 modding as there is around Doom 2 modding

Share this post


Link to post
5 minutes ago, CBM said:

I would loved it if there had been the same amount of sourceports, tools and community around Doom 3 modding as there is around Doom 2 modding

i think it doesn't have the same big community for two reasons. first, doing "real 3d maps" is harder. now we have tools like Trenchbroom, but the original Doom3 editor is not that fun to use. and there is always an entry barrier too, because drawing some 2D map seems to be much easier task than crafting full 3D map. of course, for complex map it usually reversed (i.e. create complex 3D geometry is much easier with a real 3D engine), but Doom editing has that great feeling of "easy start".

 

and second, Doom3 is not a good game by itself. don't get me wrong, it's not bad, but it is so far from the previous Doom formula, that fans simply didn't got it. people were going into Doom3 expecting the same frantic action they enjoyed in the previous installments, but got something closer to horror survival expirience. so fans of the first Dooms were disappointed, and horror game fans simply didn't looked at it, because they aren't expecting such gameplay style from something called Doom.

 

and i agree that it is really sad, because the engine is good, and we could get a lot of very cool mods with it. but… alas.

Share this post


Link to post
5 hours ago, ketmar said:

@CBM thank you! hope you'll find even more k00l features inside. ;-)

 

technically, yes. realistically, no. first, they need properly prepared Quake BSP to work. second, even if you will manage to somehow make them work with Doom BSP, it won't help. because k8vavoom rebuilds BSP for each new map (it always ignores any pwad nodes), and on top of that, it does more surface subdivisions to better fit lightmaps. neither of algorithms are fixed and predictable. and on top of that, all the hard work on precalculating light will go directly to the trash bin with volume shadows/shadowmap renderers anyway, because they aren't using lightmaps at all.

 

so, while all technical problems are solveable, i don't see good enough reasons to invest any time in that.

Well multibounce static lighting looks fly ;) there is a lot of tools available and given the recent development of ZDRay, it got me thinking: Why does Vavoom/K8Vavoom not look into this?

 

A side-silly question: How would Vavoom fare? Same answer? ;)

1 hour ago, ketmar said:

 it's not because we all so stubborn, it's because you're asking for impossible things.

Nothing is impossible ;) Its just that to combat the facets that are inherent on Doom's rendering would take a madman to effectively refactor or emulate through an original engine.

 

But who is to say? Stranger Things have happened. Both the show and in Doom.

Share this post


Link to post
18 hours ago, Redneckerz said:

Why does Vavoom/K8Vavoom not look into this?

well, it looks Good Enough(tm) for me. ;-) external lightmap builder is yet another gimmick that will be used once or twice, and then forgotten. but to support that i have to write a lot of code to convert external lightmaps to fit internal vavoom subdivided surfaces, or invent The Whole New Format for this, and convince tool authors to support it. the idea is interesting, but the amount of work… well, i don't think it worth it.

 

besides, you cannot use real-time shadows with it.

 

p.s.: btw, k8vavoom already does some ambient occlusion in lightmapped mode, due to ray tracer imperfections. well, technically it's a bug, but sometimes it looks like AO. ;-)

 

18 hours ago, Redneckerz said:

A side-silly question: How would Vavoom fare? Same answer? ;)

ahem… i failed to decipher the question, sorry. i mean, literally, it's beyond my English.

 

18 hours ago, Redneckerz said:

Nothing is impossible

it was explained in some other thread: the only way to do that is to have two different engines, with completely different data structures, rendering, physics, even actor representation, and pretend that it is still the one engine. it will never work right. it may work "good enough" to record short youtube videos in controlled environment, but in the end of the day it won't be a good Doom engine, and it won't be a good Quake engine. Doom is absolutely different from any later "sane" 3D engine. even BSP tree in Doom is inverted: it doesn't store solids, it stores empty spaces instead! and physics, oh, Doom physics… slopes and 3D floors are so fragile because the physics in Doom is 2D. and it doesn't matter which internal data structures one will use: you either have to keep that 2D mess, or it won't be Doom. i'm still trying to replace it with BSP-based coldet (already at 4th iteration), but each time it ends up in uncontrollable mess, because it should work almost exactly the same as the original.

 

there is simply no reason trying to "advance" idTech1 in that way: in the end of the day you will get a half-assed Q-like engine that is kept together with a ton of duct tape, cannot play Doom properly, and still much worser than even Quake1.

 

yet creating Doom-like 2D-ish map editor that can generate Quake maps looks like an interesting idea. ;-)

Share this post


Link to post

would an idtech2 engine be able to load a doom wad and internally convert it to a quake level? or will it not work for the reasons stated above?

 

I mean, an engine build on idtech2 that is focused on quake but has the minimum required amount of idtech1 duct tape to qualify as a 'doom engine'... like a quake engine in disguise

 

conversion of doom map to a quake map:

https://github.com/luser/wad2map

 

the map could be converted in memory on load

 

FrankenDoom?

 

able to load pure vanilla wads maybe but uses bsp as native next gen map format

Edited by CBM

Share this post


Link to post
18 minutes ago, CBM said:

would an idtech2 engine be able to load a doom wad and internally convert it to a quake level?

it will be completely static. all Quake and post-Quake engines are using separate brushes (3d objects) for lifts and doors, but Doom directly modifies map geometry instead. that's one of the reasons why Doom hardware-accelerated rendering is much slower than in Quake: there is nothing given about Doom map, it can change at any time. so most optimisations possible with engines using immutable geometry are out of picture, and idTech1 engine has to feed GPU with data on each frame instead of doing that once on map loading, and then simply tell GPU to draw what it already has in its memory.

 

you can create some heuristics to detect doors and lifts, and to convert them to brushes (that's basically what id did in the nuDoom for E1 easter egg), but it is very fragile, and will break with most modern maps. so you will have the engine that is more-or-less capable of playing vanilla iwads, some other pwads you specifically tought it, and that's all. and those things are already perfectly playable in any existing sourceport anyway. ;-) to take the full advantage of such engine you will have to use Quake editor to create Quake maps… and what is the reason to NOT use Quake in this case? ;-)

Share this post


Link to post
10 minutes ago, ketmar said:

it will be completely static. all Quake and post-Quake engines are using separate brushes (3d objects) for lifts and doors, but Doom directly modifies map geometry instead. that's one of the reasons why Doom hardware-accelerated rendering is much slower than in Quake: there is nothing given about Doom map, it can change at any time. so most optimisations possible with engines using immutable geometry are out of picture, and idTech1 engine has to feed GPU with data on each frame instead of doing that once on map loading, and then simply tell GPU to draw what it already has in its memory.

 

you can create some heuristics to detect doors and lifts, and to convert them to brushes (that's basically what id did in the nuDoom for E1 easter egg), but it is very fragile, and will break with most modern maps. so you will have the engine that is more-or-less capable of playing vanilla iwads, some other pwads you specifically tought it, and that's all. and those things are already perfectly playable in any existing sourceport anyway. ;-) to take the full advantage of such engine you will have to use Quake editor to create Quake maps… and what is the reason to NOT use Quake in this case? ;-)

the idea would be to give quake some doom makeup so it could be sold to the doom crowd as a next gen option, by making it able to run pure vanilla doom wads it would technically classify as a doom engine while initially needing a quake editor to create next gen maps.... until ultimate doom builder or a fork of it decided to support the bsp map format.. no need for it to support UDMF or BOOM stuff

 

and to have a platform to further improve idtech2 as idtech1 has with gzdoom and k8vavoom :-)

 

I cant believe ultimate doom builder isnt shipping with k8vavoom support already btw

Edited by CBM

Share this post


Link to post
46 minutes ago, CBM said:

I cant believe ultimate doom builder isnt shipping with k8vavoom support already btw

there is nothing really special there, normal GZDoom config should work most of the time. the only major missing part is 3d polyobjects, but they are relatively new, and the spec is not even finalized yet (it should be stable, but i didn't declared it "final" for now).

 

ah, and you also have to check dynamic lighting in k8vavoom itself, because it's light formulas are slightly different from GZDoom, so UDB 3d preview with dynlights will not exactly match what you will see in k8vavoom. it is roughly the same, but not exact.

 

still, i don't think that there is any urgent need to add separate k8vavoom support to UDB. i'm planning to submit configs to SLADE (and maybe UDB) later, tho. the only problem is that UDB is simply doesn't work on my box. ;-)

 

p.s.: as for improved idTech2 — DarkPlaces is basically "GZDoom of Quake1 engines", i believe. it has a lot of features, including realtime lighting and shadows with shadowmaps (written by no other than Lee Salzman of Tesseract fame!).

Share this post


Link to post
11 minutes ago, ketmar said:

p.s.: as for improved idTech2 — DarkPlaces is basically "GZDoom of Quake1 engines", i believe. it has a lot of features, including realtime lighting and shadows with shadowmaps (written by no other than Lee Salzman of Tesseract fame!).

hey! pretty cool! Maybe my excessive need for stacking floors on top of each other can be satisfied by darkplaces  :-D

Share this post


Link to post

@CBM just in case, i meant that DarkPlaces is one of the most advanced Quake1 engines, not that it supports anything from Doom. ;-)

Share this post


Link to post
20 minutes ago, ketmar said:

@CBM just in case, i meant that DarkPlaces is one of the most advanced Quake1 engines, not that it supports anything from Doom. ;-)

Yes I know. But it seems to have a somewhat "active" community.

And Quake 1 BSP maps do support true 3D maps.

Share this post


Link to post

Probably the best place for darkplaces would be Xonotics version: https://gitlab.com/xonotic/darkplaces

 

After the author of Nexuiz sold-out to game developers (hence why Xonotic was forked) they also forked all dependent code, so they also develop darkplaces.  And they are much better developers than the original author was.

 

Darkplaces' main site is barely updated and the git repo has 'some' activity.  But not on the same level as Xonotic's version (which most people use instead now).

Share this post


Link to post
7 hours ago, ketmar said:

there is nothing really special there, normal GZDoom config should work most of the time. the only major missing part is 3d polyobjects, but they are relatively new, and the spec is not even finalized yet (it should be stable, but i didn't declared it "final" for now).

 

ah, and you also have to check dynamic lighting in k8vavoom itself, because it's light formulas are slightly different from GZDoom, so UDB 3d preview with dynlights will not exactly match what you will see in k8vavoom. it is roughly the same, but not exact.

 

still, i don't think that there is any urgent need to add separate k8vavoom support to UDB. i'm planning to submit configs to SLADE (and maybe UDB) later, tho. the only problem is that UDB is simply doesn't work on my box. ;-)

Is there a map that serves as a tech demo of k8vavoom or a list of features? maybe some tutorials?

 

It would be nice with a tech demo map that could be used to show all the different stuff that can be done in the k8vavoom engine... from what I can gather so far it supports this:

 

polyobjects (same as in GZDoom?) and 3D polyobjects (I must study ramillias latest map to figure those out)

slopes

3d floors

dynamic lighting

transparency?

conveurbelts?

scripting

intermediate screens for telling a story

3d models? (but somehow in a different way than in GZDoom?)

voxels??? (are they also just translated internally to 3d objects like in GZDoom?)

no portals, either horisontal or vertical

 

anything Ive missed? Is there a complete list?

 

4 hours ago, Gibbon said:

Probably the best place for darkplaces would be Xonotics version: https://gitlab.com/xonotic/darkplaces

 

After the author of Nexuiz sold-out to game developers (hence why Xonotic was forked) they also forked all dependent code, so they also develop darkplaces.  And they are much better developers than the original author was.

 

Darkplaces' main site is barely updated and the git repo has 'some' activity.  But not on the same level as Xonotic's version (which most people use instead now).

 

nice, I will be sure to check out that version

 

Share this post


Link to post
3 hours ago, CBM said:

Is there a map that serves as a tech demo of k8vavoom or a list of features?

it is mostly on par with GZDoom (except the portals, and stacked sector support is still buggy). the major difference is the lighting. so most of GZDoom expirience applies.

 

3 hours ago, CBM said:

3D polyobjects (I must study ramillias latest map to figure those out)

…or try to take a closer look at the k8vavoom archive you downloaded. the "specs/" directory is not just sitting there to make the archive bigger. ;-)

 

3 hours ago, CBM said:

3d models? (but somehow in a different way than in GZDoom?)

basic GZDoom MODELDEF is supported. the major difference is model scaling/translation: it is not stacked, as in GZDoom.

 

3 hours ago, CBM said:

voxels???

sorry, no voxel support at all.

 

3 hours ago, CBM said:

anything Ive missed? Is there a complete list?

basically, "if it works in GZDoom, and it is not using portals/ZScript/player morphing, then it should work in k8vavoom too". of course, it is slightly more complicated, because not all GZDoom features are supported, but most of the time everything works as expected. and if not, k8vavoom will usually tell you what is wrong, just look at "conlog.log".

 

and VavoomC is not documented on purpose: i DO NOT want people to use it. if somebody can figure out things on their own… well, so be it. but VavoomC is not set in stone, and anything can change at any moment. if somebody will want to write a completely new game using k8vavoom tech, then they'd better contact me, and we'll find a solution. but otherwise DECORATE is the way to go, and if you can't do it with DECORATE… don't do it. ;-)

 

contrary to GZDoom, k8vavoom is not trying to be a general game engine. yes, you can use it to write a non-Doom game, it is at least as extensible and modifiable as GZDoom, but that's not how i see it.

 

don't get me wrong, i have nothing against standalone games on k8vavoom tech. but to officially support that i will have to mostly freeze the development. GZDoom has ZScript versioning due to that, and it adds a lot of maintenance burden. i don't have enough resources to go that way, so VavoomC is not documented, and not meant to be used by modders.

 

note that in GZDoom you extend the engine with ZScript. but with k8vavoom, you have it written in VavoomC. everything except the renderer and some low-level subsystems is done with VavoomC, including the whole playsim with physics. so exposing VavoomC to modders will mostly force me to freeze everything as it is now to keep it compatible with released VavoomC mods.

Share this post


Link to post
1 hour ago, ketmar said:

it is mostly on par with GZDoom (except the portals, and stacked sector support is still buggy). the major difference is the lighting. so most of GZDoom expirience applies.

 

…or try to take a closer look at the k8vavoom archive you downloaded. the "specs/" directory is not just sitting there to make the archive bigger. ;-)

 

basic GZDoom MODELDEF is supported. the major difference is model scaling/translation: it is not stacked, as in GZDoom.

 

sorry, no voxel support at all.

 

basically, "if it works in GZDoom, and it is not using portals/ZScript/player morphing, then it should work in k8vavoom too". of course, it is slightly more complicated, because not all GZDoom features are supported, but most of the time everything works as expected. and if not, k8vavoom will usually tell you what is wrong, just look at "conlog.log".

 

and VavoomC is not documented on purpose: i DO NOT want people to use it. if somebody can figure out things on their own… well, so be it. but VavoomC is not set in stone, and anything can change at any moment. if somebody will want to write a completely new game using k8vavoom tech, then they'd better contact me, and we'll find a solution. but otherwise DECORATE is the way to go, and if you can't do it with DECORATE… don't do it. ;-)

 

contrary to GZDoom, k8vavoom is not trying to be a general game engine. yes, you can use it to write a non-Doom game, it is at least as extensible and modifiable as GZDoom, but that's not how i see it.

 

don't get me wrong, i have nothing against standalone games on k8vavoom tech. but to officially support that i will have to mostly freeze the development. GZDoom has ZScript versioning due to that, and it adds a lot of maintenance burden. i don't have enough resources to go that way, so VavoomC is not documented, and not meant to be used by modders.

 

note that in GZDoom you extend the engine with ZScript. but with k8vavoom, you have it written in VavoomC. everything except the renderer and some low-level subsystems is done with VavoomC, including the whole playsim with physics. so exposing VavoomC to modders will mostly force me to freeze everything as it is now to keep it compatible with released VavoomC mods.

well... if the code is open source then there is a way to get documentation on VavoomC and if one has experience coding in C then one is already well prepared :)

 

To avoid future compatibility issues then I guess your are on point by suggesting sticking to decorate for now...

 

but I cant help wonder.. will maps like Freaky Panties IV break in future versions of k8vavoom since it uses a ton of scripting?

 

I'm asking because I was thinking about how FreeDOOM would look if the levels got k8vavoom enhancements similar to what I have been trying to do in GZDoom (with GZFreeDOOM/GZFreePunk). There are still many things in GZDoom I don't know so it would be difficult for me to make a souped up version of the freedoom levels to serve as a GZDoom tech demo... But since k8vavoom has... less features right now... It would perhaps be more feasible to me to learn all there is to learn about k8vavoom mapping and use THAT to make something like a FreeVavoom project (a FreeDOOM ipk3 for k8vavoom)

 

FreeVavoom would also be a name sufficiently different from the FreeDOOM name to avoid giving the FreeDOOM team trouble

 

Still just an idea floating in my head though.

 

Edited by CBM

Share this post


Link to post
14 hours ago, ketmar said:

ah, and you also have to check dynamic lighting in k8vavoom itself, because it's light formulas are slightly different from GZDoom, so UDB 3d preview with dynlights will not exactly match what you will see in k8vavoom. it is roughly the same, but not exact.

 

That shouldn't be much of an issue, to this day UDB does not cast GZDoom's crappy shadowmaps in visual mode, which is a bigger differennce between visual mode and in-game, than there would be with UDB not displaying K8Vavoom's slightly different from GZDoom, lights.

Share this post


Link to post
17 hours ago, ketmar said:

well, it looks Good Enough(tm) for me. ;-) external lightmap builder is yet another gimmick that will be used once or twice, and then forgotten. but to support that i have to write a lot of code to convert external lightmaps to fit internal vavoom subdivided surfaces, or invent The Whole New Format for this, and convince tool authors to support it. the idea is interesting, but the amount of work… well, i don't think it worth it.

So nothing from the various variants of Light.exe (Which is basically how they compute that nice lighting seen in AD) would be sufficient?

17 hours ago, ketmar said:

ahem… i failed to decipher the question, sorry. i mean, literally, it's beyond my English.

Would Vavoom be more able to take advantage of lightmaps done through these lightmap compilers being that its less advanced than K8Vavoom?

17 hours ago, ketmar said:

it was explained in some other thread: the only way to do that is to have two different engines, with completely different data structures, rendering, physics, even actor representation, and pretend that it is still the one engine. it will never work right. it may work "good enough" to record short youtube videos in controlled environment, but in the end of the day it won't be a good Doom engine, and it won't be a good Quake engine.

Close, but no cigar. What if (hypothetically) the new engine mimicks behavior exactly, similar to how byuu's SNES emulator worked out so well/

 

15 hours ago, ketmar said:

p.s.: as for improved idTech2 — DarkPlaces is basically "GZDoom of Quake1 engines", i believe. it has a lot of features, including realtime lighting and shadows with shadowmaps (written by no other than Lee Salzman of Tesseract fame!).

There are various advanced Quake derivatives out there - Darkplaces may not even be the latest.

 

Ill never forget that short lived Nexuiz 2010 GDC demo where Darkplaces was demonstrated on PS3 and X360. Illfonic bought a license from id to use the Quake engine, and a license from then LordHavoc to get a license aswell. Ultimately, they shipped with Cryengine. But Darkplaces on console was a short lived reality.

 

Fortunately Wrath may now take its place :)

Share this post


Link to post
12 hours ago, CBM said:

well... if the code is open source then there is a way to get documentation on VavoomC and if one has experience coding in C then one is already well prepared :)

sure, and that's how i learned everything i know about Vavoom too. ;-)

 

12 hours ago, CBM said:

will maps like Freaky Panties IV break in future versions of k8vavoom since it uses a ton of scripting?

it uses only a little amount of VavoomC, and everything else is done with ACS. besides, early adopters get a cookie, and free lifetime support contract! ;-) (no, Remilia, please, i tasted that cookie a little… then a little more… we have only contracts for now.)

 

12 hours ago, CBM said:

It would perhaps be more feasible to me to learn all there is to learn about k8vavoom mapping

there is very little difference between advanced sourceports actually. at least in terms of mapping. if you will stay away from portals, stacked sectors, and mirrors, then the difference is mostly non-existent. (stacked sectors and mirrors are broken in k8vavoom now; they will be eventually fixed, but it's not a high priority, and i want to rewrite some parts of the rendering code first).

 

i mean, you don't have to choose right now, and can either switch later, of even support both engines. i have nothing against GZDoom, k8vavoom and GZDoom are not rivals, and if somebody can support both, than it's great, because players will have more choice. and giving people a way to play maps in the sourceport they prefer is very important, i believe.

 

8 hours ago, Redneckerz said:

So nothing from the various variants of Light.exe (Which is basically how they compute that nice lighting seen in AD) would be sufficient?

there is no "Universal Doom Lightmap Format", and each engine does lightmaps it's own way. algorightms for radiocity tracers are well-known, there's nothing magical there. but most of the code that actually implements those algorithms is not applicable, due to different BSP and other data formats. so one will basically have to rewrite it from the scratch anyway.

 

8 hours ago, Redneckerz said:

Would Vavoom be more able to take advantage of lightmaps done through these lightmap compilers being that its less advanced than K8Vavoom?

lightmapping idea is the same everywhere: multiply texture colors by lightmap. so improving lightmaps quality will automatically make a lightmapped engine look better. there is no difference here between Vavoom and k8vavoom (sans some fixed bugs). ah, and the fact that k8vavoom can at least cache calculated lightmaps, and load them later, so there is some way to give k8vavoom external lightmaps already, but Vavoom can't read lightmaps from disk at all.

 

8 hours ago, Redneckerz said:

What if (hypothetically) the new engine mimicks behavior exactly, similar to how byuu's SNES emulator worked out so well

then it will be called "Chocolate Doom". ;-)

 

8 hours ago, Redneckerz said:

There are various advanced Quake derivatives out there - Darkplaces may not even be the latest.

as far as i know, DarkPlaces was the only one that tried to add more features, maybe sacrificing some compatibility by the way. i.e. basically what GZDoom does. other engines may have several new features added, but mostly trying to stay "true to the original". or dropping the idea of being "Quake engines" at all, and going their own way.

 

but of course, i may be wrong here, i'm not watching Quake scene closely. that's what i know about Quake engines, it can be used as a starting point, but sure, don't take my words as The Definitive Truth. ;-)

Share this post


Link to post
1 hour ago, ketmar said:

it uses only a little amount of VavoomC, and everything else is done with ACS. besides, early adopters get a cookie, and free lifetime support contract! ;-) (no, Remilia, please, i tasted that cookie a little… then a little more… we have only contracts for now.)

 

there is very little difference between advanced sourceports actually. at least in terms of mapping. if you will stay away from portals, stacked sectors, and mirrors, then the difference is mostly non-existent. (stacked sectors and mirrors are broken in k8vavoom now; they will be eventually fixed, but it's not a high priority, and i want to rewrite some parts of the rendering code first).

 

i mean, you don't have to choose right now, and can either switch later, of even support both engines. i have nothing against GZDoom, k8vavoom and GZDoom are not rivals, and if somebody can support both, than it's great, because players will have more choice. and giving people a way to play maps in the sourceport they prefer is very important, i believe.

does k8vavoom support surfaceskin? if not, then that may explain why some of the MD3 space marines don't have textures while my OBJ fireballs have, since they just use skin to assign a single texture to a single model

 

is there somewhere where I can get an overview of ALL features present in sourceports and what sourceports that supports what features?

 

that way I will have a roadmap to follow so that I know what I still need to learn in order to have tried all features supported by the more advanced sourceports

 

I agree that choice is important

Share this post


Link to post
Guest
This topic is now closed to further replies.
×