05:29 <+bridge> [ddnet] <bluesky> How can i add a NetIntRange to the NetObject "ClientInfo" and still be able to connect to older server versions that dont know it ?
05:29 <+bridge> [ddnet] <bluesky> How can i add a NetIntRange to the NetObject "ClientInfo" and still be able to connect to older server versions that dont have it declared?
05:30 <+bridge> [ddnet] <bluesky> How can i add a e.g. NetIntRange to a NetObject  and still be able to connect to older server versions that dont have it declared?
05:35 <+bridge> [ddnet] <bluesky> How can i add a e.g. NetIntRange to a NetObject  and still be able to connect to older server versions that dont have it?
05:53 <+bridge> [ddnet] <bluesky> How can i add a e.g. NetIntRange to NetObject "GameInfo" and still be able to connect to older server versions that dont have it?
05:53 <+bridge> [ddnet] <bluesky> How can i add a e.g. NetIntRange to NetObject "ClientInfo" and still be able to connect to older server versions that dont have it?
06:33 <+bridge> [ddnet] <bluesky> How can i add a e.g. NetIntRange to a NetObject and still be able to connect to older server versions that dont have it?
07:38 <+bridge> [ddnet] <bluesky> How can i expand a NetObject and still be able to connect to older server versions that dont have it?
07:43 <+bridge> [ddnet] <Jupstar> Can't hurt i guess
07:44 <+bridge> [ddnet] <bluesky> How can i expand a NetMessage and still be able to connect to older server versions that dont have it?
08:27 <+bridge> [ddnet] <bluesky> https://cdn.discordapp.com/attachments/293493549758939136/998113787792068713/unknown.png
08:28 <+bridge> [ddnet] <bluesky> network.py
08:28 <+bridge> [ddnet] <bluesky> https://cdn.discordapp.com/attachments/293493549758939136/998113787792068713/unknown.png
08:28 <+bridge> [ddnet] <bluesky> This compiles
08:30 <+bridge> [ddnet] <bluesky> but this does not:
08:30 <+bridge> [ddnet] <bluesky> https://cdn.discordapp.com/attachments/293493549758939136/998114517118615692/unknown.png
08:31 <+bridge> [ddnet] <bluesky> https://cdn.discordapp.com/attachments/293493549758939136/998114653588705301/unknown.png
08:31 <+bridge> [ddnet] <bluesky> why
08:31 <+bridge> [ddnet] <bluesky> ^This compiles
08:33 <+bridge> [ddnet] <bluesky> i want to expand the netmessages
08:33 <+bridge> [ddnet] <bluesky> i want to extend the netmessages
08:33 <+bridge> [ddnet] <bluesky> i want to expand the netmessages
08:52 <+bridge> [ddnet] <Jupstar> i assume u didnt initialize the variable
08:58 <+bridge> [ddnet] <bluesky> its automated
08:58 <+bridge> [ddnet] <bluesky> this compiles and its the same just a different message
08:59 <+bridge> [ddnet] <Jupstar> not really
08:59 <+bridge> [ddnet] <Jupstar> u pass a pointer over it
09:00 <+bridge> [ddnet] <Jupstar> if u dont pass a pointer over it, its uninitialized
09:00 <+bridge> [ddnet] <bluesky> yes
09:00 <+bridge> [ddnet] <Jupstar> https://github.com/ddnet/ddnet/blob/3c6402830d0792d285852f5cd1159c7e4d558017/src/game/client/gameclient.cpp#L2078-L2110
09:01 <+bridge> [ddnet] <Jupstar> show me this code in ur version
09:02 <+bridge> [ddnet] <bluesky> https://cdn.discordapp.com/attachments/293493549758939136/998122620669145108/unknown.png
09:03 <+bridge> [ddnet] <Jupstar> see
09:03 <+bridge> [ddnet] <Jupstar> skinbody missing
09:03 <+bridge> [ddnet] <bluesky> i know
09:04 <+bridge> [ddnet] <bluesky> this still compiles
09:04 <+bridge> [ddnet] <bluesky> well let me initialize it
09:04 <+bridge> [ddnet] <Jupstar> but compile != runtime
09:04 <+bridge> [ddnet] <bluesky> yeah i mean the upper one doesnt give me an error
09:04 <+bridge> [ddnet] <Jupstar> ignore the python stuff, its just to generate structs
09:04 <+bridge> [ddnet] <Jupstar> imo also useless for network structs
09:05 <+bridge> [ddnet] <bluesky> i cant judge that i dont know enough about it
09:05 <+bridge> [ddnet] <Jupstar> doesnt or does?
09:05 <+bridge> [ddnet] <bluesky> I want to pass an aditional bool and 4 strings to every player as soon as one changes his skin
09:05 <+bridge> [ddnet] <bluesky> how would you do that
09:05 <+bridge> [ddnet] <bluesky> doesnt
09:06 <+bridge> [ddnet] <Jupstar> u'd use a different packet anyway, bcs this rn destroys vanilla compability and the ddnet admins will roast u
09:06 <+bridge> [ddnet] <Jupstar> but generally, i'd do it similar to your version, u just need to initialize the variables
09:06 <+bridge> [ddnet] <Jupstar> everything else was correct
09:07 <+bridge> [ddnet] <bluesky> okay i will try it
09:07 <+bridge> [ddnet] <bluesky> its weird because i only get the error when i add a string to ChangeInfo, not StartInfo
09:08 <+bridge> [ddnet] <Jupstar> what error does it display?
09:08 <+bridge> [ddnet] <Jupstar> maybe someone added a sizecheck or smth
09:08 <+bridge> [ddnet] <bluesky> i will just use updateskin packet like in 0.7
09:08 <+bridge> [ddnet] <bluesky> for skinchange
09:08 <+bridge> [ddnet] <bluesky> this error on adding a string in ChangeInfo
09:09 <+bridge> [ddnet] <Jupstar> then its just luck
09:09 <+bridge> [ddnet] <bluesky> <:(
09:09 <+bridge> [ddnet] <Jupstar> uninitilaized values can be anything
09:13 <+bridge> [ddnet] <bluesky> it works now obviously after initializing it
09:13 <+bridge> [ddnet] <bluesky> but i still wonder why the StartInfo works without initializing it
09:14 <+bridge> [ddnet] <Jupstar> set a breakpoint, see what value m_pSkinBody has
09:14 <+bridge> [ddnet] <Jupstar> then u know it
09:15 <+bridge> [ddnet] <bluesky> i searched references but didnt find any so i might do the brakpoint
09:15 <+bridge> [ddnet] <bluesky> yes
09:15 <+bridge> [ddnet] <bluesky> thank you
09:15 <+bridge> [ddnet] <bluesky> i hope it get it to work
09:17 <+bridge> [ddnet] <Jupstar> u wont find anything.
09:17 <+bridge> [ddnet] <Jupstar> 
09:17 <+bridge> [ddnet] <Jupstar> Imagine it like this:
09:17 <+bridge> [ddnet] <Jupstar> RAM consists of random bytes at the start, bcs always setting all bytes of your whole RAM to zero at the computer start would be useless, u dont use all RAM most of the time
09:17 <+bridge> [ddnet] <Jupstar> 
09:17 <+bridge> [ddnet] <Jupstar> now c++ allows you to use uninitialized memory. This is basically the RAM as is. This can in some situations be useful if you dont care about initializing it to zero before using it
09:21 <+bridge> [ddnet] <bluesky> yeah memzero before using big data
09:22 <+bridge> [ddnet] <bluesky> I found out why the behaviour seemed weird
09:23 <+bridge> [ddnet] <bluesky> ChangeInfo gets used before StartInfo
09:23 <+bridge> [ddnet] <bluesky> "OnRender" at startup calls SendInfo(false)
09:23 <+bridge> [ddnet] <bluesky> ChangeInfo gets used before StartInfo
09:23 <+bridge> [ddnet] <bluesky> "OnRender" calls SendInfo(false)
09:30 <+bridge> [ddnet] <bluesky> i will make a pr soon and i hope its gets for good constructive critic because i really wanna optimise and learn how to do things better
09:30 <+bridge> [ddnet] <bluesky> i will make a pr soon and i hope its gets good constructive critic because i really wanna optimise and learn how to do things better
11:17 <+bridge> [ddnet] <lynn> ^ really annoying imo
11:17 <+bridge> [ddnet] <lynn> sometimes i need to show how to do something in a speedrun when none of us have started racing, but as soon as i do it we have to rejoin team again cus i forget this bug
11:18 <+bridge> [ddnet] <lynn> tbqh didnt know how it worked exactly until now xd
11:18 <+bridge> [ddnet] <lynn> okay why cant i reproduce it suddenly
11:19 <+bridge> [ddnet] <lynn> there is SOMETHING broken about it, i thought for sure this was the way to produce it
11:19 <+bridge> [ddnet] <lynn> grrr
11:51 <+bridge> [ddnet] <lynn> oh i see what codedev said
11:51 <+bridge> [ddnet] <lynn> makes sense then
12:57 <+bridge> [ddnet] <cauldron> well i was just wondering.
12:59 <+bridge> [ddnet] <Ryozuki> https://scratch.mit.edu/projects/322341152/
12:59 <+bridge> [ddnet] <Ryozuki> terraria in scratch
13:15 <+bridge> [ddnet] <fokkonaut> Not possible
13:54 <+bridge> [ddnet] <Jupstar> then transform your wondering into a pr xdd
15:53 <+bridge> [ddnet] <heinrich5991> @Ryozuki I added documentation to my rust stuff: https://github.com/heinrich5991/ddnet/commit/655c812992f6d0f46fcffaa28d59ddd9da12ace8 🙂
15:56 <+bridge> [ddnet] <Ryozuki> nice 👀
16:45 <+bridge> [ddnet] <Patiga> @Not Keks @Tater I'm thinking about implementing a tilemap optimization, because the performance in browsers isn't optimal yet
16:45 <+bridge> [ddnet] <Patiga> (apart from tilemap optimizations I could 1. add mipmaps or 2. add more stuff to the renderer like entities or smth)
16:45 <+bridge> [ddnet] <Patiga> I currently can think of 2 things that could be big optimizations:
16:45 <+bridge> [ddnet] <Patiga> 1. render the tilemap to a texture first and for each next frame only render the difference (this would make tilemaps basically a no-op if the camera doesn't move), as explained in the factorio blog here https://steamcommunity.com/app/387290/discussions/0/1694924244565179392/
16:45 <+bridge> [ddnet] <Patiga> 2. reduce how much of the screen we render for each tilemap each frame. maybe split the screen into multiple quads and calculate on the cpu which of the quads actually have tiles on them, or just calculate how much clipping we can do by kinda calculating a bounding box of the visible tiles on the screen
16:45 <+bridge> [ddnet] <Patiga> 
16:45 <+bridge> [ddnet] <Patiga> for 2. there might be more options but I don't see them yet
16:45 <+bridge> [ddnet] <Patiga> which of the two do you think will be the better improvement?
16:46 <+bridge> [ddnet] <Patiga> oop, wrong link
16:46 <+bridge> [ddnet] <Patiga> https://www.factorio.com/blog/post/fff-333
16:51 <+bridge> [ddnet] <Jupstar> im interested in 1., but i think you shouldnt underestimate that waiting for the previous frame can cost lot of idle time, so if you not runnning into a bigger GPU bottleneck it might work out even worse, how often does the camera actually stand still? and has no animations etc.
16:52 <+bridge> [ddnet] <Patiga> I'd do that for each tilemap individually, there are no movement animations for tilemaps and I'd render it in the normal color and add the envelope color in the fast simple render step
16:53 <+bridge> [ddnet] <heinrich5991> that sounds like a lot of memory. it seems you could batch tilemaps with same parallax together
16:53 <+bridge> [ddnet] <Jupstar> ok but the whole layer?
16:53 <+bridge> [ddnet] <heinrich5991> same parallax and same color envelopes etc.
16:53 <+bridge> [ddnet] <Jupstar> or your tilemap as you have them now?
16:54 <+bridge> [ddnet] <Patiga> @Not Keks I'm not sure what you mean, each layer would be rendered individually, yes
16:55 <+bridge> [ddnet] <Patiga> @heinrich5991 yea that would be a good optimizations, but I'd rather do that at the end, because I think thats quite some added complexity
16:55 <+bridge> [ddnet] <Jupstar> yeah but u want to render the full layer?
16:56 <+bridge> [ddnet] <Patiga> I think the full list of things that have to be the same is parallax, envelope, envelope offset
16:56 <+bridge> [ddnet] <Jupstar> like 4000 x 4000 tiles? XD
16:56 <+bridge> [ddnet] <Patiga> no, only what the camera sees
16:56 <+bridge> [ddnet] <Jupstar> or just apply it per layer
16:56 <+bridge> [ddnet] <Jupstar> ok
16:56 <+bridge> [ddnet] <Jupstar> but still, how often does ur camera stand still
16:56 <+bridge> [ddnet] <Jupstar> especially when in an "editor" mode
16:56 <+bridge> [ddnet] <Patiga> well also if it moves, the amount of tilemap calculations is much much less I think
16:57 <+bridge> [ddnet] <Jupstar> but anyway, please try it out, i am interested in it
16:57 <+bridge> [ddnet] <Patiga> for each frame you probably move less than a pixel I'd guess
16:57 <+bridge> [ddnet] <Patiga> maybe thats a little exaggerated
16:59 <+bridge> [ddnet] <Jupstar> well for zooming out far it might give some nice performance extras ^^
16:59 <+bridge> [ddnet] <cauldron> sure, i guess thats an easy one
16:59 <+bridge> [ddnet] <Jupstar> but actually maybe not
17:00 <+bridge> [ddnet] <heinrich5991> why not?
17:01 <+bridge> [ddnet] <Jupstar> his method already kinda is linear
17:01 <+bridge> [ddnet] <Jupstar> and doest require to wait for the last frame
17:02 <+bridge> [ddnet] <Jupstar> zooming out or not doesnt make a big difference in his method
17:02 <+bridge> [ddnet] <Jupstar> bcs it doesnt rely on the vertex shader
17:10 <+bridge> [ddnet] <fokkonaut> https://media.discordapp.net/attachments/617614400739737604/998244860962275368/screenshot_2022-07-17_17-06-55.png
17:10 <+bridge> [ddnet] <fokkonaut> Many people report this, not only on my server but als others
17:11 <+bridge> [ddnet] <fokkonaut> They say they need to connect multiple times to fix it
17:11 <+bridge> [ddnet] <fokkonaut> This doesnt seem to have arrived perfectly ^^
17:11 <+bridge> [ddnet] <fokkonaut> Whatever it is made for
17:12 <+bridge> [ddnet] <Patiga> @Not Keks ah, another thing I'm wondering about is if there is a difference between doing many render passes in a command buffer or simply doing a new command buffer for each render pass and submitting them together
17:14 <+bridge> [ddnet] <Jupstar> i dunno, but many render passes might be a problem ofc, at least if you load the previous framebuffer
17:14 <+bridge> [ddnet] <Jupstar> OP_LOAD vs OP_DONT_CARE
17:15 <+bridge> [ddnet] <Jupstar> the idea behind multiple command buffers is really more for multi threading, or if you are able to have completly static command buffers
17:15 <+bridge> [ddnet] <Jupstar> for ddnet i use them only for multi threading
17:15 <+bridge> [ddnet] <Patiga> oh, to be able to record them faster?
17:15 <+bridge> [ddnet] <Jupstar> yeah kinda, you can build a signle frame in many threads
17:16 <+bridge> [ddnet] <Jupstar> https://user-images.githubusercontent.com/6654924/153448356-941222a3-8bd3-424d-8685-a43389a4f691.png
17:16 <+bridge> [ddnet] <Jupstar> 
17:16 <+bridge> [ddnet] <Jupstar> vk_st vs vk_mt is mostly about building the command buffers 😄
17:18 <+bridge> [ddnet] <Patiga> I don't think I need to load the previous framebuffer, though I also don't have DONT_CARE, only clear with a color
17:18 <+bridge> [ddnet] <Patiga> ah right, I do need load for the tilemap render textures
17:20 <+bridge> [ddnet] <Jupstar> mhh, i assume the opengl backend doesnt support it
17:20 <+bridge> [ddnet] <Patiga> load? eh :c
17:20 <+bridge> [ddnet] <Jupstar> but yeah u need to load anyway
17:20 <+bridge> [ddnet] <Jupstar> ah
17:20 <+bridge> [ddnet] <Jupstar> that also doesnt exists?
17:20 <+bridge> [ddnet] <Patiga> load exists
17:20 <+bridge> [ddnet] <Jupstar> ok
17:21 <+bridge> [ddnet] <Patiga> ah right, my message there is confusing
17:22 <+bridge> [ddnet] <Jupstar> anyway, my prediction is, fast GPUs will not gain anything might even loose FPS, very slow GPUs might gain from it. Let's see how it turns out 😄
17:23 <+bridge> [ddnet] <Jupstar> and i assume web performs bad bcs of other reasons than your renderer, it simply sucks xdd
17:23 <+bridge> [ddnet] <Jupstar> maybe too many fallbacks for GLES3 compability
17:31 <+bridge> [ddnet] <Patiga> heh ^^
17:32 <+bridge> [ddnet] <Jupstar> btw it ran quite ok for me, do u use firefox?
17:33 <+bridge> [ddnet] <Patiga> yes, but not at 144 fps as on chromium :d
17:33 <+bridge> [ddnet] <Patiga> mostly at 80 iirc
17:35 <+bridge> [ddnet] <Patiga> ah before I start trying that out, can one of your tools figure out how much time is spent in the tilemap fragment shader opposed to the rest?
17:35 <+bridge> [ddnet] <Jupstar> on the browser?
17:36 <+bridge> [ddnet] <Patiga> that would be best
17:36 <+bridge> [ddnet] <Patiga> but shouldn't the native time distribution be about the same?
17:39 <+bridge> [ddnet] <Jupstar> if webgl doesnt fallback to software rendering or smth
17:44 <+bridge> [ddnet] <Patiga> sooo, do you happen to have such a tool? ^^
17:46 <+bridge> [ddnet] <Jupstar> i looked a bit, i'd say the wgpu backend does lots of useless state changes
17:47 <+bridge> [ddnet] <Jupstar> lots of repeated webgl state changes
17:47 <+bridge> [ddnet] <Jupstar> https://cdn.discordapp.com/attachments/293493549758939136/998254559250096199/unknown.png
17:47 <+bridge> [ddnet] <Jupstar> 2303 commands for map "tutorial" on default zoom
17:47 <+bridge> [ddnet] <Jupstar> sounds insane 😄
17:48 <+bridge> [ddnet] <Patiga> that is the amount of commands inside of the command buffer per frame?
17:48 <+bridge> [ddnet] <Jupstar> @Patiga ddnet with GLES 3 does 603 for everything(HUD, text, etc.)
17:48 <+bridge> [ddnet] <Jupstar> yes
17:49 <+bridge> [ddnet] <Jupstar> at least i assume it is?
17:49 <+bridge> [ddnet] <Jupstar> or is that a record of multiple frames, let me see
17:49 <+bridge> [ddnet] <Patiga> how is that tool called?
17:49 <+bridge> [ddnet] <Jupstar> spectate.js or smth i alraedy gave it to you a while ago
17:50 <+bridge> [ddnet] <Jupstar> but it also crashes my firefox often rn xD
17:50 <+bridge> [ddnet] <Patiga> heh ^^
17:50 <+bridge> [ddnet] <Jupstar> but yeah i'd say single frame
17:51 <+bridge> [ddnet] <Jupstar> https://addons.mozilla.org/de/firefox/addon/spector-js/
17:58 <+bridge> [ddnet] <Patiga> when I go to the Information tab up there it says
17:58 <+bridge> [ddnet] <Patiga> > Commands Summary
17:58 <+bridge> [ddnet] <Patiga> >     total: 2301
17:58 <+bridge> [ddnet] <Patiga> >     draw: 61
17:58 <+bridge> [ddnet] <Patiga> >     clear: 0
17:58 <+bridge> [ddnet] <Patiga> so maybe its actually the total amount of commands?
17:58 <+bridge> [ddnet] <Jupstar> i assume so
17:58 <+bridge> [ddnet] <Jupstar> but ddnet uses 603 commands for everything
17:58 <+bridge> [ddnet] <Jupstar> hud, text and ingame rendering
17:59 <+bridge> [ddnet] <Patiga> but then I'd only use
17:59 <+bridge> [ddnet] <Patiga> ~37 each frame, right? but that sounds too little
17:59 <+bridge> [ddnet] <Jupstar> what?
17:59 <+bridge> [ddnet] <Patiga> is each draw call a frame?
18:00 <+bridge> [ddnet] <Jupstar> no
18:00 <+bridge> [ddnet] <Jupstar> 1 frame 603 commands
18:00 <+bridge> [ddnet] <Patiga> ah, each draw is a draw call on the pipeline
18:00 <+bridge> [ddnet] <Jupstar> ddnet has more drawcalls anyway, you cannot directly compare it, but it doesnt call random opengl commands for no reason xD
18:01 <+bridge> [ddnet] <heinrich5991> these messages are just troubleshooting tips when you don't connect to the game server instantly
18:01 <+bridge> [ddnet] <heinrich5991> they're not stopping you from connecting
18:02 <+bridge> [ddnet] <Jupstar> @Patiga i get > 600 fps btw
18:02 <+bridge> [ddnet] <Jupstar> https://cdn.discordapp.com/attachments/293493549758939136/998258504374693929/unknown.png
18:02 <+bridge> [ddnet] <Jupstar> on firefox
18:03 <+bridge> [ddnet] <Jupstar> chrome sadly forces vsync, dunno how i can disable it
18:03 <+bridge> [ddnet] <fokkonaut> Ahhhh
18:03 <+bridge> [ddnet] <Patiga> oh that would be more than enough, what graphics card do you have?
18:03 <+bridge> [ddnet] <Patiga> I have nvidia 1060 3GB
18:03 <+bridge> [ddnet] <Jupstar> rx 6900 xt xd
18:03 <+bridge> [ddnet] <heinrich5991> my GPU probably isn't fast, but zooming out very far goes down to just a couple of FPS
18:03 <+bridge> [ddnet] <Jupstar> so maybe little OP
18:04 <+bridge> [ddnet] <Patiga> that might be a tiny bit OP
18:04 <+bridge> [ddnet] <heinrich5991> that's probably going to be fixed by not re-rendering everything
18:04 <+bridge> [ddnet] <Jupstar> on patigas renderer?
18:04 <+bridge> [ddnet] <heinrich5991> no, in ddnet
18:04 <+bridge> [ddnet] <Jupstar> yes ddnet has vertex shader overhead
18:04 <+bridge> [ddnet] <heinrich5991> ah sorry, didn't read the whole conversation
18:04 <+bridge> [ddnet] <Patiga> I gtg off for now, will look into it more later
18:04 <+bridge> [ddnet] <Jupstar> ok
18:16 <+bridge> [ddnet] <Jupstar> 540 commands on ddnet web edition
18:17 <+bridge> [ddnet] <fokkonaut> https://cdn.discordapp.com/attachments/293493549758939136/998262279374123008/unknown.png
18:18 <+bridge> [ddnet] <fokkonaut> <a:peepopoggersspin:980464802507931708>
19:03 <+bridge> [ddnet] <Patiga> @Not Keks can I also see how long the rendering took / how long each fragment shader took?
19:03 <+bridge> [ddnet] <Patiga> or can you see that information on native maybe?
19:03 <+bridge> [ddnet] <Jupstar> renderdoc has that but not per stage, but its defs ur fragment shader anyway
19:04 <+bridge> [ddnet] <Patiga> why is it definitely the fragment shader?
19:04 <+bridge> [ddnet] <Jupstar> bcs ur vertex shader makes basically nothing
19:04 <+bridge> [ddnet] <Patiga> I guess I could test it by seeing how performance scales with the amount of tilemap layers
19:05 <+bridge> [ddnet] <Patiga> well it could maybe also just be slow in general, no? I'm not sure how big the wgpu abstraction overhead is
19:07 <+bridge> [ddnet] <Jupstar> yes could be, i have to compile without vsync for my version, then i can see how much fps i get 😄
19:37 <+bridge> [ddnet] <σℓí♡> btw why copy don't work in f2? but work in f1
19:42 <+bridge> [ddnet] <Patiga> @Not Keks my measurements on native:
19:42 <+bridge> [ddnet] <Patiga> empty map - 40,000 fps
19:42 <+bridge> [ddnet] <Patiga> 16 tiles layers - 6750 fps
19:42 <+bridge> [ddnet] <Patiga> 32 tiles layers - 3700 fps
19:42 <+bridge> [ddnet] <Patiga> 64 tiles layers - 2050 fps
19:42 <+bridge> [ddnet] <Patiga> 16 quads layers - 36550 fps
19:42 <+bridge> [ddnet] <Patiga> 32 quads layers - 35950 fps
19:42 <+bridge> [ddnet] <Patiga> 64 quads layers - 33300 fps
19:43 <+bridge> [ddnet] <Patiga> so yea, the tiles layers are quite heavy
19:46 <+bridge> [ddnet] <Jupstar> lmao, but ur broken fps
19:46 <+bridge> [ddnet] <Patiga> ah right
19:46 <+bridge> [ddnet] <Patiga> did I ask already how to properly count fps? ^^
19:48 <+bridge> [ddnet] <Jupstar> take the average xd
19:49 <+bridge> [ddnet] <Jupstar> or just use external tools
19:49 <+bridge> [ddnet] <Patiga> average of what exactly?
19:50 <+bridge> [ddnet] <Jupstar> the frame times
19:50 <+bridge> [ddnet] <Patiga> and can I measure the frame time on the cpu?
19:51 <+bridge> [ddnet] <Jupstar> i assume ur whole code is single threaded?
19:51 <+bridge> [ddnet] <Patiga> yes
19:51 <+bridge> [ddnet] <Jupstar> so every new render call is a new frame basically
19:51 <+bridge> [ddnet] <Jupstar> it doesnt buffer for ever
19:52 <+bridge> [ddnet] <Patiga> but how is that different from my approach? counting the frames and dividing by the amount of seconds
19:53 <+bridge> [ddnet] <Jupstar> i dunno u did that for like 5 seconds
19:53 <+bridge> [ddnet] <Jupstar> the average for 5 seconds xd
19:53 <+bridge> [ddnet] <Patiga> buts thats what I do
19:53 <+bridge> [ddnet] <Patiga> for 5 seconds I increment a counter
19:54 <+bridge> [ddnet] <Patiga> and divide that counter by 5 to display the fps
19:56 <+bridge> [ddnet] <Jupstar> but 40k fps never xD
19:57 <+bridge> [ddnet] <Patiga> hmmm
19:57 <+bridge> [ddnet] <Patiga> I forgot to divide by 5 xd
19:58 <+bridge> [ddnet] <Patiga> it seems I neglected that tool a bit too much
20:03 <+bridge> [ddnet] <Patiga> adjusted fps counts:
20:03 <+bridge> [ddnet] <Patiga> empty map - 8,000 fps
20:03 <+bridge> [ddnet] <Patiga> 16 tiles layers - 1350 fps
20:03 <+bridge> [ddnet] <Patiga> 32 tiles layers - 740 fps
20:03 <+bridge> [ddnet] <Patiga> 64 tiles layers - 410 fps
20:03 <+bridge> [ddnet] <Patiga> 16 quads layers - 7310 fps
20:03 <+bridge> [ddnet] <Patiga> 32 quads layers - 7190 fps
20:03 <+bridge> [ddnet] <Patiga> 64 quads layers - 6660 fps
20:07 <+bridge> [ddnet] <Jupstar> mhh, what do u think is the bottleneck, GPU cores?
20:07 <+bridge> [ddnet] <Jupstar> VRAM usage is also relativly high with this rendering technique right?
20:10 <+bridge> [ddnet] <Patiga> hm I'm not sure, we'd need to measure that
20:10 <+bridge> [ddnet] <Jupstar> normally textures and vertex buffers are highly optimized, but ofc u access the textures for every single fragment
20:10 <+bridge> [ddnet] <Jupstar> u basically have a texture lookup more than ddnets renderer
20:10 <+bridge> [ddnet] <Patiga> well the vram usage of each tilemap is easy to calculate with this rendering technique, how many does the ddnet version use for each tile on this map?
20:11 <+bridge> [ddnet] <Patiga> width * height * 4 * 4
20:11 <+bridge> [ddnet] <Patiga> I could reduce it by a factor of 2 by using f16 instead of f32 for the tilemap
20:13 <+bridge> [ddnet] <Jupstar> do u need more than u8?
20:13 <+bridge> [ddnet] <Jupstar> uint 8
20:13 <+bridge> [ddnet] <Patiga> I don't know what the bottleneck is
20:13 <+bridge> [ddnet] <Jupstar> its just tile index right?
20:13 <+bridge> [ddnet] <Jupstar> or other stuff in it?
20:14 <+bridge> [ddnet] <Patiga> yes, I used floats so that it is less work for the fragment shader
20:14 <+bridge> [ddnet] <Patiga> its index, flip_x, flip_y, rotate
20:14 <+bridge> [ddnet] <Jupstar> mh ok
20:14 <+bridge> [ddnet] <Patiga> index has to be (index + 0.5) / 256 in the fragment shader
20:15 <+bridge> [ddnet] <Patiga> and flip_x, flip_y, rotate would need to be cast to float
20:16 <+bridge> [ddnet] <Patiga> the index calculation coz it has to index into the mapres 3d texture
20:17 <+bridge> [ddnet] <Jupstar> yeaj
20:17 <+bridge> [ddnet] <Jupstar> yeah
20:17 <+bridge> [ddnet] <Jupstar> well anyway, vram isnt biggest issue, its really just about how much overhead comes from sampling
20:17 <+bridge> [ddnet] <Jupstar> f16 might be lighter too ofc
20:17 <+bridge> [ddnet] <Patiga> ah
23:14 <+bridge> [ddnet] <bluesky> `if(DoButton_CheckBox(&m_Dummy, Localize("Dummy settings"), m_Dummy, &Dummy))
23:14 <+bridge> [ddnet] <bluesky> {
23:14 <+bridge> [ddnet] <bluesky>     m_Dummy ^= 1;
23:14 <+bridge> [ddnet] <bluesky> }`
23:15 <+bridge> [ddnet] <bluesky> menu_settings.cpp
23:15 <+bridge> [ddnet] <bluesky> 
23:15 <+bridge> [ddnet] <bluesky> why is it ^= instead of =
23:19 <+bridge> [ddnet] <heinrich5991> `^` is bitwise XOR
23:19 <+bridge> [ddnet] <heinrich5991> so this means `m_Dummy = m_Dummy ^ 1`
23:20 <+bridge> [ddnet] <bluesky> okay seems pretty useless for a simple bool right
23:20 <+bridge> [ddnet] <heinrich5991> it's equivalent to `m_Dummy = !m_Dummy`
23:20 <+bridge> [ddnet] <bluesky> oh okay now i get it
23:21 <+bridge> [ddnet] <bluesky> damn everything is so extra in cpp when there is a more common solution to most stuff
23:21 <+bridge> [ddnet] <bluesky> xD