• 0 Posts
  • 9 Comments
Joined 1 year ago
cake
Cake day: February 4th, 2024

help-circle
  • I’m an Unreal Engine game dev and there’s some partial truth to this.

    It’s true that if you use all the new fancy bells and whistles like Nanite and Lumen that you will very likely raise your minimum specs by quite a bit.

    There’s more to this then just Nanite and Lumen, but these are the biggest offenders, so I’ll focus on them.

    Nanite can be thought of in basic terms as a dynamic LOD system. LOD stands for Level of Detail and is used to reduce the amount of polygons (triangles) the GPU needs to render when an object is far away, swapping the 3D mesh/model with a more simplified version. A single mesh can have multiple LODs for various distances. For the game dev, this saves a huge amount of development time not thinking about LODs and the need to create them. For the player, this prevents pop-ins when the game engine is switching between LODs. What Nanite offers is incredibly complex geometry for meshes, highly detailed rocks and trees for example. One thing that Nanite suffers from is called Nanite overdraw. That is when many Nanite meshes overlap each other from the perspective of the player, like trees in a forrest. In this case the frame time goes up (FPS goes down) due to too much processing relative to traditional methods.

    Lumen is the dynamic global illumination system in UE5. It offers (most of the time) superior lighting quality and also bounce lighting (when a window or a door is open in a dark room and light comes in and bounces around, lighting up the room). When a game uses only Lumen, there’s no static lighting which is baked before shipping the game. Baked lighting is incredibly performant, but the shadows from various stuff in the environment is static/baked, which means it can’t move. For game devs, this allows very quick iterations and much quicker dev time overall for the various scenes and environments. For players, this offers much better lighting and visual fidelity. However, like with Nanite, this increases the minimum specs.

    There’s nothing really stopping devs from just using the traditional tools instead of these new dynamic tools. That would of course take longer, increasing dev time, and certain aspects would need to be more faked like before (day/night cycle with baked lighting for example).

    Most UE5 games that have been released are using somewhat early versions of UE5. Epic releases 2 versions a year and we’re currently at 5.5.1 STALKER 2 is using some version of 5.1 IIRC. That means it’s using a very early version of Nanite and Lumen.

    Ultimately it comes down to what the dev studio wants to use and these decisions have consequences, both good and bad.

    There’s a YouTube channel called ThreatInteractive that goes deep on this. The guy comes off as a bit too hostile for some and maybe hyperbolic, but the core of what he’s saying is true.


  • Yes, but only when they enter the battlefield for the first time.

    If you cast an eligible enchantment or artifact and Bello is on thr battlefield, then, as long as it’s your turn, they enter the battlefield also as creatures.

    When it becomes your turn and these permanents are already on the battlefield, but now become creates, they do not trigger ETB effects.

    If they would trigger ETB effects when becoming creatures, then all zone changes would also apply, such as taking control over a creature an opponent controls.


  • Iceland here, we don’t use DST at all. GMT / UTC all year round, it’s nice.

    There has been a lot of discussion in the past few years about adopting it though, but a lot of people don’t really see the point, me included.

    During this time of year, October / November, the days start to get really short, so the sun doesn’t rise until 8 or 9, and it sets around 16 to 18.

    Having some sort of DST here wouldn’t make much sense IMO since it would only be 3 months or so. Then there’s the debate of do you want to use DST and have the sun rise sooner, but set sooner or vice versa with no DST.

    Personally I like that the sun is still somewhat there when I leave work, since even with DST the sun would just barely be starting to rise when I would be commuting to work in the morning.

    (Tangent: I don’t get why a lot of global schedules for some events list the start times of a live stream for a ton of different timezones, but never also include just GMT / UTC)



  • I primarily use it for C++ in Unreal Engine and use it almost exclusively to write log statements. The way to log something is done via a macro like so:

    UE_LOG(LogCategory, Warning, TEXT(“My variable: %s”), *SomeStringVar)

    Writing that boilerplate soup gets tiresome after a while, so having Copilot autocomplete the log statement for me based on other statements in the same file and the context of the function is godsend.

    It does of course happen that the text contents are wrong, but then I have that skeleton to work with. Just erase the text and type the correct contents I want. Saves so much time.


  • For me I’d say Racedriver GRID 2008

    Just something about the handling of the cars that feels good to me. A good mix between realism and arcade style.

    Then there’s the rewind time mechanic that feels good and is tweaked based on difficulty (IIRC you get X amount of rewinds based on difficulty with the highest difficulty having no rewinds)




  • I used Manjaro for about a year around 2019 and it was awful.

    I liked its selling point on being based on Arch and having access to AUR, but the official repositories would only have stuff that is vetted to work on the current release of Manjaro (at least that’s what I had heard about Manjaro at the time)

    The amount of times a package update shit the floor is too many to count.

    Before that I was using Ubuntu and for the most part it was fine.

    The first distro I used was Mint since the desktop environments, Cinnamon, resembled Windows XP.