8000 fixes small typos in README.md by Esser50K · Pull Request #1 · TanTanDev/runity · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

fixes small typos in README.md #1

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.

Sign up for GitHub

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

Open
wants to merge 1 commit into
base: main
Choose a base branch
from
Open

fixes small typos in README.md #1

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
8 changes: 4 additions & 4 deletions README.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -42,7 +42,7 @@ demo_game was the code for the small monkey banana project I also showed in my v
##### rust/runity (dll project)
Handles all C# communication, responsible for the Bevy world. Loads and communicates with the game code 'game.dll'.
Bevy systems are setup to sync the Rust side into C#.
Because of the 'ugly' FFI nature of code I seperated the game code with the communication code
Because of the 'ugly' FFI nature of code I separated the game code with the communication code

##### rust/game or rust/demo_game (dll projects)
Example game projects, all gameplay code is written in such a project, communicates with runity.dll
Expand All @@ -55,8 +55,8 @@ demo_game was the code for the small monkey banana project I also showed in my v
Some ideas I got that needs to be improved
* Instead of holding the game.dll inside the unity project, it should be kept outside so we don't have to close Unity every recompile
* asking Unity for Input is a slow operation because the system always has to be singlethreaded. Maybe inputs should be dumped every frame into rust, allowing for multithreaded systems accessing input
* Spawning gameobjects within a hiearchy of children/parents doesn’t work. They must be sent to Unity in a correct order, which they don’t atm.
* the game.dll and runity.dll has to be compiled withing the same project (I believe). Would be nice if it could be a seperate project.
* Spawning gameobjects within a hierarchy of children/parents doesn’t work. They must be sent to Unity in a correct order, which they don’t atm.
* the game.dll and runity.dll has to be compiled withing the same project (I believe). Would be nice if it could be a separate project.
* RectTransform implementation is hardcoded in C# (don’t look very scary)
* Figure out how to actually process collsion in a neat way instead of having to access the whole bevy world in the system, causing very ugly and inefficent code.
* Figure out how to actually process collision in a neat way instead of having to access the whole bevy world in the system, causing very ugly and inefficient code.
* Hashing of component in C# currently uses a hardcoded identifier. Adding new components may cause unsound logic. (Done in case we need Rust to access Unity Component values like syncing transform before the Update, which we currently don’t do)
0