Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - CompMix

Pages: [1] 2
1
Modification Help / Re: [DLL] Rendering Optimization Experiments
« on: July 15, 2019, 10:25:41 AM »
Unfortunately, the new Blockland update and the fact I overused static offsets would make this a pain to update, though it's not impossible.

Fortunately... a lot of the things in the original post might be added to the game! Badspot said he would add these improvements, though it would take effort in a PM. I answered some more of his questions yesteday. Stuff like occlusion culling would need a pretty big update, though, so for now it's just the bugs I originally described. Excitement!!

2
Modification Help / Re: [DLL] Rendering Optimization Experiments
« on: July 13, 2019, 10:03:30 AM »
This is absolutely amazing

Also, pardon my lack of understanding, but what you talk about in the OP basically means that bricks outside of the players field of view gets culled out, right?

This is frustum culling, yes. Occlusion culling is not rendering what you don't see, so as if the transparent brick was solid in that vid.

3
Modification Help / Re: [DLL] Rendering Optimization Experiments
« on: July 13, 2019, 09:42:26 AM »
I got occlusion culling to work. There's a bit of a performance hit for max shadows using a batch-by-location renderer, but without shadows enabled the performance improvements are pretty good. Illustrative recording: https://leopard.hosting.pecon.us/dl/onijn/occlusion.mp4

4
Modification Help / Re: [DLL] Rendering Optimization Experiments
« on: July 13, 2019, 12:08:16 AM »
I believe I made a mistake estimating how poorly large batches of geometry would impact game performance. For any visual update for a brick, the entire batch mesh needs an update and obviously this makes a big difference if say, players are building or a mod uses different brick datablocks to symbolize something visual (like the treasure chest). I'm going to briefly revisit the custom renderer since I poured so much time into it anyways to see if occlusion queries actually can be used here. My bad for berating the older pipeline without much reasoning to back it.

5
Gallery / Re: Enhanced Graphics Screenshots + Graphical Resources
« on: July 12, 2019, 09:55:42 AM »
Would it be okay to ask if my rendering optimization DLL be added to the main thread? It's mostly an improvement if you use shadows, so I'd imagine people looking for enhanced shadows would use it. Thanks.

6
Modification Help / Re: [DLL] Rendering Optimization Experiments
« on: July 10, 2019, 07:22:52 PM »
You will have to build it from source. However, as always, anyone can DM me on my discord for a build if they want, or instructions.

7
Modification Help / Re: [DLL] Rendering Optimization Experiments
« on: July 10, 2019, 11:50:04 AM »
also i want to ask as someone who understands rendering but doesn't understand c++, how can the brick batcher be accessed? is there some static location that the global brick batcher can be read from? does it require separate c++ code or can it be accessed from glsl? and finally is it even worth using or is it too slow at this point due to the the limitations of the engine

i see brickbatcher has its own render method for opaque and transparent. does this just provide the logic that opengl can use?

The BrickBatcher class and its friends are disabled because the performance of a batch by location first renderer is poor. You can enable it by uncommenting the CreateCustomBrickRenderer() line in Main. A BrickBatch represents a chunk of bricks and their vertex data renderable by OpenGL. I use a special hack to make the engine tell us whenever the chunks need updating, more about that if you look at the patches. None of this is accessable through glsl (I'm not sure what you mean) but the shaders still apply and everything.

8
Modification Help / [DLL] Rendering Optimization Experiments
« on: July 09, 2019, 08:31:04 PM »
Hello, I'm releasing the rendering optimization DLL I've been working on the last several weeks. It includes a few fixes to improve rendering performance and a *disabled* complete custom brick renderer.

Some exciting screenshots to start us off:





Check out that FPS boost!

So, to briefly outline the fixes, let's discuss the issues. The first issue is Blockland does not frustum cull objects during the shadow map generation pass(es). This means the entire scene will be rendered up to four times even if the shadow cascades are small! This is where the primary FPS increase comes from. The second issue is Blockland uses a bad heuristic to compute the orthographic projection (object to light space) matrix size when doing shadow maps, which greatly overestimates the size they need to be, causing more brick batches to needlessly be rendered even if they're culled against the frustum. Finally, Blockland uses an old frustum culling algorithm which is only mostly correct. Since it culls large objects (octree nodes), it falls victim to the issues discussed on this website: https://www.iquilezles.org/www/articles/frustumcorrect/frustumcorrect.htm. These issues are all fixed with this DLL! Warning: shadow cascade overlaps are forced to be ten percent of the z distance of the previous cascade because of these fixes. Some custom shaders will break unless fixed themselves.

B-But what about that custom brick renderer??!

Unfortunately for Blockland, its rendering pipeline is far too old to take advantage of more modern techniques like batching by location instead of texture in order to utilize technology like hardware occlusion queries. The sad truth is that we will never see effective use of occlusion queries in Blockland just because it's too old. As for why this happens, I'm not even sure myself (much hair has been pulled over this). I included the code for it anyways so people can experiment, but it is disabled by default.

Update: I'm going to briefly revisit this part of the DLL. See below.

Happy rendering!

Source

9
Off Topic / Re: Birthday today. Eternally grateful for you guys!
« on: July 07, 2019, 06:35:43 PM »
Happy birthday, it makes me really happy to hear you overcame your addictions. it sounds like you're in a good place now.
Happy birthday!
Who Happy B-Day!
Happy birthday my dude

Thanks for all of your support!!

blhack 2 when

Ha, ha. I have like a dozen versions on my HDD with various features. Obviously I'm not continuing work on these, but I should mention they have some positive aspects. You could theoretically make an anti esp anticheat with one of the things I did: complete prediction of players given a move. Did you know moves for other players are sent to your client? It's a left out feature of TGE that was originally intended to predict player movements. With it you can make a rad projectile aimbot, or like I said, anti esp, by predicting all the possible locations a player could be in a given amount of ticks and only sending ghost updates when necessary. Many possibilities!

you had a drug addiction??????????????
and happy berthday

Thanks. I started using when I was introduced to opiates after a surgery. They made all my pain and problems go away instantly, and the rest is history. It got to the point where I was staying up for weeks on meth. Not good, but I have a solution now and that's what matters.

10
Off Topic / Birthday today. Eternally grateful for you guys!
« on: July 07, 2019, 05:51:29 AM »
Hey, I'm 20 now. It's been a rough 10 years ever since things started getting hard for me, but here I am coming out on top. I live in a sober home with a dozen other guys right now and it's super rad. I'm grateful to be free of the crazy drug addictions I've been through, and things are finally turning for the better.

Just wanted to say thanks to the Blockland community for being my outlet all this time. Computer stuff was my escape and my way to feel better about myself when I know I couldn't love who I was.

As a way of saying thanks, I'm going to compile a list of bugs I know about Blockland and try and help out the game as much as possible before you know what happens. I love this game so deeply and it has sincerely changed my life and my decisions. I also have several DLLs I'd like to publish as well. Hopefully you guys can make good use of them.

Love you all!

11
Modification Help / Re: Moving Platform
« on: June 23, 2019, 01:39:19 AM »
Is this was is/was being used on Heed's pirate TDM?

Yes. Walking on vehicles is a very complicated hack if you want acceptable combat while standing on them while also not compromising interpolation for other cases.

For anyone who needs prediction disabled on vehicles, there's two solutions:

The first (and easier) trick is to change the integration for a vehicle's datablock to 0, call ::transmitDatablocks(1) for any client you want seeing it (preferably before a client can interact with it, like when they're done loading datablocks or about to join the game), and set it back. The client won't do integration on it's side then, and if you get control of the vehicle force update functions in the engine on the server, you can disable gravity and do whatever you want with them, i.e. create floating platforms or simple rigid bodies.

The second trick is specific to vehicles that 1. don't have tires and 2. won't use buoyant forces. You need to tell the engine the vehicle is at rest and zero out its linear and angular momentum, and the client won't do integration because it is tricked into thinking it has no forces applied to it. This works great for floating things and also doesn't need to mess with datablocks like the previous solution. But of course the setup is a little more difficult.

12
Modification Help / Re: Moving Platform
« on: June 18, 2019, 12:33:22 AM »
We had moving platforms like this implemented with vehicles, selective ghost updates, and replicating the player movement surface walking function to detect whoever was on the vehicle. Through selective ghost updates we could make players warp while you observed the vehicle and force a teleleport when riding. This was needed because when riding, the vehicle object needed to appear rigidly updated as your player object does not get the nice interpolation other players get. I'm intrigued by using physical zones as a way around this but that sounds like a headache for nonlinear motion and could fall victim to whatever prediction would like to do instead, lest a gap in server updates occurs or similar.

To make vehicles float and interpolate smoothly, only a few flags need to be set to trick the client into doing so. The rest is collision testing, math, and ghosting the right data to the right people. With this we had some cool boat mechanics for a TDM although it was laggy as all hell as expected.

13
is it possible for a server sided dll to allow clients to see the objects interpolate or would the clients need their own dll for that since there's no prediction on shapes

That's what made it special. Client does prediction on all vehicles, even ones you're not driving, so it takes a few tricks to both get lack of gravity and disabled prediction.

o im guessing the engine has its own arbitrary gravity math?

x87 and SSE instructions only accept floats from memory locations, not immediate values. I use the word immediate in the code but that's basically meant for anything not in rdata and utilizing the stack (the IEEE representation is reused everywhere). Computing 9.81 times the tick rate is just an optimization.

14
Source has been updated to fix a bug and add in the packet rate patch. Make sure to check that the packet rate variables are set properly because the default scripts like to clamp it on startup as well.

does this also mean events can run at a faster rate?
what about schedule with lower than 33?

events are simply function calls, so that doesnt necessarily happen any faster unless the tickrate also decreases the time it takes for the engine to do something. i kinda doubt that, but it might be the case since its known that timescale 2 == game engine literally runs at 2x speed. that might be a misconception though, but that's what ive heard.

definitely can do schedule lower than 33ms with this setup, probably only useful for logic gate/computer stuff. and even then there's better solutions (Redo's logic bricks that "outsource" the calculations/switching simulation into a lua engine which runs much faster than bl)

Schedules run as fast as the game can run its main loop, so sub-32ms has been a thing since forever. Timescale causes events to run faster because you're artificially scaling the elapsed time that happens between engine loops, which makes schedules execute sooner or later based on how much time has passed. So this DLL doesn't change how fast events execute.

The only difference you would see maybe is if your events or schedules caused ghost updates for things, because the engine will now both simulate objects and send updates to clients faster.

so i guess now i can make staticshapes move fluidly instead of teleporting every 33ms.

With a DLL you can cause vehicles to not have gravity on both the client and server, effectively making them interpolated shapes with rigid body physics. I made moving platforms (gears) for Heedicalking with this method and it's very smooth.

15
Modification Help / Re: [DLL] Tick Rate Modding Experiment
« on: May 12, 2019, 11:38:48 PM »
could you outline the benefits of higher tick rate for those who dont know what this means?

You're right about simulation being keener in general. The game will tick faster (a tick will last 16 or 8ms compared to 32ms) while also moving objects at smaller increments. Input will be sampled more often and makes the game feel smoother. A friend and I crashed a bunch of vehicles into buildings on a 125 tps setting, and we both agreed it felt more "solid" as we couldn't manage to penetrate bricks. Although, no formal measurements were done so this could just be placebo (Additionally this should only be slightly different than just increasing the .integration field in the datablock). The same applies for projectiles and players-- fast moving targets should have a higher likelihood of being hit.

I'm not sure about challenge servers yet because we experienced a few odd bugs related to climbing up stairs and more generally player collision with bricks. It might be that there's an extra patch that needs to be done to fix up collision calculations every tick or it could be something else. Not quite sure yet.

"Superghost but for everything" is accurate. That specific DLL/patch just makes the server flood the client with packets (it's not even specific to bots either-- ghost updates of any kind) until the window is full (ie there's a 30 packet lead from last sent to last acked) but a higher tick rate is fairly comparable, the engine will check if it needs to send packets more often. Although (rather lamely) this is limited by the range of the packet send and receive rates like $Pref::Net::PacketRateToClient as they don't go above 32 packets per second. I'll say more about that below.

Ghosting should be faster but the game will automatically flood clients with packets whenever large amounts of anything are ghosting. That DLL you mentioned patches the function that does this to just always say things are ghosting, completely ignoring the $Pref::Net::PacketRateTo* settings.

also i suspect the reason that normal clients can still join is that ts is able to run on various packet input rates. port described the situation with ts being "it'll update as fast as it receives packets" even though it only normally sends at 30 packets/sec. its how superghost for bots works - it just ups the packet rate on the server so that everyone can get updates for more than 50 bots/players that are moving, at the cost of increased bandwidth usage from the server.

Yeah, so this is kind of like increasing the timescale but with additional patches all over the engine to 1. Decrease movement distance per tick and 2. Slow down timers of things in various simulation functions. I know about unlimited/flexible packet rates and had a hunch regular clients would still be able to play but thought it was naive to feel certain since this is a lot more than just increasing tick rate. They would be running essentially completely different engines simulation wise.

Wait so does this also raise the packet send/receive rate so that the tick rate's data can all be sent? Or do people need another dll for that

I forgot to add a patch for this. Whenever a NetConnection is instantiated it checks the $Pref::Net::PacketRateTo* variables and clamps them so they don't go over 32 packets per second. This is also done when you do %connection.checkMaxRate(). Obviously this needs to be higher for the net code to take full advantage of the rest of the engine changes. I used a hacky TS solution to trick the clamp function to allow me to go up to 128 packets per second (if it thinks you're running a LAN server it quadruples the rate). Here's that (this would work on any vanilla server too and increase packet rates to clients, so think of it like that ghost update limit DLL but in TS!):

Code: [Select]
function NetConnection::setMaxPacketRate(%t)
{
    %c = $pref::Net::PacketRateToClient;
    %s = $pref::Net::PacketRateToServer;

    %l = $Server::LAN;
    %d = doesAllowConnections();

    $Server::LAN = 1;
    setAllowConnections(0);

    %t.checkMaxRate();

    setAllowConnections(%d);
    $Server::LAN = %l;
   
    $pref::Net::PacketRateToClient = %c;
    $pref::Net::PacketRateToServer = %s;
}

package SetMaxPacketRate
{
    function GameConnection::startLoad(%t)
    {
        %t.setMaxPacketRate();
   
        return Parent::startLoad(%t);
    }
};

activatePackage(SetMaxPacketRate);

I'll see if I can fix the bugs I saw with collision and add in those patches for the packet rates tomorrow. You'd have to manually set the variables though.

Pages: [1] 2