libretro joypad testers needed.

[audetto]

I've re-written the joypad handling for the libretro core.

Best description is here

https://github.com/audetto/AppleWin/blob/master/source/frontends/libretro/README.md

Some questions:

1. paddle: not sure left - right / up - down is always the right way round. do we need some options to turn them around?
2. do we need some quick & common configurations of buttons to keys? WASD? Arrows?
3. should we default map useful keys like: ENTER, ESC, SPACE to some of the L/R buttons?

[audetto]

Everything else needs to be tested too...

[Jamirus238]

Hey, thanks for working on this. I could especially see 3. (ENTER,SPACE) and 2. (Arrows) be useful, but it's not really a must imho, as long as users can configure it by themselves.
Also, the Retroarch online core updater has an option to enable "experimental cores", I suppose you can make it available first through that?
As for actual testing, I'm not really a Linux guy (I do have a Mint installation though), can I try building the core according to the current instructions, ie. the new code is already included?

[audetto]

Everything is committed and works in Linux and mingw64 if you prefer it.

I could do:

• L = SPACE
• R = ENTER
• L2 = Left
• R2 = Right

If one uses the analog pad, the up/right/left/down buttons aren't used and are prime candidates for arrows.
But for a standard pad they are used for the paddles, so I wan't very sure.

Or I could enable to remap the right analog axis, and use that for arrows.

[Jamirus238]

Did a quick test. I did build the core and put it together with the info file into my Retroarch (app image) core folder.
It's possible to use "Start Core", but "load content" wasn't working because the core doesn't appear after picking a Apple dsk.file for me.
I thought this was related to the info file, but modifying it didn't remedy it.

[audetto]

Just tested and it works fine in mingw64.

I have never really understood how retroarch manages content, and what it recognises as such. If anyone knows how to configure it or where to find help, please do tell me.

Same goes for the exact role of the info file. What I know for sure, is that without it, save / load state does not work, but how content / core / file extensions work together is a mystery to me.

Meanwhile, you can execute it like this

retroarch -L path/to/applewin_libretro.dll path/to/the/disk

[Jamirus238]

Aha yes, it works via cli. I also realized you can associate stuff via playlists, doing a manual scan and setting file extensions.
However, I couldn't get my my m3u file recognized either way.
Controls seemed to work fine.
Savestates didn't work
Core resolution is set to 560x384. This is a problem for the shader system, ideally this should be changed to 560x192 and the "core provided" scaling setting sets a correct aspect ratio.
While looking for info about extensions, I came across this old link about core development, which lays out info about graphics and extensions in cores, maybe that helps
https://www.beardypig.com/2016/01/22/emulator-build-along-2/

[audetto]

valid_extensions is already populated

AppleWin/source/frontends/libretro/libretro.cpp

Line 186 in c25fd44

info->valid_extensions = "bin|do|dsk|nib|po|gz|woz|zip|2mg|2img|iie|apl|hdv|yaml|m3u";

I do not understand what is wrong with 560x384.

The link provided sets the aspect ratio to 330 / 410 which is the same as their base_width / base_height which is the default if the core does not set one.

AppleWin/source/frontends/libretro/libretro-common/include/libretro.h

Line 6273 in c25fd44

* an aspect ratio of <tt>base_width / base_height</tt> is assumed.

so I do not think I am doing anything different.

[Jamirus238]

I can elaborate a bit.

1. Resolution: 560x384 makes RA see it as an interlaced or high res progressive image. The Apple II was non-interlaced low res progressive (hence only 192). AppleWin simulates this with "half scanlines" setting. RA has it's own approach with much more sophisticated CRT-shaders. These expect a non-linedoubled image for the most part. However, there are ways around this and I'm not sure if at least parts of the AppleWin's composite emulation rely on linedoubling, so it's probably better to leave it as is for now.
2. Aspect ratio: The Vectrex is kinda of a bad example. Computers would ofc output to a TV/monitor, to achieve a more realistic ratio, dot clock rates can be taken into account.
   (https://pineight.com/mw/page/Dot_clock_rates.xhtml)
   This would result in taller image. Check this out:

However, advanced users can manually set the ratio in RA. The most important thing is getting content loading sorted out, I hope someone with actual RA coding experience offers help.

[audetto]

One thing I cannot do is to change the size of the video buffer: it is managed by AppleWin.

But, one can disable half scanlines (the is an option for this) and tell RetroArch that the aspect ratio is twice as big, and the RA adds its own version of that?

change to

info->geometry.aspect_ratio = 2.0 * float(info->geometry.base_width) / float(info->geometry.base_height);

If you find a better configuration, let me know.

[Jamirus238]

Yeah, you can disable the Applewin's own "scanlines" in the core options, but it's not a solution. You'll need to be familiar with the shader system to understand the problem. Just leave that as it for now, it's not a big deal.

[Jamirus238]

Loading content and m3u files work here for me (Windows build), but save states still won't, despite messages in RA appearing that it's supported for the core.
https://github.com/redenvelope2000/applewin_L2