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

k8vavoom: no good thing ever dies! (2021, Jul 18 build)

Recommended Posts

1 hour ago, Redneckerz said:

The only thing i have not added in yet is a history of the port itself

it is basically like this: i always loved Vavoom, and i thought that it is The Best. Janis stopped working on Vavoom. i waited, and waited, and waited, and then decided to make my little (and private) fork. and then i read the topic on DW, "which sourceport you want to see resurrected" (or something like this), and somebody said "Vavoom" there. then i decided to finally register at DW, and make k8vavoom public.

 

some more history follows.

Spoiler

 

at first i had no way to build it for windows, but then i tried MXE crosscompiler, and it worked. that's how the first windows public build appeared.

 

most of the work at "private times" was done on extending VavoomC compiler (because i love to write compilers). when i went public, i started to improve DECORATE support, and added parsing of some [G]ZDoom textual lumps.

 

i also made stenciled renderer actually playable (from ~40 FPS at E1M1 to 80+). added proper tracing to lightmapped dynamic lights (so they start casting shadows too; it was too slow 15 years ago, but now it is working with acceptable speed). added updating of lightmaps when some static light has moved (most Doom decoration lighting converted to static lights, for example, so the engine will be able to precalculate lightmaps for those). added lightmap cache, so it won't be necessary to relight the map on game load.

 

i also added Teh Official Way to load VavoomC mods, converted most menu definitions to text files, and did alot of other cleanups. also, fixed some long-standing Vavoom bugs, like things using cylinders for hitscan detection, not boxes (and hitscan attacks didn't check the adjacent blockmap cells). implemented support for GZDoom-style 3d floors.

 

btw, k8vavoom supports sound in Opus format. also, it doesn't support sounds in MP3 format, only music (i disabled MP3 sound support due to problems with proper detection of MP3 files).

 

this might be enough for small history section at wiki. feel free to ask more questions if you need.

 

and thank you again for creating the article!

 

 

Share this post


Link to post
13 hours ago, ketmar said:

i disabled MP3 sound support due to problems with proper detection of MP3 files

Ha, yes it's quite an annoying format to quickly validate or invalidate.

Share this post


Link to post

@Gez, oh, while you're here. i created k8vavoom configuration and UDMF namespace in SLADE 3.1.12 (by copying and renaming ZDoom configs). everything is working perfectly except one thing: there is no light in 3d preview. i mean, regardless of sector light level, everything is pitch black. it works with ZDoom config, tho. of course, i don't expect you to remote debug it for me, but maybe i simply missed some obvious thing?

 

i literally copied "zdoom.cfg" to "k8vavoom.cfg", and changed "port", "name" property, "udmf_namespace" property, and added some new UDMF property definitions. ah, yes, i copied "props_zdoom.cfg" to "props_k8vavoom.cfg" too (and included it in main config).

Share this post


Link to post
2 hours ago, Gez said:

Most probably because of the hardcoded namespace check here:

oh, i see. thank you! not that i can rebuild the sources, tho, so i think i'll simply hack zdoom part for now.

Share this post


Link to post

and some more news: the new build will come with experimental game controller support. no force feedback yet, tho, sorry. it is also possible to set up to 4 bindings via options menu now. controller hotplugging should work, but if you have more than one controller attached, you cannot select which one you want to use yet (at least not with hotplug ;-). you can choose which analog stick you want to use for movement, and which one for turning/vertical look, and controller buttons can be bound in the binding configuration menu.

 

as i absolutely don't understand how people are playing Doom (or anything else ;-) with controllers, i will expect your feedback -- i don't really know what you want to be configurable, and how.

Share this post


Link to post
On 4/13/2021 at 7:17 PM, ketmar said:

it is basically like this: i always loved Vavoom, and i thought that it is The Best. Janis stopped working on Vavoom. i waited, and waited, and waited, and then decided to make my little (and private) fork. and then i read the topic on DW, "which sourceport you want to see resurrected" (or something like this), and somebody said "Vavoom" there. then i decided to finally register at DW, and make k8vavoom public.

Well, Vavoom is certainly an interesting port from the get go as it turns to Doom from a completely different angle than most ports do.

On 4/13/2021 at 7:17 PM, ketmar said:

 

some more history follows.

  Reveal hidden contents

 

at first i had no way to build it for windows, but then i tried MXE crosscompiler, and it worked. that's how the first windows public build appeared.

 

most of the work at "private times" was done on extending VavoomC compiler (because i love to write compilers). when i went public, i started to improve DECORATE support, and added parsing of some [G]ZDoom textual lumps.

 

i also made stenciled renderer actually playable (from ~40 FPS at E1M1 to 80+). added proper tracing to lightmapped dynamic lights (so they start casting shadows too; it was too slow 15 years ago, but now it is working with acceptable speed). added updating of lightmaps when some static light has moved (most Doom decoration lighting converted to static lights, for example, so the engine will be able to precalculate lightmaps for those). added lightmap cache, so it won't be necessary to relight the map on game load.

 

i also added Teh Official Way to load VavoomC mods, converted most menu definitions to text files, and did alot of other cleanups. also, fixed some long-standing Vavoom bugs, like things using cylinders for hitscan detection, not boxes (and hitscan attacks didn't check the adjacent blockmap cells). implemented support for GZDoom-style 3d floors.

 

btw, k8vavoom supports sound in Opus format. also, it doesn't support sounds in MP3 format, only music (i disabled MP3 sound support due to problems with proper detection of MP3 files).

 

this might be enough for small history section at wiki. feel free to ask more questions if you need.

 

and thank you again for creating the article!

 

 

I like your idea of history as its completely different from mines :) Thanks. I grabbed some details and updated the wiki entry accordingly on this.

On 4/14/2021 at 7:09 PM, BlooDaBeast_OG said:

how do you set this thing up?

Depends. What are you using? Windows? Or Linux?

 

For Arch Linux, there is a guide available.

10 hours ago, ketmar said:

as i absolutely don't understand how people are playing Doom (or anything else ;-) with controllers, i will expect your feedback -- i don't really know what you want to be configurable, and how.

You also aren't familiar with the Xbox 360 standard controller scheme that most shooters on the platform use?

 

Will get you your PM later :)

Share this post


Link to post
Posted (edited)
2 hours ago, Redneckerz said:

You also aren't familiar with the Xbox 360 standard controller scheme that most shooters on the platform use?

for me, any scheme with a controller is simply unplayable. also, it is usually very easy to see if some shooter video was made with a controller: camera movement patterns are very... distinctive (and limited).

 

of course, in the usual [k8]vavoom style, almost everything will be configurable. but yeah, i'd like to add some common scheme, so most people could simply plug their controller and play. i'll be very grateful for some standard schemes people are using to play Doom.

 

p.s.: also, Vavoom is the only freestep Doom sourceport out there, afaik. other sourceports run playsim in 1/35 steps, and then interpolate everything. yet Vavoom interpolates only "forced" monster movement (which comes from state machine actions). everything that is controlled by velocities is running with the actual framerate, so falling things, lifts, doors, etc. are moving exactly by the amount they should move between frames. i.e. "free smooth movement". ;-) this is what Quake does, and Janis converted the whole Doom playsim to this logic.

 

this is also the reason i hardcapped FPS to around 200. with higher FPS floating point errors starts accumulating, and with VERY big FPS values the whole physics simulation can totally break.

Edited by ketmar

Share this post


Link to post
Posted (edited)
On 4/16/2021 at 1:48 AM, ketmar said:

ll be very grateful for some standard schemes people are using to play Doom.

The standard scheme i think should be

 

Left analog = movement

Right analog = looking

X (bottom button on your right hand) = Use

Triangle (top button on your right hand) = Automap

L1 (left shoulder) = previous weapon

R1 (right shoulder) = next weapon

L2 (left trigger) = run

R2 (right trigger) = fire

Start (right button above analog stick) = pause

Select (left button above analog stick) = open menu

 

 

 

I think that's pretty much how it is on the Unity port. Leaves some of the buttons free to do whatever with.

 

Also don't forget force feedback ;)

 

 

Share this post


Link to post
Posted (edited)
1 hour ago, Muusi said:

The standard scheme i think should be

thank you! yeah, that may be good defaults. they're still "too vanilla", tho -- dunno if it is a big problem or not. i mean, even built-in BDW mod is using "reload" action, and many mods are using "alt-fire" too (Zan, for example).

 

1 hour ago, Muusi said:

Also don't forget force feedback

it is quite problematic to implement logic-wise. see this discussion on zdoom forums, for example. there is simply no way to make it work reliably without manually checking/modifying each mod in existance. more "vanilla-ish" ports can get away with this, because their modability is limited, but even there dehacked can confuse the engine quite alot.

 

i'm not yet sure if i want to write alot of code to have a broken/half-working implementation as a result. so this feature is put on hold until i (or somebody else) will come up with some acceptable solution. sorry.

Share this post


Link to post
Posted (edited)

added yet another feature to 3d polyobjects: top texture can be used as railing. (thanks id0 for the crazy idea ;-)

Spoiler

fnzux3.png

 

here, the lower platform has top textures set to MIDGRATE. linedef "clip midtex" flag is abused as "top texture is blocking" (that flag is useless with hw rendering anyway). there is currently no way to specify top texture height, so it will always be fullheight. this may be changed in the future (technically it is not hard, i just don't have a good place for that arg). also, such textures currently don't block projectiles/hitscans.

 

of course, you can add some decorations as bottom textures too. like vines, or hanging wires. bottom texture is not blocking in any case, it is purely decorative.

Edited by ketmar

Share this post


Link to post
Posted (edited)

hi. hope all is well on your side of the world.


small requests for consideration:
* could you add a chevron/caret as one of the crosshairs? i made one below using an app called [ms paint]. sorry, i am not good in IT stuff.

Spoiler

vHcicik.png

* could the center for the overlayed automap be toggle to have a mini version? the mini version of the automap could be moved anywhere on the screen (via coordinates in k8vavoom options) and the display area of the automap be customised (via size parameters in k8vavoom options) like the mini-automap in the screenshot below? the mini automap could also be zoomed. 

Spoiler

s01radR.png

 

some ideas for consideration:
apart from dazzling lighting effects, perhaps k8vavoom could distinguish itself more from other source ports? like...
* capable of running the biggest most complex map for classic doom. for example, a true to scale 20x20 miles (400 square miles) open-world map (read "open-hell" map) on a low end computer. the likes of game [just cause 3], etc.
* the maps could have weather cycles, wind effects (have debris flying, moving fog, etc).
* advanced physics like glass shattering, rocks breaking, water ripples, etc.
 

a big thank you for the awesome work done on k8vavoom and in advance for future works on this awesome source port.

Edited by saibog

Share this post


Link to post
Posted (edited)
15 hours ago, saibog said:

could you add a chevron/caret as one of the crosshairs?

you can do it yourself with a simple mod. all crosshair graphics is "graphics/crosshaiN" lumps, where "N" is a digit. as for inclusion in default set... all default crosshairs are drawn for 320x200 resolution. your crosshair shape simply will not look good with that small size. and i don't have plans to bump default crosshair picture resolution for now.

 

15 hours ago, saibog said:

could the center for the overlayed automap be toggle to have a mini version?

it is technically doable, but i'm not convinced that the feature is worth inclusion at the present time. i mean, i have plans of "widgetization" of most HUD elements (so players will be able to configure fullscreen HUD with drag-n-drop), and automap will be converted to resizeable widget too. automap code has hard-coded fullscreen logic, so it should be almost completely rewritten first. i'd better leave this rewrite to the time when i will do complete HUD overhaul.

 

i.e. your idea is not rejected, but it will have to wait... a little. ;-)

 

15 hours ago, saibog said:

capable of running the biggest most complex map for classic doom. for example, a true to scale 20x20 miles (400 square miles) open-world map (read "open-hell" map) on a low end computer.

sorry, but this is out of project scope. supporting huge overdetailed maps with acceptable FPS is something that will require a complete engine rewrite, and this is also something i'm not really interested in.

 

that is, i never wanted to turn k8vavoom into "universal idTech1 engine for creating TCs". at least not open-world TCs with alot of non-doom effects. idTech1 is not a good choice for such things anyway, due to alot of internal architectural limitations which cannot be changed without losing compatibility with... well, with all existing idTech1 games. ;-)

 

the most limiting thing is that it is impossible to run playsim on multiple CPU cores. and the engine should run playsim (including physics emulation) for almost every entity on the map. i recently introduced alot of hacks to skip full physics for entites that look like "dormant", but it is still a hack, and it won't help "open-world" maps, because there will be alot of things roaming around, or doing some game logic (almost everything in the game world is done with invisible entities -- moving lifts, closing doors, even scrolling textures; and there is no way to skip those computations).

 

also, rendering huge detailed maps is CPU-consuming task too, and it will also require a good GPU. idTech1 is very GPU-hostile, and the engine has to do alot of work to keep acceptable framerates on complex maps. yes, the box that can render modern Crysis in solid 60 FPS can have single-digit FPS on something like Frozen Time bridge scene. there is nothing we can do with that, at least not without completely dropping compatibility with existing idTech1 games. GZDoom is trying hard to utilize CPU and GPU as good as possible, and it is still struggling with Frozen Time. and GZDoom renderer performs alot of tricks under the hood, including using multiple CPU cores to process geometry and feed GPU.

 

tl;dr: it will require rewriting most of the engine code just to get a "nice to have" feature that will hardly be used by anyone. i simply don't have physical resources (time and energy) to do that. it will require several man-years of hard full-time work. sorry.

 

15 hours ago, saibog said:

the maps could have weather cycles, wind effects (have debris flying, moving fog, etc).

advanced physics like glass shattering, rocks breaking, water ripples, etc.

this is something that can be emulated with VavoomC, at least for some extent. the whole playsim (including physics) is written in VavoomC, and can be modified if necessary without recompiling C++ code.

 

of course, it is hard to do, because there is almost no documentation on VavoomC and engine internals. but this is partly because i don't want people to use VavoomC. mods with VavoomC code will create a kind of "vendor lock-in" -- they absolutely cannot be portable to other sourceports, and i strongly believe that cross-port compatibility must be one of the primary targets of the sourceport. i.e. using VavoomC (or ZScript, for that matter) to create a gimmick (which the map rarely needs anyway) will prevent people to play the map in other sourceports. it is ok to add new linedef specials, or DECORATE actions, because they can be emulated in other engines. but VavoomC cannot be "emulated", because you have to rewrite your engine to be exactly like Vavoom to allow VavoomC mods. (and yes, to "emulate" ZScript you have to be exactly like GZDoom).

 

that is, maps that are designed to use k8vavoom lighting can be playable in other sourceports. they will not look right, but they will still be playable. 3d polyobject feature i'm working on now can be implemented in other engines too; it may be hard to do, but it is doable (and i will try to provide "good enough" specs, so 3d pobjs can be implemented in compatible way simply by reading the documentation). yet if the map is using some VavoomC code for its logic/playsim... this is game over. if one day i'll be hit by a bus, all such maps will become mostly unplayable over the time.

 

also, i don't want people to use VavoomC because i'm often changing engine internals, and keeping compatibility with existing VC mods will be a PITA (if possible at all).

 

of course, if somebody wants to start a huge TC/standalone game based on k8vavoom, i can provide some help. but most of the time people want k8vavoom to be "GZDoom with k00l lighting modes", and there are alot of GZDoom features i will never ever implement.

 

 

sorry for this huge rant, that mostly has nothing to do with your suggestions. ;-) thank you for trying k8vavoom, and for giving a feedback! even if i can't implement your ideas "as is", they're still valuable, and giving me some food for my thoughts; it may inspire me to implement more features to make the engine better. so don't hesitate to drop even your most crazy ideas here. one of them may "click", who knows... ;-)

Share this post


Link to post

also, i think that the public build is very close. i need to test some non-pobj related changes and such, but everything i wanted to have is there, and seems to work. 3d pobjs is an experimental feature anyway, and it will be improved later, but i want to be sure that if i documented something as "allowed with 3d pobjs", it will work as expected, and you won't have to fix your maps later. just don't do anything that is not explicitly allowed in specs, and you should be safe. the documentation and demo maps will be included in the next public build. i still have to decide what will be the best for some small implementation details, and document some unobvious things, but there should be no major release blockers anymore.

Share this post


Link to post
Posted (edited)

i mostly finished with 3d pobj specs (first draft, v0.99 ;-), so there is a hope to see the public build in the next week 7 days. ;-) still need to create some simple demo maps, as those i'm using for development are quite messy.

 

i tried to add alot of checks, so the engine should reject most invalid configurations. i.e. the map with invalid 3d pobj will not be loaded most of the time. i think this is much better than silently accepting almost anything and then try to make maps with UB work. of course, there is more than one way to cheat the checker code, but i hope that it won't become a new mapping challenge. ;-)

Share this post


Link to post
41 minutes ago, ketmar said:

i tried to add alot of checks, so the engine should reject most invalid configurations.

Honestly, I kinda like stricter checks.  Feels more forward-compatible when I know that what I do is correct, not just "accepted".

Share this post


Link to post
47 minutes ago, Remilia Scarlet said:

Feels more forward-compatible when I know that what I do is correct, not just "accepted".

yeah, that's the idea. i'm trying to make sure that if the engine accepted something, it won't suddenly break in future versions due to some UB. i won't make the same mistake ZDoom did! ;-)

 

of course, checks aren't ideal, and cannot catch everything, but it is still better than totally nothing, i believe.

Share this post


Link to post
Posted (edited)
5 hours ago, Mr.Rocket said:

Yep..

pre-release testing. ;-) just look at git log -- no major changes, just small fixes here and there. still have to create demo maps for 3d polyobjects. of course, i have those i used for dev and testing, but they're very barebones. maybe i'll still use them, tho. not the best way, i wanted something much more interesting (like rotating cogs a-la Duke3D, and aerial lift with several stop points), but...

Share this post


Link to post
Posted (edited)
On 4/21/2021 at 5:26 AM, terminator said:

could the center for the overlayed automap be toggle to have a mini version? the mini version of the automap could be moved anywhere on the screen (via coordinates in k8vavoom options) and the display area of the automap be customised (via size parameters in k8vavoom options) like the mini-automap in the screenshot below? the mini automap could also be zoomed.

...and i though: 'cmon, why not? i can always reimplement it later for the new UI, so there is no reason to not add it right now. and i implemented a configurable minimap (no menu configuration yet, only cvars; but i hope to implement simple visual configuration later this day, or tomorrow).

 

screenshot. ;-)

Spoiler

959qt2.png

 

Share this post


Link to post

Ketmar you are going full "beast mode" on K8Vavoom. Perfect time to use it on my upcoming Project Slipgate: Remastered. One quick question....how are donations handled?

Share this post


Link to post
9 hours ago, ketmar said:

...and i though: 'cmon, why not? i can always reimplement it later for the new UI, so there is no reason to not add it right now. and i implemented a configurable minimap (no menu configuration yet, only cvars; but i hope to implement simple visual configuration later this day, or tomorrow).

 

screenshot. ;-)

  Reveal hidden contents

959qt2.png

 

wow! thanks, @ketmar. love it :)

Share this post


Link to post
Posted (edited)

@ketmar may I ask why do you thought Vavoom to be the best. I'm intrigued.

 

Also, what are your ideas for your fork in the future? more graphical goodies? some custom mapping format? more compatibility with existing pwads? stand along game engine?

 

 

Great job, I'm loving it.

Share this post


Link to post
Posted (edited)
9 hours ago, Gunrock said:

how are donations handled?

food and internets. ;-) my stable income is zero, so the less i have to care about living expenses, the more time i can spend on k8vavoom development. if you want me to work specifically on some feature, it is negotiable too. if the feature is not ruining my dev plans, and your project/idea is interesting enough, i may do it. in this case donation may improve the speed (but no, you can't "hire" me this way ;-).

 

tl;dr: donations are used for living. i hope to get enough for booze and hookers everyday, but this is still a dream. ;-)

 

if you'll look at git commit log, you'll see that i am pushing commits almost every day. and there are more private branches where i'm experimenting with new ideas and such. basically, i'm woriking on k8vavoom as "full-time project" (and even more), only mostly for free. ;-)

 

 

6 hours ago, terminator said:

wow! thanks, @ketmar. love it :)

you're welcome. even i don't know when some interesting idea may "click", so bring more, please! ;-)

 

 

6 hours ago, Arl said:

may I ask why do you thought Vavoom to be the best.

very clean codebase, good architectural design, features that some engines started to implement only about decade after Vavoom development suspended. if you'll take the original Vavoom source code, you could see that while it is definitely not finished, there is the careful planning behind it, it's not just features randomly dropped in (yeah, ZDoom, i am looking at you). Janis is programming genius.

 

i don't care about having "next-gen gfx" in Doom engines ('cmon, it's Doom we're talking about!), yet Vavoom rendering is still unique too -- this is the only engine with lightmapped lighting a-la Quake (even with overbright support). currently, lightmapped mode got less love than i wish to give it, but it is not forgotten. i just don't have enough hours in a day to code everything i want to code. ;-)

 

6 hours ago, Arl said:

more graphical goodies?

graphically, i don't think that i will go much further. i definitely won't implement any kind of "PBR" (i.e. no materials, normal maps, etc.). i don't think that with Doom low-res textures it looks good, and i don't like hires textures at all (i'd happily nuke support for hires textures from k8vavoom, but i can't, because it already was in Vavoom, and i'm usually not removing features until it is strictly necessary). implementing shadowmaps was planned from the very beginning, tho, so i did it.

 

so, don't expect fancy shiny materials or custom shaders. graphically k8vavoom is mostly like i wanted it to be. i will still work to make rendering faster, tho, but without sacrificing features, and preferably without bumping required OpenGL version (currently, you should be able to run k8vavoom with OpenGL 2.1 + GLSL120 capable GPU).

 

still, there will be floor/ceiling decals (the renderer can do it, it's the logic that is not there yet). also, k8vavoom is the only sourceport that can render decals on masked walls, afaik. this is because i LOVE blood splats, and want them everywhere! ;-)

 

6 hours ago, Arl said:

some custom mapping format?

no, we already have UDMF, it is very extensible. custom UDMF namespace? yes, sure. i have plans to give mappers more control over lighting, and maybe some more.

 

6 hours ago, Arl said:

compatibility with existing pwads?

you already can play alot of pwads with k8vavoom, and i'm constantly improving things. it's not possible to be 100% compatible with everything (especially with maps utilising vanilla renderer hacks), but i am doing my best. don't expect k8vavoom to be demo-compatible or such, and don't expect it to emulate every vanilla quirk, but it is still Doom, it feels like Doom, it plays like Doom.

 

sure, i added alot of gameplay-changing features (like headshots and criticals, or higher friction for player mobj), but all such features can be customized/turned off, to give the player "mostly vanilla expirience" if they want so.

 

DECORATE support is very important too. i did alot of work to improve it (Vavoom had nuts and bolts in place, but it was last touched 10+ years ago...), and i'm still working on DECORATE, to make even more mods playable.

 

6 hours ago, Arl said:

stand along game engine?

even Vavoom could be used like this, and k8vavoom made this even easier. almost everything in Vavoom/k8vavoom is written in VavoomC -- this includes AI and even physics. VavoomC source is compiled by the engine on the fly, so it is possible to create a completely different game with k8vavoom tech without ever touching C++. most of other engine definitions are textual files too (including most of the menus).

 

but this is not the goal of the project, it is just a side effect of the engine architecture. k8vavoom is, and will always be the engine to play Doom (and Heretic, Hexen, Strife). this is what i am using it for (i love to play Doom!)

 

6 hours ago, Arl said:

what are your ideas for your fork in the future?

oh, i have a huge TODO list. i don't want to promise things i may not be able to do, though.

 

there will be a widget-based HUD with visual drag-n-drop customisation (the core widget mechanics is there; you may not notice it, but Vavoom UI built with full-featured hierarchical widget system).

 

i will eventually add tools to help mappers too. you'll be able to open in-game map editor, and tweak alot of things. i'm not sure about changing geometry yet, but everything else should be tweakable. the first thing i want to implement is real-time lighting editor, which will be of great help for making maps look great, i guess. i mean, no editor is capable of rendering the exact picture, and with rich set of Vavoom/k8vavoom rendering modes i don't expect editors to catch up. yet the engine can do lighting in real-time, so editing the lighting inside the game looks natural.

 

i have plans to finish bot AI too. currently, there is a foundation for it, and some very rudimentary code. but i want bots to be able to finish most "normal" maps on themselves. i.e. the bots should be able to understand the map and various switches effects, plan their routes, and use long-term goal planning.

 

there are alot of other things i'm experimenting with, but it's too early to talk about them. let me just say that my TODO/roadmap for k8vavoom is big enough that a studio of 5-8 people should work fulltime for around 3-5 years to implement everything i want to do. and i'll inevitably add more ideas to the table. ;-) of course, as i am doing almost all design and coding by myself, i have to prioritize things, and sometimes spend monthes paying techincal debts (code cleanups and such, to keep the thing maintainable), so implementing even the things i described above may take years. but i'm not in a hurry anyway. ;-)

 

i'm full of ideas, and full of enthusiasm. i was working on k8vavoom prior to puiblic announce, so it makes 3+ years of work now, and i am even more excited than i was when i started. don't expect k8vavoom to die again! ;-)

 

ah, and i'm always ready to add gameplay features that people may want. if somebody want to create a map, and can think of some engine feature that may help, don't hesitate to PM me. even if your request will be rejected, i'll try to explain why exactly the feature is impossible, and we'll try to find a workaround. or you can simply drop your ideas right into this thread, and something may stick. ;-)

 

6 hours ago, Arl said:

Great job, I'm loving it.

thank you! and stay with us, we have cookies demons and shotguns!

Edited by ketmar

Share this post


Link to post

Hey @ketmar I have a question or two for you. Is there any documentation or cookbook style examples (how to make X or how to do Y) for VavoomC? I have been learning various C based languages recently. Mainly C# and C++. I want to start working with VavoomC for a few projects I am working on. 

 

How many players can play in a single multiplayer game with K8Vavoom?

Share this post


Link to post

i could postpone it forever, adding more and more features, but sometimes somebody should come and say: "stop!" so i looked at the mirror, and saw a writing there. it was "STOP!", with big red letters.

 

so, here is the new build for you all!

 

note, that this build has alot of code changes under the hood, so it may have small unexpected glitches here and there. i tried to test is as much as i can, but shit happens sometimes.

 

if you're interested in 3d pobj specs and simple demos, look into "specs/3dpobj/k8vavoom_3dpobj.html" file for specs, and "specs/3dpobj/simple_wads/" for some demos. sorry for demo wads quality (or, rather, the lack of). they are mostly slightly cleaned up test maps i made during 3d pobj development.

 

PLEASE, READ THE SPECS CAREFULLY, AND DON'T DO ANYTHING THAT IS NOT EXPLICITLY STATED AS ALLOWED/DEFINED IN THE SPECS!

also, if you'll make some maps with 3d pobjs, please, report any behavior that contradicts the specs.

 

brief changelog:

Spoiler

* WARNING! your saves may be broken again! sorry! (renamed VavoomC `Level` class to `VLevel`)
* alot (ALOT!) of internal code changes required for the next three bullet points
* implemented t-junction fixing code for lightmapped renderer (there should be no more Space Ants in any of rendering modes! except for polyobjects. ;-)
* new polyobject management code: polyobjects now aren't restricted with the original Hexen rules
  (i.e. they can have any shape, cross sector boundaries, and can reside in any sector)
* experimental 3D POLYOBJECTS implementation: they have height, can move in all 3 dimensions and rotate, and they can carry things on top of them!
* lightmapped mode may lit 3d polyobjects wrongly, or not lit at all; this is known problem that will be solved later
* 3d polyobjects may have some Space Ants; will be fixed later too
* experimental support for UDMF user fields (VavoomC and ACS API included)
* implemented ACSF `DamageActor()`
* fixed bug in `A_RadiusThrust()` (it should not damage actors)
* added options for fine control of sprite shadowmaps (thanks, Firebrand!)
* added SF2 selector (with presets for each selected SF2) to sound options menu
  (drop all your SF2 files where the binary is, and you'll be able to switch between them with the menu)
* crop brightmap textures if their base textures were cropped (thanks, id0!)
* completely rewritten surface generation code (should have less visual glitches with various 3d floor configurations)
* new texture mapping calculation code (not fully finished yet, but slightly more correct than it was before)
* do not switch Doom title screen while title music is still playing
* fixed small memory leak in game saving code
* added proof-of-concept of "advanced damage indicator" (options -> hud -> damage indicator)
  it shows horizontal and vertical direction of the incoming damages;
  vertical direction is shown by smaller bars; inside bars means "down", outside bars means "top";
  you'll get used to it (i hope ;-)
* fixed long-standing hitscan bug -- hitscan attacks could miss some walls and things in some very special cases
* you can bind up to 4 keys/buttons from control options menu now
* experimental game controller support, with hotplug (but hotplug works only with one controller yet)
* added some TPlane methods (3d algebra) to VavoomC
* better sorting of translucent surfaces vs sprites (still not perfect, and may glitch with translucent 3d slopes, but hey, translucent slopes are not officially supported anyway)
* textures with solid and translucent pixels now rendered in two passes, so solid pixels could be lit and cast shadows
* added separate autoaim control for hitscan and projectile weapons (with possibility to force autoaiming)
* automap controls are fully configurable now
* implemented "CheckSwitchRange" mapinfo and linedef flag (experimental)
* fixed off-by-one month in save dates (lol) (thanks, Steinkrauz!)
* added "+k8MuzzleFlash" actor flag to mark muzzle flash actors (this is used in some light calculations; it is not necessary, but recommended to mark such actors)
* implemented `SoundSequenceOnXXX` ACSFs ("on sector" is only partially) (thanks, Remilia Scarlet!)
* corpses should not slide off from 3d floors anymore
* sprite precaching should work with sprite brightmaps and psprite cropping now (i.e. it should be safe to turn it on)
* added HUD options to draw map stats and name when not on automap
* added simple minimap widget (controlled with "minimap_*" cvars, and new options menu)
* fixed pk3 filtering system ("filter/" directories) -- they weren't working for several builds (thanks, id0!)

 

Share this post


Link to post
Posted (edited)
27 minutes ago, Mr_SquarePeg said:

Is there any documentation or cookbook style examples (how to make X or how to do Y) for VavoomC? I have been learning various C based languages recently. Mainly C# and C++. I want to start working with VavoomC for a few projects I am working on.

sorry, there is no proper documentation yet. also, while you can use VavoomC for writing standalone programs, it's not that easy. you have to build vccrun from the sources (and this may be a really complicated task for windows), and you have to know where to put core .vc source files, and which ones. the language itself is very similar to C# (and to D), but its standard library is not very big, and mostly consists of things i need for k8vavoom.

 

in the future i may release a standalone vccrun version and some samples, tho. it is quite easy to write simple gfx apps with vccrun, so it may be a fun testbed/playground.

 

and if you want to write a mod for k8vavoom using VavoomC... oh, abandon hope, all ye who enter here! ;-) you have to know much more than the language itself -- the deep knowledge of k8vavoom engine architecture and internals is required too. and of course, there is no documentation on it either.

 

sorry if all this sounds disappointing. VavoomC is very powerful, but it is not well-suited for learning. to make it more friendly i have to write alot of documentation, and i simply don't have enough time and resources for this.

 

still, if you're curious, you can look into basepaks. the engine compiles VavoomC code from the sources on startup, so basepaks contain full and unobfuscated VavoomC source code. just don't modify it. ;-)

 

also, you can PM me if you really want to create some TC that requires VavoomC code. we may find some solution.

 

27 minutes ago, Mr_SquarePeg said:

How many players can play in a single multiplayer game with K8Vavoom?

8. the engine is capable of more, but currently maximum number is hardcoded as 8. also, please note that MP code is not as good as i want it to be, and lacks many features (like client-side predictor, for example). i have plans to improve it, but the priority is quite low, as i'm not playing MP games at all. MP games should work OK over the LAN, but playing over internet, especially with high ping, may not be a pleasant expirience.

Share this post


Link to post

I think at least the base commands should be compiled and documented, for now. :P

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×