DDraceNetwork - developer

goodmorning

1

Robyt3

So the maximum size of a square game layer should be 23170x23170

that's sad

03:57

ig I'll start the long long int revolution

Jupstar ✪

i mean somehow tokio does this internally. all i want is control over it xd try_run_tasks so i guess it doesn't exists, rip

i used a different executor now, which does exactly what i wanted to have: https://docs.rs/async-executor/1.5.4/async_executor/struct.LocalExecutor.html#method.try_tick

LocalExecutor in async_executor - Rust

A thread-local executor.

morning

hai

Robyt3

[ddnet/ddnet] Pull request opened: #7344 Use member variables for demo player snapshot data, enable use of video recording for each demo player individually

Use member instead of static variables for demo player snapshot data. The static variables would otherwise cause issues when multiple demo players are playing at the same time, especially demo players used in background jobs for replay demo slicing. This hopefully closes #7068. Previously all demo players checked IVideo::Current to render a video, which would cause issues when rendering a demo while a demo slicing background job is running. Now video rendering can be toggled for each dem...

Teero

ig I'll start the long long int revolution

what for

Robyt3

In the map format yes, in other functions we try to switch to size_t

we should limit map sizes. size_t is a red herring, I think

11:14

@Patiga didn't you have some statistics about plausible max sizes?

yes, I agree with Patiga that 8192x8192 would be a sensible limit for layer sizes. I considered maximum 5000 when I added validation on teeworlds at some point

5000 would also be good

11:16

I would've loved 4096, however there already are maps on ddnet bigger than that

I would use size_t for the parameters anyway, so we can check if Size > MAX_INT and fail the saving

1

all tilemaps over 4096

message.txt

6.6 KB

github-merge-queue[bot]

[ddnet:master] 3 new commits

668e6fb Use member variables for demo player snapshot data - Robyt3 d00283e Enable use of video recording for each demo player individually - Robyt3 2ddde45 Merge pull request #7344 from Robyt3/Engine-Demo-Antistatic - def-

11:25

def-

[ddnet/ddnet] Pull request closed: #7344 Use member variables for demo player snapshot data, enable use of video recording for each demo player individually

11:25

def-

[ddnet/ddnet] Issue closed: #7068 Crash in demo slicing background job

not really sure how how to decide on a good limit, maybe 5000 is the next best conservative size

11:28

huh, I didn't know chill let's climb 2 and 3 have the same height

Robyt3

[ddnet/ddnet] Pull request opened: #7345 Add tests and documentation for swap_endian function

Checklist

[ ] Tested the change ingame
[ ] Provided screenshots if it is a visual change
[ ] Tested in combination with possibly related configuration options
[X] Written a unit test (especially base/) or added coverage to integration test
[ ] Considered possible null pointers and out of bounds array indexing
[ ] Changed no physics that affect existing maps
[ ] Tested the change with [ASan+UBSan or valgrind's memcheck](https://github.com/ddnet/ddnet/#using-addres...

heinrich5991

we should limit map sizes. size_t is a red herring, I think

why would you limit them?

github-merge-queue[bot]

[ddnet:master] 2 new commits

d9a7df0 Add tests and documentation for swap_endian function - Robyt3 46c7229 Merge pull request #7345 from Robyt3/Tests-Swap-Endian - def-

12:24

def-

[ddnet/ddnet] Pull request closed: #7345 Add tests and documentation for swap_endian function

Teero

why would you limit them?

it should at least not cause overflows

12:30

overruns

memory safety

Robyt3

So the maximum size of a square game layer should be 23170x23170

so it should atleast be this no?

That's just one limit in the map format, there could be more limits elsewhere. And it makes no sense to allow maps that cause crashes due to out of memory for the majority of the users