Thanks for the information, this is the first time I have RT when migrating a project to a new version
What’s bad here is your base idea of what a minimap is supposed to do. And the usage of the tools you are utilizing to create one.
A map is an approximation for reference not a 1:1 accurate representation (even true for topographic maps IRL).
If GTA5 can do this with a static picture, ask yourself: why can you not, when your end result looks about a billion times worse?
Then there is also the fact that:
You complain about performance issues; I tell you right where the problem is from the start. You ignore it. Drone on. And get back to “oh its the minimap”.
If you won’t listen to what people tell you, what’s the point in even asking?
I don’t quite understand what GTA5 with its static game world has to do with my game, where I deliberately aim to move away from pre-made scenes and instead generate them randomly. You’re comparing a dog and a cat, claiming the cat is better. For my purposes, my minimap is undeniably better than GTA5’s, both functionally and visually.
As for your advice, yes, you did recommend looking into the minimap, but there were many such recommendations, and I can’t check everything at once. Moreover, I had already tried roughly disabling the minimap widget among other things, but it took additional efforts to pinpoint the issue later.
Finally, nobody here has been able to explain why the exact same thing works perfectly in 5.4 but terribly in 5.5, instead shifting the discussion to imply that I’m the one who doesn’t understand anything and that it’s my fault, not the engine developers’.
No one is exculpating epic here.
But this is your fault for taking something that needs to be rendered once, or maybe once every 30 seconds tops and making it render constantly.
Its as simple as that.
I would agree with you if it didn’t work in 5.4, I would have immediately discovered a drop in performance at the implementation stage, but since it didn’t cause any problems, it means I did everything correctly, even if not perfectly.
I beg to differ.
The concept is flawed and against best practice;
Just as much as epic is at fault for increasing the rendering cost on the RT a tenfold or so.
“It worked fine before” is what everyone who makes some hacky stuff that’s against best practice likes to stick to. Really doesn’t fly in any professional world - meaning that I have personally fired people for less.
If you think this way, you should probably not be a developer - so change your thinking and keep developing 
Change stuff around, learn better practices.
I got you that this concept is not optimal, but why fix something that is not broken?
My goal is to make a game, not to achieve technical perfection in its development.
I only improve what hinders the main goal. At the moment, I have decided that the transition to 5.5 does not give me anything, but it makes me worsen one of the features of the game.
When I see the profiles of unreal insight (at least in my case).
I see that it is not just one thing that causes problems.
In fact, all the things separately look great.
But you start adding nanoseconds of this plus nanoseconds of that.
And the result is milliseconds… which is starting to get more serious.
So if you want your game to perform at its best, every nanosecond you can shave off here and there is important.
Especially when you only have one thread for the game (Like 20 years ago… Just in case someone from Epic reads this 
).
In my case I have found all my problems in “UWorld_Tick” (In case it helps).
I think there are still things that can be improved… If only I knew what the hell is “waiting for tasks” for example…
Best Regards!!!
A task is normally an async procedure
waiting for a task means you are using the async procedure in a non async way - directly telling that function call to “wait”
In c# something like
string test = await functionthatgetsastring(“is this a string? If no return null”);
Doing this you remove any purpose you had into building the function so that it could be awaited.
But - and thats probably what’s what here - you cannot run the async function in a non async thread without awaiting it.
Stuff like the animation notifies, for instance, are async calls. They could be generating the wait time.
There are other sources of that in engine - even a lot you have no control over.
As a whole, lowering or increasing that time should have no impact if the system is set up correctly.
The system should be waiting functions whenever it can - if it didn’t compute by the time the frame rendered the call is aborted and everything moves on withouth it finishing.
But - im not sure that’s what the log shows here with “wait for task” - it seems like its actively waiting for it to compute and bring in results.
Could be just bad wording on the engine’s end and its doing exactly what I mentioned instead.
Find a function that’s async. Throw in a manual calculation of pi that never stops calculating converting it to and adding into a string. See if the game still runs or if you get it to lock up… best way to test that…
1 Like
Thanks for the explanation!!
I have two asynchronous tasks (FRunnable)…
I will do the test you propose just in case.
Thank you so much!!
1 Like
Hi, from your image its likely waiting for the RenderThread to catch up (you have 78.8ms for Scene::UpdateAllPrimitiveSceneInfos there). Cause the GameThread is only 2 (or 1?, I’m a bit confused about their current RHI documentation…) frames ahead of the render thread, so if the render thread takes longer, then game thread will eventually wait for it to catch up.
1 Like
Hi @chrudimer
Good appreciation… It makes sense.
Next time I have to look at the rest of the threads too.
I was obsessed with the game thread.
And I don’t pay attention to the fact that things are also happening further down in the graph.
Thank you so much @chrudimer
I ended up having more issues. For example with the Zen server being enabled by default or UMG and missing textures in UMG. I went from 5.3 to 5.5. But even though it was three weeks of work, I finally gave up, scrapped it and stayed with 5.3.
btw: when I profiled it with Insight, I had something in there with particles and render target. But I don’t remember much of it and honestly, I don’t want to anymore. I give up.
3 Likes
Like always, adopting an Alpha or Beta version that epic calls a “release” is a mistake.
You are their guinea pigs, so they experiment on you.
Some times, maybe often, the experiment is akeen to a psyops gas lighting effort the size of Ubi and making black samurai into a thing by way of paying random people to post fake images and articles across social media.
Just look at it.
They seem to have yelled loud enough to convince the whole industry that game development companies should discard years of work on their properly built in house engines to make use of a non functional UE5 that adopts improper rendering standards!
And since eggheads managers know how to talk to other eggheads - its like their own language - they seem to have “stuck”. (Unlike Ubi, who will likely shutter or sell IPs as a result of being r-tarded).
So, in essence,
Don’t think you “gave up”, think you saw through their BS and decided not to be Epic’s unpaid testester.
Also because even if you don’t give up, the next update will undo or destroy everything you “learned” or “fixed”.
5 Likes
You’re right… I’ve felt that way many times… one of my biggest disappointments was with “online services”… I spent months trying out the library only to find out it didn’t work. In the end I had to go back to online subsystem.
That’s true too!! Every time I update something it breaks… usually it can be fixed easily… but first you have to find out what broke.
1 Like
No. I gave up. I’ve been a developer for 20 years (Unreal, Cryengine, a couple of AAA inhouse engines - Art/Tech Art) and I still have a job as a gamedev. I don’t plan on using 5.5. It’s enough for me to struggle with it at work 
But in my opinion it is almost useless for independent development with small studio. It’s starting to be just as hellish as with Cryengine.
On the other hand, I have to say that this is one of the best engines I’ve used so far.
1 Like
I prefer cry.
At least everyone knows what to expect going in just from the name.
Performance and visuals though are just So. Much. Better. Even if you do cry to set stuff up.
also, epic is incapable of addressing proper performance, or bug reports.
Never had any issue with cry. H3ll, devs even reach out to get your customized source in order to replicate stuff if you ask nicely.
Try that with Epic (unless you pay them, then maybe you have one of their evangelists around your office anyway).
But yea, as an indy? Next to worthless.
Just stick to 4.27 generally.
When will UE5 be generally stable?
Probably never, from what I see epic is hiring incompetent developers (probably overseas?) And ends up with crap work out of it.
Before one of their compentent people has time to review the work and correct it, it could be years.
f they can even correct it. Some of the stuff is just so n00b hour that it becomes impossible to change without starting from 0.
Generally, its at least a couple years before things start to work if they actually put in the time - but like with the rest, they only put time on what is needed for fortnite. A cartronish crap game that uses 1/100 of what the engine is capable of…
Everything else is done by other - probably less well paid - people. And they direct them to start on something, then stop them in their tracks leaving it in a beta state constantly… so it never even gets fixed.
2 Likes
“When will UE5 be generally stable?”
I think it will take a long time. One fact remains - that engine is starting to get over their heads.
I don’t want to be a advocate for devil, but when they have a large number of people working on the engine at the same time, there is usually a problem with safe commits. The thing is that while you have fixed something, for example, you are still tied to a previous commit that could have broken something. The only thing that can save them is months with datalock and then fixing the bug. However, I don’t think this is possible until unfinished features are finished The commit basically won’t get out soon and there are other factors that can make more (for example Microsoft ). But i just thinking loudly.