From fd26a712305e0e7e0383e697695e199b0ef4784b Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Andr=C3=A9=20Esser?= Date: Fri, 24 Jun 2022 18:06:34 +0100 Subject: [PATCH] fixes small typos in README.md --- README.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/README.md b/README.md index dd4ee5d..ba2ceee 100644 --- a/README.md +++ b/README.md @@ -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 @@ -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)