Bevy

Google says you have a Core i7-620M,

No, I have an I5, it even has a sticker, but my I5-7500 desktop has an I7 sticker, so stickers aren't reliable. (I have better evidence than the sticker, trust me)

that’s a Westmere, first-generation Intel HD Graphics, provided everything is configured correctly you should have OpenGL 2.1.

I rechecked 1-2 days after making the post, and Mesa reported 2.1 & 2.0 ES, which is consistent with techpowerup, that website never failed me even when I failed myself.

…and, no, you probably really, really don’t want to use OpenGL 1.x. If your implementation supports shaders at all then it’s going to be some vendor-specific non-standard thing. If you want to do anything 3D then 2.0 or 2.1 is the bare reasonable minimum (2.1 gets you PBOs).

I think shaders are a 3D-only thing? which shouldn't be useful for an isometric game. My favorite game runs on DirectX 3.0a, so I 1.x should work, I guess?

Also I will look up PBOs, that acronym looks cool!

If you’re doing 2D well I don’t think it would be wrong for bevy to have a 2.5D engine that...tightly-timed assembly at that, once upon a time it was considered impossible to get smooth side-scrolling on VGA cards – until Carmack came along...

about 1-1.5 weeks ago I watched some Johnathan Blow hating on programming paradigms and game engines, and to be honest, I had already been viewing pre-built engines as things that produce games that are... familiar... they lack souls, integer/buffer_overflows, and their physics are too well-made. I understand the benefits of a prebuilt 3D engine; I played a 3D game on DOSBox and saved before every jump - except the ones that got me stuck in a wall, in addition to an indie 3D C++ mess on Itch (it's the only game I am excited for its release at the moment, as it's still in beta).

I also saw an attempt at using SDL as a Bevy renderer-backend on Github, and there were problems according to the README.md, but I had lost interest by then, because...

After watching much JBlow, I came away with 3 things:

1- OpenGL isn't worth learning anymore, but don't use SDL to abstract yourself from it, use raylib. That's his opinion, so I decided to build my engine on Macroquad, a raylib-like thing, as using rust-bindgen feels un-ergonomic.

2- ECSes and other pre-forced paradigms are meaningless, just write the game.

3- He doesn't like Rust, which I ignored.

You might think Rust is a bad choice if I like overflowing things, as Rust is safe, but before you is something I wrote semi-seriously (I say "semi-" so I don't get laughed at) a day or two ago:

let mut key = Key::new(500.0, 500.0, 50.0, PINK, unsafe {
        let x = &entities[9] as *const Box<dyn Entity> as *mut Box<dyn Entity>;
        // SAFETY: This is straight up undefined behaviour, I have a solution
        // that is better, simpler and safe, which is seperating the entity list
        // and `GameContext`, but I wanted this to exist in the git history.
        //
        // And before I sleep and forget, the way is passing `&mut door` to
        // `update()` manually, and passing `entities` to `walk`.
        //
        // A `RefCell` wouldn't have complained at runtime anyway.
        #[allow(invalid_reference_casting)]
        &mut *x
    });

As you can see, using anything remotely similar to Arc<Mutex<T>> would get me accused of having skill issues, which is extremely bad considering I am one of those 'I use NeoVim/Colmack-DH/Rust/Linux BTW' people, so I prefer extreme measures, AKA just regular-C-code style of writing, so it won't be long before I meet some REAL undefined behavior.

If you're interested in my little project, it's about a yellow square in rooms of yellow walls, which I planned to write in 3 days, which I finished today, a few hours after Fajr prayer, one week after I set the deadline to 3 days.

Time to add a 3D turn-based combat system to it for reason, I first need a flat yellow cube, and some doom-like fake-3D enemies.

In case you’re into the arcane craft of the elders, here’s a book.

Thanks, I wish to write assembly sometime down the road, and discover these treasures of knowledge.

Edit: in case you're wondering how I solved the code problem, I started thinking and realized that I wanted to pass a &mut T to Key.Update(), but I was also holding a &T inside of GameContext, which is impossible in safe Rust, so I changed it hold a &mut T instead.

They say: "Make it work, then make it right, then make it fast", but maybe they didn't mean jumping to unsafe when they said "work".

Edit2: I forgot to say something about prebuilt engines. In addition to creating an inconsistency between quality of the engine (physics and UI interactions), and the quality of the game-specific code, they are also very bloated and that's reflected in binary sizes and the performance penalty of being a general-purpose engine.

Macroquad is also an offender of this, as a mere cargo add bloats the release binary up to 70 whole Mibs, but I managed to shave off 10 Mibs in a few hours by cloning the repo and "forking" Macroquad and it's huge math library, grim, and "de-bloating" them, and my game would still compile fine, so there's much room for optimizing the binary size, as well as performance, since I am low-level enough to implement my own delta time.

Also I am crazy about performance, which can be traced back to trying to run games on an HP compaq DC 5800 for 4 painful years, whose GPU is even worse than the laptop's.

PBO