From the creator of Absolute Drift comes art of rally, a top-down racing game that heavy on style and it has great gameplay to back it up too.
Here's the thing: I don't drive. Not in real life and any attempt at doing so seriously in games always comes with massive amount of hilarious failure. I'm terrible at DiRT Rally, I'm equally as crap at the F1 series, back when GRID Autosport came to Linux a lot of my time was spent on my roof and…you get the idea. They're all actually a little brutal for people like me - which is why I've come to appreciate the calmer side of it all thanks to the magnificent art of rally.
Direct Link
With thanks to the developer providing a key ahead of the release, I've been playing it and thoroughly enjoying the whole thing. From repeatedly trying to improve my times in the career mode and time trial, to just taking in a bit of scenery in the sandbox / open map exploration mode there's a lot to love about it. Something I'll be clear on though is that this is not an easy game, it's still quite challenging and the handling does take a while to get used to. It's definitely not a simple arcade game and you will need to learn when to carefully drift and when to pull hard on the handbrake.
In art of rally you get to power through a little bit of history in various year categories, although not exactly official because as a small indie developer Funselektor doesn't get to use all proper licenses but you still get to drive tons of cool looking cars that resemble plenty of the classics.
art of rally is a game that shows how games can be quite beautiful, without pushing ever closer towards realism. It's easy on the eyes, it's clearly not trying to go for the level of Codemasters titles graphically and yet it looks absolutely gorgeous and I'm constantly blown away by it. A fine example of how to do a lot with so little.
I can't tell you how much joy art of rally truly is. Not many games let you send a little MINI absolutely flying around a corner, right into a barrel roll and came out of it looking pretty damn spectacular. art of rally does though, and it lets you do some pretty wild things - totally on purpose of course.
The game is single-player, however, you still get to challenge the world and you friends thanks to everything having a leaderboard. You can see how you stack up against everyone else, or you can ignore it and just play it entirely for your own fun and pleasure. It even has daily and weekly challenges to really test you.
As fantastic as it is, and as wonderful as it feels, nothing will stop me from ending up like this directly in front of the finishing line. I've turned failing into a perfect art.
That was a perfect opportunity to use the great built-in photo mode. More games need this! There's so many moments across games I've wanted to capture from fun angles and having it frozen, so you can pan/tilt and whatever to get the best view is super fun. You don't just freeze-frame though, after finishing you can go back through a whole replay if you want to pick some fun moments from new angles.
With art of rally you get a racing experience that pulls away all the fluff, puts it back to the basics of you and the car wrapped up in a visually striking look that I can easily and quite happily recommend.
I think this is caused by the heavy use of compute shaders, which might be fixed by this:
https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5632
Maybe someone using a current 20.2-rc can confirm? The demo should be enough to reproduce the bug:
https://funselektor.itch.io/art-of-rally#download
Just a quick warning; broken graphics on Mesa 20.1.8/radeonsi. No foliage, rocks or trees, spectators are just black unmoving blocks.
I think this is caused by the heavy use of compute shaders, which might be fixed by this:
https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5632
Maybe someone using a current 20.2-rc can confirm? The demo should be enough to reproduce the bug:
https://funselektor.itch.io/art-of-rally#download
20.2-rc4
Not sure if the empty trunks are by design or a bug
Last edited by x_wing on 24 September 2020 at 3:28 am UTC
However, the AMD+Mesa graphics bugs have been around a long time and seems to be caused by Unitys wonky Indirect Instancing buffers. I had hoped for a fix before release but I guess it's complicated. :/
The team is well aware of the issue. Join the funselektor Discord or file a bug report with the right side button on artofrally.com to help them out.
edit: I reported back in late July that mesa-git 20.2 built with clang was working, although bloom was still causing excessive lens flares at night if using any other antialiasing setting than TAA.
Last edited by dpanter on 24 September 2020 at 11:44 am UTC
Not sure if the empty trunks are by design or a bugThey are present with the nVidia binary blob as well. Thought it was a statement on climate change, as odd as that might be in a racing game ...
I finally had time to compile Mesa from git and the game is rendering correctly now. The shader link errors disappeared too so I guess the problem really was insufficient shader buffers.
compile Mesa from git and the game is rendering correctly nowCan you test if the lens flares are gone as well? Use different AA settings at night with bloom enabled.
Thanks guys!
I finally had time to compile Mesa from git and the game is rendering correctly now. The shader link errors disappeared too so I guess the problem really was insufficient shader buffers.
A bit late to the party, but I had time to test it out and can also confirm the black crowd and missing trees.
Tested on Mesa 20.1.8 / RX 5500XT
Can you test if the lens flares are gone as well? Use different AA settings at night with bloom enabled.That's still a problem with 20.3.0-devel.
I'll try to file a bug with Mesa when I have some time to spare.
Has this game inside cabin view?
I only see outside views of the cars.No. As Liam writes in the very first sentence of this article, it's a "top-down racing game".
Has this game inside cabin view?
Here's the bug report for the lens flare issue with a couple of patches to try out:compile Mesa from git and the game is rendering correctly nowCan you test if the lens flares are gone as well? Use different AA settings at night with bloom enabled.
https://gitlab.freedesktop.org/mesa/mesa/-/issues/3562
Here's the bug report for the lens flare issue with a couple of patches to try out:compile Mesa from git and the game is rendering correctly nowCan you test if the lens flares are gone as well? Use different AA settings at night with bloom enabled.
https://gitlab.freedesktop.org/mesa/mesa/-/issues/3562
Does this patch only fix the issue with Proton/DXVK?
Does this patch only fix the issue with Proton/DXVK?Good question. I haven't actually tried the Mesa patch yet since it supposedly caused other glitches. But I assumed it would work in both cases?
For now I just set anti alias to "taa".
Does this patch only fix the issue with Proton/DXVK?Good question. I haven't actually tried the Mesa patch yet since it supposedly caused other glitches. But I assumed it would work in both cases?
For now I just set anti alias to "taa".
Unfortunately I think this Mesa patch won't fix the OpenGL issue. It's definitely forcing an ACO compiler fix (i.e. Vulkan), not to mention that this patch is probably the same as adding this config for radv driver in dri.rc:
<application name="art of rally" executable="artofrally.exe">
<option name="radv_enable_mrt_output_nan_fixup" value="true" />
</application>
Unfortunately I think this Mesa patch won't fix the OpenGL issue. It's definitely forcing an ACO compiler fix (i.e. Vulkan), not to mention that this patch is probably the same as adding this config for radv driver in dri.rc:You're right
<application name="art of rally" executable="artofrally.exe">
<option name="radv_enable_mrt_output_nan_fixup" value="true" />
</application>
I haven't followed Mesa development that closely as of late, so I wrongly assumed the ACO compiler was used for OpenGL too.
Can you test if the lens flares are gone as well? Use different AA settings at night with bloom enabled.
Does this patch only fix the issue with Proton/DXVK?Don't know if you follow the fdo bug or not, but I modified one of the shaders in the game to get rid of the NaN issue and it seems to be working fine here:
https://gitlab.freedesktop.org/-/snippets/1232
Drop the file in a dir and run the game with
MESA_SHADER_READ_PATH=/path/to/shader/dir
See more from me