RetroArch 0.9.8-beta1 bug reports

RetroArch General
#1

Please report bugs for 0.9.8-beta1 here, or on Github (https://github.com/Themaister/RetroArch/issues?state=open). Only PC-related bugs go here.

#2

I’ve got a problem with mednafen pce fast module. Trubografx cds doesn’t work. Retroarch just show me error: Retroarch returned with an error! Code: 3221225501

I’ve got syscard3.pce in my system folder, ive got all paths correctly typed (btw Sega CD games works fine), libretro-0924-mednafen-pce-fast-x86 Windows 7 32 bit. Original Mednafen works fine, video mode changing had no impact on error.

As i can see log is fine:

RetroArch CMD: E:/games/retroarch/retroarch.exe E:/games/retroarch/roms/Might_and_Magic_(NTSC-J)_[NAPR-1022].cue -c E:/games/retroarch/retroarch.cfg -v -s E:/games/retroarch/save/Might_and_Magic_(NTSC-J)_[NAPR-1022].srm

RetroArch: Opening file: "E:/games/retroarch/roms/Might_and_Magic_(NTSC-J)_[NAPR-1022].cue"
=== Build =======================================
Compiler: MinGW (4.7.2) 32-bit
Built: Nov 13 2012
=================================================
RetroArch: [CPUID]: Vendor: GenuineIntel
RetroArch: [CPUID]: SSE:  1
RetroArch: [CPUID]: SSE2: 1
RetroArch: [CPUID]: AVX:  0
=== Config ===
video_driver = "gl" 
audio_driver = "dsound" 
libretro_path = "E:/games/retroarch/libretro-0924-mednafen-pce-fast-x86.dll" 
video_vsync = "false" 
system_directory = "E:/games/retroarch/system/" 
stdin_cmd_enable = "true" 
audio_enable = "true" 
=== Config end ===
RetroArch: Loading dynamic libretro from: "E:/games/retroarch/libretro-0924-mednafen-pce-fast-x86.dll"
RetroArch: Version of libretro API: 1
RetroArch: Compiled against API: 1
Internal emulation modules: pce_fast
RetroArch: Environ SYSTEM_DIRECTORY: "E:/games/retroarch/system/".
RetroArch: Environ SET_PIXEL_FORMAT: RGB565.
Frontend supports RGB565 - will use that instead of XRGB1555.
RetroArch: Environ PERFORMANCE_LEVEL: 0.
RetroArch: ROM loading skipped. Implementation will load it on its own.
Loading E:/games/retroarch/roms/Might_and_Magic_(NTSC-J)_[NAPR-1022].cue...

 CD 1 Layout:
  Track  1, LBA:      0  AUDIO
  Track  2, LBA:   3590  DATA
  Track  3, LBA:  20308  AUDIO
  Track  4, LBA:  25147  AUDIO
  Track  5, LBA:  31744  AUDIO
  Track  6, LBA:  50530  AUDIO
  Track  7, LBA:  68241  AUDIO
  Track  8, LBA:  84270  AUDIO
  Track  9, LBA:  89121  AUDIO
  Track 10, LBA: 104516  AUDIO
  Track 11, LBA: 105062  DATA
  Leadout: 121483

Using module: pce_fast(PC Engine (CD)/TurboGrafx 16 (CD)/SuperGrafx)
#3

It might be that PCE CD requires the US BIOS.

Try to rename your US PCE CD BIOS to syscard3.pce, put it in the system directory and let me know if that works. If it does, I could try to work out a hack so that it picks the right BIOS depending on region.

#4

Issues with .cg and .cgp shaders:

  1. Using OpenGL mode, most .cg shaders result in a hard crash in nvoglv64.DLL (details posted below).

  2. Using Direct3D9 mode, .cg shaders work fine, but .cgp metashaders soft crash with a parse error, specifically:

RetroArch [ERROR] :: [D3D9 Cg]: Vertex error: D:/Data/Roms/Shaders/CG Shaders/metashaders/xbr-hybrid-bicubic.cgp(1) : error C0000: syntax error, unexpected ‘=’, expecting “::” at token “=”

To my very untrained eye, it looks like Direct3D9 mode is trying the read the .cgp as if it were a .cg.

OpenGL crash dump:

Problem signature: Problem Event Name: APPCRASH Application Name: retroarch.exe Application Version: 0.0.0.0 Application Timestamp: 50a18c77 Fault Module Name: nvoglv64.DLL Fault Module Version: 9.18.13.1090 Fault Module Timestamp: 50de92ec Exception Code: c0000005 Exception Offset: 0000000000851b70 OS Version: 6.1.7601.2.1.0.768.3 Locale ID: 1033 Additional Information 1: 16aa Additional Information 2: 16aaf4436ea76d86a0c1f1aae0986a4d Additional Information 3: 75e0 Additional Information 4: 75e03fa5213d0863e9090851cd56a4b9

#5

I don’t know if this is a problem with retroarch or libretro, so apologies if this ends up not being the correct place to post this.

The other day I was playing Chrono Trigger with libretro-bsnes when suddenly I had an unexpected power outage. When the power came back and I fired up the game again, I noticed that all the progress I made before the power outage was lost; the in-game save slot I was using (I believe it’s called the SRAM?) was in the same way it was when I last played before that day.

So I made some tests and found out that SRAM files are “dumped” only when retroarch exits successfully. If I force kill the process or turn off the computer before closing retroarch, any progress made is lost.

I tested this with libretro-genplus and had the same results, so I believe it’s not a problem of the emulators but with libretro or retroarch. I don’t know if this is made this way by design, but I think that, if it’s not possible to write this data as soon as changes are made, SRAM should be dumped every X minutes into some kind of backup file (name_of_the_game.srm~?), and recover it next time retroarch launches.

#6

Yeah, what you describe is the case - SRAM files will only really be ‘saved’ to disk when you exit/unload the ROM.

This can cause problems in situations like this. However, the alternative (periodically checking if SRAM needs to be saved to disk) would be slow (especially on systems where file I/O is slow) and probably not worth it.

Over to you, maister.

#7

RetroArch has a mode for that. It’s called autosave_interval. There will be a thread sitting in the background, and periodically flush out SRAM to disk when it changes. By default it’s disabled though as it could potentially cause performance issues if disk I/O is a problem.


# Autosaves the non-volatile SRAM at a regular interval. This is disabled by default unless set otherwise.
# The interval is measured in seconds. A value of 0 disables autosave.
# autosave_interval =
#8

Damn, I should have read the configuration files more carefully. Thanks for the info :slight_smile: