bve-reborn / ktx2 Goto Github PK

ktx2 parsing library

License: Apache License 2.0

Rust 100.00%

ktx2's Introduction

BVE-Reborn

BVE-Reborn is a remake of the train simulator OpenBVE that focuses on visual quality and performance, as well as code quality and flexibility.

While progress is strong, there is still a lot of work to do in order to get a working demo.

BVE uses Rust for all code, which allows the code to be robust and safe from crashes while being just as fast as C/C++.

Building from Source

Binaries will be provided when there is a release, but for now, only developers can make use of BVE-Reborn. If you are a developer the following is how you build from source.

Rust toolchain

You need to install the 2020-06-22 nightly toolchain of rust:

rustup install nightly-2020-06-22

Then you may run the main build process:

cargo build  # Debug Build
cargo build --release  # Release build

Running it requires data files, so contact me directly on the discord if you want to try building it.

ktx2's People

Contributors

Stargazers

Watchers

Forkers

ralith superdump expenses lpghatguy james7132

ktx2's Issues

Build error with no_std

cargo build --no-default-features results in a build error:

error[E0433]: failed to resolve: use of undeclared crate or module `std`
   --> src\lib.rs:254:34
    |
254 |             let key = match std::str::from_utf8(key) {
    |                                  ^^^ not found in `std`
    |
help: consider importing this builtin type
    |
32  | use core::primitive::str;
    |
help: if you import `str`, refer to it directly
    |
254 -             let key = match std::str::from_utf8(key) {
254 +             let key = match str::from_utf8(key) {

A workflow should be added to test no-std to catch regressions like this in the future.

Align DFD type names with spec

Currently, some of the types related to Data Format Descriptors (DFDs) don't quite align with the KTX and KDF specifications. I propose that a couple types are renamed:

Reader::data_format_descriptors -> Reader::data_format_descriptor_blocks OR Reader::dfd_blocks
DataFormatDescriptor -> DataFormatDescriptorBlock OR DfdBlock
DataFormatDescriptorHeader -> DataFormatDescriptorHeaderBlock OR DfdBlockHeader

A KTX2 two file has one data format descriptor, containing multiple data format descriptor blocks.

The full name "data format descriptor block" is very long, so it might be preferable to use DFD, an abbreviation used frequently in the spec. These types can be affixed with references to the KTX spec or the Khronos Data Format spec, which has detail that I think is very useful.

BasicDataFormatDescriptorHeader -> BasicDataFormatDescriptorBlockHeader OR BasicDfdBlockHeader OR DfdBlockHeaderBasic

Thought process is similar here to the other types. It might be more clear to use the name DfdBlockHeaderBasic because this type is the header for some data contained within a DFD block.

Any other types that reference DFDs (plural) would be changed to reference DFD blocks.

link to the spec is broken

the start of the crate docs link to the ktx2 spec but khronos seems to have moved the file because it's a 404

Dual license?

Currently, the crate is licensed solely under Apache 2.0. Would it be desirable to relicense to dual license with MIT?

Higher-Level Encode API

Description

Building on top of #14, it would be useful to expose a higher-level API for encoding KTX2 images. I think that it should be possible to create an unopionated, simple API to help calculate byte offsets and padding.

Proposed Solution

I am working on an API as part of a separate crate in tandem with PRs like #14 that I'll propose more concretely once it's more functional.

Alternatives

It's important for ecosystem adoption of ktx2 to make pure Rust KTX2 image encoding straightforward. I think that it belongs in this crate, as the existing API leaves the user to do a lot of heavy lifting still.