daniel_rh

I love that idea! Please let me know if it's of any help :-)

Since the Playdate doesn't have any of the sprite rendering hardware that made the gameboy both underpowered in compute and overpowered in graphics at the time, some of the tricks may be unnecessary.

I suppose you could do some kind of shift of a whole row of the framebuffer easily with a memmove sort of operation. The gameboy's shift registers and the per sprite drawing are what really made this both difficult and possible at such a slow CPU clock speed. The playdate CPU is about 40x faster than that on the gameboy, so probably all these kinds of tricks and more would work just fine.

This is so cool! I've been working on trying to minimize the F-zero render loop to fit on gameboy and multiplayer over the link cable...it's been a journey. (I rushed the writeup cus of this article--still polishing the text), but give the game a try on the in-browser emulator: https://fireflyk64.github.io/makingfsub/

Yes the old game only ran at 15-20 fps and it wasn't even synced to the clock! This endeavour also added time sync and I chose 20 fps (which makes some missions harder). Wingman shots are delayed by up to a few frames, but the system has a high latency mode that double-sends steering commands over the lossy layer. The weapon commands are at least synced with where the ships fly. I haven't tried too much in high latency scenarios (mostly LAN) so we will see how well it holds up online

Here's the source code: https://github.com/danielrh/wcmulti if you notice any issues and want to file any tickets (or want to add support for X-Wing or others)

I've been looking for a really engaging solid intro to number theory course on youtube, including rings, Abelian groups, etc for early teens.

Does anyone have a recommendation here?

Or go for one of these gamified math tutorials.

For instance: this one teaches geometric proofs without mentioning the formalism, just letting you "unlock" the tools from a few "axiom" starter tools.

https://www.euclidea.xyz/

This is similar to the solution we used in Vega Strike https://www.vega-strike.org/ detailed here https://graphics.stanford.edu/~danielh//classes/VegaStrikeBl...

This article mentions the woes of circular imports. I thought MyPy let you work around that by doing if False: around your imports

eg a.py: import c

  if False:
     import b

  class X:

   def x(self):
       #type: () -> b.Y
       from b import something_that_returns_y

       return something_that_returns_y(self)

b.py:

  from a import X

  class Y:

    pass

  def something_that_returns_y(x : X) -> Y:

    return Y()

per https://github.com/asottile/flake8-typing-imports

I think the newer version of this is https://github.com/bazelbuild/rules_rust which lets you either vendor the dependencies or pull them from your Cargo.toml directly every time.

Per the article: bazel + rules_rust should have the flexibility to override the linker flags that Cargo may take as required since that would be a property of the bazel toolchain used.

It's a nice amalgamation of how cargo works and how bazel works.

In general bazel supports hermetic builds, multiple toolchains, cross complilation, and ways to compile multi-language projects.

I still wish that Cargo.toml didn't support build.rs as it can cause a lot of system-dependent problems that bazel sidesteps entirely by being hermetic.

Does anyone have experience with eBPF on aarch64? How well is it supported? On what kernel revisions was it phased in and well tested there?

I was just experimenting with eBPF and ran into a limitation: Is there a way to load the source IP into a register when working in userspace? When I SO_ATTACH_BPF to a SOCK_DGRAM it only makes the udp header accessible, per https://github.com/danielrh/bpf_buffer_per_source/blob/main/... I would love to be able to run logic based on both IP and port rather than being limited to port alone. Yet it's not worth the inconvenience/danger of running as root to operate with RAW sockets.

Highly recommend http://privateer.sourceforge.net/ Gemini gold

Hi! Just noticed this post :-) I started the game in the late 90’s and open sourced it in 2001 The previous versions were win Mac Linux but the current dev team has been focusing on Linux right now.

At the time there were some mod communities like privateer Gemini gold with a polished release and Vega Trek; those also had windows builds that also work on wine. You might need to install into a folder with read/write permissions.

Ya we briefly corresponded in a mailing list some time back... he liked the multiplayer version, but wasn't interested in opening the source code yet. Maybe one of these years he will--I should reach out again... until them I have some pretty well annotated IDA file

Wow you played begin too! I added multiplayer through DOSbox--

it was interesting that the AI craft were just like player craft but had a different controller. It was possible to splice in keyboard input for that. Then I wrote some screen scraping software to send the commands remotely.

Here's the software project http://begin2.sourceforge.net/

Unfortunately the sourceforge matchmaking server has long gone offline, but you could connect direct to IP addresses too, so it should still be playable

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

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

There's the family plan which offers up to 6 members an account for a great monthly price.

https://help.dropbox.com/accounts-billing/plans-upgrades/dro...

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.

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.

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.

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...

if a user has uploaded a file in the past and their desktop client can prove they have access, then they can avoid uploading it again

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.

Dropbox uses a similar toolbox as https://chromium.googlesource.com/chromiumos/docs/+/master/s...

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.

Hi folks, I'm Daniel from Dropbox, and I am happy to answer any questions about this tech.

2 words: bash reduce

(eg using cut, sort, split -l, nohup, ssh to orchestrate a massive job with only bare unix tools available)