Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Not an issue] Works on Raspberry pi #83

Open
TheMaverickProgrammer opened this issue Aug 24, 2020 · 2 comments
Open

[Not an issue] Works on Raspberry pi #83

TheMaverickProgrammer opened this issue Aug 24, 2020 · 2 comments

Comments

@TheMaverickProgrammer
Copy link

Installing linux libs allowed me to run the engine from raspberry pi and all example projects. I also cloned WhinPooh42's top-down game and after removing -mwindows from the cmake files (and the git submodule Engine's cmake files), I was able to play it as well.

You should add this to your x-platform list. Good little library!

@WinPooh32
Copy link
Contributor

Thank you for review! Good to hear that it works on rpi.

Also it can be compiled to wasm/js using Emscripten compiler, but some CMakeLists modifications are required. Tested this with top-down game about 2 years ago :)

@TheMaverickProgrammer
Copy link
Author

TheMaverickProgrammer commented Aug 24, 2020

Quick question. I originally intended to fork your engine and expand on it. Your coding style and design decisions for the engine are almost identical to how I make design choices. However there are some items I would separate responsibilities from. For instance, I wouldn't make drawables responsible for their own Draw() calls, but rather accept a target render buffer to draw onto.

If I make these changes I can port my activity and screen-transition library to this engine:
https://github.com/TheMaverickProgrammer/Swoosh

This design lets anything draw onto anything. As opposed to having some drawable limited to the first render buffer it was set to. Futhermore I'd separate features like being able to detect if mouse is over to some sort of interface class that provides those abilities. Etc.

Still, it's very close to my engine written in SFML (and uses my screen transition library):
https://github.com/TheMaverickProgrammer/OpenNetBattle/tree/development

I aim to port it because SFML lacks support for embedded devices and I had to fork it to enable GL ES 2 support on mobile devices. This engine looks promising because it's already running on pi, SDL2 can run on embedded devices, and it's close to how I would have written it.

This is a long winded way to ask, if there's room for restructuring and collaborating on making this engine beefier if I lead the way? I'd like to fork it, restructure it a little, and then start migrating features from my SFML engine (and SFML itself like ease-of-use utils), and shove it into this one to make it more powerful.

Let me know if you're interested. If not, I'll fork it and re-purpose it for my own uses. And I think collabing would be more fun.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants