libretro / libretro-common Goto Github PK

vendor/libretro-common/vfs/vfs_implementation_cdrom.c: In function ‘retro_vfs_file_seek_cdrom’:
vendor/libretro-common/vfs/vfs_implementation_cdrom.c:49:19: error: ‘libretro_vfs_implementation_file {aka struct libretro_vfs_implementation_file}’ has no member named ‘cdrom’
stream->cdrom.byte_pos = offset;
^~
compilation terminated due to -Wfatal-errors.
Makefile:25: recipe for target 'vendor/libretro-common/vfs/vfs_implementation_cdrom.o' failed
make: *** [vendor/libretro-common/vfs/vfs_implementation_cdrom.o] Error 1

https://github.com/libretro/libretro-common/blob/master/vfs/vfs_implementation_cdrom.c#L49

How are dependancies for this project acquired?

Take for instance the dependancies for the mixer components such as format decoders.

I am getting:

GLideN64/src/GLSLCombiner.h:107:44: error: ‘glUniform4i’ was not declared in this scope

When I try to use glsm/glsmsym.h.

It looks like glsm.c doesn't have the code for glUniform4i?

Problems in vc2010:

• fill_pathname_expand_special and fill_pathname_abbreviate_special are missing (for retro team to solve)
• there's irrational _MSC_VER ifdefs in rthreads.h (for discussion)
• nonstandard ssize_t is used by retro_file.h (needs compat treatment) (for myself to create a patch)
• snprintf used by retro_dirent.c (needs compat treatment) (for myself to create a patch)

note: none of these are blockers for me presently, since I don't need the functions in the first bullet point and the others are easy to workaround

1. clarify that API does not support changing the system or save paths once the core is running
2. clarify when the core should check the system and save paths -- retro_load_game so that the core can fall back on the content path if the frontend has not set system or save path
3. clarify that the core should fall back on the content path, if indeed that is the standard behavior

Is it possible to specify any integer configuration fields in custom cores?

I'm starting this issue as a placeholder so that I come back and help write up documentation on how this callback function works.

A lot of discussion has been going on about a VFS layer for libretro.
I think it would be important to discuss, the problem, outline the goals and a set of requirements before attempting to come up with a solution.

I've been reading the chat, and the PRs that have been opened about this and I have found the following:

Problem

The API contemplates two scenarios regarding content loading:

• The frontend loads content for them and hands over the data and the size of such data
• The frontend hands the core the path to the content file that the user requested.

I assume any frontend including Retrix might be able to work as-is on the first scenario. Load the content th content in-behalf of the core and just pass the data over.

The second scenario is often used by contat that might be:
a. to big to be pre-loaded in memory by the frontend
b. might be composed of several files
c. might need patching before loading
d. might be inside an archive and require many of the files within the archive
d. might need to write to the content file or the content dir (nintendo FDS for instance)

Proposals

The proposal is a VFS ala KODI which allows the frontend to get data from different filesystems and would then hand over the data or a file handle to the core.

libretro/Genesis-Plus-GX#98
http://dpaste.com/13WQAV1
libretro/RetroArch#3715

Use cases

• A user might have a file hosted in a web server (the frontend would need to support http to be able to retrieve the file in the first place)
• Allow using Google SAF to load files from various content providers on Android
• Allow using native iOS APIs to load files from various content providers on iOS

CXX libretro.cpp
libretro-common/cdrom/cdrom.c: In function ‘cdrom_get_available_drives’:
libretro-common/cdrom/cdrom.c:1394:20: warning: implicit declaration of function ‘strcasestr’; did you mean ‘strcasecmp’? [-Wimplicit-function-declaration]
 1394 |                if (strcasestr(mods->elems[i].data, "sg "))
      |                    ^~~~~~~~~~
      |                    strcasecmp
CC libretro-common/cdrom/cdrom.c

#define _GNU_SOURCE should be defined before #include <string.h> when using strcasestr() since its a nonstandard extension. But since this is in the libretro-common and i'm unfamiliar with other systems that would use this, ill leave it to someone who knows better to silence some of the warnings.

file_path is being used before it's initialized, I think the following patch should show the problem and a possible solution:

diff --git a/libretro-common/file/dir_list.c b/libretro-common/file/dir_list.c
index 60c12fe..e27901d 100644
--- a/libretro-common/file/dir_list.c
+++ b/libretro-common/file/dir_list.c
@@ -184,11 +184,12 @@ struct string_list *dir_list_new(const char *dir,
       char file_path[PATH_MAX_LENGTH];
       int ret                         = 0;
       const char *name                = retro_dirent_get_name(entry);
-      bool is_dir                     = retro_dirent_is_dir(entry, file_path);
       const char *file_ext            = path_get_extension(name);

       fill_pathname_join(file_path, dir, name, sizeof(file_path));

+      bool is_dir                     = retro_dirent_is_dir(entry, file_path);
+
       ret    = parse_dir_entry(name, file_path, is_dir,
             include_dirs, include_compressed, list, ext_list, file_ext);

(It's a diff from Retroarch/libretro git but that code is the same)

This is a request for an option to turn off Wii U gamepad (for players using TV), in order to preserve battery.
Thank you very much.

These are the issues off the top of my head.

• No 24bit WAV support (in many WAVs)
• No Sony Wave64 support
• No ulaw/mlaw decoding
• No ADPCM decoding

Just keeping these as a note for whoever maintains libretro-common, nor is it a indication really of if I will look at those myself like I did for FLAC and MP3.

Many cores create save and configuration files which are named based on the filename of the content they are executing.

When a core sets need_fullpath==false, there is no means specified in libretro.h for the core to determine the filename so there is no way to name the save files. @fr500 provides an example of this issue from beetle-gba here: libretro/beetle-gba-libretro#33 (comment)

I'm creating this issue because it seems separate from the PR I submitted to clarify the existing behavior.

Two possible ways I can think of to provide the name of the content to the core are:

• update the API so that if need_fullpath == false then retro_game_info::path will return the filename of the content (not the full path)
• create a new callback which returns the name of the content

net_natt.h and net_natt.c won't work without RetroArch.

These files were moved out of libretro-common in the RetroArch repository, but they still remain here.

I would like to point out that identifiers like “__LIBRETRO_SDK_FILE_PATH_H” and “__RARCH_MISCELLANEOUS_H” do eventually not fit to the expected naming convention of the C language standard.
Would you like to adjust your selection for unique names?

Here is below a patch to add ARM thumb2 support. Tested using gcc-5.4 (-with-arch=armv7-a --with-tune=cortex-a7 --with-fpu=neon-vfpv4 --with-float=hard --with-mode=thumb) and libretro-dosbox.

--- armeabi.c.orig 2016-07-25 22:40:54.000000000 +0200
+++ armeabi.c 2016-07-25 22:42:58.000000000 +0200
@@ -22,7 +22,25 @@
static thread_local uint32_t co_active_buffer[64];
static thread_local cothread_t co_active_handle;

-asm (
+#if defined(thumb2)

• asm (

•  ".thumb\n"
  

•  ".align 2\n"
  

•  ".globl co_switch_arm\n"
  

•  ".globl _co_switch_arm\n"
  

•  "co_switch_arm:\n"
  

•  "_co_switch_arm:\n"
  

•  "  mov r3, sp\n"
  

•  "  stmia r1!, {r4, r5, r6, r7, r8, r9, r10, r11}\n"
  

•  "  stmia r1!, {r3, lr}\n"
  

•  "  ldmia r0!, {r4, r5, r6, r7, r8, r9, r10, r11}\n"
  

•  "  ldmfd r0!, { r3 }\n"
  

•  "  mov sp, r3\n"
  

•  "  ldmfd r0!, { r3 }\n"
  

•  "  mov pc, r3\n"
  

•   );
  

  +#else /defined(thumb2)/
• asm (
  ".arm\n"
  ".align 4\n"
  ".globl co_switch_arm\n"
  @@ -32,6 +50,7 @@
  " stmia r1!, {r4, r5, r6, r7, r8, r9, r10, r11, sp, lr}\n"
  " ldmia r0!, {r4, r5, r6, r7, r8, r9, r10, r11, sp, pc}\n"
  );
  +#endif /defined(thumb2)/

/* ASM */
void co_switch_arm(cothread_t handle, cothread_t current);

Using D54250WYK nuc box (intel iris HD 5000 gfx hardware).

I'm using ubuntu 16.04.01 and RetroPie 4.1 (freshly built yesterday)

Here's the bactkrace, hope it can be of use:

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffe0de1700 (LWP 23800)]
0x0000000000000000 in ?? ()
(gdb) bt full
#0  0x0000000000000000 in ?? ()
No symbol table info available.
#1  0x00000000004f8572 in rglgen_resolve_symbols_custom (map=0x60c840 <rglgen_symbol_map>, proc=0x0)
    at libretro-common/glsym/rglgen.c:34
        func = <optimized out>
#2  rglgen_resolve_symbols (proc=0x0) at libretro-common/glsym/rglgen.c:41
No locals.
#3  0x00000000004f2e6d in gl_init (video=0x8eeea0, input=0x874048 <current_input>,
    input_data=0x874040 <current_input_data>) at gfx/drivers/gl.c:1923
        mode = {width = 320, height = 240, fullscreen = true}
        inp = {input = 0x0, input_data = 0x0}
        interval = 1
        mip_level = 0
        full_x = <optimized out>
        full_y = <optimized out>
        shader_filter = {index = 0, smooth = 0x0}
        shader_info = {set_active = false, num = 0, idx = 0, data = 0x0}
        ident_info = {ident = 0x0}
        wrap_info = {idx = 0, type = RARCH_WRAP_BORDER}
        win_width = <optimized out>
        win_height = <optimized out>
        temp_width = 0
        temp_height = 0
        force_smooth = false
        vendor = 0x0
        renderer = 0x0
        version = 0x0
        hwr = 0x0
        error_string = 0x0
        gl = 0x7fffdc0008c0
#4  0x00000000004df4bd in video_thread_handle_packet (incoming=0x7fffe0de0a20, thr=0x8eee80)
    at gfx/video_thread_wrapper.c:342
        i = <optimized out>
        pkt = {type = CMD_INIT, data = {b = false, i = 0, f = 0, str = 0x0, v = 0x0, set_shader = {
              type = RARCH_SHADER_NONE, path = 0x0}, set_viewport = {width = 0, height = 0, force_full = false,
              allow_rotate = false}, rect = {index = 0, x = 0, y = 0, w = 0, h = 0}, image = {data = 0x0, num = 0},
            output = {width = 0, height = 0}, new_mode = {width = 0, height = 0, fullscreen = false}, filtering = {
              index = 0, smooth = false}, osd_message = {msg = '\000' <repeats 254 times>, params = {x = 0, y = 0,
                scale = 0, drop_mod = 0, drop_x = 0, drop_y = 0, drop_alpha = 0, color = 0, full_screen = false,
                text_align = TEXT_ALIGN_LEFT}}, custom_command = {method = 0x0, data = 0x0, return_value = 0},
            font_init = {method = 0x0, font_driver = 0x0, font_handle = 0x0, video_data = 0x0, font_path = 0x0,
              font_size = 0, return_value = false, api = FONT_DRIVER_RENDER_DONT_CARE}}}
        ret = false
#5  video_thread_loop (data=0x8eee80) at gfx/video_thread_wrapper.c:591
        pkt = {type = CMD_INIT, data = {b = false, i = 0, f = 0, str = 0x0, v = 0x0, set_shader = {
              type = RARCH_SHADER_NONE, path = 0x0}, set_viewport = {width = 0, height = 0, force_full = false,
              allow_rotate = false}, rect = {index = 0, x = 0, y = 0, w = 0, h = 0}, image = {data = 0x0, num = 0},
            output = {width = 0, height = 0}, new_mode = {width = 0, height = 0, fullscreen = false}, filtering = {
              index = 0, smooth = false}, osd_message = {msg = '\000' <repeats 254 times>, params = {x = 0, y = 0,
                scale = 0, drop_mod = 0, drop_x = 0, drop_y = 0, drop_alpha = 0, color = 0, full_screen = false,
                text_align = TEXT_ALIGN_LEFT}}, custom_command = {method = 0x0, data = 0x0, return_value = 0},
            font_init = {method = 0x0, font_driver = 0x0, font_handle = 0x0, video_data = 0x0, font_path = 0x0,
              font_size = 0, return_value = false, api = FONT_DRIVER_RENDER_DONT_CARE}}}
        updated = <optimized out>
        thr = 0x8eee80
#6  0x00000000004dc9cf in thread_wrap (data_=0x8d98a0) at libretro-common/rthreads/rthreads.c:105
        data = 0x8d98a0
#7  0x00007ffff74696ba in start_thread (arg=0x7fffe0de1700) at pthread_create.c:333
        __res = <optimized out>
        pd = 0x7fffe0de1700
        now = <optimized out>
---Type <return> to continue, or q <return> to quit---
        unwind_buf = {cancel_jmp_buf = {{jmp_buf = {140736966039296, 503386055352764156, 1, 140737488340175,
                140736966040000, 8863808, -503379172028070148, -503404258749200644}, mask_was_saved = 0}}, priv = {
            pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}}
        not_first_call = <optimized out>
        pagesize_m1 = <optimized out>
        sp = <optimized out>
        freesize = <optimized out>
        __PRETTY_FUNCTION__ = "start_thread"
#8  0x00007ffff168f82d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109
No locals.
(gdb)

Original post by @leiradel:

"My problem with the mixer was that I couldn't decide how to store PCM data in memory. The problem is that the data comes in 16-bit signed integers, the resampler wants floats, the mixer wants 16-bit signed integers (I'm not sure about this one), and the audio sample rate can change at any time (as I was told at the dev channel.)

So if I keep audio data as int16_t, I'll need to convert to float and resample every time a sound is played. I can convert to float only once and resample every time, but then we'll need twice the memory for audio data. I wanted to get away with resampling every time, but then I'd need to keep the original data around so if the sample rate changes I could resample to the new rate."

Issue resolved. libretro_directory cfg param needs to be set to the exact directory the plugin is being run from, or RetroArch will fail to detect the features of the plugin correctly and will disable all state functionality. I was running some plugins from different directories than the system one, and plugins that were installed to the system directory were being scanned instead of the ones I was running, creating all sorts of strange behavior.

Some platforms support microphone input devices, the most well-known being the original Famicom controller. Emulators currently handle it via button presses, but true audio input could be made available through the API, which would allow emulators to at least implement some basic processing without having to handle capture themselves.

My initial thought is to simply provide raw audio frames with metadata (number of channels, frequency range, depth, etc.). Alternatively, resample/normalize input and provide data in a simpler representation, e.g. amplitude mean and extrema for each frame. I would like to open a discussion with this issue.

<Autechre> if we do add it hough
<Autechre> it has to become a Privacy feature
<Autechre> that people have to give permission to

This description has one too many *:
libretro.h

#define RETRO_ENVIRONMENT_GET_MIDI_INTERFACE (48 | RETRO_ENVIRONMENT_EXPERIMENTAL)
                                           /* struct retro_midi_interface ** --
                                            * Returns a MIDI interface that can be used for raw data I/O.
                                            */

In the actual implementation, it's a pointer to a struct that you must provide, which it will fill in. See: runloop.c

The MIDI example also helps make this clear: libretro.c

The description should also not say that it returns an interface, since it is filling out the struct you provide.

When trying to use the --max-frames-ss option in RetroArch, the screenshot never gets taken because of a reported error in RPNG:

[INFO] Taking a screenshot before exiting...
[RPNG]: Error in line 237.
[ERROR] Could not take a screenshot before exiting.

That line doesn't look particularly exciting.

Happens in the latest nightly as of the time of this writing (11/7/2018)

DEATH released his modifications & optimizations for the resampler.

Includes optimizations for the SSE resampler, as well as NEON.

https://www.foobar2000.org/sinc-resampler

I am somewhat confused by the VFS API.

With VFS, is it implied that CDROMs are selected to be accessed, like say if a user selects a CDROM, It is then read by the active callbacks as the current CDROM in the "drive" is accessed.

I could implement this by CD/DVD/Bluray drive emulation directly in my frontend as image file reading I suppose, so a selected CD "drive" is a CD/DVD/Bluray image file. Would need to then research into ISO/NRG/Alcohol/CHD/RVZ/etc image reading I suppose! (which certainly isn't a problem, I am just wondering how the VFS API for CDROMs work)

pwd

../libretro-common-master/samples/net

franck-mac-book-air:net franck$ make DEBUG=1
cc -I../../include ../../net/net_http.c -c -O0 -g -Wall -pedantic -std=gnu99 -o ../../net/net_http.o
cc -I../../include ../../net/net_compat.c -c -O0 -g -Wall -pedantic -std=gnu99 -o ../../net/net_compat.o
cc -I../../include ../../net/net_socket.c -c -O0 -g -Wall -pedantic -std=gnu99 -o ../../net/net_socket.o
cc -I../../include ../../compat/compat_strl.c -c -O0 -g -Wall -pedantic -std=gnu99 -o ../../compat/compat_strl.o
cc -I../../include ../../encodings/encoding_utf.c -c -O0 -g -Wall -pedantic -std=gnu99 -o ../../encodings/encoding_utf.o
cc -I../../include ../../string/stdstring.c -c -O0 -g -Wall -pedantic -std=gnu99 -o ../../string/stdstring.o
cc -I../../include net_http_test.c -c -O0 -g -Wall -pedantic -std=gnu99 -o net_http_test.o
net_http_test.c:40:25: warning: incompatible pointer types passing 'char [89]'
to parameter of type 'struct http_connection_t *'
[-Wincompatible-pointer-types]
..."http://buildbot.libretro.com/nightly/windows/x86_64/latest/mednafen_psx_libretro.dll.zip");
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../../include/net/net_http.h:47:55: note: passing argument to parameter 'conn'
here
struct http_t *net_http_new(struct http_connection_t *conn);
^
net_http_test.c:45:25: warning: incompatible pointer types passing 'char [26]'
to parameter of type 'struct http_connection_t *'
[-Wincompatible-pointer-types]
http3 = net_http_new("http://www.wikipedia.org/");
^~~~~~~~~~~~~~~~~~~~~~~~~~~
../../include/net/net_http.h:47:55: note: passing argument to parameter 'conn'
here
struct http_t *net_http_new(struct http_connection_t *conn);
^
2 warnings generated.
cc -I../../include ../../net/net_http.o ../../net/net_compat.o ../../net/net_socket.o ../../compat/compat_strl.o ../../encodings/encoding_utf.o ../../string/stdstring.o net_http_test.o -O0 -g -Wall -pedantic -std=gnu99 -o http_test
cc -I../../include ../../net/net_ifinfo.c -c -O0 -g -Wall -pedantic -std=gnu99 -o ../../net/net_ifinfo.o
cc -I../../include net_ifinfo_test.c -c -O0 -g -Wall -pedantic -std=gnu99 -o net_ifinfo_test.o
cc -I../../include ../../net/net_ifinfo.o net_ifinfo_test.o -O0 -g -Wall -pedantic -std=gnu99 -o net_ifinfo
franck-mac-book-air:net franck$ ./http_test
Segmentation fault: 11
franck-mac-book-air:net franck$ lldb ./http_test
(lldb) target create "./http_test"
Traceback (most recent call last):
File "", line 1, in
File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/copy.py", line 52, in
import weakref
File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/weakref.py", line 14, in
from _weakref import (
ImportError: cannot import name _remove_dead_weakref
Current executable set to './http_test' (x86_64).
(lldb) run
Process 28269 launched: './http_test' (x86_64)
Process 28269 stopped

• thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=EXC_I386_GPFLT)
  frame #0: 0x00007fff6aadca76 libsystem_info.dylibsi_addrinfo + 182 libsystem_info.dylibsi_addrinfo:
  -> 0x7fff6aadca76 <+182>: movsbl (%rax), %ecx
  0x7fff6aadca79 <+185>: cmpl $0x0, %ecx
  0x7fff6aadca7c <+188>: jne 0x7fff6aadca8a ; <+202>
  0x7fff6aadca82 <+194>: movq $0x0, -0x20(%rbp)
  Target 0: (http_test) stopped.
  (lldb)

Hi, sorry if this comes across badly but I wanted to share my negative experience of using the RETRO_DEVICE_LIGHTGUN API while adding lightgun support to the Saturn and PlayStation cores - my hope is we can improve it. I was unable to use it to support the guns on these cores and had to misuse other APIs to get the result I wanted.

My main problems were:

1. The RETRO_DEVICE_ID_LIGHTGUN_X/Y position values are relative, like a mouse - this seems at odds with how CRT lightgun technology works (and therefore naturally not suited as inputs to systems designed when CRTs were in use). The cores I was working with were expecting an absolute screen position as input - presumably something out there uses deltas?

Fortunately I was able to use the RETRO_DEVICE_ID_POINTER_X/Y instead - but this isn't what it was designed for and presumably a front-end could elect not to provide input on that channel? I'd suggest we add RETRO_DEVICE_ID_LIGHTGUN_SCREEN_X/Y and implement it in the same way as the pointer API.

2. The API is missing 'id values' for generic auxiliary controls e.g. Guncon has A, B action buttons, Justifier has a single Aux button, GunCon2 also has a d-pad. These will also need to be remappable.

This should be easy to fix -- just adding a few more constants, eg.

#define RETRO_DEVICE_ID_LIGHTGUN_DPAD_UP
#define RETRO_DEVICE_ID_LIGHTGUN_DPAD_DOWN
#define RETRO_DEVICE_ID_LIGHTGUN_DPAD_LEFT
#define RETRO_DEVICE_ID_LIGHTGUN_DPAD_RIGHT

#define RETRO_DEVICE_ID_LIGHTGUN_AUX1
#define RETRO_DEVICE_ID_LIGHTGUN_AUX2
#define RETRO_DEVICE_ID_LIGHTGUN_AUX3
#define RETRO_DEVICE_ID_LIGHTGUN_AUX4

3. In RetroArch there's no way to remap the mouse buttons used to generate the action inputs (trigger, start, pause, ...), or to assign joypad or keyboard controls to these actions. In the PSX/Saturn cores I had to use the mouse API to read buttons directly and provide suitable mappings and options at the core level. Again, misusing an API as a work-around and doing work the front-end should be responsible for.

Hope I've not come across negative with this - but imho the lightgun API needs work. I'm hoping it's not too late to do something about this and get the ball rolling to improve it for all cores - I don't think it's far off. I'd be interested to know if other cores are also using work-arounds? and what their experiences were in doing so. It would be a shame to hold off from 'breaking' an API that no-one is actually using.

One of my first contributions to RA was the code that converts from 'special' characters to the underscore (_) per No-Intro filename standards.

It came up in Discord #programming that cores don't necessarily have this kind of protection against cross-platform filename issues.

If it seems appropriate, I would be glad to contribute that code as a function in file_path (https://github.com/libretro/libretro-common/blob/master/include/file/file_path.h) to make it one step easier for cores to standardize on this method of sanitizing paths and filenames if they choose.

Currently RetroArch can document the various options in both sub-labels and help messages (Select / Shift) and these can be very helpful. However it would be great if these could also used by the cores for their own core options found in the quick menu. At the very least this would be strongly desirable for GLupeN64 where @loganmc10 will no longer have to use the github wiki for that which many users may not ever see. Though there is no reason it could not be used to great effect by any other core with core options.

https://github.com/GLupeN64/GLupeN64/wiki/Core-Options

I am getting GL_INVALID_ENUM with these 2 sections of code:

https://github.com/libretro/libretro-common/blob/master/glsm/glsm.c#L1981-L1985

https://github.com/libretro/libretro-common/blob/master/glsm/glsm.c#L2038-L2042

Right now MAX_TEXTURE is hardcoded to 32, but it can vary from platform to platform, the max value is actually the value of GL_MAX_COMBINED_TEXTURE_IMAGE_UNITS minus 1 according to:

https://www.opengl.org/sdk/docs/man/docbook4/xhtml/glActiveTexture.xml

Which can be retrieved by doing something like this:

int MAX_TEXTURE;
glGetIntegerv(GL_MAX_COMBINED_TEXTURE_IMAGE_UNITS, &MAX_TEXTURE);

The code in audio_mixer.c crashes if the input file samplerate matches the mixer samplerate.
This is because the resampler instance isn't created, thus there is a null function pointer.

This is easily reproduced using any 441khz Vorbis file and running the mixer at the same samplerate.

This is seen at the following points:
https://github.com/libretro/libretro-common/blob/master/audio/audio_mixer.c#L429
https://github.com/libretro/libretro-common/blob/master/audio/audio_mixer.c#L707

It would be nice to have a core option to allow switching on and off audio channels in mGBA. This feature exists in the standalone Windows build.

RETRO_ENVIRONMENT_SET_SERIALIZATION_QUIRKS and RETRO_ENVIRONMENT_SET_HW_SHARED_CONTEXT share the same id of 44.

I noticed the semaphore implementation using rthreads is under a GPL license.

Is there any alternatives to GPL?

Implement the (optional) capability for cores to display in pseudo wide-screen.

I'm assuming that a core would need to be updated to specifically support this capability - but that libretro would abstract as much as possible.

Description and source code can be found at https://kzone.winosx.com/posts/widegb-playing-game-boy-games-on-wide-screens/

I'm writing a core with libretro and get a deadlock following the document/header file. After doing some trace I found retro_frame_time_callback_t is not called before first retro_run().

It will be called right before retro_run() every frame.

I found a strange repeatable bug.
Found in Ys games. Easiest one to replicate it in is YSIV english translate.
Libretro/retroarch: all latest cores etc. Nothing beta.
System: Win10pro 64bit, latest updates
Only weird things about this system: it has a projector instead of screen. my roms are on a "storage pool", which I think is RAID5?

To replicate:
Play the game for a bit. Save it a few times in different slots.
Exit the game/libretro.
Load the game back up, you will see your saved games.
Play the game more. Save in some other slots or over your current slots.
Turn your monitor off. and/or let the computer go to sleep (I did not do the later). However, the platter hard drive (non SSD) did sit long enough to stop spinning?
Come back to your game, it will be frozen.
You will be forced to stop the application.
After you load it back up, your original saved games will be there. But your new saved games won't be.

I'm wondering if they don't immediately get saved to disk and were still memory resident only?

Hi team. Please be aware that WiiU Retroarch suffers from slow SD file access when loading cores and/or roms.

For instance : -with everything installed on SD card: launching Retroarch takes almost 30 seconds, loading a big rom (>20 MB) takes almost 20s.
-When using the vWii version (Retroarch-Wii), with everything installed on FAT32 USB : launching Retroarch takes less than 7s, loading the same rom takes less than 6s...

So it may be suggested to create a USB installable RA for the Wii U.
Thanks very much.

Proposal

It would be great if we had two new environment commands: RETRO_ENVIRONMENT_GET_RENDERED_HEIGHT and RETRO_ENVIRONMENT_GET_RENDERED_ASPECT_RATIO.
These would allow hardware rendered cores like N64, PlayStation, Wii emulators to output at the window's resolution!
Owners of ultrawide, ultra HD monitors get to use the aspect ratio and/or resolutions of their amazing screens.
Standalone emulators have these features and they're missing in RetroArch.

RETRO_ENVIRONMENT_GET_RENDERED_HEIGHT - Gets the window height that can be overridden by the frontend
RETRO_ENVIRONMENT_GET_RENDERED_ASPECT_RATIO - Gets the aspect ratio of the window that can be overridden by the frontend

Examples

ParaLLEl N64 can have a resolution option: "Auto" to render at the frontend-provided resolution. It would calculate the width based on the height and aspect ratio of the game.
Dolphin has options to render at a custom aspect ratio and pixel height in the standalone emulator. In this case the core can have "Auto" core options for resolution and aspect ratio.

Proposed Definitions

#define RETRO_ENVIRONMENT_GET_RENDERED_HEIGHT (61 | RETRO_ENVIRONMENT_EXPERIMENTAL)
                                            /* unsigned * --
                                            * Integer value that lets us know the height of the window.
                                            *
                                            * The returned value can be used by cores to automatically
                                            * scale the resolution how it sees fit.
                                            *
                                            * The returned value can be NULL. In this case the core should
                                            * use a sane default (i.e. native resolution in an emulator).
                                            *
                                            * A frontend could override this if desired.
                                            */
#define RETRO_ENVIRONMENT_GET_RENDERED_ASPECT_RATIO (62 | RETRO_ENVIRONMENT_EXPERIMENTAL)
                                            /* float * --
                                            * Float value that lets us know the aspect ratio of the window.
                                            *
                                            * The returned value can be used by cores as a suggestion
                                            * for scaling.
                                            *
                                            * The returned value can be NULL.
                                            *
                                            * A frontend could override this if desired.
                                            */

Unresolved Questions

• Is rendered a good word for it? Maybe screen, window... the values can be overridden, and the doc comments should reflect that.
• Would it be better to tackle #41 first? I don't think so.
• Does this make the existing core options for resolution (and possibly aspect ratio) pointless? The frontend would be able to provide it, and emulators can set a core option for the native resolution if necessary.
• Should we concern about rotation? I don't think so if the core needs to set it, and if RetroArch's Aspect Ratio override doesn't care either.
• What settings would RetroArch have to override this? Can we use the Aspect Ratio setting, or do we need a new one? The setting for resolution could have values like Window Height (default), Window Height / 2, Core provided (would give NULL making it up to the core to figure it out, like by giving a native resolution).
• Is the formatting in my proposed definitions correct? Does the explanation for the aspect ratio command suffice?
• Do we need some sort of callback for when the window size changes? Or does it suffice to check if the current size is different from the previous... or something. Something convenient.

In libretro/fbalpha@df22096 i had to disable file_stream_transform for src/burner/libretro/retro_cdemu.cpp, that's the file for neocd iso operation, it uses fopen/fseek/fclose/fread/ftell/fgets, i couldn't determine which one but one of those drop-in replacement from file_stream_transform is not working as it should because if i enable this stuff, cdda playback is totally messed up.

Steps to reproduce :

1. remove the hack in makefile.libretro (see my commit)
2. build the core
3. try to play a neocd game (NB : some neocd games don't have cdda)

These items:

https://github.com/libretro/libretro-common/blob/master/include/glsm/glsmsym.h#L397
https://github.com/libretro/libretro-common/blob/master/glsm/glsm.c#L1825-L1830

Should not apply to GLES2, you get an error when compiling, because GLuint64 is not valid for GLES2

This issue is triggered by parallel-n64 with FORCE_GLES=1 on Linux. Please see issue libretro/parallel-n64#557.

However the point of failure is in libretro-common and I think this issue is also relevant here. Basically after mesa commit https://github.com/mesa3d/mesa/commit/f7d42ee7d319256608ad60778f6787c140badada it now contains the following typedef in include/GLES2/gl2ext.h.

typedef double GLdouble;

https://github.com/mesa3d/mesa/blob/3b2ad8b290215a4bd52be4e397c9ab5603b8b372/include/GLES2/gl2ext.h#L2947

While libretro-common contains the conflicting typedef in include/glsm/glsm.h.

And then includes GLES2/gl2ext.h in include/glsym/rglgen_headers.h.

This is not valid and will cause build issues.

In file included from ./libretro-common/include/glsm/glsmsym.h:26,
                 from mupen64plus-core/src/api/vidext_libretro.c:41:
./libretro-common/include/glsm/glsm.h:35:17: error: conflicting types for ‘GLdouble’
 typedef GLfloat GLdouble;
                 ^~~~~~~~
In file included from ./libretro-common/include/glsym/rglgen_headers.h:56,
                 from ./libretro-common/include/glsm/glsm.h:30,
                 from ./libretro-common/include/glsm/glsmsym.h:26,
                 from mupen64plus-core/src/api/vidext_libretro.c:41:
/usr/include/GLES2/gl2ext.h:2947:16: note: previous declaration of ‘GLdouble’ was here
 typedef double GLdouble;
                ^~~~~~~~
make: *** [Makefile:932: mupen64plus-core/src/api/vidext_libretro.o] Error 1

Removing the typedef from libretro-common will work, but I am not sure what if any issues that will cause with older mesa releases or other platforms.

Alternatively this patch can be used, but I am also not sure about the negative consequences.

diff --git a/libretro-common/include/glsym/rglgen_headers.h b/libretro-common/include/glsym/rglgen_headers.h
index 766efb63..3de538d6 100644
--- a/libretro-common/include/glsym/rglgen_headers.h
+++ b/libretro-common/include/glsym/rglgen_headers.h
@@ -53,6 +53,7 @@
 #include <GLES2/gl2ext.h>
 #elif defined(HAVE_OPENGLES2)
 #include <GLES2/gl2.h>
+#define GL_NV_path_rendering
 #include <GLES2/gl2ext.h>
 #elif defined(HAVE_OPENGLES1)
 #include <GLES/gl.h>

Or maybe the headers can be rearranged in a way to avoid this?

This breaks libretro-uae (Amiga PUAE core) compilation if I update libco to latest version in that core. It compiles fine if I change asm to __asm__ which is what it used to be:

Hi, this is a design/specification (and request for comments) for an enhanced drive API for LibRetro cores.

The current LibRetro API defines a single anonymous drive. While this is sufficient for consoles like the PlayStation, it is not suitable for describing the more complex and varied configurations of home computer systems such as the C64, Apple ][ and Amiga, etc.

This new API introduces a mechanism for cores to tell the front-end about an arbitrary number of independent "drives" each with additional meta-data to both identify the drive with a system specific name (e.g. "DF0") and generally describe the kind of drive (e.g. 3.5" floppy, DVD drive, etc.) to allow for correct iconography and terminology such as disk/disc, etc. Also with an API to control the state of the drive and to request content data be loaded into it.

The API is a recognisable mix of the controller API and existing disk control interface.

Drive

A drive is the generic name used to describe any media storage device that can be loaded with content stored on the host computer in a core-specific or standardised image file format.

A drive can represent a wide range of devices such as a tape cassette, floppy disk, hard disk, ROM cartridge, memory stick, etc.

A drive can accept only one content file at a time. It is the front-end's responsibility to implement "CD multi-changer" functionality for multiple disk titles.

The core provides a list of acceptable content file extensions on a per-drive basis to allow for mixed media support (e.g. .TAP files limited to just the cassette drive).

Drive States

A drive can be in one of the following 6 states.

RETRO_DRIVE_STATE_INVALID,
The drive does not exist, the index used to specify it is invalid.

RETRO_DRIVE_STATE_CLOSED,
The drive is connected but empty and also unavailable for new content to be loaded. The simulated drive mechanism (e.g. CD tray, cassette door, etc.) is considered to be closed/locked in this state. Requesting a RETRO_DRIVE_STATE_OPEN state may allow content to be loaded if the core permits it. This state allows the core to forbid media insertion on this drive. This is the recommended default state for drives on start-up.

RETRO_DRIVE_STATE_OPEN,
The drive is empty and available for new content to be loaded. The simulated drive mechanism (e.g. CD tray, cassette door, etc.) is considered to be open/unlocked in this state.

RETRO_DRIVE_STATE_LOADED,
The drive has content loaded into it and is operating correctly, able to read and/or write data as the core decides. This state is typically set by the core automatically after a call to the retro_drive_load_content function. The front-end must maintain a consistent pointer to any allocated memory for content supplied via an in-memory buffer.

RETRO_DRIVE_STATE_REMOVED,
The drive has been physically disconnected from the system. It is not available for content to be loaded and cannot be accessed by the core. It is implied that the removal of the drive has also emptied it of any media/content. This drive can be hidden by the front-end until potentially re-instated via a state change to RETRO_DRIVE_STATE_OPEN or RETRO_DRIVE_STATE_EMPTY.

RETRO_DRIVE_STATE_ERROR,
The drive has failed but is in a recoverable error state. This state is for use by the core to report when invalid data has been encountered such as a bad sector, or a host file error has occurred. This condition can be addressed by requesting a RETRO_DRIVE_STATE_OPEN or RETRO_DRIVE_STATE_REMOVED state transition.

Note that some states are not permitted for certain drive types, the core determines whether a requested state transition is permitted and has the final say on which states are used / reported to the front-end. Drive state should not be assumed by the front-end.

Drive API

struct retro_drive_description
{
   const char* desc;

/* [OPTIONAL] Short core specific identifier for the drive for human presentation.
A system without a named drive (such as a PlayStation) should use NULL.
e.g. a DOS machine might use "A:" for a floppy drive. The core is required to keep this pointer valid
while loaded or until a new retro_drive_description array is submitted to the front-end.
*/

   unsigned media_id;

/* Describes the kind of drive and media this drive accepts for human usage. Used to allow the front-end to describe it more accurately. For example being able to use disk or disc correctly, or to draw a suitable icon in a menu.
The value is specified as a main type in the low byte and a sub-type in the high byte. A sub-type of 0 mean generic or not-applicable. Main and sub types are given below as RETRO_MEDIA_xxx constant definitions.
For sub-types that are super-sets of lesser types, specify the maximum supported or most common media type - e.g. A PlayStation 2 would specify RETRO_MEDIA_DISK_DVD even though it can also accept CDs. */

   const char* valid_extensions;

/* Same definition as retro_get_system_info(). */

}

A structure describing a single drive in the system.

Media class constants

#define RETRO_MEDIA_CLASS_SHIFT            8
#define RETRO_MEDIA_CLASS_MASK             ((1 << RETRO_MEDIA_CLASS_SHIFT) - 1)

/* media classes */

#define RETRO_MEDIA_GENERIC                0
#define RETRO_MEDIA_CASSETTE               1
#define RETRO_MEDIA_FLOPPY                 2
#define RETRO_MEDIA_DISC                   3
#define RETRO_MEDIA_HDD                    4
#define RETRO_MEDIA_CARTRIDGE              5
#define RETRO_MEDIA_CARD                   6

/* media sub-classes */

#define RETRO_MEDIA_FLOPPY_8                (( 1 ) << RETRO_DEVICE_TYPE_SHIFT)
#define RETRO_MEDIA_FLOPPY_5_1_4            (( 2 ) << RETRO_DEVICE_TYPE_SHIFT)
#define RETRO_MEDIA_FLOPPY_3                (( 3 ) << RETRO_DEVICE_TYPE_SHIFT)
#define RETRO_MEDIA_FLOPPY_3_5              (( 4 ) << RETRO_DEVICE_TYPE_SHIFT)
#define RETRO_MEDIA_FLOPPY_NINTENDO_FDS     (( 5 ) << RETRO_DEVICE_TYPE_SHIFT)

#define RETRO_MEDIA_DISC_LASER              (( 1 ) << RETRO_DEVICE_TYPE_SHIFT)
#define RETRO_MEDIA_DISC_CD                 (( 2 ) << RETRO_DEVICE_TYPE_SHIFT)
#define RETRO_MEDIA_DISC_GDROM              (( 3 ) << RETRO_DEVICE_TYPE_SHIFT)
#define RETRO_MEDIA_DISC_DVD                (( 4 ) << RETRO_DEVICE_TYPE_SHIFT)
#define RETRO_MEDIA_DISC_MINI_DVD           (( 5 ) << RETRO_DEVICE_TYPE_SHIFT)
#define RETRO_MEDIA_DISC_HD_DVD             (( 6 ) << RETRO_DEVICE_TYPE_SHIFT)
#define RETRO_MEDIA_DISC_BLURAY             (( 7 ) << RETRO_DEVICE_TYPE_SHIFT)

#define RETRO_MEDIA_HDD_IDE                 (( 1 ) << RETRO_DEVICE_TYPE_SHIFT)
#define RETRO_MEDIA_HDD_SCSI                (( 2 ) << RETRO_DEVICE_TYPE_SHIFT)
#define RETRO_MEDIA_HDD_ACSI                (( 3 ) << RETRO_DEVICE_TYPE_SHIFT)

#define RETRO_MEDIA_CARD_SD                 (( 1 ) << RETRO_DEVICE_TYPE_SHIFT)
#define RETRO_MEDIA_CARD_SEGA_MYCARD        (( 2 ) << RETRO_DEVICE_TYPE_SHIFT)
#define RETRO_MEDIA_CARD_HUCARD             (( 3 ) << RETRO_DEVICE_TYPE_SHIFT)

struct retro_drive_info
{
   const struct retro_drive_description *drives;
   unsigned num_drives;
};

A container structure similar to struct retro_controller_info

#define RETRO_ENVIRONMENT_SET_DRIVE_INFO

Used to specify a pointer to a retro_drive_info structure

typedef unsigned (RETRO_CALLCONV * retro_drive_get_state_t)(unsigned drive_index);

/* Returns a RETRO_DRIVE_STATE_xxx value for the drive.
drive_index is the logical index from the retro_drive_info array.
Invalid indices should return RETRO_DRIVE_STATE_INVALID */

typedef bool (RETRO_CALLCONV * retro_drive_request_state_t)(unsigned drive_index, unsigned state);

/* Request a state transition for this drive, returns true if successful.
The core is free to ignore any state request. */

typedef bool (RETRO_CALLCONV * retro_drive_load_content_t)(unsigned drive_index, struct retro_game_info* content);

/* Submit content for the given drive index. Returns true if successful, however the front-end should check for RETRO_DRIVE_STATE_ERROR for subsequent errors during execution.
For data buffers, the core should NOT take ownership of the given pointer. The F-E should check for a state being other than RETRO_DRIVE_STATE_LOADED before freeing this memory. */

struct retro_drive_control_callback
{
   retro_drive_request_state_t request_state;
   retro_drive_get_state_t get_drive_state;
   retro_drive_load_content_t load_content;
};

A structure to contain the control callback function pointers.

#define RETRO_ENVIRONMENT_SET_DRIVE_CONTROL_INTERFACE

Used to specify a pointer to a retro_drive_control structure.

In the Desmume Core repository, a limitation concerning the framebuffer was discussed.
libretro/desmume#30

For some cases it is useful to have a second framebuffer which only affects regions of the screen.
The Desmume Case is one example. However more cases are upcoming which more or less will require a second framebuffer. Especially due to Subsystem support, which was introduced in the latest main release, a second framebuffer could be helpful to display systems differently.
Cases are for example:
Nintendo DS - Desmume - Hybrid Mode (as the link already shows)
Nintendo 3DS - Citra - Hybrid Mode
Gameboy/Gameboy Advance - VBA-M/mGBA - Multiplayer
GameCube/Gameboy Advance Link - Dolphin/VBA-M/mGBA - Link Cable Connection
Dreamcast - Reicast - VMU Display
WiiU - CEMU (?) - Second Screen

Most likely there will be other use cases in which a second framebuffer is useful. Especially to render a "different" output at a certain region on the screen. or to display the output on two different screens.

I found a potential replacement for libco though I am not 100% sure as to the veracity of its claims:
https://github.com/hnes/libaco
Also found another library by Tencent:
https://github.com/Tencent/libco/tree/v1.0
and this:
https://github.com/heiher/hev-task-system

libaco claims to be the fastest cothread library, while also having support for saving/restoring MMX/SSE/AVX state on x86/x64, which iirc byuu's libco doesn't have. The changes compared to libco on resulting cores haven't been profiled, though personally I am quite intrigued in seeing if on bsnes-mercury it helps, if even minutely.

Earlier MSVCs are missing some math.h functions that other compilers have. There is already a #define for roundf in msvc.h that works around one of the missing round functions.

I thought I was going to need one or two more round functions so I drafted two additions, but it turns out I do not have a use case at the moment to test these with. For now I'm including the existing roundf define below for reference, along the two new drafts.

#define roundf(in) (in >= 0.0f ? floorf(in + 0.5f) : ceilf(in - 0.5f))
#define roundd(in) (in >= 0.0  ? floor(in + 0.5)   : ceil(in - 0.5))
#define roundl(in) (in >= 0.0  ? floor(in + 0.5)   : ceil(in - 0.5))

While there is this workaround :

It still doesn't seem path_mkdir works properly on wii u when there is a trailing slash (the workaround makes sense so i'm not sure what's the issue and i don't have the means to debug this myself, all i can do is to try fixing this by removing the trailing slash in libretro/FBNeo@5b472aa then libretro/FBNeo@eeaabd1)

I'm just leaving this here for tracking, in case I drop dead or something, not that im planning on it

https://sourceforge.net/p/desmume/code/5551/
https://sourceforge.net/p/desmume/bugs/1569/

RETRO_NUM_CORE_OPTION_VALUES_MAX is currently 128. That's slightly less than the number of RETROK_* . So not quit enough to expose all keys in mappers. The old API didn't have this restriction AFAIK.