Update Retroarch 1.7.3


b_o_b said:
Is the Hatari core working? I have placed the tos.img image in the system/bios directory but it crashes after selecting a rom.
I wanted to provide a better report, but I couldn't start Retroarch from command line after mounting the pnd and executing runscript.sh.
Click to expand...

I did test it, and yep, it tries to find tos in the wrong place, but it crashes with a Bus Error, don't know if it's related.
It's on my TODO list, so maybe you will see it as an update next time.

I did found some more that are slow and/or crash, and prone to be removed, but thankfully there's good subtitutes for them.

b_o_b said:
Not sure if this is expected behaviour, but retroarch.cfg file is wiped every time after removing the sd card with Retroarch from the pandora, reinserting the card and starting it again. Retroarch then crashes and the cfg file is present but empty (0 kb)
I am now shutting down the Pandora before removing the card.
Click to expand...

Can't replicate your problem.
Did you unmount before removing the card?

b_o_b said:
Just noticed a recent commit on github that mentioned the same error.
https://github.com/libretro/picodrive/commit/c7d7ac71a421c43c0c701b18c58b87fc868e02d8
Click to expand...

Noticed the same day it was posted and i did compile with armv flag, with all the extra flags from Codeblocks PND, works fine and no strange errors, so it will be on the next release, ;)

Thx for the feedback.
 
b_o_b said:
Is the Hatari core working? I have placed the tos.img image in the system/bios directory but it crashes after selecting a rom.
I wanted to provide a better report, but I couldn't start Retroarch from command line after mounting the pnd and executing runscript.sh.
Click to expand...
FWIW, you can get pretty good logs by looking in /tmp after running the pnd. They're called pndrun_[project name].out IIRC, and they contain the terminal log plus surrounding stuff from the pnd_run script.

Or you can run pnd_run yourself. That should mount the pnd and execute the runscript in the same way as double clicking it from the desktop menu, because that's what the .desktop files run. IIRC pnd_run is in your path.
 
canseco said:
Can't replicate your problem.
Did you unmount before removing the card?
Click to expand...

No I don't, you are probably right and I might need to wait a bit longer or unmount the card before removing. Will try unmounting, that seems to be the safest method.

Thanks, looking forward to the updates!

levi said:
FWIW, you can get pretty good logs by looking in /tmp after running the pnd. They're called pndrun_[project name].out IIRC, and they contain the terminal log plus surrounding stuff from the pnd_run script.

Or you can run pnd_run yourself. That should mount the pnd and execute the runscript in the same way as double clicking it from the desktop menu, because that's what the .desktop files run. IIRC pnd_run is in your path.
Click to expand...

Tried ./pnd_run.sh -p /retroach.pnd -m -> pnd was mounted
after that from /mnt/utmp/retroarch ./runscript.sh -> crashes retroarch

Will check /tmp next time for any log files and indeed starting pnd_run instead of ./pnd_run.sh mounts and executes the pnd. Will be helpful providing better bugreports - thx :)
 
Last edited:
Changelog

1.6.7.2

- Cores updated:

picodrive 9ae88ef
fbalpha b20cfd4
gw-libretro 7cafbf4
libretro-handy 420a16f
beetle-ngp-libretro 163fc92
libretro-fceumm 3cbd99e
nestopia 3eacbb2

- Cores removed:

hatari (Bus error, looks on the wrong place for tos)
meteor_libretro (segfault)
mednafen_gba_libretro (too slow)
mgba_libretro (segfault)
vba_next_libretro (too slow)
vbam_libretro (too slow)
 
1.6.7.3

- Cores updated:

beetle-ngp-libretro ab5d1d5
beetle-pce-fast-libretro d2080d7
Dinothawr 21adc38
fbalpha 1d0a61c
gw-libretro 068f600
Genesis-Plus-GX 7104058
libretro-fceumm d6df119
libretro-atari800 f892b44
mgba_libretro 49c9254
mrboom-libretro fca110d
nestopia 54f6d76
nxengine-libretro edc96c3
picodrive c3887ce
snes9x eb7cced
QuickNES_Core 7c0796d
pcsx_rearmed c7dde5e
px68k-libretro a272864
vice-libretro 8139feb

Removed:

mame, mame 2010, 2014 (too slow)

- Updated libs, SDL 2.0.7, libpng 1.6.34, etc.
 
Do you have your changes or sources up somewhere? I'd like to try building for Sailfish OS.
 
Changelog

1.6.9.0

- Updated to latest stable release.

- Cores updated:

bettle-pcfx 5331315
beetle-wswan-libretro ff4bbff
beetle-supergrafx-libretro c9634b2
fmsx-libretro 8ca1dca
gpsp dbb83e5
libretro-cap32 3e14ceb
libretro-gme 2d0fb4e
libretro-handy a4de67f
tgbdual-libretro a973b67
prosystem bdc2a82
xrick-libretro 2623032
scummvm e35edf9
[doublepost=1511394336,1511393964][/doublepost]
klapse said:
Do you have your changes or sources up somewhere? I'd like to try building for Sailfish OS.
Click to expand...

Didn't do any changes to the source code.
I compiled most of them with:

make platform="armv neon" or make platform="unix"

Thankfully ptitSeb Codeblocks PND command line CFLAGS and CXXFLAGS are already setup out of the box for OpenPandora.
 
Shenmue said:
Is there a way to make shaders work without causing massive slowdown? Overall, this is pretty good. Good job!
Click to expand...

There are some shaders made for Rasbperry Pi that could work, but depending on the emulator it could be too much.
 
Changelog

1.7.0.0

- Latest Retroarch stable release.
- More info: https://www.libretro.com/index.php/retroarch-1-7-0-released/

Updated cores:

scummvm 2.0.0 6345d9a
beetle-ngp-libretro d8145bd
beetle-pce-fast-libretro 3731ec9
beetle-wswan-libretro fd18010
bettle-pcfx 47240d7
beetle-supergrafx-libretro 9749ab8
Genesis-Plus-GX 69b2c0c
gw-libretro 8f054a1
libretro-fceumm 221c1fa
mgba_libretro 05e2ff4
mrboom-libretro def60c8
nestopia 754d283
prosystem 57c80cb
QuickNES_Core 58e77db

Added cores:

snes9x2010 48eebbb

Removed:

snes9x (too slow)
 
Last edited:
1.7.0.1

Updated:

beetle-ngp-libretro 024d3ec
beetle-pce-fast-libretro d4d6fea
bettle-pcfx 0c1c381
beetle-supergrafx-libretro 216a61a
beetle-wswan-libretro 3d6e700
fbalpha 529a485
fmsx-libretro 006d389
gpsp a00ccac
Dinothawr fbb3a75
Genesis-Plus-GX 7176e8a
mrboom-libretro e4c06f4
nestopia ef33882
nxengine-libretro 3826092
picodrive e768a4d
px68k-libretro 6029a45
QuickNES_Core 8c4f63a
vice-libretro 3f75f94
 
do any upscaling shaders run fast enough? (2xsai, hqx, scalefx, xbrz)?
 
Changelog

1.7.1.0
- Latest Retroarch stable release.
- Updated SDL 2.0.8 (thx to ptitSeb for updating his github repo so quickly) and SDL2 Image 2.0.3.
- Updated source code in src folder.
- More info: https://www.libretro.com/index.php/retroarch-1-7-1-released/

Updated:

Genesis-Plus-GX 0aa222e
GW (GameWatch) 9962b03
GME (Game Music Emulator) 111ca8f
FBAlpha (Arcade) e809986
FCEUMM (NES) 16170cd
MGBA b3c4ab2c
MRBoom (Game) 4.4 50ccc5b
Nestopia 5ecea44
Picodrive f5d7a8d
Snes9x2010 b9be098
TGB Dual (GB) bad6ae0
VICE 3.0 (C64) bea26

See changelog for more info:
https://www.libretro.com/index.php/retroarch-1-7-1-released/
 
Changelog

1.7.2.0
- Latest Retroarch stable release.
- This time using latest git gl4es release instead of GLES2 directly.
- Updated lots of cores, see list below.
- More info: https://www.libretro.com/index.php/retroarch-1-7-2-released/

Updated:
atari800 (Atari-5200) 01ac024
beetle-ngp (NeoGeo Pocket) b2b5c2c
beetle-pce-fast (PC Engine) 11f7aaa
bettle-pcfx 1767dd1 (PC-FX)
beetle-supergrafx (SuperGrafx) 022f188
beetle-wswan (Wonderswan) 4d702bc
cap32 (Amstrad CPC) 76529bd
Dinothawr 92431d1
Genesis-Plus-GX (Megadrive) 823e278
gpsp (GBA) 434612a
GME (Game Music Emulator) 7f7aa31
GW (GameWatch) ae06261
FBAlpha (Arcade) 08cf5c6
FCEUMM (NES) 82fd24e
fmsx (MSX1/2) d856a29
handy (Atari Lynx) 64e5f90
mgba (GBA) 9e02efe0
MRBoom 4.4 (Game) dc95890
Nestopia (NES) 4fceba0
nxengine (Cave Story) 32d68ce
Picodrive (Megadrive) eaac037
prosystem (Atari-5200) 360c65d
QuickNES_Core (NES) 6d50e29
Snes9x2010 (SNES) 443e3d1
TGB Dual (GB) fe5c3ff
VICE 3.0 (C64) bd62332c1
XRick 5d5baab
px68k (X68000) f69e15f
 
ptitSeb said:
Nice! did you try the runahead feature, on a NES game for example to keep system load reasonable?
Click to expand...

I tried the 3 NES emus i compiled, FCEUMM and QuickNES work fine with runahead activated, but Nestopia gets stuttering.
Still didn't tried different amount of frames ahead.
 
All software shaders will slow things down to some extent; I think all that apply in GL2.0 (which is closest to being fully emulated in Ptitseb's GL4ES I think) are pixel shaders and vertex shaders. Vertex shaders emulated as software will probably need to pull the vertices off the GPU, transform them then squirt them back, which might be quite costly I don't know. But in terms of emulators you'll probably be concentrating more on pixel shaders as they're the subset of 2D shaders for 2D consoles, and also includes basic 3D stuff like bump mapping, gouraud shading (including phong shading) and that kind of thing because while these are based on the 3D normal vertices, they only paint the final 2D pixels.

Basically you always need to intercept the GPU's transforms, yank data out and squirt is back all while doing the basic calculations needed to emulate the console in question - they're always likely to be relatively expensive, especially on an older CPU like the OMAP3 family in our Pandoras.
 
levi said:
All software shaders will slow things down to some extent; I think all that apply in GL2.0 (which is closest to being fully emulated in Ptitseb's GL4ES I think) are pixel shaders and vertex shaders. Vertex shaders emulated as software will probably need to pull the vertices off the GPU, transform them then squirt them back, which might be quite costly I don't know. But in terms of emulators you'll probably be concentrating more on pixel shaders as they're the subset of 2D shaders for 2D consoles, and also includes basic 3D stuff like bump mapping, gouraud shading (including phong shading) and that kind of thing because while these are based on the 3D normal vertices, they only paint the final 2D pixels.

Basically you always need to intercept the GPU's transforms, yank data out and squirt is back all while doing the basic calculations needed to emulate the console in question - they're always likely to be relatively expensive, especially on an older CPU like the OMAP3 family in our Pandoras.
Click to expand...
Vertex and Pixel shaders are computed on the GPU, not CPU (even with gl4es).
Vertex shader are probably not an issue here, there are very few vertexes... (like 4, or 6 :p)
Pixel shaders can, of course, be very demanding. It depends what you do, but, if you can, avoid "discard" as the OMAP doesn't like that much. Also, be aware that texture fetching is not super fast, so blur effect that tend to fetch 16 texel per pixel (or more) will be very slow...
 
Last edited:
You must log in or register to reply here.
Back
Top