Game menu sometimes chooses the wrong game

[manu-romero-411]

On the latest beta version, if starting scrolling on the game menu from bottom upwards, it can happen that the game isn't correctly chosen. Instead, open_agb_firm will load the game which was above on the list.

This isn't happening in every case. If my game list is considerably big, and I start scrolling from top downwards, the behaviour is the expected: the chosen ROM will be the loaded ROM. I've noticed that when the menu scrolls from bottom to top the bug isn't always occurring.

On the previous alpha releases this bug was inexistent. All games loaded fine.

[profi200]

I can't reproduce this behavior. You need to be more specific on the steps to reproduce this.

[manu-romero-411]

Sorry, I wasn't too specific, and I haven't had too much time to elaborate further.

My system is a New 2DS XL, if it's useful for you to know. The bootloader is fastboot3ds, and I run the latest Luma3DS. As an example, we consider three games in the menu:

  GameA.gba
> GameB.gba
  GameC.gba

We have GameB.gba highlighted on the menu, as noted by the >. What's expected: when pressing the A button, GameB.gba loads. What (often) happens: when pressing the A button, the above ROM GameA.gba loads instead of the highlighted GameB.gba.

As I wrote on my previous message, this issue isn't occurring always. My game list is rather vast, around 120 ROMs, and is easier to reproduce the bug for me if I scroll to bottom. On a less populated game list, where scroll isn't needed to see all ROMs, the issue is harder to reproduce.

As for now, I'm running an older version which unfortunately lacks your latest improvements.

[profi200]

No matter what i try i can't reproduce this behavior with the latest release even in a folder that has more entries than fit on the screen.

[JCollins2048]

@manu-romero-411 I have an incredibly basic question, but hear me out. You didn't happen to rebind any of the controls in the main config.ini file, did you? Specifically, the A button? I'm not sure is rebound controls affects the load menu, but that's the only thing I can think of that could be happening.

Edit: Never mind. Not applicable, apparently.

[profi200]

Button remapping is done in hardware and only affects the GBA hardware.

[GandalfTheFray]

This is happening to me to, but its interesting because its not every game, I believe there is a single bad rom file throwing off the index or something somehow. Games at the top of the list load fine, but games towards the bottom seem to load the incorrect game.

Edit: Further testing concludes that the issue does not seem to start with a single rom, rather results can be inconsistent, one game may open up incorrectly one time, and then correctly in another instance. Tried reducing the size of the largest file name, and relocating the location of the roms. Nothing seems to be fixing it atm.

Edit 2: I am now noticing at the bottom of the list there is a blank game entry, and when I select it, it is loading what should be the last game in the list (the game above the blank space)

Edit 3: Further investigation reveals that the number of games in the windows explorer, the folder where I originally copied the roms from, and the game selector within agb_firm have the same number of games (not counting the blank spot at the end of the list) but I did notice that 3 sets of games show in a different order than they do in windows explorer.

Final Edit: It is now working, here is what I did... I tried removing open_agb_firm from the luma/payloads folder, and deleted the open_agb_firm folder from the within the 3ds folder, I tried reinstalling from github which failed because it would not extract for some reason, then I reinstalled from universal updater instead, and finally I moved my gba roms to the gba rom folder which was generated when Twilight++ was installed. I believe the fix was moving the files to the gba folder as it has a txt file called "Place GBA roms here" which it may have been expecting prior but not finding? idk, I hope this information helps other users and the developer.

[Korkd]

Spent a bunch of time trying to understand this problem and have a theory.

In testing, this only occurs when there are 26 or more files in the directory. It appears to be a display issue and my best guess is this particular line in https://github.com/profi200/open_agb_firm/blob/beta_2024-12-24/source/arm11/filebrowser.c:

ee_printf("\x1b[%lu;H ", oldCursorPos - windowPos + 1);

When pressing up and there are greater than 26 files, windowPos has a value of 2 or more. That means on the next iteration of the loop you wind up with an int underflow. This is further reinforced as with 25 files, pressing up functions correctly and results in a windowPos of 1 not causing the int underflow.