Quoting: stormaI tried Retropie, Recalbox and Lakka but none of them was a smooth experince, Lakka not even starting. Came across this article and gave it a shot. Works well out of the box. This will stay as the default.

Yeah, back at the time when I've acquired a RPI3B, I started using Retropie because it was more flexible, but I ended up taking too much time configuring, downloading and compiling things.

When Recalbox v4.2 launched, I jumped in and found amazing because a lot of stuff that was done through Retropie-Setup scripts and required a keyboard was already available at the Emulation Station on Recalbox, and also, the plethora of supported controllers was great. But the drawback of buildroot based distros is that it is pretty static so, no way to add additional stuff.

Batocera is now on a nice balance here: you have a buildroot systemd but you can also use pacman for some basic stuff and flatpak for more elaborate software like Steam. So now I have a Retrogaming and a Steam Box plugged in my TV.

View this comment - View article - View full comments

This trailer brings back some good memories from the Motherload game(which I think inspired Bore Blasters a little), with some extra speed and action.

Will definitively try this out.

View this comment - View article - View full comments

Another thing here: Batocera wiki pages might look rough edged but that's because this is a distro for you to install on any equipment and dedicate it completely for retro-gaming so, solutions like the Dual boot one that is linked on this article is really made on best effort, and they assume the ones doing it have some "medium to advanced" knowledge on Linux setup.

That being said, Batocera is usually one big FAT32 partition that holds the overlay image for the entire system, and a second partition for the SHARE storage, which is user data and batocera initialized data. SHARE partition is created from the remaining space on the disk.

There is are another wiki links[refer 1] article with instructions on how to use ROMs stored on an already existing partition, if ext4 or btrfs:

1 - Edit /boot/batocera-boot.conf, set sharedevice=SHARE
2 - Add the line sharedevice_part1=ROMS@2efa1068-UUID-OFYR-PART-EXAMPLEEEE:/home/<user>/roms

This might be helpful to dualboot with Batocera and keep your ROMs on the home folder of your current desktop distro for example.

References
====================================
[1] https://wiki.batocera.org/store_games_on_a_second_usb_sata_drive [External Link]

View this comment - View article - View full comments

This game was already running pretty well on Steam Deck during the demo :)

The verified is just a nice to have at this point.

View this comment - View article - View full comments

Quoting: michaldybczakHow this is plays on hybrid setup AMD CPU/AMD GPU?

Is it only about dGPU or maybe also iGPU?

Usually, dGPU is powered down (or shows energy usage below 1W). When it is activated for games, then I guess it should deliver whatever it has in store, but otherwise, it should power down again, when it's no longer used. However, I'm not sure how it works when low demanding titles are launched.

I think that on Laptop usecases the impact will not be THAT big because usuallt the lower voltages are way lower on those dGPUs than they are on Desktop GPUs.

My Laptop RXT3070 can get as low as 8W on Idle when I'm on battery and set for optimus mode looking at nvidia-smi.

But since even Firefox tries to use GPU nowadays by setting GL_ instructions, I end up configuring my laptop into "iGPU only" on battery which will send a pci detach to the nvidia dGPU making it unavailable and completely powered off.

View this comment - View article - View full comments

Quoting: chtkSo, wait. The current stable release is 6.7 (patch 8). Will this be patched in 6.7 or the currently in rc 6.8?

It is already applied. While I don't have an AMD GPU to test, there are these 2 reports from 1 month ago in this issue that reinforce this information:

This comment [External Link]:

Since kernel 6.7, power1_cap_min went from 0 to 136000000 on my 6600XT.
I understand this is the behavior introduced in commit 1958946858a62b6b5392ed075aa219d199bcae39.
Am I understanding correctly that this is a safety feature to prevent the over-draw issue?
I used to set my power1_cap at 75W (as a hard limit on noise and heat) and it worked fine for me.
That's now not possible due to the higher power1_cap_min.
Was this always out of spec and I was just lucky to not encounter the issue?

And this comment [External Link]:

Dear maintainers, I too am affected by the issue described above, i.e. power1_cap_min went to 96W on my RX6600 
(default is 100W I think); before, I could happily apply a 50W power cap. Is there any possibility to restore 
the ability to set lower power caps?

View this comment - View article - View full comments

Quoting: dpanterThis is a bit of unfortunate nonsense, if users want to break their hardware then they should be able to. Not that lowering power limit actually does that but whatever.
I don't like this kind of overbearing handholding. It's fine to have the driver adhere to the board manufacturers specifications, it's another thing to block functionality and outright refuse to entertain the option. That's not cool.

Because people are upset over this regression and feature limitation, a patch has been created to restore it by user fililip in Gitlab issue 3183 [External Link]

While I agree with your point that customers ultimately should OWN the hardware in all levels, most of amdgpu developers are AMD Engineers, and they seem to be defending the company against any hardware damage that might lead to warranty issues.

I'm not saying that I agree with them, but I kinda understand the reason. Being a Support Engineer myself, I had to face a couple of those situations where the Engineering team implements some lock mechanisms and I had to deal with the splash damage of explaining the customer some "brand new limitation on our shiny software".

View this comment - View article - View full comments

Funny fact here: This game was massively sold in Brazil because of the meme.

Pal is pt_BR slang for "D--k"(actually Pau, but the pronunciation is quite similar).

Based on that, you can imagine that streamers are delighted to make live content and read stuff like:

- Pal fluid, Pal boxes, riding a Pal
- You smell like Pal
- You've cuddled your Pal
- There are small and big Pals around

You've got the point here... ( ͡° ͜ʖ ͡°)

It all started as a meme and people are still enjoying it there.

View this comment - View article - View full comments

Quoting: Purple Library GuyI was expecting OpenGL per se to start getting deprecated in favour of Zink + Vulkan, but not so soon.

The advantage here is that Zink implements some of the multithreaded goodies from Vulkan making it naturally faster than any OpenGL implementation on nouveau - https://www.collabora.com/news-and-blog/news-and-events/nvk-holiday-update.html [External Link]

If it reduces maintenance in OpenGL implementations and ends up adding performance, it's a win-win situation :)

View this comment - View article - View full comments

While I'm using mesa-git here, but I didn't switched back to nouveau yet. I also don't know if there are any specifics(caveats) for prime rendering so, not changing from nvidia-dkms yet.

View this comment - View article - View full comments