Development discussion. Logged to https://ddnet.tw/irclogs/ Connected with DDNet's IRC channel, Matrix room and GitHub repositories — IRC: #ddnet on Quakenet | Matrix: #ddnet-developer:matrix.org GitHub: https://github.com/ddnet
Between 2017-11-29 00:00:00Z and 2017-11-30 00:00:00Z
<nemo2> seems silly to throw away something with some marginal value. So I go into windows, turn off as many services as I can, turn off restore points, remove swap, turn on full drive compression, uninstall any preinstalled stuff.
<nemo2> heh. there was a time I had every DOS command memorised. was super scornful of wyswig document tools. wp51 for-ever who would ever want a tool where your formatting marks are invisible
<heinrich5991> nemo2: how do you save the collision? tightly packed?
22:48
<nemo2> heinrich5991: collision is simply a 2 byte array. so a traditional 1024x2048 map uses 4 megs of RAM
22:48
<nemo2> heinrich5991: whiiiich nowdays is really not that much
22:49
<nemo2> heinrich5991: we did in fact get it running on first generation iphone. although with 1024x1024 map limit - I think we could probably have done 2048x1024 tho
<nemo2> heinrich5991: things are actually getting a bit tight as it is
22:54
<eeeee> in teewebs i had an optimization to only store the game layer as a bitmap (for fast collision tests), and all other layers as rle packed since rendering scans them sequentially and overhead is not that large for that
22:57
<nemo2> eeeee: yeah. we actually have 2 arrays. one for rendering and one for collision
22:58
<nemo2> we've considered RLE for the non-collision one, but haven't bothered yet
22:58
<eeeee> would be nice to research better data structures for collision as well
22:58
<nemo2> eeeee: actually we are rather wasteful since we have 2 bytes for the collision terrain flags, and 4 bytes for the pixel data
22:59
<nemo2> eeeee: in addition though there's also the gl textures
22:59
<nemo2> but at least we don't create those for empty areas
22:59
<nemo2> the one we should crank down is the pixel data. RLE would help there.
22:59
<nemo2> at this point probably won't get fixed tho
23:00
<nemo2> systems have more and more RAM - probably mattered back when we were trying to support really wimpy specs
23:00
<heinrich5991> eeeee: collision trees or sth?
23:00
<heinrich5991> like you have one big square
23:00
<nemo2> heinrich5991: hm? all collision is pixel based
23:00
<eeeee> agree, generally better to spend time adding new features for 95% of your users than making optimizations for the remaining 5%
23:01
<heinrich5991> which splits into four more squares if the collision isn't the same over the whole square
23:01
<nemo2> heinrich5991: oh. no
23:01
<nemo2> heinrich5991: warmux experimented with that kind of model
23:01
<nemo2> they never did get it to work properly w/ a fully destructible pixel world
23:01
<heinrich5991> mhh
23:01
<heinrich5991> okay
23:01
<nemo2> don't see much benefit in it tbh
23:02
<eeeee> heinrich5991: i see how that supports efficient point collision tests, but do you know how to do the line segment collision thing that tw needs?
23:02
<heinrich5991> isn't that easily possible as well?
23:02
<heinrich5991> you check the squares the line goes through
23:03
<heinrich5991> which is better than the current: check after 1 "game-distance"
23:03
<eeeee> yeah but how fast is it when your tree is dense
<nemo2> mostly used to pass through hogs and objects
23:04
<nemo2> but occasionally other things
23:05
<eeeee> uh tfw i just now realized you're coding in pascal.. haven't seen any pascal codez in a long time
23:06
<nemo2> eeeee: Rust is on the todo 😉
23:07
<eeeee> cool
23:07
<nemo2> it's a pretty C-like pascal. no OOP
23:07
<eeeee> why though?
23:07
<nemo2> why rust?
23:07
<eeeee> yeah
23:07
<nemo2> ton of reasons
23:07
<nemo2> freepascal has had many compiler bugs over time. optimises poorly, has no llvm support.
23:08
<eeeee> well i mean, C+ kind of works fine for teeworlds for example
23:08
<nemo2> we constantly get people complaining about syntax. I have relatively little sympathy for folks who can't figure out that mapping but it is a minor issue
23:08
<nemo2> rust though would free us from our occasional fails on things like failure to initialise or bad pointer math
23:08
<eeeee> we're even migrating from C+ to C++ now
23:08
<nemo2> wait. I thought that was a typo
23:08
<nemo2> "C+" is what exactly
23:09
<eeeee> haha, C+ is when your code isn't using stl or most modern C++ features but still isn't C either