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

k8vavoom: no good thing ever dies!

Recommended Posts

@Mr.Rocket i restored LAN server searching (i hope), so in the next build it should be possible to discover LAN game servers without master. expect it to not work, tho, because i cannot test it with real LAN. ;-)

 

p.s.: tested by id0, and seems to work.

Edited by ketmar : post scriptum

Share this post


Link to post

Nice, I can't wait to test it out!

 

hmm, well the current launcher should work.. at least with build 317x.

I'll send you a pm with the latest version. ~ beta2

I've actually been in the same boat, having to test localhost, I need to get around to testing to another computer p2p now.

either way, I see no reason why it shouldn't work.

 

ps. lol just noticed I forgot to put a check if the dedicated server isn't in the same location as the launcher.

eg. the launcher will bomb out if it's not there. woops.. ;)

 

 

 

 

Edited by Mr.Rocket

Share this post


Link to post

sorry for being silent for so long. everything is going good, and new build is on its way!

Share this post


Link to post

Hello everyone! After two weeks of fun with k8vavoom and @ketmar, i'm announcing that k8vavoom
ported to Android system. This (very) experimental patches (hacks) already accepted to master-branch.
If someone interested i provide precompiled apk below.

 

Requirements:
- Android 4.1+
- GPU with OpenGL ES 2.0
- External memory for wads
- External keyboard, gamepad or virtual keyboard that mimics gamepad

 

Usage:
1. Install apk
2. Put iwads to /storage/sdcard0/Android/data/org.k8vavoom.app/files/.k8vavoom/iwads (may differ on some devices)
3. Optionally specify you command-line parameters in /storage/sdcard0/Android/data/org.k8vavoom.app/files/.k8vavoom/args.txt
4. Run k8vavoom

 

Known problems:
- Change screen resolution breaks FBO, do not change it at runtime :)
- Plugging/unplugging external keyboard at runtime may quietly crash the engine
- App minimizing breaks input from virtual keyboard (in game)
- Bloom effect crashes the engine, do not enable it
- Sparks aren't rendered for some reason
- Skies with two textures may not work (i don't know wads where it used, so it just not tested)
- The engine currently do not provide it's own onscreen controls, so you need external input methods

- Performance issues. This apk built without optimizations because GCC report internal compiler errrors... i'll fix this soon.

 

Please, send GLES/Android related bugreports to @SovietPony. You may do it in this thread.
If you found that something looks differently on GLES render with the same config on a Big Machine with a desktop GL, probably you found a BUG.
Note that this apk built from latest sources, so you can see currently unannounced features and new system independent bugs :)

 

Thanks for your attention. :)
Hope this is useful for someone.

 

DOWNLOAD APK

 

PS: GLES patches (hacks) can also be used to run k8vavoom on single board computers (like Raspberry Pi) :)

Edited by SovietPony

Share this post


Link to post
12 minutes ago, Gez said:

This may be of interest to @beloko, adding another advanced port to Delta-Touch.

thanks. but it is far from being ready yet, it's more like a PoC now. let it stabilise a little, and gain some features (at least better controls). it was released so people could see some progress, and SovietPony could get their share of fame. ;-)

Share this post


Link to post

and here we have windoze build too!

 

* WARNING! savegame wadlist detection scheme was changed, so many of your old saves may not be found anymore! sorry.
* fixes to 3d floor surface builder; for now sloped 3d floors may be slightly broken, but water should not cut 3d floors anymore (thanks, Khorus)
* some fixes to water surface rendering (excessive fog) (thanks, Khorus)
* partially fixed 3d floor side texture offsets (thanks, Khorus)
* some fixes to thing lighting on 3d floors
* fixed statusbar rendering with negative health
* added named translations parsing and ACS/DECORATE API
* the engine is buildable with GCC6 again
* network could hang up if the very first packet is lost
* network traffic is slightly encrypted now (it is not a "hacker protection", though, just a way to implement a form of "weak auth")
* implemented very simple "rcon" protocol to send console commands to dedicated server (use "net_rcon_secret_key" to set rcon password)
* it is possible to create password-protected servers now (use "net_server_key" cvar to set password)
* show messagebox with connection rejection reason
* returned (experimental) LAN server searching
* some internal changes to UI system (sink/bubble event propagation model and such, nothing user-visible)
* added startup splash screen (and "-nosplash" CLI arg to disable it)
* "r_model_light" meaning was messed, and it wasn't working as it should; now models should be properly lit from light sources in shadow volume renderer
* better model lighting in shadow volume renderer (fixed wrong normal rotation, fixed model lighting by owned light)
* fixed some internal code and shader inconsistencies, found by SovietPony
* bdw mod: player should press "reload" twice to reload half-empty assault rifle (to avoid accidental ammo loss)
* bdw mod: added some brightmaps to assault rifle (ammo display)
* added support for [g]zdoom GLDEFS glow color and fullbright flags
* allow sprite effects for sprites like 'BURNF0' (effects will be applied to all rotations)
* implemented different render styles for Spectres, and slider to control their transparency (thanks, Remilia Scarlet)
* added very simple and ugly "fuzz" shader for Spectres and others with the same render style
* fixed render bug with long skill names (i made menu wider, but forgot to make skill widgets wider too)
* fixed bug with invisibility render effect carried over maps (oops, stray `static` in C++ code can wreak havoc!)
 

 

@-TDRR- ping! ;-)

Edited by ketmar

Share this post


Link to post

Niice!

I dig the new splash screen btw, now we know what k8vavoom is actually doing there at startup. ;)

I'll hopefully have an official launcher ready by next weekend. ~ looks like I'll need to be adding the recon password stuffs also.

I may end up having to put a tab'd page in for network options heh, I don't want the size of the launcher any larger than it already is.

 

Cheers!

Share this post


Link to post
4 minutes ago, Mr.Rocket said:

I dig the new splash screen btw, now we know what k8vavoom is actually doing there at startup. ;)

...if anybody'll be able to read that fast-scrolling text. ;-) yet it is actual console output.

 

5 minutes ago, Mr.Rocket said:

I'll hopefully have an official launcher ready by next weekend

great, thank you!

 

6 minutes ago, Mr.Rocket said:

looks like I'll need to be adding the recon password stuffs also.

there is tools/k8vavoom-query.exe (and txt) which can be used to control dedicated server too. you can exec it to send various console commands, like server shutdown.

Share this post


Link to post
33 minutes ago, ketmar said:

there is tools/k8vavoom-query.exe (and txt) which can be used to control dedicated server too. you can exec it to send various console commands, like server shutdown.

Oh nice!

Yeah I didn't even notice the tools folder heh, man we need a little more documentation on these server tools, besides the k8vavoom-query.txt.

~ or at least all commands they support. Unless what's said in the .txt is all commands they have?

Share this post


Link to post
1 hour ago, Mr.Rocket said:

man we need a little more documentation on these server tools

i lied a little, k8vavoom-master is not a tool, it is full-featured master server. no args required (but it is console app, and i don't remember if i enabled windows console with it).

 

query sample can either query my master (if run without args), or send rcon command. this is basically what it is -- a compiled sample code. i just thought that instead of forcing you to compile it yourself i can provide the binary. ;-)

Edited by ketmar

Share this post


Link to post

The situation with the performance appears to have gotten a bit better, and while it's still stuttery at times it's kinda playable now.

 

Also, the TDBots now actually load up and play, even the latest Zandronum version v26b works, though I'll have to change some of the functions so they can actually attack, but there aren't any crashes anymore!

 

There's a couple bugs that might mess up some other mods though, if K8Vavoom does not support all of Zandronum's features, then I don't see why GetPlayerAccountName should be supported, as it's the way mods differentiate between Zandronum and ZDoom but in this case it just makes them break since none of the other Zandro functions are implemented (Like ConsoleCommand, most importantly). In short, GetPlayerAccountName should always return zero, unless you're gonna implement the rest.

 

On the subject of sourceport identification, could an ACS function that always returns TRUE be implemented? Since it wouldn't be available in ZDoom and Zandronum they will return FALSE there, giving a nice way to check if the current sourceport is K8Vavoom. Or, maybe just check for a K8V-exclusive CVAR that defaults to TRUE (or higher).

Share this post


Link to post
21 minutes ago, -TDRR- said:

if K8Vavoom does not support all of Zandronum's features, then I don't see why GetPlayerAccountName should be supported

it's because some mods are sure that there is only Zandronum that can run their code. but k8vavoom can do it too, so i added a dummy ACSF to run such mods. i don't remember exact names now, tho.

 

21 minutes ago, -TDRR- said:

On the subject of sourceport identification, could an ACS function that always returns TRUE be implemented? Since it wouldn't be available in ZDoom and Zandronum they will return FALSE there

they will crash on unknown ACSF code, i believe. but sure, i can add it. it would be better to add something like `GetSourceportId()`, but that will require some collaboration from other sourceports, and i am not ready to start that process.

 

21 minutes ago, -TDRR- said:

Or, maybe just check for a K8V-exclusive CVAR that defaults to TRUE (or higher)

"game_name" is string cvar that holds current "-game" value, for example. it is never holds empty string, so it won't be zero. it is also cannot be modified, so no mod can reset it.

there is also "gl_max_anisotropy" integer cvar, it is always 1 or greater. GZDoom doesn't have it, afaik.

 

21 minutes ago, -TDRR- said:

The situation with the performance appears to have gotten a bit better, and while it's still stuttery at times it's kinda playable now.

tbh, i don't even know what to say. i am happy that it is better for you, but i haven't the slightest idea why. i.e. i didn't done anything special. it's a magic! ;-)

Share this post


Link to post
5 hours ago, ketmar said:

they will crash on unknown ACSF code, i believe. but sure, i can add it. it would be better to add something like `GetSourceportId()`, but that will require some collaboration from other sourceports, and i am not ready to start that process.

They don't, surprisingly. I think this is a relatively recent addition, maybe around ZDoom 2.7? I know because GZDoom 1.8.6 does not crash with Zandronum 3.0's new functions (That were added 3 years after GZD 1.8.6's release!), nor does Zandro crash with modern GZD ACS functions (floor and ceil are notable examples, as well as ScriptCall).

 

Either way, "GetSourceportId" is not really viable in my opinion, since you simply can't go back and update the older versions with that, so it just adds even more unnecessary complication if you need to support those. What could be done is that ACSUtils also adds this function to be able to identify K8Vavoom too, so we can have a way to know which sourceport is in use in a single ACS function but without killing support for the older versions (And Zandronum which doesn't look like it's gonna have an update very soon).

 

5 hours ago, ketmar said:

"game_name" is string cvar that holds current "-game" value, for example. it is never holds empty string, so it won't be zero. it is also cannot be modified, so no mod can reset it.

there is also "gl_max_anisotropy" integer cvar, it is always 1 or greater. GZDoom doesn't have it, afaik.

Nice, so just this should give the desired result? I'll try that.

function bool IsK8Vavoom (void)
{
  	if(StrLen(GetCVARString("game_name")) == 0)
		return FALSE;
	return TRUE;
}

EDIT: fixed up the code to not blow up and break horribly if it's actually K8Vavoom
EDIT2: fixed another very obvious mistake that broke it, a.k.a directly comparing strings with the == operator but this isn't BCS so of course that doesn't work

Edited by -TDRR-

Share this post


Link to post
7 hours ago, -TDRR- said:

Nice, so just this should give the desired result? I'll try that.

i think you can simply do `if (GetCVARString("game_name")) { yes, k8vavoom! }`, because returned string is dynamic, so its index will never be zero.

no, you can't, i'm dumb. ;-)

 

p.s.: of course, you can create any cvar with VavoomC code. at least until other sourceports won't start rejecting mods with VC code as k8vavoom does with zscripted ones. ;-)

Share this post


Link to post
12 hours ago, ketmar said:

as k8vavoom does with zscripted ones. ;-)

Wait, does it instantly abort execution if it notices a "ZSCRIPT" lump? Doesn't that break D4T, QC:DE and Bloom (the Blood+Doom mod) before they even get a chance to start up? Besides that and the usage of A_Warp in D4T (for cosmetic reasons mostly), I don't see anything that would otherwise prevent them from running mostly correctly in K8V.

Share this post


Link to post
1 hour ago, -TDRR- said:

Wait, does it instantly abort execution if it notices a "ZSCRIPT" lump?

yep, it does. there is no way to tell if zscript is just a decorate in different clothes without implementing full-featured zscript parser, and i definitely won't do that. if some zscript code can be expressed as decorate, then write it as decorate, not as zscript. if there is zscript, k8vavoom assumes that there is some code that is required for a mod to work, and so it is better to abort early than to collect false "bug reports". GZDoom didn't bothered to introduce any way to tell if zscript is optional, so better be safe than sorry.

 

p.s.: the only exceptions are Eviternity and Adventures Of Square (before it fully switched to zscript). k8vavoom knows them "by their fingerprints". yet it will say that Eviternity is not fully supported, because it is true. ;-)

Share this post


Link to post

Maybe a -ignorezscript param would be useful? It's a huge loss to not be able to run QC:DE with properly Quake-ish lighting!

Share this post


Link to post
17 minutes ago, -TDRR- said:

Maybe a -ignorezscript param would be useful? It's a huge loss to not be able to run QC:DE with properly Quake-ish lighting!

1. you can remove zscript with something like SLADE (i know, nobody will bother).

2. you almost guessed it. add one more "-" somewhere in the middle, and you're there! ;-) you won't see it in "--help", tho, for a reason. (yeah, most of the time there are some CLI args to skip various checks. but they're hidden, so people shoud know for sure what they're doing, why, and how to do it.)

Share this post


Link to post
1 hour ago, ketmar said:

1. you can remove zscript with something like SLADE (i know, nobody will bother).

Not even I would, and I use SLADE a bit too much :p

1 hour ago, ketmar said:

2. you almost guessed it. add one more "-", and you're there! ;-) you won't see it in "--help", tho, for a reason.

Ah, it makes sense. -ignore-zscript? Or you mean --ignorezscript? That's gonna be definitely useful.
 

2 hours ago, ketmar said:

the only exceptions are Eviternity and Adventures Of Square (before it fully switched to zscript)

I think I already told you this, but TAoS for Zandro exists and it's probably the better option for K8Vavoom. I didn't remove the ZScript lump I think so it'll require -ignore-zscript, I might try later but no real testing 'cause framerates won't be good at all :p

Episode 2 is likely to be 100% beatable, and besides a crappy boss (That I myself modified because the original ZScript one was hard to do in DECORATE) it's the same experience as modern GZDoom.

Share this post


Link to post
2 minutes ago, -TDRR- said:

Ah, it makes sense. -ignore-zscript?

yep. ;-)

 

2 minutes ago, -TDRR- said:

I think I already told you this, but TAoS for Zandro exists

it seems that i missed it. thank you, i'll take a look. for now, k8vavoom knows about TAoS v1.86 -- that was one of the last versions with decorate support. sadly, the author removed old versions from the site (at least i didn't found them last time i checked).

 

5 minutes ago, -TDRR- said:

I didn't remove the ZScript lump I think so it'll require -ignore-zscript, I might try later but no real testing 'cause framerates won't be good at all :p

i may add it as "known mod" for the next public build. actually, you can do it yourself, there is basev/detectors.txt file that contains all "known mods", checksums to detect them (by lumps), and various options to apply.

oops. just looked at it, and it seems that it is exactly the version i have, lol. k8vavoom already knows about it, and can run it without any additional options.

Share this post


Link to post

@-TDRR- i added credits to detector, so it now properly reports it as "The Adventures of Square/Zandro, ported by TDRR".

Share this post


Link to post
1 hour ago, ketmar said:

@-TDRR- i added credits to detector, so it now properly reports it as "The Adventures of Square/Zandro, ported by TDRR".

Ah, that's nice, thank you. Might also help out quite a bit with people thinking that official TAOS is supported by K8Vavoom!
I'll also mention K8Vavoom in the title of the thread, so people know it'll work for it too.

Share this post


Link to post

in the meantime i added experimental OPL music player (based on NukedOPL). it is "experimental" because i didn't spent much efforts to make sure that it replays everything right yet, but it is works... more-or-less. some people prefer that "old-school" sound (including me sometimes).

Share this post


Link to post

Hey ketmar! Looking good with the new builds!!! I tested the new build with my upcoming "Dissolution: Remastered" and found two potential issues. First, underwater  rendering is broken when using the 161: "sector set contents: Vavoom compatibility" underwater method. GZDoom works correctly, while in K8Vavoom he falls right through it. Silent Steel: Remastered uses this method throughout the maps.

 

Also one last nit pick. Animated water/lava flats no longer work in Gothic Dreams: Definitive Edition

 For some odd reason they work fine in this demo wad. Thank you for your hard work!!!!  

LiquidTest.zip

Share this post


Link to post
2 hours ago, Gunrock said:

First, underwater  rendering is broken when using the 161: "sector set contents: Vavoom compatibility" underwater method. GZDoom works correctly, while in K8Vavoom he falls right through it.

eh. it seems that i broke it while fixing other things. thank you!

 

2 hours ago, Gunrock said:

Also one last nit pick. Animated water/lava flats no longer work in Gothic Dreams: Definitive Edition

 For some odd reason they work fine in this demo wad.

thanks, i'll check both issues. hope to fix them for the next build.

 

 

also, some small news for you all: while i am working on improved widget system (it is mostly user-invisible code changes), i added combobox-like selectors for all "option" menu items. not the best-looking thing, but at least you can select value from a list now instead of blindly pressing left/right to check all possible options.

Spoiler

dk1tzi.png

 

Share this post


Link to post

@SovietPony did the initial work on using VBO instead of old `glVertex()` rendering (thanks!). i picked it up, and now i am converting most rendering pathes to VBO. even in its current form without any geometry caching it should be slightly faster than the old code due to less OpenGL calls.

 

why it matters? first, this makes GLES port easier. second, sooner or later i will switch to OpenGL core profile, and it doesn't have those old APIs. third, i am planning to implement geometry data caching, which will allow the engine to avoid starting each frame from the scratch (i.e. part of the map geometry will be resident in GPU RAM, which means less data transfers).

 

even without the caching the engine tries to group surfaces by their properties to minimise context switches, which means ~10 times less OpenGL calls. this is not such a huge improvement as it seems (because in the end of the day the amout of data sent to a GPU is the limiting factor, and that amount is still roughly the same), but the situation is still better than it was before.

 

tl;dr: switching to VBO should (i hope) improve performance both on old and on new GPUs (less OpenGL calls is always better). there is still a long road ahead, but we did first important steps.

Share this post


Link to post

today is a big day! exactly two years ago i decided to finally fork Vavoom and start k8vavoom development. that day i made my first non-cosmetic commit. yay!

Share this post


Link to post

K8Vavoom is what got me back into mapping! Congrats Ketmar for all your hard work!!!!

Share this post


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