[HN Gopher] Fyrox 0.25 Feature Highlights
___________________________________________________________________
Fyrox 0.25 Feature Highlights
Author : gigagoogoo
Score : 60 points
Date : 2022-05-15 10:57 UTC (12 hours ago)
(HTM) web link (fyrox.rs)
(TXT) w3m dump (fyrox.rs)
| cf100clunk wrote:
| Two concerns about the name Fyrox:
|
| 1) slight name collision with Firefox when spoken, or...
|
| 2) Viking afficionados can correct me on this, but AFAIK "Fyr"
| would be pronounced "Fear"
| WalterGR wrote:
| Is the editor an existing project or based on an existing
| project, or is it brand new for the engine?
| Hemospectrum wrote:
| The editor has been developed alongside the engine, and has
| been one of its distinguishing features, for quite some time.
| What they added here was the ability to run the game inside the
| editor, instead of having to switch between them.
| mrDIMAS wrote:
| The editor is built specifically for the engine, it is a bit
| younger than the engine - the engine is 3+ years old and the
| editor is 2 yo. Asking a potential question - the editor is
| built using fyrox-ui library which is made from scratch too.
| WalterGR wrote:
| Very cool. It looks impressive.
| inshadows wrote:
| Sorry for stupid question, but how does it actually draw
| stuff onto screen? I see lots of GUI abstractions in fyrox-
| ui/src/lib.rs but I can't find where it actually interacts
| with the underlying OS. I'm very curious about how GUIs work
| in general but I am layman. I assume that you have to go
| through some API to push your graphic buffers onto screen. So
| something like SDL, OpenGL, or something native to
| Linux/Windows (Direct Rendering Manager?). Thanks in advance!
| erlend_sh wrote:
| > Before 0.25 the engine was mainly used as framework backed by
| the scene editor. Now the situation has changed, now it is
| possible to run your game in the editor, like in many other
| mainstream engine such as Unreal Engine, Unity, Godot, etc.
|
| That's a major usability improvement. It's truly a 'Godot lite'
| engine now, which is a noteworthy milestone for the Rust gamedev
| ecosystem!
| incrudible wrote:
| _" You probably already asking: why not just use DLL hot-
| reloading? The answer is very simple: Rust does not guarantee ABI
| stability across projects. What does that mean for a typical
| engine user? Well, in short: subtle bugs and crashes. There were
| a lot of experiments with hot-reloading and all of them failed."_
|
| That sucks. I'm used to C++ not caring about ABI stability, but
| Rust takes it to another level.
| mrDIMAS wrote:
| Yeah, I've spent almost a week trying to go through compiler
| issues, like mismatch TypeId for the same type across projects
| (game DLL and engine) was a main source of headache. I did some
| workarounds (use UUIDs as type ids), but that wasn't enough -
| some libraries use `Any` trait inside to do dynamic type
| casting. It is done by comparing TypeIds and simple pointer
| type cast, but TypeId does not match across projects! Even if I
| would fixed those issues, I still playing with fire -
| everything that passing DLL boundary is a source of undefined
| behavior and potential crashes. So I decided to use static
| linking instead, as the post says, it have its own pros and
| cons, but at least it is super safe.
|
| It is possible to use C ABI, via C bindings but in this case
| you losing all benefits that Rust provides.
| mrDIMAS wrote:
| Hi, engine author here, ask me anything.
|
| Join engine community in Discord -
| https://discord.com/invite/xENF5Uh
___________________________________________________________________
(page generated 2022-05-15 23:02 UTC)