Historically, one of the taboo constructs in Unity3D was the use of c# foreach block because each iteration of the loop would consume a few bytes of data uncessarily.
Curious if that's still the case on modern releases?
My Googling and (very rudimentary) testing is coming up with non-conclusive results and I'd like to leach off of someone else's knowledge here rather than dive into low-level benchmarking myself. :-)
Has anyone poked at this recently to determine if it's still necessary to avoid foreach in Unity3D?
No, foreach is no longer bad in 'modern' unity but the fix is not yet fully released.
It was first fixed on a special build Unity Patch 5.3.5p8 on early July, which you can get from here. This is a special Edition you must get to receive that fix.
Now, Unity upgraded their compiler to Mono 4.4 on Unity 5.5 beta release which is not yet final release. It fixed the foreach problem. Once this version is released in the coming months, foreach memory allocation will be a thing of the past. You can still download for testing purposes but don't release a game with a beta build.
Scripting: Upgrade C# compiler to Mono 4.4. The new compiler still
targets C# 4 and .Net 3.5, but provides better performance and many
bug fixes.
It is now fixed but the fix is still in beta mode.
Related
So I ask you for a unity version (specified version number) that is tested and won't cause me issues in the future, and at least supports the Third Person Character Control Starter Asset.
Some of the versions I tried:
unity 2021.3.3 takes too much time to build (1 hour minimum) especially mobile build, "Your device is weak", I never had this issue with older versions, same project, same assets, takes less time.
unity 2020 and before, many of the assets I need are not supported.
unity 2019 manually setup android build (please kill me) + won't work at the end.
unity 2021.3.16, newly created URP projects by default are bugged with the issue (Burst Compile Error) and I can't add the URP package to an existing project.
You should check release notes from each build at this site if you think an older version will suit you better, you have pre-releases as well on the hub or website but those might cause you trouble in future since they can change substantially until they are official releases.
Although It is strongly recommended that you install a LTS version due to support, go figure.
Each issue you face its either your fault, and you can solve it with a search on the topic, or its a bug and its either been fixed on a later build, pending resolution (there's plenty) or you could create a bug report.
This is not my place entirely since I only use Unity but I hear Godot is light weight and could fit you better.
I'm trying to target .NET 6 for my WPF app, but because I'm using RX.net, the highest I can go is net5.0-windows10.0.19041. One example is that ObserveOnDispatcher() is not available when I'm targeting net6.0-windows, which my app makes heavy use of.
Does anybody know either A) when a .NET 6 version of RX.NET will be released, or B) any workarounds for ObserveOnDispatcher() or ObserveOn(DispatcherScheduler.Current.Dispatcher) on .NET 6?
Thanks
A relatively painless way I found was to simply add the ReactiveUI.WPF package to my WPF projects. This allowed me to advance to net6.0-windows, and also to use DispatcherScheduler. I am not using anything from ReactiveUI library, so this is technically a hack, but took 5 minutes of my time and added only a few hundred kilobytes added to the shipped binaries, so it was worth it for me to be able to move on from previously being held back on net5.0-windows10.0.19041 because of RX.
If I had more time and skill I would dig into how the ReactiveUI.WPF source code achieved this desired effect, and apply this to my own source code... maybe someone has a more elegant, non-hack solution.
This will be fixed in v5.1
https://github.com/dotnet/reactive/pull/1660
You could try the nightly builds as per the readme.
https://github.com/dotnet/reactive#get-nightly-builds
I have a .Net 4.6.1 Winforms application which has more or less 10 years.
It has worked pretty well since the beginning, but in the last few weeks I faced a problem I never had.
Firebird 2.5 (latest version available)
.net client (latest version available)
Visual studio 2015 or 2019 (in both versions, same problem)
Now, the application, when is about Firebird, calls a sequence of select statements in order to load a dataset. It works well, as usual, as it always worked. Since few weeks, the whole sequence of select statements is slow, tremendously slow.
What do I mean with slow? It usually takes 5 or 6 seconds in my PC to load the whole set of data, now it takes 70 seconds, with no reason. Nothing has changed in the architecture or sequence, nothing was added or removed from the environment.
However, I don't know why, the release version of the software is fast as it was originally, so I don't really get where the point is here.
I have a debug version in Visual Studio which is slow at loading the data using a set of select statements, and a release version which is fast as usual.
Now, when I first realized that the software was running very slow, I upgraded the whole set of Firebird components to the latest versions, but had no joy. I was still using old versions because I had no real reason to upgrade: "does it work? Don't touch it!"
In the release version I use the embedded Firebird version, because I have to redistribute the application. In the debug, the server version, so I can manage the database with IBExpert and run the software together. It has always been like this since ages.
So, I'm looking for a suggestion, because I have no idea where or what to look for.
I fixed this odd behaviour by setting Pooling=true in the connection properties
So I am converting a project from Unity 4.x to 5.x and there are a number of functions that the Unity compiler is warning me that are no longer supported or are obsolete.
My question is do these functions still work? (even though they are marked as obsolete)
I know at some point they need to be updated to the newer API but for the moment I just need to fix the bugs so that the game works. Are these functions still usable? or are they potentially the source of runtime bugs?
Thanks
All obsolete functions has been replaced with new functions. So should take a backup and update your project. Go to Assets->Run API Updater, if your project in not getting updated automatically. Dont worry unity will take care of most of the things.
Yes, it's still work ! They just only warning it.
But i suggest you should change for better result, Unity 5 will update you code from old project, then you should change it following warning, just replace
using "xxxx" instead.
to the current context.
I would like to generate LLVM IR for a toy language whose compiler is written in Scala.
SLEM seems to be exactly what I need but I can't figure out if it's usable in its current
state. I tried to download the sources but I am unable to compile it.
Anyone used it successfully or knows whether it's usable?
I haven't used SLEM, but checking its commits it seems that the last one was from early 2011, so it's updated to LLVM version 2.9 at the latest. The IR has significantly changed since then, so it would probably not be usable if you try to use it with a newer LLVM.
You can update it, of course, but perhaps a better option would be LLVM-J - Java bindings to LLVM. It's updated to LLVM 3.1, in which the IR is far closer to what it is right now, plus it's basically just a wrapper around LLVM's C API, so updating it yourself should be relatively simple.