glitch PGM games on FBNEO libretro WII U

[Zeox-Gamer]

The games run well in terms of fps rate, however, all PGM games on FBNEO on WII U contain glitchy graphics in the background of cutscenes, making platformers like Demon Front unplayable due to not knowing where to jump on the platforms.
In all games the character sprites and life and energy bars are perfect, only the background graphics of the scenes are flawed, such as the ground and objects and landscape backgrounds, some of which are many in other games, not so much but they are incorrect.

[dinkc64]

Hi, since we don't have one of these devices to test on, please take some pictures of the bad scenes that you mentioned and post them here, so we can try to think about where the problem might be

best regards,

• dink

[barbudreadmon]

This one was reported last year (c09901b), i made some attempts at fixing it back then but without success.

@crystalct any chance you could take a look ?

[crystalct]

Just tested Demon Front .... it works perfectly... and ... a very nice game... :P
So on PS3 not glitchy graphics in the background.

[barbudreadmon]

@crystalct hmmm are you sure your ps3 build is using our latest pgm driver ? it got updated sometime last year

[crystalct]

this is a big problem... on the PS3 the current version of FBneo can no longer be compiled.. I should take the latest compileable version and manually make the changes to the new pgm driver...
and often the new changes refer to new things made elsewhere.... a total panic

[barbudreadmon]

on the PS3 the current version of FBneo can no longer be compiled..

Oh, is that anything we could help with ?

[crystalct]

no... too many things now refer to a more modern gcc.... we would need a working version made on PSL1GHT.... which has a decently modern version of gcc

[barbudreadmon]

too many things now refer to a more modern gcc...

Do you have examples ? I was almost sure our codebase was still compatible with older gcc

[crystalct]

are you sure there aren't many more things that need g++ now?
Not so much fbneo core... but RETROARCH layer....

[barbudreadmon]

I don't think FBNeo should fail building on older gcc, but maybe retroarch does ?

[crystalct]

Yes... latest retroarch compilable is 1.10.x or maybe 1.11.x

[barbudreadmon]

Shit, so they entirely dropped support for ps3 after that sdk shitstorm a few years ago ?
Maybe current FBNeo core is buildable with older retroarch ?

[crystalct]

Absolutly no.... we need someone with a lot of free time... many many free time, to finish the porting of Retroarch on PSL1GHT

[Zeox-Gamer]

Olá, como não temos um desses dispositivos para testar, tire algumas fotos das cenas ruins que você mencionou e poste aqui, para que possamos tentar pensar onde pode estar o problema

atenciosamente,

* pensar

This error in PGM games on FBNEO core WII U

[barbudreadmon]

some additional note : back when the issue was reported on discord, it was mentioned that other stages in demon front's attract mode didn't seem affected by the "missing floor" issue

[dinkc64]

hmm, so bg layer (nburnlayer & 1) is missing

[dinkc64]

@barbudreadmon, please merge the pgm_draw update, it's just a test to see if I need to dig deeper or not :)

[barbudreadmon]

sure, done

[barbudreadmon]

@Zeox-Gamer is it better with the new core ?

[vaguerant]

Confirming no major changes since a year ago on Wii U, running d64b24c. Attached are some screenshots of the various issues occurring in Demon Front, or at least where they occur.

Missing floor on Stage 1 (Valley):

I don't remember noticing this last time, but there are screen-shaking explosion effects throughout this area and they result in that middle line of corrupted graphics at the vertical center of the screen.

Attract mode text crawl:

The problem here is not visible in a screenshot, but the text scrolls very awkwardly on Wii U, jumping up and down while it scrolls instead of smoothly moving up.

This screen runs if you leave the attract mode running for a bit. It goes:

• gameplay demo 1 (Valley)
  first screenshot
• fancy intro animation showing off the different characters
• gameplay demo 2 (Passage)
  notably, the floor works fine on this and other stages, only Valley has issues as far as I can see from the attract sequence
• text crawl
  second screenshot

Just to be clear, the issues are not limited to the attract mode. The Valley stage is missing the floor, etc. Here's some gameplay screenshots:

Station level (left on the stage select):

Background is missing in the opening area. The floor is here, though.

Forest level (right on the stage select):

Might be fine? Definitely the least problematic of the first three stages which are unlocked in a new game.

[Zeox-Gamer]

@Zeox-Gameré melhor com o novo núcleo?
I haven't tested it yet, can I update it via the Wiiu retroarch?

[Zeox-Gamer]

@barbudreadmon friend, I updated the core yesterday using the Wii U retroarch and tested the PGM games, there was no difference, the errors continue

Unless the emulator you corrected is to be downloaded elsewhere, in that case I don't know where to download it other than through Retroarch Wiiu itself, like I did yesterday

[Zeox-Gamer]

Good friends, the error I reported still persists so I know if what I downloaded from retroarch is your corrected version or you haven't even touched it yet and I misunderstood, sorry if that's it
I have already done my part to report the error that occurred only in PGM games.

[Zeox-Gamer]

@barbudreadmon No friend, the latest version of Final Burn Neo on Wii U still contains the same errors.
I updated and tested it these days, it's exactly the same, the same defects as before in the pgm games.

[barbudreadmon]

Due to FBNeo hitting some kind of size limitations with libretro's wiiu buildbot last month, the FBNeo wiiu core can't be updated anymore. I don't know when/if this buildbot problem will ever be fixed.

At this point, there isn't much point in fixing big-endian issues since neither ps3 nor wiiu builds are updated anymore, so i can only recommend using a better device for your emulation needs, one that isn't underpowered and using some long dead big-endian architecture.

[dinkc64]

barbudreadmon, could you have the wiiu core compile without d_nes for a possible fix for build?

[vaguerant]

FYI, the buildbot is likely to be fixed in the (relatively) short term. There is ongoing work to update RetroArch for Wii U to run under the modern Aroma homebrew environment instead of the old, outdated way that it runs currently. Most other homebrew has already been switched over to the new environment. RetroArch is the one major holdout, as it is compiled with an older toolchain which cannot build for Aroma.

Downstream at ashquarky/RetroArch, RetroArch has been updated to compile with the current toolchain, allowing it to build again on up-to-date consoles. This has also allowed current FBNeo to build and run without issue. Once all the kinks are ironed out and everything has been tested, these changes will be merged upstream and RetroArch for legacy environments will be sunsetted in favor of the modern (working) Aroma version.

Wii U's not dead yet! :P

[barbudreadmon]

@dinkc64 removing drivers would only be a short term solution, and i'm not entirely convinced removing only 1 driver would solve anything. i'd be more in favor with providing "several smaller cores" for problematic platforms (as @crystalct did for its ps3 builds ?) but that'd require time and i don't have a lot of that atm.

@vaguerant yeah, i heard about that aroma thing that has been in the works for many years, but it doesn't seem there is any ETA yet for its use in libretro's buildbot.

[vaguerant]

Indeed, the major hold-up for the last year or so was that libretro initially wanted to support building for both the legacy and modern homebrew environments, meaning a lot of duplicated work making sure everything compiled with an ancient toolchain from 8 years ago and a modern toolchain from now and maintaining both of those separately. Nobody was super eager to go to all that effort to support a dying legacy homebrew environment on a dying legacy console, so the whole thing kind of got backburnered.

Very recently (in the last couple of weeks), the subject was brought up with libretro again and this time they were willing to just sunset the legacy version, which immediately gave the project a massive boost, since nobody has to dig up enthusiasm for doing the whole project twice to benefit the handful of users who refuse to update. Within a week or so, it's gotten to a very mature state; almost all cores now build--the couple of outliers are in-progress, with a PR in to fix DOSBox and ScummVM, and work going on to fix cores with dynamic recompilation, since the old method of "obtaining" some RWX memory was just to clobber some existing RWX memory and hope nothing broke. quarky's new method will dynamically load in a memory allocation library to do this properly in a non-broken way.

Once that is done, it's mostly a matter of some regression testing and then everything gets merged. I don't want to sound overly optimistic, but getting this all pushed through now looks way more likely than it did even a month ago.

[barbudreadmon]

Very recently (in the last couple of weeks), the subject was brought up with libretro again and this time they were willing to just sunset the legacy version

The timing seems to match so my guess is that they freaked out when FBNeo stopped building.

[barbudreadmon]

@vaguerant any news about that aroma thingy ?