k8vavoom: no good thing ever dies!

[ketmar]

1 hour ago, unpleasantmarine said:

believe it or not, windows 10 is using the same wavetable synth used since windows 98

if it works... DON'T TOUCH! ;-)

[ketmar]

i made textured automap. now k8vavoom is officially "modern", and therefore sux.

[ketmar]

yay, i am so... i can't even find a word. all this time, AJBSP did UDMF maps wrong due to me being dumb: i forgot that UDMF vertices could have non-integral coordinates, and was using integers to store BSP node splitting plane parameters. i never noticed this on converted vanilla maps (yeah, i am expert at testing!), but of course, most modern UDMF maps were glitchy as fuck. missing walls, invisible obstacles, disappearing flats, all kinds of weird behaviour. i wonder what kind of drugs i was using when i wrote that integration code.

 

please, note that this is not AJBSP flaw: internally, AJBSP is using floats, so it is ok. the only place it is using ints to store coordinates is BSP node structure, and that was ok too, because original AJBSP cannot process UDMF maps anyway. and i forgot to fix that part when i merged AJBSP code into k8vavoom. baka-baka-baka.

[Gunrock]

Hey ketmar! I haven't been posting much lately( busy doing remasters of old projects). I came across what appears to be a bug in Map 5 of Silent Steel. The rocket torrent in the last section of the map is spawning the rocket projectiles too low to the ground and not in the correct height. In the last K8Vavoom build it was spawning the projectile correctly.

 

Here are some pics.

 

Thanks for your hard work as always!!!

 

 

[ketmar]

1 hour ago, Gunrock said:

The rocket torrent in the last section of the map is spawning the rocket projectiles too low to the ground and not in the correct height. In the last K8Vavoom build it was spawning the projectile correctly.

thank you, i'll check it and report back. i remember that it worked fine too. strange thing.

[ketmar]

@Gunrock it seems to work right in the development version. maybe i fixed it while fixing some other bug, or maybe this is strange glitch in windows builds. i'll check it with windows builds before next public one too.

[Gunrock]

I forgot to mention in my last post that I recently made an updated Silent Steel: Remastered v1.1

I did a couple of low key changes to the game play and I must have inadvertently screwed up the rocket torrent's behavior. K8Vavoom probably picked up on that, and now it spawns the rocket incorrectly in the last K8Vavoom build.

 

Can you try SS:v1.1 on your build to see if its correct?

Sorry to waste your time on something so small.

 

 

[ketmar]

ah. with 1.1 it is really broken. i'll take a look, thank you.

 

51 minutes ago, Gunrock said:

Sorry to waste your time on something so small.

it's ok. it is still a bug/incompatibility. and noticing such small things is very important (i myself wouldn't prolly notice it), so this is not a waste of time, quite the contrary! ;-)

[ketmar]

@Gunrock ok, the difference between GZDoom and k8vavoom is that thing height is absolute for GZDoom, but relative to a floor in k8vavoom. so the previous release worked ok in k8vavoom, but not in GZDoom, and the new release is working ok in GZDoom, but...

 

i don't know if thing height should always be absolute, or there are some exceptions, tho.

 

@Graf Zahl here, i summon you, The Great Mastermind of GZDoom! obey my will, Archdemon, and answer my question! what is the right way to process thing Z? ;-)

 

 

p.s.: for now, i added a hardcoded hack for SS1.1, so with the next release people will be able to play both 1.1 and older versions. but this is not a proper soultion, of course.

Edited July 9, 2019 by ketmar

[Gunrock]

Ok thanks!

[Graf Zahl]

On 7/9/2019 at 1:16 PM, ketmar said:

@Gunrock ok, the difference between GZDoom and k8vavoom is that thing height is absolute for GZDoom, but relative to a floor in k8vavoom. so the previous release worked ok in k8vavoom, but not in GZDoom, and the new release is working ok in GZDoom, but... 

 

i don't know if thing height should always be absolute, or there are some exceptions, tho.

 

Can you give more info what thing types this is about?

Relative thing height was inherited from Hexen and is generally used for everything.

 

The only exceptions in GZDoom are the ones which originate in Vavoom, like the 15xx slope makers.

 

 

 

 

[Mr.Rocket]

Is k8vavoom OpenGL only?, no software or d3d commands?

[ketmar]

8 hours ago, Graf Zahl said:

Can you give more info what thing types this is about?

yep. this is thing 9001 (MapSpot). if i change height for it from relative to absolute, it works like in GZDoom. Silent Steel is using that thing as rocket origin, so it is easy to visually check heights in GZDoom. i didn't read GZDoom code yet, just thought that you may know the answer.

 

p.s.: i checked actor definitions, and they're the same both in k8vavoom and in GZDoom. i.e. there are no additional flags there.

[ketmar]

2 hours ago, Mr.Rocket said:

Is k8vavoom OpenGL only?, no software or d3d commands?

yes. only OpenGL, and you need at least OpenGL 2.1 capable GPU, with support for GLSL 1.20.

 

software renderer was removed by Janis, d3d renderer and support for OpenGL 1.1 were removed by me.

[-TDRR-]

13 hours ago, Mr.Rocket said:

Is k8vavoom OpenGL only?, no software or d3d commands?

Yes, if you want D3D or Software you will have to stick to old Vavoom or some other port.

[Mr.Rocket]

@ketmar & @-TDRR-

Ah ok, I have no probs running it on my main system in OpenGL, but then I tried my oldie laptop and it just couldn't, so I thought I'd ask.

Ok thanks!

 

@ketmar

I'm not sure If I've asked before if k8vavoom's network code was functional yet?

It doesn't seem like it is, it tries to connect but that's about it, never joins the game heh.

Server side seems to be hosting the game though!

 

Anyway, this port is look really nice so far, Thanks! ;)

 

[ketmar]

11 minutes ago, Mr.Rocket said:

I'm not sure If I've asked before if k8vavoom's network code was functional yet?

i tried to keep it working, but never really tested that. i also recently changed a protocol slightly, but again, didn't tested if it works. the foundation for network code is good, but the code itself is more like a first draft of what it should be. i am not playing network games, and considering that my time is limited, i didn't put any efforts in it. not that i haet it or something, it is just a matter of time and priorities.

 

tl;dr: network should work, but may fail at unexpected places, or even refuse to connect. ;-) i'll do a quick test, but don't expect much.

 

15 minutes ago, Mr.Rocket said:

Anyway, this port is look really nice so far

thank you!

[Graf Zahl]

7 hours ago, ketmar said:

yep. this is thing 9001 (MapSpot). if i change height for it from relative to absolute, it works like in GZDoom. Silent Steel is using that thing as rocket origin, so it is easy to visually check heights in GZDoom. i didn't read GZDoom code yet, just thought that you may know the answer.

 

p.s.: i checked actor definitions, and they're the same both in k8vavoom and in GZDoom. i.e. there are no additional flags there.

 

Map spots are regular actors, their z-position should be relative to the floor.

[ketmar]

13 minutes ago, Graf Zahl said:

Map spots are regular actors, their z-position should be relative to the floor.

yet it looks like in GZDoom it is absolute. at least in SS case. ok, i'll try to find out what exactly is going on later. there is something strange going on there.

 

p.s.: you can see it for yourself on SS map05: previous SS release (i can PM you one if you don't have it) shoots missiles way too high. if i'll make that mapspot position absolute, k8vavoom missile height becomes that high too. and with new release, and relative position, it is exactly what GunRock wrote -- it is too low. strange shit.

[Graf Zahl]

I don't have that version, so please PM it. I won't be able to have a look until this evening though.

 

[ketmar]

56 minutes ago, Graf Zahl said:

I don't have that version, so please PM it. I won't be able to have a look until this evening though.

done. along with brief explanation where to warp to check it.

[Graf Zahl]

I have an idea what's happening.

The offending MapSpot lies directly on a line and in this case Doom's positioning code acts a bit weird. In short: The spot gets positioned with the line's back sector's floor height as reference. In this case its height looks correct.

 

If for whatever reason Vavoom changed this so that it uses correct LineSide calculations it will end up in front of the line, and then the position is not correct.

Try moving it by one map unit in y-direction up and down and see what happens. For Gunrock I'd recommend to move the spot off the line, one y-unit down. Then it is inside the sector and not subject to bad algorithms. ZDoom once had this correct as well, but the results were not pretty. Several maps took the original calculation for granted.

 

 

 

[ketmar]

@Graf Zahl yeah, it seems that mapspot ends up in sector 1546 -- front sector of that linedef. which is strange, becase vavoom code prefers back sector when a point is exactly on a line. sans floating point inexactness, of course. but in this case the line is horizontal, so there shouldn't be any fp issues (horizontal and vertical lines are even special-cased in plane creation code). interesting. i'll try to find out the cause.

 

thank you for your help! somehow i didn't even thought about such case, and didn't noticed that the thing is on a line.

 

p.s.: yeah, it ends in a wrong sector, hence using a wrong floor. oops. oh, how i haet such bugs... thank you for help in finding it!

Edited July 12, 2019 by ketmar

[ketmar]

@Gunrock here, Graf pointed me at the bug (and as usual, this is The Bug That Cannot Happen). until i'll fix it, i added mapfix workarounds for both SS:R versions (actually did what Graf said, moved mapspot around a little ;-), so both versions will work (and will continue to work when i'll fix the bug -- the fix will break v1.0 without mapfix ;-).

 

now, this is very nasty bug that could hid for ages, and make some maps works "slightly wrong". thank you for reporting it, in the end it turned out to be a huge thing, not a small one! ;-)

[Mr.Rocket]

Back again real quick and I'm glad you guys got that sorted out! 

 

I thought I'd throw this out there for some later reference if you need.

A while back I made a wad for Doom Legacy that has a specific purpose, to test the 3d floors. It makes for a good reference for anyone that happens to use the 3d types, my self included.

I'm not sure how far you planned to go with 3dfloor types but this could be a good wad to use for a quick look up.

Gzdoom displays all the floor types with no problem, so I figured you might like to use the wad if you could/plan to use these old data types, as some of them show up in k8vavoom, but not all of them.

 

It is a pretty old wad and they can be made differently now via UDMF also, but it may still be of some use.

 

Legacy_3ddemo.zip

 

Edited July 12, 2019 by Mr.Rocket

[ketmar]

53 minutes ago, Mr.Rocket said:

I thought I'd throw this out there for some later reference if you need.

thank you! having test wads is always good.

 

i am usually trying to support those old features, if it is not too hard to implement. supporting Legacy 3d floor types shouldn't be that hard (after all, some of them are already there), and your wad will definitely help! i'll check it ASAP. ;-)

[ketmar]

so, i added workaround to BSP traversing code. sadly, vavoom is not using (x,y)-(dx,dy) to check for BSP side (it is using real plane equation), so full emulation will require alot of efforts. but most of such things placed on horizontal and vertical lines anyway, so i emulated the effect for those lines, and mindlessly copypasted some code in a silly attempt to emulate it for others. now both SS:R versions spawning the rockets like in GZDoom (but there is mapfix hack, so they won't glitch in k8vavoom anyway).

 

i also added support for some Legacy specials. not all of them, but many. ;-) among others, k8vavoom now supports Legacy colored lighting and translucent walls (and almost half of 3d floor types, and some more height transfers, so most Legacy swimmable waters and walkable floors should work). tnx, @Mr.Rocket!

 

after some more testing i will push a public release. wanna bet that i'll find a Big Bug immediately after uploading the archive? ;-)

 

i wanted to make a public release at my birthday (Jul, 9), but couldn't. anyway, let's name next release "ketmar's birthday release". missing deadline for several weeks is "exactly in time" at programmers land. ;-)

[Mr.Rocket]

15 hours ago, ketmar said:

i also added support for some Legacy specials. not all of them, but many. ;-) among others, k8vavoom now supports Legacy colored lighting and translucent walls (and almost half of 3d floor types, and some more height transfers, so most Legacy swimmable waters and walkable floors should work). tnx, @Mr.Rocket!

Hey Cool! no problem ;)

15 hours ago, ketmar said:

after some more testing i will push a public release. wanna bet that i'll find a Big Bug immediately after uploading the archive? ;-)

Nice, I bet maybe 1 virtual dollar! heh

 

I'm looking for some command lines for k8vavoom, the old Vavoom docs are pretty limited.

In testing phase, I'm working on a game dll for the Doom Connector to support k8vavoom.

I'd like to know the commands to start a server and connect to the server from command line, instead of using the in-game menu, is there a way?

Even though the net code in k8vavoom may not be perfectly complete yet, the options could be there for future use.

Thanks

[ketmar]

11 minutes ago, Mr.Rocket said:

I'd like to know the commands to start a server and connect to the server from command line, instead of using the in-game menu, is there a way?

basically, everything you're doing from menus internally just put commands to console buffer. and you can put commands to console buffer from CLI, with "+cmd args" syntax.

 

so, there are:

-ip 1.1.1.1

this is IP address server will listen on

-port 16666

this is port client and server will use

 

and then there are console commands to start a server:

+maxplayers 4

+nomonsters 1

+deathmatch 2

+timelimit 100

+skill 3

+map map01

 

or to connect to server:

+connect 1.1.1.1

 

i.e. you can start server from CLI like this:

k8vavoom +maxplayers 4 +nomonsters 1 +map map01

 

hope that helps.

[Mr.Rocket]

Ok, yeah that's what I was looking for! So I guess it must always spawn a server on game run?

Sweet, Thanks!