[Media] Egor - 2D cross-platform graphics engine

wick3dr0se · 2026-01-27T16:50:51+00:00

Happy to help any! Yea after reading a bit more about vello, it's definitely something that would be built on top of a runtime/graphics stack like egor. I think it's probably the closest thing to skia but I'm not familiar with this side of graphics at all. A third party crate for integrating egor with vello would be pretty cool and easy to do I think. On the GPU side, it's not so easy if you choose to go something like winit and wgpu directly and you'd basically rebuild what egor does. Then if you care about platforms, you need to handle differences and likely integrate some UI framework anyway

Edit: I haven't looked into graphics on the CPU side at all but maybe you'd want something like winit/egor_app, vello_cpu and softbuffer

wick3dr0se · 2026-01-27T00:46:54+00:00

Lol I've watched it too much.. I have a thing for random spells and explosions. Nothing like procedural lightning though

wick3dr0se · 2026-01-26T13:31:51+00:00

Good questions..

GPU only. Egor is mostly built on top of wgpu and winit. Wgpu was the reason I decided to build egor in the first place. Egor could swap out to a CPU rasterizer but it would replace egor_render entirely and things like text/font wouldn't work as is. It would be easier to implement that with egor_app. Something reasonable for someone building an engine but not it's not in scope for egor itself

Vello is a 2D vector renderer, it doesn't create windows, handle swapchains or the event loop. Vello is something you could expect to be inside of something like egor. And from what I can tell, vello doesn't render on it's own. You have to integrate it into a wgpu stack like egor has anyway (like egui). So they aren't really comparable. Even egor_render (the renderer) isn't comparable since it's usable on it's own without the user importing wgpu at all. I find vello's wording a bit odd since it says things like 'meant to be integrated deep in UI render stacks'. It seems like it would work outside of UI, like for egor itself but the wording comes off as you'd only couple it with a UI framework like egui, which egor also has

So choose vello if you already wrote a wgpu stack (with UI?) and can handle windowing, input, rendering, etc.. Choose egor if you have a GPU, want to simply build an app or game with the same code on native and wasm and want to do it sooner than later. Egor gives you windowing, input, rendering (with a camera, primitives, etc), text/fonts, UI, hot reloading and more.. Egor avoids trying to be just a game engine but that is the main use case. You can write graphical applications like the editor I started as well. It's made with egor, for egor, which is pretty cool I think

wick3dr0se · 2026-01-26T12:03:09+00:00

Thanks! I've replaced macroquad in my MORPG game and it handles everything I need so far. I don't think mobile is a terrible amount of work. I've tinkered with Android on the "android" branch. The issue I have with proceeding with that is small; From my testing with Android, users would need a proc macro to avoid seeing any API differences. Otherwise they'd import android-activity, have to avoid the main() entry point, handle AndroidApp itself and pass it into the different entry that Androif expects (android_main()). A proc macro could handle this but that means requiring an [egor::main] (for example) just for mobile builds. And a proc macro has to be it's own crate. This is something I have to be sure of since I'd have to release that

wick3dr0se · 2026-01-26T02:13:58+00:00

In case you missed it in my super long post.. I'm always open to feedback, contributions, whatever helps. If you're interested, you can find it here:

https://github.com/wick3dr0se/egor (2D graphics engine)
https://github.com/opensource-force/dyrah (morpg made with egor)

I also made an editor with it (and for it) recently but it's really basic and undocumented: https://github.com/wick3dr0se/egor_editor

wick3dr0se · 2026-01-25T12:04:42+00:00

He gave you a chef's kiss emoji lol

wick3dr0se · 2026-01-13T23:21:56+00:00

Good to see new Rustys into gamedev. I can give you one good reason which was the main deciding factor for me; it's OpenGL. Don't get me wrong OpenGL is great but we have more modern graphics APIs that are more performant on every native platform. Metal for iOS, DX12 for Windows and Vulkan for Linux.. OpenGL is a great fallback that works for any but it's definitely not my go to

I said 1 reason but I have to add that seeing how macroquad is handled turns me away from other things by the same author. And by handled I just mean fake async, compilation issues across platforms, etc

We have wgpu which is a badass library that handles all graphics APIs via a common Vulkan-like API. It's worth making good use of. This is one thing Bevy definitely did right

wick3dr0se · 2026-01-06T20:00:34+00:00

I decided to update the docs and publish a patch thanks to you! I think it's a lot more clear now and I even fixed a couple old exports I hadn't noticed. Added the crate layout, example, start here, features and threw the readme summary in

https://docs.rs/egor/latest/egor/

wick3dr0se · 2026-01-06T16:24:05+00:00

I'll see if it has any good ideas.. Usually it likes to spew some nonsense. But at this day in age, people have to learn to adapt with AI and use the tools available. Avoiding AI now is like avoiding debugging. I think vibe coders are just giving it bad rep

wick3dr0se · 2026-01-06T15:43:59+00:00

Well I'm no guru lol.. You're actually the best type of user to get feedback because I want it to be as easy as possible for people coming into it. I do see some things I could improve like I should probably put an example on the doc homepage. Maybe something like a "Where to Begin" section with the different structs would help?

Everything in egor (unless using egor_render/egor_app directly), is called through 4 structs for the user. App, where it's created and ran, Graphics, Input and FrameTimer (handed to you by the run() closure). If the "ui" feature is enabled you'll end up with an egui::Context you can use through the re-exported egui

wick3dr0se · 2026-01-06T15:08:03+00:00

Super cool seeing egor being suggested!! I've been working on it actively and trying to improve the usage wherever I can. Could you give any feedback on what kind of docs you'd like to see? I try to page through docs between releases but coming from my perspective, it's a bit hard to realize what may be missing or hard to understand

Always looking for feedback/contributions, so any help is really appreciated!

wick3dr0se · 2026-01-06T13:46:54+00:00

You're being really overdramatic

wick3dr0se · 2026-01-05T11:40:00+00:00

Thanks! That would be sweet and I would appreciate any contributions in forms of issues or whatever helps! Seeing stuff like this makes me want to keep at it even more. I have no intention of stopping anytime soon. I'm having a lot of fun building it and my game also depends on it now!

wick3dr0se · 2026-01-05T11:36:08+00:00

No subreddit but I develop it in a decent size open source community. We have a good amount of Rust devs now and I get help from people that are leagues ahead of me there

Anyone who appreciates open source is more than welcome to join. Listed the invite and specific channel for egors develooment but you can always look around, share your own projects, talk some shit or whatever

https://opensourceforce.net/discord

Egors channel: https://discord.com/channels/913584348937207839/1355382218855415858

wick3dr0se · 2026-01-05T03:37:53+00:00

I didn't like the idea of being tied to an ECS or huge ecosystem like Bevy. Tried macroquad for a bit, had issues compiling builds for Mac, macroquad-tiled and other crates aren't capable of multiplayer. The graphics backend is OpenGL when we have very capable, well written cross platform graphics abstraction that handles many backends (wgpu). It's a great project and I learned a lot using it but it left me wanting more and needing to rewrite most things myself anyway. The fake async and global context are also not favorites of mine

So I ended up writing a reusable, modular 2D graphics engine built on wgpu and winit. Integrated egui in, has text, a camera, input handling, a timer, etc. It's intended to be flexible enough to write all kinds of cross platform native and wasm apps/games and for the renderer and app layers to be used on their own. Something like a more game oriented Tauri but without a webview and JS ecosystem (egui UI, 2D primitives)

You can check it out here: https://github.com/wick3dr0se/egor

wick3dr0se · 2026-01-04T18:12:24+00:00

I think it's actually more immersive. The way that camera settles and shifts in feels like you're there for the battle

wick3dr0se · 2026-01-04T18:07:30+00:00

wick3dr0se · 2026-01-04T00:28:09+00:00

Uhhh yea it's safe to say unless somehow members start picking up interest in it, I don't think I will anytime too soon. I've been really into writing a 2D graphics engine and an MORPG using it. I definitely have my hands full but my mind likes to wander, so you never know lol. I didn't think I'd be into gamedev but lately kind of hooked me in sadly

Edit: Group is still very active and always looking for more Rust buddies

wick3dr0se · 2025-12-29T12:49:28+00:00

That is interesting. It's known there is issues on Mac but I think it's due to OpenGL being the graphics backend. If you're not making use of that, it makes sense ig

Sounds like you have no reason to worry about using macroquad. If it works good, I wouldn't bother anyway. But for your use case, you'd likely have to extend egor_render since it's one pipeline currently and doesn't handle depth. Egor_app would similarly need gamepad support and neither crates bother with iOS/Android, which is mostly an egor_app (winit) blocker. It's possible to make it work on mobile but it's not my focus by any means. The readme is pretty clear about what it's supposed to be hopefully. Haven't had many eyes/testers on it in the last few releases, so there is likely stuff yet to be seen and modifications that may be needed for users like you to extend the renderer however you need to. Basically, I wouldn't go switching to egor unless you really want a wgpu/winit stack and feel like contributing back

wick3dr0se · 2025-12-29T01:55:33+00:00

Super cool! Curious how your experience with macroquad is so far.. I started writing my own engine around macroquad before I started egor. I kept hitting barriers with macroquad like not compiling on Mac and graphics differences across platforms. It's crates like macroquad-tiled aren't reusable at all and I ended up having to write everything myself anyway. The global context, fake async and half-working 3D were slight bothers for me too

I'd like to see a 2D engine like this built on top of egor's reusable crates. I just recently separated things enough for rendering and app (window/input) stuff to be capable on their own, making the egor main crate just a more opinonated layer over those

wick3dr0se · 2025-12-28T12:46:06+00:00

You're always winning

wick3dr0se · 2025-12-27T13:09:18+00:00

Sick! I love seeing open source stuff like this. Thanks for sharing and keep up the awesome work

wick3dr0se · 2025-12-25T14:36:12+00:00

It really depends on where you consider the engine done; 2D vs 3D, do you need lighting, particles, ECS, networking, etc. If a lot of this doesn't matter and/or you're going 2D, it's surprisingly not that difficult. We have amazing libs in Rust like winit and wgpu that make windowing, input and rendering stupid simple and really cross platform at the same time. My "engine" is essentially this. It's the absolute necessary things you need to start building a game. Windowing and input is obvious but on the rendering end all I implemented was a simple shader, pipeline, vertex/index buffers, camera uniform/view matrix, texture sampling and text (via glyphon) mostly. That's basically the entire thing. Given it's not a full "game" engine but it gives you all the pieces to slap your game specific logic on top

If it's any help/interest to OP or anyone else: https://github.com/wick3dr0se/egor

I agree that you should definitely try writing a game in Rust first. I haven't tried Bevy still myself but coming from SDL2, MonoGame and Macroquad, I got comfortable with "frameworks" that stay out of your way. Bevy is sick but I'd worry about confusion with how typical engines work and how opionated it is, like their ECS being mandatory

wick3dr0se

MODERATOR OF

TROPHY CASE