chariotengine / chariot Goto Github PK

The initial implementation could probably get away with using lazy_static! but eventually files will need to be loaded from disk.

The idea here is to present textual data to the user in their chosen language and fall back to en_US if we don't have a particular string (or entire files) for their selected locale.

Doing so was, frankly, a naive decision on my part and was partly an excuse for me to be lazy (so I didn't accidentally publish multiple crates when I only meant to publish a particular one).

I could rebase those commits away entirely (which would essentially restore their history and ownership/blame).

Currently we only read graphics, sounds, etc. from DRS archives.

Ideally we would read from the shipped containers and a known location in the source tree.

This will allow us to drop in custom resources without authoring DRSes.

My current thinking is:

• resource: *_rc
• component: *_comp
• system: *_sys
• action: *_act

Which means the following code:

        fetch_components!(arg, entities, [
            components(on_screen: OnScreenComponent),
            components(units: UnitComponent),
            mut components(decals: DecalComponent),
            mut components(selected_units: SelectedUnitComponent),
            mut components(transforms: TransformComponent),
            resource(keyboard_state: KeyboardKeyStates),
            resource(mouse_state: MouseState),
            resource(path_finder: PathFinder),
            resource(players: Players),
            resource(view_projector: ViewProjector),
            resource(viewport: Viewport),
            resource(occupied_tiles: OccupiedTiles),
            resource(terrain: Terrain),
            mut resource(action_batcher: ActionBatcher),
        ]);

Would be changed to:

        fetch_components!(arg, entities, [
            components(on_screen_comp: OnScreenComponent),
            components(units_comp: UnitComponent),
            mut components(decals_comp: DecalComponent),
            mut components(selected_units_comp: SelectedUnitComponent),
            mut components(transforms_comp: TransformComponent),
            resource(keyboard_state_rc: KeyboardKeyStates),
            resource(mouse_state_rc: MouseState),
            resource(path_finder_rc: PathFinder),
            resource(players_rc: Players),
            resource(view_projector_rc: ViewProjector),
            resource(viewport_rc: Viewport),
            resource(occupied_tiles_rc: OccupiedTiles),
            resource(terrain_rc: Terrain),
            mut resource(action_batcher_rc: ActionBatcher),
        ]);

Of course these suffixes (could be prefixes but in general I don't find that helpful, could be convinced otherwise) could be made more brief:

• resource: *_r
• component: *_c
• system: *_s
• action: *_a

Original issue link

Now that the game is rendering delta graphics (see angered-ghandi/OpenAOE#37), there are hundreds of TODO comments being printed out when the game starts up:

...
TODO: skipped 15 instead of drawing the shadow
TODO: skipped 20 instead of drawing the shadow
TODO: skipped 13 instead of drawing the shadow
TODO: skipped 13 instead of drawing the shadow
TODO: skipped 7 instead of drawing the shadow
...

I made it draw yellow instead of skipping, and it looks like several of the delta graphics are nothing but shadows:

Unfortunately, with the way the SLP crate is currently laid out, it's not going to be easy to correctly implement the actual shadows. In the original game, it'd use the index of the color in the destination pixel buffer to determine the shadow color to draw. We'll need to do something clever here since that's not feasible with OpenGL (at least not with good performance). Might be able to make it look as close to the original as possible using a pixel shader, but being able to use a shader will require a rewrite of the whole render system.

This will require fixing crates/types/src/vector3.rs:

    #[test]
    fn test_typical_normalize_use_case() {
        let position: Vector3 = Vector3::new(100.into(), 100.into(), 1.into());
        let velocity: Vector3 = Vector3::new(1.into(), 2.into(), 0.5.into());
        let time: Fixed = 0.0166666667.into();

        let new_position = position + velocity * time;
        let delta = new_position - position;
        let direction = delta.normalized();
        let direction_length = direction.length();

        assert_eq!("(100.0166667, 100.0333333, 1.0083333)".to_string(),
                   format!("{}", new_position));
        assert_eq!("(0.0166667, 0.0333333, 0.0083333)".to_string(),
                   format!("{}", delta));
        assert_eq!("(0.4364425, 0.8728850, 0.2182212)".to_string(),
                   format!("{}", direction));
        assert_eq!(1, direction_length.to_i32().unwrap());
    }

  --> src/vector3.rs:78:34
   |
78 |                    format!("{}", new_position));
   |                                  ^^^^^^^^^^^^ the trait `alga::general::real::Real` is not implemented for `fixed::Fixed`
   |
   = note: required because of the requirements on the impl of `std::fmt::Display` for `nalgebra::Matrix<fixed::Fixed, nalgebra::U3, nalgebra::U1, nalgebra::MatrixArray<fixed::Fixed, nalgebra::U3, nalgebr
a::U1>>`
   = note: required by `std::fmt::Display::fmt`

error[E0277]: the trait bound `fixed::Fixed: alga::general::real::Real` is not satisfied
  --> src/vector3.rs:80:34
   |
80 |                    format!("{}", delta));
   |                                  ^^^^^ the trait `alga::general::real::Real` is not implemented for `fixed::Fixed`
   |
   = note: required because of the requirements on the impl of `std::fmt::Display` for `nalgebra::Matrix<fixed::Fixed, nalgebra::U3, nalgebra::U1, nalgebra::MatrixArray<fixed::Fixed, nalgebra::U3, nalgebr
a::U1>>`
   = note: required by `std::fmt::Display::fmt`

error[E0277]: the trait bound `fixed::Fixed: alga::general::real::Real` is not satisfied
  --> src/vector3.rs:82:34
   |
82 |                    format!("{}", direction));
   |                                  ^^^^^^^^^ the trait `alga::general::real::Real` is not implemented for `fixed::Fixed`
   |
   = note: required because of the requirements on the impl of `std::fmt::Display` for `nalgebra::Matrix<fixed::Fixed, nalgebra::U3, nalgebra::U1, nalgebra::MatrixArray<fixed::Fixed, nalgebra::U3, nalgebr
a::U1>>`
   = note: required by `std::fmt::Display::fmt`

The resulting JSON can easily be manipulated and searched via jq.

The current unit_selection_system implementation iterates over all the units on the screen to find a targetable unit, and that is expensive.

This can be improved if we can get the current graphic under the cursor then find the associated entity.

For example instead of this code:

use ecs::resource::*;

We want the following:

use ecs::resource::{
    MouseState,
    KeyboardKeyStates,
    PathFinder,
    Players,
    ViewProjector,
    Viewport,
    OccupiedTiles,
    Terrain,
    ActionBatcher,
};

Scenario MUF7E5_1 requests 517.slp (just a bit to the right of the the bottom edge of the map) which doesn't exist in the shipped GRAPHICS.DRS.

This is a workaround until we learn how the Genie engine dealt with missing resources or find a better way to do it ourselves.

Perhaps the scenarios shipped on-disc weren't meant to be played in the retail product so this is just bogus data that was valid at one point in development.

Currently multiple entities can occupy the exact same position. This is not desired.

Resources:

• https://answers.unity.com/questions/790857/unit-local-avoidance-in-rts-type-games.html
• http://grail.cs.washington.edu/projects/crowd-flows/continuum-crowds.pdf
• https://gamedevelopment.tutsplus.com/tutorials/understanding-steering-behaviors-flee-and-arrival--gamedev-1303
• http://orhanbalci.github.io/rust-steering-behaviors/steering/index.html

Noticed this in /r/programming and thought it would be useful:
https://richg42.blogspot.fi/2018/02/some-lessons-learned-while-developing.html

This is going to require some refactoring.
The fetch_components! macro may be rendered unnecessary.

Notes:

• RunArg was replaced with SystemData (which can be an N-tuple of types that implement SystemData)
• update was replaced with run which takes Self::SystemData
• System now has a lifetime
• Iterating over required systems is now done via .join()
• Planner is now Dispatcher (created via DispatcherBuilder)

"Diagonal" in this context means from the perspective of the viewer looking at the 2d window (not in relation to the grid coordinate system).

Determining cell neighbors does include diagonal pieces.

A test that includes only diagonal possibilities passes:

    #[test]
    fn test_find_tile_path_diagonal_only() {
        let width = 3;
        let map = vec![
            1, 0, 0,
            0, 1, 0,
            0, 0, 1,
        ];

        let (terrain, path_finder) = make_terrain_and_path_finder(map, width);
        let occupied_tiles = OccupiedTiles::new();

        let test = &mut |from, to, exp| {
            let path = path_finder.find_tile_path(&terrain,
                                                  &occupied_tiles,
                                                  from,
                                                  to,
                                                  UnitTerrainRestrictionId::Flying);
            assert_eq!(exp, path);
        };

        test((0, 0), (2, 2), vec![(0, 0), (1, 1), (2, 2)]);
    }

@angered-ghandi do you have any insight as to why this may be the case?

Original issue here

We will probably want to use rusttype to avoid a native sdl2_ttf dependency.

https://docs.travis-ci.com/user/customizing-the-build/#Safelisting-or-blocklisting-branches