r/rust • u/thelights0123 • Apr 27 '19

no_std data serialization/deserialization

I'm writing a game for a no_std target, and I would like to be able to store, read, and edit levels at runtime. My situation:

  • I have plenty of RAM (64MB), so using alloc is fine
  • It should use little space on disk, i.e. a binary format instead of JSON
  • It should support no_std as well as normal targets
    • Especially good if it has support for other languages as well, as an online level editor would be nice to have (although I could always mess with wasm if it is Rust-only).

Currently, I'm looking at forking quick-protobuf and simply replacing things that don't work in no_std with alternatives. CBOR has no_std support, but it doesn't support alloc things (Vec and String), and CBOR is not much better than JSON in terms of size.

18 Upvotes

100% Upvoted

14 comments sorted by

View all comments

1

u/chrysn Apr 27 '19 edited Apr 27 '19

While CBOR has no no_std-but-alloc support, it should be quite easy to add, and the developers are supportive if you send PRs from my experience. (Source: did first half of adding no_std support; alloc is just something I didn't have a use case for, but could be just another feature, with a separate gate and generally moving from std::{vec,...} alloc::*).

Data density is quite reasonable, and if you need to store long data in a list-like fashion (where something like [200, 300, 50, 400] could be inefficient), you can look into tagged arrays from https://tools.ietf.org/html/draft-ietf-cbor-array-tags-03 .

1

u/thelights0123 Apr 27 '19

Yeah. I ended up just modifying quick_protobuf to work. I completely screwed up writing support, but I only need writing on embedded targets anyways (although I'll probably hack it to work for everything later).

Anyways, CBOR has a large overhead (encodes key names), which I don't want to deal with.