Kodi Community Forum
RetroPlayer Test Builds (updated for Nexus) - Printable Version

+- Kodi Community Forum (https://forum.kodi.tv)
+-- Forum: Support (https://forum.kodi.tv/forumdisplay.php?fid=33)
+--- Forum: Game support (https://forum.kodi.tv/forumdisplay.php?fid=292)
+--- Thread: RetroPlayer Test Builds (updated for Nexus) (/showthread.php?tid=173361)

Pages: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170

RE: RetroPlayer Test Builds (updated for Isengard) - garbear - 2015-08-27

we're missing a controller add-on for those platforms

RE: RetroPlayer Test Builds (updated for Isengard) - CrispyXUK - 2015-08-27

How do I reset control configuration? Is there a specific file that is safe to delete?

RE: RetroPlayer Test Builds (updated for Isengard) - garbear - 2015-08-27

delete userdata\addon_data\peripheral.joystick\buttonmap.xml

RE: RetroPlayer Test Builds (updated for Isengard) - CrispyXUK - 2015-08-27

Thanks man, I'd imagine I can follow that xml schema to add a second player to this?

RE: RetroPlayer Test Builds (updated for Isengard) - garbear - 2015-08-27

last night I re-wrote the port mapping code. multiple joysticks are supported, and each joystick should maintain their port when others are unplugged/replugged. The keyboard typically gets assigned to the first unplugged port. if anyone has multiple controllers, this could definitely use some testing.

I'll upload a new OSX build so you can test multiplayer.

anyone know of some good 4 player game to test with"

RE: RetroPlayer Test Builds (updated for Isengard) - a1rwulf - 2015-08-27

mario kart Tongue
but I'd have to rebase first!
ah and yeah, osx still not ready^^

RE: RetroPlayer Test Builds (updated for Isengard) - Scourge - 2015-08-27

I'll be able to test 2 player NES games this weekend. Am still on vacation atm, but will be back saturday. I have to NES to USB adapters waiting to be used Tongue

RE: RetroPlayer Test Builds (updated for Isengard) - Heat - 2015-08-27

(2015-08-27, 20:40)garbear Wrote: anyone know of some good 4 player game to test with"
Well, for n64 there is:

-mario kart 64
-golden eye
-star fox
-super smash bros
-donkey kong 64
-mario party

RE: RetroPlayer Test Builds (updated for Isengard) - garbear - 2015-08-27

needs to have a working core, like bSNES. mupen64plus is still in development

RE: RetroPlayer Test Builds (updated for Isengard) - natethomas - 2015-08-27

Just tested bSNES using smc files. Also doesn't work. Same issue as the sfc files.

RE: RetroPlayer Test Builds (updated for Isengard) - Heat - 2015-08-27

ah, sorry. Well for snes there is:
-super bomberman 1-5

This guy list all the games that games that supports up to 5 players.

For the NES there is:
-Bomberman(of course)
-Gauntlet 2
-Swords and Serpents
-Super Off Road

Turbograft there is:
-Double Dragon 2
-Dungeon Explorer 1-2

For genesis there is this list.

Saturn 4 player games

If the game is bombeman or NBA Jam/Sport game, it will most likely support 2+ players.

RE: RetroPlayer Test Builds (updated for Isengard) - CrispyXUK - 2015-08-28

I have about 20 odd controllers so I'll certainly do some testing Smile

Is there an easy way to get the "Games" menu into the amber skin btw?

RE: RetroPlayer Test Builds (updated for Isengard) - Montellese - 2015-08-29

On win32 beetle-bsnes fails with
Code:
Debug Print: AddOnLog: SNES (Beetle bSNES): Loading E:\Media\Games\ROMs\snes\Super Mario World.smc...
Debug Print: AddOnLog: SNES (Beetle bSNES):  Using module: snes(Super Nintendo Entertainment System/Super Famicom)
Debug Print: AddOnLog: SNES (Beetle bSNES): MDFN_MakeFName: E:\Coding\Cpp\xbmc\portable_data\userdata\addon_data\game.libretro.beetle-bsnes\save\Super Mario World.srm
Debug Print: AddOnLog: SNES (Beetle bSNES): Error opening save file "E:\Coding\Cpp\xbmc\portable_data\userdata\addon_data\game.libretro.beetle-bsnes\save\Super Mario World.srm":
Debug Print: AddOnLog: SNES (Beetle bSNES): MDFN_MakeFName: E:\Coding\Cpp\xbmc\portable_data\userdata\addon_data\game.libretro.beetle-bsnes\save\Super Mario World.rtc
Debug Print: AddOnLog: SNES (Beetle bSNES): Error opening save file "E:\Coding\Cpp\xbmc\portable_data\userdata\addon_data\game.libretro.beetle-bsnes\save\Super Mario World.rtc":
Debug Print: GAME - LoadGame() - addon 'game.libretro.beetle-bsnes' returned an error: the command failed
I checked and E:\Coding\Cpp\xbmc\portable_data\userdata\addon_data\game.libretro.beetle-bsnes didn't exist so I created E:\Coding\Cpp\xbmc\portable_data\userdata\addon_data\game.libretro.beetle-bsnes\save\ manually but it still shows the same error.

I then created the files manually (empty files) and then it got a step further but fails with
Code:
Debug Print: AddOnLog: SNES (Beetle bSNES): Loading E:\Media\Games\ROMs\snes\Super Mario World.smc...
Debug Print: AddOnLog: SNES (Beetle bSNES):  Using module: snes(Super Nintendo Entertainment System/Super Famicom)
Debug Print: AddOnLog: SNES (Beetle bSNES): MDFN_MakeFName: E:\Coding\Cpp\xbmc\portable_data\userdata\addon_data\game.libretro.beetle-bsnes\save\Super Mario World.srm
Debug Print: AddOnLog: SNES (Beetle bSNES): MDFN_MakeFName: E:\Coding\Cpp\xbmc\portable_data\userdata\addon_data\game.libretro.beetle-bsnes\save\Super Mario World.rtc
Debug Print: AddOnLog: SNES (Beetle bSNES): MDFN_MakeFName:
Debug Print: AddOnLog: SNES (Beetle bSNES):   Loading custom palette from ""...
Debug Print: AddOnLog: SNES (Beetle bSNES):    Error opening file:
Debug Print: GAME - LoadGame() - addon 'game.libretro.beetle-bsnes' returned an error: the command failed

EDIT: I tried beetle-gba now and funny enough it can create the save files it needs but it also fails loading the palette:
Code:
Debug Print: AddOnLog: GBA (Beetle GBA): Loading E:\Media\Games\ROMs\gba\Mario Kart - Super Circuit (E).gba...
Debug Print: AddOnLog: GBA (Beetle GBA):  Using module: gba(GameBoy Advance)
Debug Print: AddOnLog: GBA (Beetle GBA):   ROM:       4096KiB
Debug Print: AddOnLog: GBA (Beetle GBA):   ROM CRC32: 0x20025842
Debug Print: AddOnLog: GBA (Beetle GBA):   ROM MD5:   0xf99fb545ac65126e9956a7718c30d6a3
Debug Print: AddOnLog: GBA (Beetle GBA): MDFN_MakeFName: E:\Coding\Cpp\xbmc.montellese\portable_data\userdata\addon_data\game.libretro.beetle-gba\save\Mario Kart - Super Circuit (E).f99fb545ac65126e9956a7718c30d6a3.type
Debug Print: AddOnLog: GBA (Beetle GBA): MDFN_MakeFName: E:\Coding\Cpp\xbmc.montellese\portable_data\userdata\addon_data\game.libretro.beetle-gba\save\Mario Kart - Super Circuit (E).f99fb545ac65126e9956a7718c30d6a3.sav
Debug Print: AddOnLog: GBA (Beetle GBA): MDFN_MakeFName: E:\Coding\Cpp\xbmc.montellese\portable_data\userdata\addon_data\game.libretro.beetle-gba\save\Mario Kart - Super Circuit (E).f99fb545ac65126e9956a7718c30d6a3.eep
Debug Print: AddOnLog: GBA (Beetle GBA): MDFN_MakeFName:
Debug Print: AddOnLog: GBA (Beetle GBA):   Loading custom palette from ""...
Debug Print: AddOnLog: GBA (Beetle GBA): Error opening file
Debug Print: AddOnLog: GBA (Beetle GBA):    Error: Error opening file
Debug Print: GAME - LoadGame() - addon 'game.libretro.beetle-gba' returned an error: the command failed

This seems to be a bug in MDFN_MakeFName which is called at https://github.com/libretro/beetle-bsnes-libretro/blob/cf7711128f0b358584dadabe376a4030e1009e5f/mednafen/snes/interface.cpp#L63 with MDFNMKF_PALETTE and syspalname being NULL but its implementation at https://github.com/libretro/beetle-bsnes-libretro/blob/cf7711128f0b358584dadabe376a4030e1009e5f/libretro.cpp#L511 doesn't handle MDFNMKF_PALETTE and therefore returns an empty path.

RE: RetroPlayer Test Builds (updated for Isengard) - Montellese - 2015-08-30

I've hunted down the deadlock that happens when connecting my Bluetooth controller while an emulator is running:
Code:
> CPeripheralBus::TriggerDeviceScan() Line 260                                            CPeripheralBus::m_critSection (blocked)
  PERIPHERALS::CPeripherals::TriggerDeviceScan() Line 155                                 CPeripherals::m_critSection (blocking)
  CWinEventsWin32::WndProc() Line 749
  CWinEventsWin32::MessagePump() Line 382
  CWinEvents::MessagePump() Line 84
  CApplication::FrameMove() Line 2479
  CXBApplicationEx::Run() Line 140
  WinMain() Line 243

> CPeripherals::GetBusType() Line 159                                                     CPeripherals::m_critSection (blocked)
  PERIPHERALS::CPeripherals::GetAddon() Line 725
  PERIPHERALS::CAddonJoystickButtonMap::CAddonJoystickButtonMap() Line 30
  PERIPHERALS::CAddonJoystickInputHandling::CAddonJoystickInputHandling() Line 35
  PERIPHERALS::CPeripheral::RegisterJoystickInputHandler() Line 535
  PERIPHERALS::CPeripheralJoystick::InitialiseFeature() Line 71
  PERIPHERALS::CPeripheral::Initialise() Line 146
  PERIPHERALS::CPeripherals::CreatePeripheral() Line 319
  PERIPHERALS::CPeripheralBus::RegisterNewDevices() Line 117                              CPeripheralBus::m_critSection (blocking)
  PERIPHERALS::CPeripheralBus::ScanForDevices() Line 128
  PERIPHERALS::CPeripheralBus::Process() Line 212
  CThread::Action() Line 221
  CThread::staticThread() Line 134

Looking at the whole peripherals code I'm getting the feeling that there are a lot of places for potential deadlocks. Every class has a single lock that is used for locking all kinds of different things. And device scans seem to be initiated from a lot of different places and therefore also potentially from a lot of different threads (callback from peripheral addon implementation, os events, ...).

Unfortunately I don't know this code at all and I haven't really understood the design behind it yet so proposing any improvements would be a shot into the dark.

RE: RetroPlayer Test Builds (updated for Isengard) - garbear - 2015-08-30

The peripherals code isn't that bad off. Each peripheral bus gets its own thread, and all scanning happens within that thread, regardless of where the scan was triggered

The mistake here is that the add-on bus shouldn't hold a lock when passing control to the add-on. I'll get this fixed