3 ms·

God I would love for Unity to offer a Swift (no GC, fully type safe, compiled, fast) API with a rethought API surface. And have only one renderer to choose from

by wilg 4y ago

God I would love for Unity to offer a Swift (no GC, fully type safe, compiled, fast) API with a rethought API surface. And have only one renderer to choose from instead of 3 with all different features.

andrewf 4y ago
And have only one renderer to choose from instead of 3 with all different features. So you want a fourth renderer? :)
Pulcinella 4y ago
I’m not sure how much of a performance hit ARC traffic would be. Though I think at least some of Unity’s DOTS systems really on structs instead of reference counted objects so it shouldn’t be a problem there.
- wilg 4y ago
  Swift structs should work for that too. But also DOTS is like years away from being ready it seems like. Basically hacked into the engine and language and kinda over complicated and confusing at the moment.
- Arcanum-XIII 4y ago
  Not ARC per se but the message dispatch mechanism was the biggest hurdle to high performance Objective C. The solution was easy : drop to C. Not really the best options for ease of approach :)
oaiey 4y ago
C# on Unity is very different then what you expect. Different base class library, stack instead of heap objects, heap arranged to allow fast iterating over them. It is C# but it is not your typical .NET. And .NET done right is in the performance region where other aspects kick in (like network or UI bottlenecks).
- wilg 4y ago
  My only .NET experience is Unity and it’s not great.
atwood22 4y ago
Honestly, ARC in a game engine sounds miserable. Circular references are a common occurrence in game development.
- wilg 4y ago
  I mean the #1 issue with Unity performance is GC pauses which are very easy to create. Swift of course has tools for dealing with circular references. I’d certainly take the trade.
- Jweb_Guru 4y ago
  There's a ton of mandatory reference counting in almost every contemporary graphics driver. I also hate reference counting overhead, but it really isn't as big of a deal as you're making it out to be unless you use it for stuff like references in render passes.
  - atwood22 4y ago
    There's nothing wrong with reference counting. Manual reference counting using a technique like pointers into a generational array is fine. When the reference count goes to 0, release the generational memory. Any dangling pointers can handle the null value returned when trying to read the generational memory. That's a totally fine solution to reference counting. My issue is with automatic reference counting. It's just way too easy to hold on to a reference accidentally, especially now that lambdas / closures are an essential language feature. I don't have much Swift experience, but I do have a lot of Objective-C experience, and it's just way too easy to accidentally capture self or some other value. In game programming, there is very little concept of ownership. Everything exists as peers that can modify each other. This leads to a high likelihood of reference cycles.
    - Jweb_Guru 4y ago
      I have not found in my own game programming experience that there's a whole lot of pointer soup, except in temporary scopes that can use stuff like arenas (indeed, this would be pretty terrible for performance) and there's usually a pretty clear ownership structure to be found (ownership may be muddled in a logical sense, but this isn't that relevant from a memory management perspective). Perhaps this is because I'm using a language that doesn't mandate reference counting though, so it's easy to do stuff like just build up temporary references into arrays etc. when necessary...

by wilg 4y ago

andrewf 4y ago

And have only one renderer to choose from instead of 3 with all different features. So you want a fourth renderer? :)

Pulcinella 4y ago

I’m not sure how much of a performance hit ARC traffic would be. Though I think at least some of Unity’s DOTS systems really on structs instead of reference counted objects so it shouldn’t be a problem there.

wilg 4y ago
Swift structs should work for that too. But also DOTS is like years away from being ready it seems like. Basically hacked into the engine and language and kinda over complicated and confusing at the moment.
Arcanum-XIII 4y ago
Not ARC per se but the message dispatch mechanism was the biggest hurdle to high performance Objective C. The solution was easy : drop to C. Not really the best options for ease of approach :)

oaiey 4y ago

C# on Unity is very different then what you expect. Different base class library, stack instead of heap objects, heap arranged to allow fast iterating over them. It is C# but it is not your typical .NET. And .NET done right is in the performance region where other aspects kick in (like network or UI bottlenecks).

wilg 4y ago
My only .NET experience is Unity and it’s not great.

atwood22 4y ago

Honestly, ARC in a game engine sounds miserable. Circular references are a common occurrence in game development.

wilg 4y ago
I mean the #1 issue with Unity performance is GC pauses which are very easy to create. Swift of course has tools for dealing with circular references. I’d certainly take the trade.
Jweb_Guru 4y ago
There's a ton of mandatory reference counting in almost every contemporary graphics driver. I also hate reference counting overhead, but it really isn't as big of a deal as you're making it out to be unless you use it for stuff like references in render passes.
- atwood22 4y ago
  There's nothing wrong with reference counting. Manual reference counting using a technique like pointers into a generational array is fine. When the reference count goes to 0, release the generational memory. Any dangling pointers can handle the null value returned when trying to read the generational memory. That's a totally fine solution to reference counting. My issue is with automatic reference counting. It's just way too easy to hold on to a reference accidentally, especially now that lambdas / closures are an essential language feature. I don't have much Swift experience, but I do have a lot of Objective-C experience, and it's just way too easy to accidentally capture self or some other value. In game programming, there is very little concept of ownership. Everything exists as peers that can modify each other. This leads to a high likelihood of reference cycles.
  - Jweb_Guru 4y ago
    I have not found in my own game programming experience that there's a whole lot of pointer soup, except in temporary scopes that can use stuff like arenas (indeed, this would be pretty terrible for performance) and there's usually a pretty clear ownership structure to be found (ownership may be muddled in a logical sense, but this isn't that relevant from a memory management perspective). Perhaps this is because I'm using a language that doesn't mandate reference counting though, so it's easy to do stuff like just build up temporary references into arrays etc. when necessary...