DDraceNetwork - developer

@deen Update on hungarian.txt: -Fixed most uppercase errors on words -Fixed spelling mistakes -Added extra details on option descriptions -Added the rest of the missing words, that needed translation

hungarian.txt

22.89 KB

ddnet-maps

[ddnet-maps:master] 1 new commit

01d183a M DontMove, M Pyramid-freeze-race - ddnet-maps

maybe I can try working on 0.7 support in the dissector, ChillerDragon

05:35

@heinrich5991 that would be hot :)

05:38

@yair you mean the score that gets displayed for each player in the scoreboard? That is indeed CPlayer::m_Score but you can also modify when it when its being send to the client in the snap

deen

You can also use https://ddnet.tw/codebrowser/

neat

Cellegen

@deen Update on hungarian.txt: -Fixed most uppercase errors on words -Fixed spelling mistakes -Added extra details on option descriptions -Added the rest of the missing words, that needed translation

Thanks

def-

[ddnet/ddnet] Pull request opened: #5698 Update hungarian language file (by Cellegen)

Checklist

[ ] Tested the change ingame
[ ] Provided screenshots if it is a visual change
[ ] Tested in combination with possibly related configuration options
[ ] 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...

@Jupstar ✪ seems like linus torvald touched the new apple m2 for linux stuff https://lore.kernel.org/lkml/CAHk-=wgrz5BBk=rCz7W28Fj_o02s0Xi0OEQ3H1uQgOdFvHgx0w@mail.gmail.com/

08:08

cuz u said m2 cant do linux :p

Its more about gpu

Could also be m1

08:15

It's really nice to finally have a high performance computer you can use without any fan noise

[quakenet] ChillerDragon

@yair you mean the score that gets displayed for each player in the scoreboard? That is indeed CPlayer::m_Score but you can also modify when it when its being send to the client in the snap

Found it thanks man

hi, I would like to tackle this Prediction for laser doors #1279 , how difficult is this to implement (I'm beginner cpp)?

https://github.com/ddnet/ddnet/issues/1279

Prediction for laser doors · Issue #1279 · ddnet/ddnet

add some prediction for laser doors so you dont have this bouncy buggy screen while walking on them. make them like stoppers (as other players look smooth on doors, just not the own tee)

This might be fixed by https://github.com/ddnet/ddnet/pull/4176. Have you checked that it still looks bouncy?

09:30

For prediction stuff its probably best to get advice from @trml , he's our expert and can maybe guide you to how to best implement something there

def-

[ddnet/ddnet] Issue opened: #5699 Large fps drop with freeze bars

Reported by Skyrx on Discord:

Btw, when 64 players with freeze bar fps drops from 800 to 100-150

@C0D3D3V could you take a look? Is this expected?

deen

It's really nice to finally have a high performance computer you can use without any fan noise

I'm not sure how nice it is to have a different CPU architecture though. on mac I heard it's pretty well integrated, but if you're running linux, I'm not aware of such a thing

What would the problem be?

not being able to run some proprietrary software, having to manually compile stuff, less distros to choose from

I don't think I run any proprietary software on Linux, all just intalled from pacman/AUR

10:18

except some stuff via wine, surprisingly that just works on macOS

10:19

So I guess Rosetta helps for some stuff

(e.g. docker also doesn't work anymore, it's all x86_64 binaries, I think)

10:24

it seems the only proprietrary software that I have installed is clion and webstorm, so that would be fine on ARM as well

gpu driver?

my laptop also has an intel CPU that works out of the box, I haven't installed the discrete GPU's driver

10:25

and that wouldn't matter for the apple laptop, they have their own GPU, no proprietrary drivers for linux exist AFAIK

Intel can kind of blame themselves with ARM. They dropped their own ARM processors to promote Atom, but no one wanted to use Atom in mobile devices. Otherwise iPhone would probably have ran on Intel ARM CPUs from the start

A new processor generation with 30% more performance can overcome the emulation cost required to emulate old software in the processor architecture. Then new software ofc needs to adopt to the new architecture or live with some perf decrease.. But most apps probs don't need insane perf...

but AFAIK I don't have a convenient way to do that on linux yet; that's what I'm complaining about, not the cost of emulation

heinrich5991

but AFAIK I don't have a convenient way to do that on linux yet; that's what I'm complaining about, not the cost of emulation

So Linux on M2/M1 means you don't get any x86_64 compatibility at all?

Mh ok but that's simply bcs it's not a deal yet.. Yuzu emulates the switch. Which is an arm processor

10:34

So it basically exists

I know that theoretically it's no problem

Just wrong way

but I want to practically use the computer ^^

Jupstar ✪

Mh ok but that's simply bcs it's not a deal yet.. Yuzu emulates the switch. Which is an arm processor

A much weaker one than an m1 btw. As it gets stronger and stronger emulating stuff gets very annoying

In VMs you can use Rosetta to run x86-64: https://developer.apple.com/documentation/virtualization/running_intel_binaries_in_linux_vms_with_rosetta?language=objc Not yet on Asahi

it's also not just about being able to run x86_64 code

10:36

apple integrated the whole stuff into the system AFAIK, shipping the relevant libraries also for x86_64, etc. (edited)

yeah, works quite seamlessly

PS3's Cell gave everyone hell, it's emulation is still janky. Older nintendo consoles emulation is still usually inaccurate so it can perform well realtime

deen

In VMs you can use Rosetta to run x86-64: https://developer.apple.com/documentation/virtualization/running_intel_binaries_in_linux_vms_with_rosetta?language=objc Not yet on Asahi

So for native linux to have this someone would need to basically figure out what rosetta does and reimplement it

Learath2

PS3's Cell gave everyone hell, it's emulation is still janky. Older nintendo consoles emulation is still usually inaccurate so it can perform well realtime

Though I guess arm does mesh rather well with native x86 instructions in most matters, hence how performant rosetta and new nintendo console emulators are

Not sure how much of the magic is in hardware vs software. The Linux VM solution could probably be adapted for Asahi

Huh apparently some people already ran rosetta for linux on arm64 machines other than apples

deen

This might be fixed by https://github.com/ddnet/ddnet/pull/4176. Have you checked that it still looks bouncy?

Just got back, do you know if it fixed it or should i go test it out?

I guess what's required for Linux is a multiarch like some distros have for x86-64/x86, but for arm/x86-64 instead, to bring in all the shared libs etc

yup

10:47

ah, is arch linux available for arm? I think there's only archlinuxarm.org, which seems to be for specific systems only

10:47

and not apple hardware

Nope

10:48

just x86-64

10:51

For reference, Debian builds DDNet for these archs: amd64 arm64 armel armhf hppa i386 m68k mips64el mipsel ppc64 ppc64el riscv64 s390x sh4 sparc64 x32

bubliman

Just got back, do you know if it fixed it or should i go test it out?

I don't know, you test it please

1

bubliman

hi, I would like to tackle this Prediction for laser doors #1279 , how difficult is this to implement (I'm beginner cpp)?

it's a little bit complex, but it depends a bit on how it is implemented. the current implementation of laser doors isn't too nice since it works by modifying the map, so the implementation has to take that into account when a switch is enabled/disabled and when a laser door goes in/out of the snapshot (the most complex question is perhaps overlapping laser doors, although a perfect solution is maybe not necessary)

trml

it's a little bit complex, but it depends a bit on how it is implemented. the current implementation of laser doors isn't too nice since it works by modifying the map, so the implementation has to take that into account when a switch is enabled/disabled and when a laser door goes in/out of the snapshot (the most complex question is perhaps overlapping laser doors, although a perfect solution is maybe not necessary)

Client could read and store the value of switches, using that to be able to not walk through a gate when it would know that it is closed. Eliminating the issue since the client would not have to wait for a response from the server. Could this work?

the client already has the switch values (and predicted as well) from the server, so the client only needs to identify where the doors are (using the laser netobjects -- here one question is whether to keep using entityex) and apply these to the map (using the switch status)

I guess there is no harm in introducing new netobjs instead of the entityex solution we initially went with

out of the loop on this, will have to read up how the map interacts with players etc

I would kind of also want to go in that direction

12:29

and that was also why I didnt try to add too many features using entityex initially (also with the new work by codedev etc on extendible netobjects there are perhaps no downsides left)

The only issue I can think of is it's introducing a branch per player, that I dont know how well the branch predictor will do on

12:31

The index of the loop strongly predicts the outcome of the branch, but idk if it's smart enough nowadays

yes, true, have never really looked at server profiling. but since those branches can skip the entityex snapping it will perhaps be a net positive?

@Patiga u ready for the next optimization? xd

trml

yes, true, have never really looked at server profiling. but since those branches can skip the entityex snapping it will perhaps be a net positive?

Dont we snap entityex either way and just let clients that dont understand it drop it themselves?

Jupstar ✪

@Patiga u ready for the next optimization? xd

am on one rn :d

15:03

trying to optimize the cpu calculations, figured out that combining the transformations into one matrix multiplication could be better

Patiga

trying to optimize the cpu calculations, figured out that combining the transformations into one matrix multiplication could be better

i thought about minimizing GPU load too

15:08

but cpu + gpu would ofc be optimal

what did you think of? ^^

its nothing special actually, i already thought about it for ddnet

15:09

but with ddnet it would increase load times, which might be worse than in your experiments

hm what is it? I'm curious :)

Learath2

Dont we snap entityex either way and just let clients that dont understand it drop it themselves?

I dont remember how it is for all entities, but since entityex aren't used for anything yet for lasers (except slightly optimizing delta snapshots) it would be safe to drop them completely if a new laser/door netobject is added

well actually its 2 approaches, since i dunno which is better, and also i am not 100% sure how much it will give, but for bigger maps probs more than enough u pre analyze all textures used, put all non transparent pixels of the texture into one texture, all non transparent into another

oh god o.o

then u draw the non transparent in reversed order without alpha enabled

15:11

and then u either render the others with stencil buffer(which was filled by the non transparent ones)

15:12

yeah i guess try that first, if u interested xd

Jupstar ✪

then u draw the non transparent in reversed order without alpha enabled

don't we have to use the stencil buffer here already, since we render the layers from front to back

yes

15:14

i just forgot to write it there and included it in the next sentence XD

15:14

the first pass fills stencil whenever there is a pixel drawn

15:15

the advantage in your approach over ddnet is, that there a few vertices total

15:15

the GPU ofc has to wait for the previous fragment stage, before starting a new, bcs stencil is used(needs sync for colliding fragments)

oh god separating transparent and non-transparent sounds a bit nightmarish to me o.o

but maybe the drivers are clever enough anyway

15:16

without that approach it wont give u alot tho

15:16

almost any tile layer has atleast rounded corners

15:16

which would result in non transparent pixels

I don't understand how the transparent pass should work though, the stencil buffer has to change whenever there was another non-transparent layer inbetween, no?

also rendering without an alpha stage after the fragment shader should eliminate the extra work for the stencil test inside the fragment shader(e.g. is pixel transparent)

Patiga

I don't understand how the transparent pass should work though, the stencil buffer has to change whenever there was another non-transparent layer inbetween, no?

the non transparent are completly rendered before tho