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

k8vavoom: no good thing ever dies! (2019, Oct 01 build)

Recommended Posts

sadly, video will hardly help -- i think i understand what you mean anyway, and has absolutely no idea of what is going wrong. still, if you will be able to record it so the difference is really visible, i'd like to see it anyway. who knows, maybe it will bring some crazy ideas on my table. ;-)

 

p.s.: i mean -- thank you for trying to record it, your efforts are valuable. i just absolutely don't know what to think, and even what to ask. ;-)

Edited by ketmar

Share this post


Link to post
On 12/1/2018 at 4:16 AM, ketmar said:

yeah. this thing is a major PITA. ;-)

There's a lot going on with that command! But, essentially, it should work with your scheme, I would think. It's a matter of scaling.

It looks like, when it encounters a SetHudSize(320, 200), if you're running 1024x768, it internally sets multipilers X to (1024/320) = 3.2, and Y (768/200) = 3.84.

 

Then, subsequent calls to position things get their X coord multiplied by 3.2, and their y coord multiplied by 3.84.

 

In your case, your system already does this, to present 640x480 to everything. So when *you* encounter a SetHudSize(320, 200), your multipliers should get force fed 640 and 480, so X multiplier = (640/320) = 2, Y (480/200) = 2.4. So, the scaling system created by SetHudSize scales coords, that you then feed to your scaled 640x480 system that will rescale everything to your resolution. In theory :)

 

Or, I have no idea what I'm talking about... Good luck!

Share this post


Link to post

ah, i have `SetVirtualScreen(int width, int height);` API. but using it directly producing weird looks, with either distorted fonts (if i obey ACS orders), or with distorted HUD graphics and broken text wrapping (if i map ASC coordinates to my "integrally scalled" virtual screen). that is the real problem: i have to choose between ugly HUD or ugly fonts. hard decision, indeed! ;-)

Share this post


Link to post

@kb1 do you maybe know what could be causing my game speed to be all wonky on my laptop? According to ketmar my game goes too fast when it is set to capped framerate (or at least that's what I gather from what he said earlier) which is weird since setting cl_cap_framerate to 0 which should uncap the fps and so SHOULD be introducing the speed issues works properly, its like its doing the opposite of what I expect :/

 

Oh yeah also I should point out this only happens with this sourceport, not any others.

Share this post


Link to post

small call to help here.

 

to properly implement "3d midtex", i need small sample maps, both in UDMF and in Hexen formats. currently, the engine simply ignoring that flag, which is obviously wrong. please, give me something very-very simple, so i can easily test it.

 

also, too bad that we don't have a site with such simple maps for various advanced features. sure, there are not many new sourceports appears each day, but it will still be nice to have even for existing ones, to do regression testing, for example.

Share this post


Link to post
2 hours ago, ketmar said:

small call to help here.

 

to properly implement "3d midtex", i need small sample maps, both in UDMF and in Hexen formats. currently, the engine simply ignoring that flag, which is obviously wrong. please, give me something very-very simple, so i can easily test it.

 

also, too bad that we don't have a site with such simple maps for various advanced features. sure, there are not many new sourceports appears each day, but it will still be nice to have even for existing ones, to do regression testing, for example.

 

I think this should be enough?

 

midtex.zip

Share this post


Link to post

@KVELLER yeah, thank you alot!

 

of course, i immediately hit a bug with zero-length "behavior" lump, lol. two bugs for the price of one, i love it!

Share this post


Link to post
17 hours ago, therektafire said:

@kb1 do you maybe know what could be causing my game speed to be all wonky on my laptop? According to ketmar my game goes too fast when it is set to capped framerate (or at least that's what I gather from what he said earlier) which is weird since setting cl_cap_framerate to 0 which should uncap the fps and so SHOULD be introducing the speed issues works properly, its like its doing the opposite of what I expect :/

 

Oh yeah also I should point out this only happens with this sourceport, not any others.

Do you have a way to determine exactly what the frame rate is at any given time, or are you just basing the speed issues on look and feel?

What I mean is: Does k8VaVoom have an FPS counter, and have you turned it on? Because, you're going to need that to determine the problem.

 

So, with the FPS counter, I would suggest you load up a pretty detailed map - a map that may tend to slow down the renderer a bit. Now, I want you to find 4 diffrerent areas in this map, and save your game to a new slot in each area, so you're going to end up with 4 savegame files:

  1. A very lightly-detailed area, easy on the renderer.
  2. A slightly more detailed area.
  3. A detailed area, maybe with a lot of dead monsters.
  4. A super-detailed area, with lots of dead monsters - an area that might slow down the renderer.

Now you have 4 different profiles. Get familiar with these savegames. You're going to have to do the following steps a few times: When you first turn on your laptop, when you're laptop has been on for a while, when your laptop's battery is low, when your laptop is hot, etc.

 

In each of those different laptop scenarios, load up k8VaVoom, then load each savegame, and write down the FPS count. Do this at all the above laptop states. What we're trying to do is see if the FPS count is the same when your laptop is cold, when it is hot, when the battery is low, etc. The questions we're trying to answer are: Is your machine doing CPU throttling? (Is the problem your laptop's fault, or k8VaVoom's fault) Is k8VaVoom acting erratically?

 

We need to determine which component is the problem: Is it your hardware, or is it the engine? By using savegames, you're forcing k8VaVoom to do *exactly* the same thing, over and over, so it has a chance to give you a stable FPS rate. You could have CPU throttling. You could have background processes running that are stealing your CPU cycles, you're free memory, etc. Or k8VaVoom could, in fact, have some sort of timing issues. If it is set to cap the frame rate, you should always see 35 FPS, or less if the engine cannot maintain 35 FPS, due to a complex scene.

 

To really get an answer, you need to do this quite a few times, and become very familiar with the level, and the FPS count, until you can memorize them. This is the type of problem that requires the type of familiarity that comes from doing exactly the same set of tests over and over, until you notice exactly what makes things change:

 

Does a particular scene get slower after your laptop has been running for a few hours? (heat-induced CPU throttling)

Does a particular scene get slower for a few minutes, and then speed up? (Periodic background programs running)

Does a particular scene get faster or slower if you unplug your internet connection? (Malware "phoning home")

Does a particular scene get faster if you turn of your virus/malware scanner?

Can you check your CPU rate (Task manager on Windows) while running k8VaVoom?

 

Have you checked for background processes that could be running?

 

So, in summary:

  • Become hyper-familiar with FPS rate while looking at a specific scene in k8VaVoom.
  • Determine if k8VaVoom FPS rate stays solid for a specific scene.
  • Try the tests with the laptop cold, hot, low  battery, etc.
  • Look for patterns and determine what external to k8VaVoom can explain the FPS situation.

Without having your laptop in front of me or ketmar, it is up to you to isolate problems outside of k8VaVoom. You say it only happens with k8VaVoom, which may be true, but that does not necessarily make k8VaVoom the culprit. k8VaVoom may simply use the CPU or memory in a different way than other source ports, making some situation with your particular laptop occur more often. For example, it may use more memory than other source ports, and cause your laptop to use the Windows swapfile, because some other program you're using is also eating a lot memory. Just a possible theory.

 

Please try this test, and post your results. Also, note that I am no expert on k8VaVoom. However, this is a valid test for any program that seems to be experiencing slowdown issues.

 

 

13 hours ago, ketmar said:

also, too bad that we don't have a site with such simple maps for various advanced features. sure, there are not many new sourceports appears each day, but it will still be nice to have even for existing ones, to do regression testing, for example.

Yes, this is badly needed, ,and is a good project to start. We wouldn't have to start from scratch, either. There are a few WADs that are helpful: There's a Boom feature test WAD that actually has textures with text on them, showing the linedef number. These textures are shown right beside an example of each linedef. Actually, I think there are 2 such WADs covering Boom features.

 

There's also the WAD that came with earlier versions of Legacy, showing 3D floors, including a translucent 3D floor river. Also shown are colored light sectors, and lots of Boom floor scrollers.

 

Also, there's that 3D midtex test map.

 

It would be very cool to follow the convention of the Boom test map, and make a bunch of example WADs with textures with text describing each feature. Instead of putting all the features in one map, I would split them up, for engines that choose to support new features one at a time.

 

I'll put this on my very very long to-do list :)

Share this post


Link to post

Concerning the Spelunky game.dat ... why does it seem that a lot of the files in it are read as corrupt by 7-zip? 

Share this post


Link to post
9 minutes ago, Danfun64 said:

Concerning the Spelunky game.dat ... why does it seem that a lot of the files in it are read as corrupt by 7-zip? 

Just a guess: Maybe they were compressed with a newer version of 7-Zip?

Share this post


Link to post

@Danfun64 heh. my fairly old p7z unpacks it without any troubles. yet i downloaded windows version from 7zip.org, and it cannot unpack game.dat for some reason. it looks like new 7z is broken.

 

mine p7z is 15.09, and it works. new one 18.05 fails for some reason.

 

here is repacked file. just rename it to "game.dat", it should work.

game.zip

 

@kb1 not even 7z, it is a custom zip tool.

Edited by ketmar

Share this post


Link to post

One last question. If Spelpub is running under a modified k8vavoom engine (as opposed to native k8vavoom) then where can we download the engine source code (unless of course you make it a pure k8vavoom mod, in which the question would be unnecessary)?

Share this post


Link to post
On 11/3/2018 at 4:27 AM, ketmar said:

vcc runner is inside k8VaVoom source repository, Spelunky source code is inside "game.dat".

There!

Share this post


Link to post

Hm so I found the fps counter option for k8vavoom and apparently when the framerate is capped it f doesn't run at 35 fps like kb1 says it should, it runs at 90 and I don't see any way of changing it. I winder of that has anything to do with the problems I am having since they only happen when the fps is supposed to be capped and the cap is higher than what it should be (I guess?)

Share this post


Link to post

@therektafire cap is 90, this is what it is supposed to be. k8VaVoom is not lockstep engine (ok, not fully lockstep). kb1 just got a slightly wrong idea of what FPS cap in k8VaVoom is (and i missed that, so didn't corrected). i.e. 90 is the right number.

 

also, you can try to turn on VSync. this should give you 60 FPS, and it may trigger some other OS heuristics.

Share this post


Link to post
2 hours ago, ketmar said:

@therektafire cap is 90, this is what it is supposed to be. k8VaVoom is not lockstep engine (ok, not fully lockstep). kb1 just got a slightly wrong idea of what FPS cap in k8VaVoom is (and i missed that, so didn't corrected). i.e. 90 is the right number.

 

also, you can try to turn on VSync. this should give you 60 FPS, and it may trigger some other OS heuristics.

Ah, ok. Interesting. 90 fps is a curious choice, for me. It's not easily divisible by 35, and it doesn't match most monitors I've seen. But, of course, since it's over 35, it's ok. I suppose making it a number not easily divisible by 35 forces the "free stepping" stuff to do its thing on every frame, huh?

 

You're right, I probably got a lot of things wrong about k8VaVoom: it's obviously a very advanced engine that I'd really like to study!

Share this post


Link to post

i am pretty sure that 90 is arbitrary number, just something that was "barely reachable" decade ago.

actually, there is a way to cap on 35 FPS: if "real_time" cvar set to 0, FPS will be capped at 35 (and will actually switch the engine to kinda lockstep mode).

 

tbh, frame timings is something i never really digged. there's some complicated stuff goes on there, slightly different for various cases (pure network client, local game, dedicated server). i just never needed to decipher that code, 'cause it "works for me", and i have alot of other things to do. it looks like i'd better dig it now, as things are not that simple. ;-)

 

Quote

It's obviously a very advanced engine that I'd really like to study!

Janis wasn't joking when he called VaVoom "most advanced source port". ;-)

Edited by ketmar

Share this post


Link to post

Well I tried playing Strife with this, and right off the bat noticed a slight issue: level changes don't actually work! I can't leave Tarnhill.

There doesn't seem to be any replacement system for the "brightmap" effect either, where certain palette colors would remain fullbright at all times. This means that robots don't glow in the dark, the electric crossbow's arrow tip doesn't glow in the dark, etc.

Also, the screen that pops up when you quit only covers the bottom right quarter of the screen:

 

jp0rAvQ.png

 

 

EDIT: Also, Wildweasel's Stranger mod simply crashes the game upon trying to load a level. It was working fine in an earlier version of the port.

Share this post


Link to post

@TheMightyHeracross thank you!

 

stranger mod was really broken (my bad, and a well-hidden bug, tnx!). also, it is slightly broken by itself (tries to give player "ShotgunReloadStart" inventory item, which weren't declared anywhere). but anyway, it works again.

 

you are absolutely right, there is only "fullbright" flag for the whole sprite. i have plans to implement brightmaps, but it is not done yet.

 

as for other bugs -- tnx alot, i will investigate. i have exit prompt turned off, that's why ending screen is garbled -- i just never seen it. ;-) and i still not played past first two guards and first NPC, so report about broken level changes is VERY valuable!

 

i will prolly upload a new build soon.

Share this post


Link to post

i really-really-really-really need at least one more developer. one that knows decorate (and don't afraid to read GZDoom source to decipher what decorate actions really does; but i can help here, and it is not frequently required). 'cmon, people! VaVoom C is very much like C, only better and easier! don't be afraid, i am always here to answer your questions (that is, if i know the answer myself ;-).

 

improving decorate is fun -- you can immediately see results of your work, feedback cycle is very short (you may don't know that, but k8VaVoom compiles the whole VaVoom C codebase at startup, almost 3 MB of source code! it is THAT fast!), and seeing previously broken mods working is a joy.

 

i want to concentrate my efforts on low-level engine parts (improving VaVoom C compiler, adding JIT, rewriting renderer, writing faster GC, and such), and i really need someone to take decorate duties. if only somebody will step in, you will soon see features you've never ever seen in other engines! i have some secret plans on my table, but i am short of time -- there are too many things to do.

 

JOIN THE DARK SIDE, WE HAVE VAVOOM C!

Share this post


Link to post

while we are waiting for Sigil, there is something to destroy... a new build!

reminder for bloodthirsty players: "-gore" can paint your game red. especially with turned off autoaim for hitscans, and headshots.

 

* fixed occasional black bar between status bar and player view
* steamlined decal texture loading; now decals obeys colormaps (invul. inversion, for example)
* texture translations now preserve original texture alpha channel
* fixed rare out-of-buffer access in wad reader
* fixed initial player inventory: i was using invalid variable there (tnx, TheMightyHeracross!)
* proper replacement in decorate (the engine should follow current replacement chain, not simply replacing what is written)
* fixed bug in console command parsing; also, some console commands (summon, give) now have autocompletion for arguments
* slightly optimized internal array implementation
* another bugfix for "+nointeraction" decorate flag
* slightly faster sound channel management code
* fixed case sensitivity where it shouldn't matter
* preliminary (and incomplete) implementation of 3dmidtex (tnx, KVELLER!)
* fixed loading of degenerate (it is a term! ;-) levels (they have no partner segs)
* fixed Strife exit picture and help screens
* actor limiters for gore and bdw mods, so huge levels with lot of monsters won't spawn 100500 blood/casing actors
* better and lighter blood actors in gore mod
* gore mod now works with Strife
* most monster melee attacks (and other damages) spawns some blood now
* less dynamic string allocation in VM
* blood actors now has `Tracer` set to bleeding actor, and `Args[0]` to amount of damage, so your blood mods can have some info to act upon
* "+StickToFloor" and "+StickToCeiling" decorate flags, so you can stop thrusting your actors to ceiling, and use "+NoInteraction" for sticky actors
* VaVoom C ternary (and other) type coercion fixes, and other VC improvements
* some code to reduce sprite flickering for very close sprites (you have to turn on sprite sorting in advanced video options for this to work)

 

 

this build may be somewhat less stable, as i changed alot of internal things, while having a freakin' strong toothache. as i cannot afford pills, we can only hope that i didn't broke everything to pieces. ;-)

Share this post


Link to post

aaaand i immediately found a FATAL bug that can (and will) ruin all your games! who could... please, download hotfix ASAP (531213_1).

Share this post


Link to post

GOOD NEWS, EVERYONE! i am Teh Idiot. almost year ago i introduced very subtle bug in VC Object initialization sequence. it is mostly harmless, and has no fatal effects for Doom/HH games (that's why i never noticed it)... but not for Strife. the effect was that none of special Strife linedef actions were working (including level teleport for seamless world). yay. now i found it, and fixed it, and i will upload a new build soon. there you will be able to really enter into Sanctuary!

 

@TheMightyHeracross i found it! soon you won't be an eternal prisoner of Tarnhill! ;-)

Share this post


Link to post

Awesome job! I'll do another big Strife test when the next build is up and running.

 

Thanks for being so hasty to fix bugs and getting Strife going. :)

Share this post


Link to post

i bet you all want to try working Strife, so... wait no more! here's the build for you!

 

* visual crosshair selector in options menu
* Strife dialogs are usable at 800x600 now
* it is possible to control menus with bound keys in addition to arrows/enter ("cancel" is bound to "strafe")
* fixed bug that prevents Strife specials from acting
* Strife Assault Gun is a hitscan weapon, so it should obey "no autoaim for hitscan weapons" cvar
* it was impossible to complete traitor quest in Strife if you never picked up any gold (yay!)

Edited by ketmar

Share this post


Link to post

eat this, zscript! dynamic arrays of user types, and dictionaries (aka hashtables) of user types!

 

Spoiler

class Main : Object;

struct ListItem {
  string vname;
  int value;
}


struct Test {
  string s;
  int n;
  array!ListItem list;
}


void dumpList (const ref array!ListItem list) {
  writeln(" list length: ", list.length);
  foreach (auto idx, const ref auto val; list) {
    print("  %d: %q=%s", idx, val.vname, val.value);
  }
}


void test00 () {
  array!Test ss;

  dictionary!(string, array!Test) i2s;

  ss.length = 2;

  ss[0].s = "string 1";
  ss[0].n = 42;
  ss[0].list.length = 2;
  ss[0].list[0].vname = "item 0";
  ss[0].list[0].value = 1;
  ss[0].list[1].vname = "item 1";
  ss[0].list[1].value = 2;

  ss[1].s = "string 2";
  ss[1].n = 666;
  ss[1].list.length = 3;
  ss[1].list[0].vname = "item 2";
  ss[1].list[0].value = 3;
  ss[1].list[1].vname = "item 3";
  ss[1].list[1].value = 4;
  ss[1].list[2].vname = "item 4";
  ss[1].list[2].value = 5;

  i2s.put("key", ss);

  ss.length = 0;
  writeln(i2s.length);

  auto sp = i2s.find("key");
  writeln(sp.length);
  foreach (auto idx, ref auto val; *sp) {
    print("--- %d: <%q> : %d", idx, val.s, val.n);
    dumpList(val.list);
  }
}


void test01 () {
  Test ss;

  array!string sarr;
  sarr[$] = "string 1";
  sarr[$] = "string 2";

  dictionary!(string, array!string) i2s;

  i2s.put("a", sarr);

  sarr.length = 0;

  auto sp = i2s.find("a");
  writeln(sp.length);
  foreach (auto idx, auto val; *sp) print("%d: <%q>", idx, val);
}


void main () {
  writeln("===============");
  test00();

  writeln("===============");
  test01();
}

 

 

Share this post


Link to post

with this update, we lost our permanent item: decorate fixes. oops. it is on a vacation, i guess.

 

* rewritten VObject initialisation, so i don't have to remember which fields should not be touched in ctor anymore
* private fields in VC are really private now ;-)
* private method protection violation now correctly reports that violation instead of simple "method not found"
* implemented VaVoom C dictionary type (with complex data types as values; try to do that in zscript! ;-)
* different VC vector types are not compatible now (and it unveiled a bug in explosion code: angles != direction)
* "reduce sprite flickering" code is not really working, so no reason to try it now (oops)
* it is now possible to assign structures (this does deep copying), and deep-copy dynamic arrays
* updated VC mini-documentation
* fixed decal rendering for stenciled lighting
* fixed clipping with translucent/transparent walls
* original aspect ratio is 1.2, not 1.6
* status bar is aspect-correct now (as if anybody is playing in non-fulscreen mode, and cares)
* blood spots in gore mod should have no height ;-)
* various small (bug)fixes
 

Share this post


Link to post

some update for curious persons: i am working on new UI system, with css-like styling, and with flexbox layouter. later, you will be able to freeze a game, and inspect/change various properties of different objects (things, linedefs, sectors, etc.) with nice MDI UI.

 

in the (distant) future, you will be able to use this system to place, for example, light sources and immediately see how your level will look with lighting -- i think that this will be a useful tool for map designers. maybe someday we'll even get full-featured in-game map editor. ;-)

Share this post


Link to post
1 hour ago, ketmar said:

some update for curious persons: i am working on new UI system, with css-like styling, and with flexbox layouter. later, you will be able to freeze a game, and inspect/change various properties of different objects (things, linedefs, sectors, etc.) with nice MDI UI.

 

in the (distant) future, you will be able to use this system to place, for example, light sources and immediately see how your level will look with lighting -- i think that this will be a useful tool for map designers. maybe someday we'll even get full-featured in-game map editor. ;-)

 

That sounds really interesting (not to mention useful). I would love to see that implemented.

Share this post


Link to post

tnx. don't expect map editor soon (the obvious troubles with BSP rebuilding are yet to be solved), but at least Inspector should be done in a month or so (wow, deadlines are never missed, aren't they?) -- because i really need this tool myself (i am so tired of opening maps in eureka to find out what is going on there).

 

new UI system is already working. of course, it has only "button" widget for now, but styling, layouting, window management are already there (it has X Window-like window manager with external decorations, wow!).

 

and various Inspectors will prolly be done as mods, so users will be able to modify existing ones, or write something completely new without rebuilding engine base files at all.

 

this is one of my "Secret Plans". i have other Plans too, but it is too soon to talk about them. ;-)

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
×