<commit_before># p2d - a tile-based 2D graphics library

A simplistic library for drawing sprites to a window, built atop `rust-sdl`.

As is, <NAME> is the sole author. The code in this repository is released under the terms of the [3-Clause, "New BSD License"](https://en.wikipedia.org/wiki/BSD_licenses#3-clause_license_.28.22Revised_BSD_License.22.2C_.22New_BSD_License.22.2C_or_.22Modified_BSD_License.22.29).

## Philosophy & Goals

The Author says: I created this repo to share the (generalizable) work that I've been doing with 2D graphics in Rust. With this in mind, I want to keep it focused on the task of providing a useful, simplified & opinionated set of APIs for doing UX in the context of a 2D, tile/grid/sprite-based application.

`p2d` also provides some data-structures and API around a portal-based Field-of-View discovery and drawing scheme, based on a modified version of [Mingo's Restrictive Precise Angle Shadowcasting (MRPAS)](http://roguebasin.roguelikedevelopment.org/index.php?title=Restrictive_Precise_Angle_Shadowcasting). An early demo of this system is available in a [December 20th, 2013 video on youtube](https://www.youtube.com/watch?v=6WPm2mOZuQI).

#### Current Capability

- Load and keep a `p2dux::gfx::TextureSheet`, whose input is defined by `p2d::sprite::SpriteSheet`, in memory from a `.bmp` file on the filesystem
- A `TextureSheet` can draw a portion of itself, as defined in `p2d::sprite::SpriteSheet`, to the screen
- A `World<T>` data structure, consisting of a number of `Zone`s, `Portal`s and `Payload`s
- Some utility API around interacting with the above items for the purpose of field-of-view discovery and drawing-to-the-screen
- A rough pattern about UX/input management that also forms the basis of the main loop
- data-structures representing variable-width sprite fonts and basic API for drawing a line of text, in a given `p2d::sprite::SpriteFontSheet` at a given screen location

#### Future Work

- Further refinement of the font-drawing API (such as rendering a block of text in a word-wrapped fashion within a bounding box.. what about scrolling.. ?)
- Data structures simpler than `World<T>` for representing non-fancy tile/grid structures like UX menus, etc and API for drawing them
- Further generalization of `World<T>` to pull out everything from `Tile` except the `portal_id` and `payload_id` fields
  - Situations that call for interacting with `Tile` payloads in any way (like in `p2d::fov` or `p2dux::gfx::draw`) would take a parameterized strategy trait impl to pull out the `Payload` and make decisions based on its contents<commit_msg>work on current capabilities section in README<commit_after># p2d - a tile-based 2D graphics library

A simplistic library for drawing sprites to a window, built atop `rust-sdl`.

As is, <NAME> is the sole author. The code in this repository is released under the terms of the [3-Clause, "New BSD License"](https://en.wikipedia.org/wiki/BSD_licenses#3-clause_license_.28.22Revised_BSD_License.22.2C_.22New_BSD_License.22.2C_or_.22Modified_BSD_License.22.29).

## Philosophy & Goals

The Author says: I created this repo to share the (generalizable) work that I've been doing with 2D graphics in Rust. With this in mind, I want to keep it focused on the task of providing a useful, simplified & opinionated set of APIs for doing UX in the context of a 2D, tile/grid/sprite-based application.

`p2d` also provides some data-structures and API around a portal-based Field-of-View discovery and drawing scheme, based on a modified version of [Mingo's Restrictive Precise Angle Shadowcasting (MRPAS)](http://roguebasin.roguelikedevelopment.org/index.php?title=Restrictive_Precise_Angle_Shadowcasting). An early demo of this system is available in a [December 20th, 2013 video on youtube](https://www.youtube.com/watch?v=6WPm2mOZuQI).

#### Current Capability

- Load and keep a `p2dux::gfx::TextureSheet`, whose input is defined by `p2d::sprite::SpriteSheet`, in memory from a `.bmp` file on the filesystem
- A `TextureSheet` can draw a portion of itself, as defined in `p2d::sprite::SpriteSheet`, to the screen
- Some utility API around interacting with the above items for the purpose of field-of-view discovery and drawing-to-the-screen
- A rough pattern about UX/input management that also forms the basis of the main loop
- data-structures representing variable-width sprite fonts and basic API for drawing a line of text, in a given `p2d::sprite::SpriteFontSheet` at a given screen location
- A `World<T>` data structure, consisting of a number of `Zone`s, `Tile`s, `Portal`s and `Payload`s
    - `Zone`s are defined as being an arbitrary size (currently only one size dimension is specified). This initializes the zone as being filled with a number of `Tile`s equal to the `Zone`'s size, squared
    - `Tile`s make up the contents of a `Zone`. They current consist of information about `SpriteTiles` that should be rendered in the `Tile`'s location, as well as FOV/movement info and weak references, via id, to optional `Portal` and/or `Payload` components
    - `Portal`s connect two `Zone`s together. They consist of two `Zone` identifiers, two `coord` fields (of type `(uint, uint)`) and two `TraversalDirection` fields indicating which direction the respective `Portal`s "point in"
    - `Payload`s are the `T` in `World<T>`. Each `Tile` carries an optional weak references to a `Payload` which kept, by `Uuid` identifier, in the top-level of the world. Eventually, all of the non-`Portal`/`Payload`-related fields within the `Tile` (`fov`, `passable`, `sprites`) will move into the `Payload` and be supported in their respective APIs by demanding that any `World<T>` passed into the APIs have its `Payload` type impl some trait that enables exposing germane capabilities to those APIs

#### Future Work

- Further refinement of the font-drawing API (such as rendering a block of text in a word-wrapped fashion within a bounding box.. what about scrolling.. ?)
- Data structures simpler than `World<T>` for representing non-fancy tile/grid structures like UX menus, etc and API for drawing them
- Further generalization of `World<T>` to pull out everything from `Tile` except the `portal_id` and `payload_id` fields
  - Situations that call for interacting with `Tile` payloads in any way (like in `p2d::fov` or `p2dux::gfx::draw`) would take a parameterized strategy trait impl to pull out the `Payload` and make decisions based on its contents
{'fraction_non_alphanumeric': 0.08188854489164087, 'fraction_numerical': 0.012074303405572756, 'mean_word_length': 4.8523550724637685, 'pattern_counts': {'":': 0, '<': 13, '<?xml version=': 0, '>': 13, 'https://': 4, 'lorem ipsum': 0, 'www.': 2, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '1104435', 'n_tokens_mistral': 1902, 'n_tokens_neox': 1794, 'n_words': 867}