the clock rate isn't quite enough--because more enemies do cause it to advance the program counter more...
really you do want to measure how long the frame took and sleep the interim
It was WC1 and I disassembled the code and added in a time-dependent limiter in dosbox.
I also added multiplayer--it's not quite documented and ready for consumption, but if you're interested in how it works, the code is right now up as a patch to dosbox in the wcmulti branch
https://github.com/danielrh/dosbox3d/tree/wcmulti
most of the changes are in the src/cpu/core_Normal.cpp and src/cpu/wc_net.cpp
the way you run it is... run a retail copy of WC.EXE with the branch of dosbox3d
then do
wcnet startserver <port>
on one machine and
wcnet connect <ip addr> <port>
then both machines just run wing commander as normal.
and the first one can start the first mission and the other connects in and gets to play as spirit. You can play through the whole campaign this way
Now I almost regret never having really played WC back then. Suddenly having the ability to play a round or two in co-op sounds pretty amazing and it's the first time I've seen DOSBox used to augment a running program by peek- and poking around in its address space. I feel like this almost deserves its own post.
We heavily investigated zstd and met with the brilliant inventor, Yann, who provided amazing insights into the design and rationale behind zstd and why it is so fast and such an amazing technology. I also recompiled zstd into rust using https://github.com/immunant/c2rust and tried using various webasm mechanisms to run it (I didn't get webasm quite fast enough, and teaching c2rust to make it safe would be quite a slog).
But the main reason we settled on Brotli was the second order context modeling, which makes a substantial difference in the final size of files stored on Dropbox (several percent on average as I recall, with some files getting much, much smaller).
And for the storage of files, especially cold files, every percent improvement imparts a cost savings.
Also, widespread in-browser support of Brotli makes it possible for us to serve the dropbox files directly to browsers in the future (especially since they are concatenatable). Zstd browser support isn't at the same level today.
> the main reason we settled on Brotli was the second order context modeling
This advanced feature is only relevant on reaching compression levels 10 or 11, which are extremely slow. Below that, it's barely used by the encoder, due to memory and cpu taxes.
Given your application has reached speed concerns, and ends up using brotli at compression level 1 in production, you would be surprised to notice that in this speed range, zstd compresses both faster and stronger, by a quite substantial margin.
For long term storage of blocks, we compress at much higher compression levels like you mention. These densely compressed blocks are, in turn, served directly to customers when they download their own files.
For uploads you're right: we'd be theoretically better off with high performing zstd, but there are maintenance costs with maintaining 2 separate compression pipelines that are similar, but different, for upload and downloads.
Plus there is no safe rust zstd compressor and the safe rust zstd decompressor linked in this thread is only recently available and is also several times slower than the safe rust brotli decompressor.
Great question! We developed and deployed Lepton to losslessly encode JPEG image files. Lepton continues to deliver substantial storage and cost savings every year. You can read more about it here https://dropbox.tech/infrastructure/lepton-image-compression...
Savory with a touch of sweetness, Broccoli Bread cooks up like cornbread but offers fiber and calcium. The original name was Brot-cat-li (since files could be concatenated and compressed in parallel), but when we said it fast it sounded like "Broccoli" and the name stuck.
And yes, much of the overhead stems from the RPC server that needs to be implemented. For lepton we used a raw TCP server (a simple fork/exec server) to answer compression requests. For Lepton we would establish a connection and send a raw file on the socket and await the compressed file on the same socket. A strict SECCOMP filter was used for lepton. It was nice to avoid this for broccoli since it was implemented in the safe subset of rust.
Does this pave the way for a “lite” version of the Dropbox client that _only_ syncs files and has none of the “added value” bloat that has crept in of late?
When are you going to offer a cheaper plan with less storage for people that only need <50GB?
I lucked out and have 2 free plans that have bonus storage from various promotions. I get about 25 GB per account. I haven't maxed either one.
I absolutely love the product. My wife scans a file, I can grab it right away. I'm at work and need some document (e.g., my driver's license photo), I hop on the website and download it.
I pay $5 for backblaze to backup 5TB. I don't want to spend $10 a month for storage I'll never use (I couldn't even keep that much synced on most of my devices) but I'd gladly pay $3-5 a month for 50-100GB.
With Dropbox Family, each member of the plan has their own Dropbox account. A single person, the Family manager, will manage the billing and memberships for the entire Family plan.
Out of curiosity, how much does bandwidth usage contribute to your overall operational efficiency (as compared to for example the cost of running the actual servers)? Would totally understand if you can't answer this :)
Alexey from Traffic Team is here. Traffic is definitely a non-negligible part of the budget. We try to reduce it as much as possible for both lower operational expenses and better user experience. Main drivers for that improvement (besides owning our own Edge infrastructure) on the client side are:
1) Brotli (Broccoli) compression.
2) Differential updates through librsync.
3) "LANSync" a P2P sync within a broadcast domain (secured through server issued short lived TLS certs.)
That said, Desktop Client is only 1/3 of the overall Dropbox traffic -- the rest 2/3 are split between Web and API.
Does this ratio include the Dropbox official mobile apps?
Have LANsync peers been considered as a sources of blocks for mobile clients?
Like most, I’m observing (and participating in) multidimensional access to data. For not, accessing files on my local desktop is still much faster than direct downloads from the Dropbox cloud. It’s a bummer to source files that are on my LAN from the cloud. This may become more problematic as bandwidth billing models move toward pay-per-bit.
> Desktop Client is only 1/3 of the overall Dropbox traffic -- the rest 2/3 are split between Web and API
Interesting! I assume the desktop client is still dropbox's main product so that's surprising to hear. Is it because the desktop has everything cached and rarely has to download whereas web and mobile has to download a fresh copy each time they are viewed?
I can't find any information on linux support with KSP2. Does anyone have a link with more linux information? One of the many reasons I loved KSP was robust linux support.
KSP is the only case I've seen where people actually learned to use Linux just so that they could play the game - KSP actually worked better on Linux, because for a long time Windows didn't have a 64bit build, and 32bit build run out of RAM very quickly once you started modding the game.
(And mods for KSP are a thing to behold; they turn a somewhat curious game into a masterpiece and deepest treatment of space exploration in videogames to date.)
or written in a secure language without undefined behavior and without any "unsafe" code
like Rust or Safe Haskell.
IoT probably should be shipping code that uses static compiler checks as the first line of security defense rather than run-time checks like valgrind and asan.
