Closed GoogleCodeExporter closed 8 years ago
Well, it does not happen for me so most likely the problem is on your side, not
mine, but with so few information, how would you expect anyone to help you or
figure anything, that's absurd.
Just make sure you are using IOS58 if you are using an USB drive to load CD
images (you can tell what IOS version is used in your Wii by entering the exit
sub-menu).
That's say, i am not even sure what you mean by AdvanceAA Shader. I can only
speak for the Wii port i am maintaing, other ports (made with retroarch) might
run slower depending on the platform, there is nothing i can do against that.
Original comment by ekeeke31@gmail.com
on 28 Jan 2013 at 2:59
hello,
I am using the retroarch ps3 port. Squarepusher told me to post the issue on
here
Original comment by jamalc...@gmail.com
on 28 Jan 2013 at 3:01
ok, i will try to explain you.
lag in emulation can be caused by two things: either 1) emulation is too slow
and eventually falls down the output framerate (frames are missed) or 2) it is
a synchronization problem between audio and video outputs(emulation desyncs
from one or another, which results in audio or video hichup)
Emulation synchronization with audio and video backend is the role of the
frontend (retroarch in that regard), the core only gives access to functions
that need to be called with proper sync to whatever timing base the target
hardware is using. On that regard, Genesis Plus GX (my Wii port) provides
perfect synchronization with audio AND video, and i can confirm it does not
miss or repeat a single frame EVER (tested during an hour with Sonic 2
interlaced mode which requires the emulator to swap rendered fields in sync
with Wii displayed fields).
Emulation speed is bound to target hardware as well, although i would expect
PS3 to be on par with Wii and again, i can tell you there is no lag or speed
issue with the Wii native port (and not even the Gamecube version I think,
although i can not confirm it). I don't know what options you have access to
with RetroArch PS3 but generally, disabling overscan and High-Quality FM can
help improve emulation speed. On that regard, i know that Retroarch by default
always resamples emulator audio output to desired output samplerate: the thing
is that the emulator core already does the same, which can be quite
inefficient. Setting config.hq_fm to 0 will select a faster (but less
quality-wise) resampling algorithm.
Sega CD emulation is already quite well optimized and there isn't much room for
improvment beside rewriting stuff in assembly and breaking portability, which i
do not want to do.
A major bottleneck with Sega CD emulation though is I/O access (access to your
harddrive or whatever is used to store CD image files). Since files
(datatrack, audio tracks) are accessed permanently and randomly by the
emulator(contrary to ROM files that can be stored for once in RAM), slow device
access can indeed ruin emulation speed and cause noticeable lags. Again,
nothing i can do about this, pretty much depends on every console hardware and
the library it uses to access files, as well as the storage device itself.
I hope you appreciate me taking some time to give you a detailled answer about
why those lags you are experiencing are not really my concern since they are
most likely not caused by the emulator core itself.
Original comment by ekeeke31@gmail.com
on 28 Jan 2013 at 7:49
Yes, your response is most appreciated. I apologize for the lack of detail
earlier.
Original comment by jamalc...@gmail.com
on 28 Jan 2013 at 8:27
Hi ekeeke,
I too have been noticing issues of this nature on RetroArch PS3 in the past few
days with Sega CD - Sonic CD being a game where it's most evident. I should
probably check RetroArch Wii as well to see if it affects that as well.
All I know is that this didn't happen a couple of revisions ago.
A couple of things I could try on the libretro end is -
* setting the samplerate from 44Khz to 48Khz and seeing if this produces better
results.
* Avoiding resampling on the core side altogether - RetroArch already does this
and there should be no discernable difference in sound quality (it would also
be faster too - on Android where most CPUs have softfloat support only,
resampling in the core would be especially painful compared to our optimized
NEON resampling being done in RetroArch).
I think the 'lag' here is misattributed by the original poster and it's just
disk I/O delays that is causing this - HDD file I/O are terrible on PS3/360. I
could try one last thing - a HDD disk I/O cache was previously used on PS3 and
360 - I have since discarded that since I thought I didn't really need it for
anything. Perhaps this is what caused it - this is just a speculation but I
should test it out to see if it's the case.
This all being said and done, I do hope I will be able to restore performance
back to the way it was before - because I am absolutely 100% confident this did
not happen before at all.
Original comment by libre...@gmail.com
on 28 Jan 2013 at 8:36
On another note, Genesis Plus GX is now on the Google Play store through
RetroArch - and for free -just thought I should let you know - I already let
Charles McDonald know and he was excited about it at least.
Original comment by libre...@gmail.com
on 28 Jan 2013 at 8:37
I can confirm it was a I/O issue. I transferred the .bin and .cue to the
internal HDD of the ps3 from my Ext HDD and I no longer receive lag.
Original comment by jamalc...@gmail.com
on 28 Jan 2013 at 9:35
great, buffered I/O could eventually improves reading speed (i think it is
done by libfat on wii/gc, through a read-ahead cache) but if device access is
too slow (like usb1 instead of usb2), it won't change much
regarding recent commits, honestly, i can not think of anything that would
affect emulation speed or sync...
@squarepusher: that's very cool, i just looked at your recent work on github
and it seems you have been working non-stop for the last month... impressive,
time for some rest maybe ;-)
i tried to get it working on my smartphone (htc desire, quite old) but it´s
not compatible, most likely because i'm using an outdated android os (currently
stuck to that though unless i hack it)
nice work anyway, it´s great to finally have a solution that respect the
original "spirit" of emulation scene
Original comment by ekeeke31@gmail.com
on 28 Jan 2013 at 9:48
Android 2.3 support is going to be done soon.
Regarding Genesis Plus GX on ARM in general - perhaps you could look into
adding Cyclone for ARM (notaz maintains a version here that works for Picodrive
at least - http://notaz.gp2x.de/cyclone.php) - it should decrease system
requirements by a lot.
Original comment by libre...@gmail.com
on 28 Jan 2013 at 3:50
Yes, I know about Cyclone and DRZ80 but I have actually no ARM
compiling/testing setup and not much time to spend on this sadly. This could be
a nice exercise for anyone wanting to step in genesis plus gx sourcecode though.
On a side note, I also have PowerPC assembly 68k and Z80 cores (Asgard68k &
AsgardZ80) written by Aaron Gilles but never took the time to look at them.
They might be useful someday when tackling with 32x emulation on Wii/PS3/X360...
Original comment by ekeeke31@gmail.com
on 28 Jan 2013 at 4:49
Hi there ekeeke,
just wanted to let you know that RetroArch Android works now on Android 2.3 and
up.You should be able to use it on your HTC Desire now if you have at least
2.3. I can't go any lower than that for the reason that native activities were
not yet available before API Level 9 (2.3).
Original comment by libre...@gmail.com
on 30 Jan 2013 at 11:18
I just checked and it seems my smartphone is stuck on 2.2 (froyo), HTC didn't
ever bother releasing 2.3 conpatible for it, from what I gathered on internet.
So i guess i am out of luck until I bought a more modern one.
Out of curiosity, what are native activities ?
Original comment by ekeeke31@gmail.com
on 31 Jan 2013 at 7:20
Damn, I was hoping this would enable you to use it.
Anyway, a 'native activity' is a glue code layer so that native code can
interface with upper-level Java code and services. A 'native activity' also
maintains its own state and lifecycle in native code as opposed to having to
implement that in Java.
Behind the scenes though, it is still a mixture of Java and native code - but
this allows you to just not bother with a single line of Java code if you don't
want to.
Original comment by libre...@gmail.com
on 31 Jan 2013 at 7:44
BTW, sorry about those people badgering you about resolutions in RetroArch Wii
- it's driving me nuts as well. Just know I have nothing to do with them
bothering you with that. They're doing it with Tantric as well and creating a
lot of ill feelings towards me because they're continually going about it like
'RetroArch does this, RetroArch does that - why don't you do it?'.
Original comment by libre...@gmail.com
on 31 Jan 2013 at 7:06
No problem, it was actually more about pixels no being as sharp in Retroarch as
in Genesis Plus GX or Snes9X GX under some "resolution" mode
I don't mind explaning technical stuff to people and clearing misconceptions
they have, it's actually a good exercise ^^
Thanks about the explanation about native activity, I was convinced that
Robert's framework (which works on 2.2) was purely C++ code, are you sure there
isn't any way to run native code before 2.3 ? Or maybe it's more complicated
than that, I admit that I know barely nothing about Java. Anyway, it's already
awesome what you accomplished with this release, let's hope this will kick out
all those commercial emu ports once for all.
Original comment by ekeeke31@gmail.com
on 31 Jan 2013 at 8:24
Native activities cannot be used for API levels lower than API Level 9 (Android
2.3 - Gingerbread) - so I'm afraid this is as low as I can go.
What Broglia is doing is really the inverse of what I'm doing - he's spending
most of his runtime state inside Java land, while I'm spending most of my
runtime state inside native code. I wouldn't have it any other way because of
the slowness of Java's garbage collector, the Dalvik JVM having to increase its
heap size every time you allocate something in Java, and lots of other reasons
that makes me even more convinced that doing as much native as possible is the
only way to go.
Original comment by libre...@gmail.com
on 31 Jan 2013 at 8:47
BTW - I'm experiencing an issue right now with a Sega CD game on Genesis Plus
GX (libretro port) - probably not the right thread for it but hopefully you
don't mind me posting it here -
I'm trying to load the Mega CD game 'Lunar - Eternal Blue' with a CUE sheet
that looks like this -
http://pastie.org/6002365
When I start up the '.cue' file, it shows me the Japanese Mega CD screen. After
pressing Start, it shows the audio CD screen. I then press Start again with the
cursor highlighting the 'CD-ROM' button. It shows a 'Sega copyright screen'.
After that, nothing will show up and the game won't progress - screen stays
black.
I'm curious what the issue here is. I've had another guy test a bunch of
Japanese Mega CD games for me and so far everything works except for Lunar
Eternal Blue. Is there something wrong with my libretro code in libretro.c?
Original comment by libre...@gmail.com
on 1 Feb 2013 at 2:32
I don't know, i will have to test it in my standalone genesis plus gx to see if
it still works. Does the US version works ?
Also, does the CD player shows the 4 tracks ? Can it play audio tracks ?
Original comment by ekeeke31@gmail.com
on 1 Feb 2013 at 7:37
Yes, according to almostalive the US version works whereas the Japanese version
doesn't. Even the redump image of the game doesn't seem to work.
The CD player shows all 4 tracks and you can play the redbook audio tracks just
fine. It just doesn't start up when you select CD-ROM - it just shows a black
screen after the 'Sega Enterprises' copyright screen.
Original comment by libre...@gmail.com
on 1 Feb 2013 at 8:30
I can confirm the Japanese version of Lunar Eternal Blue hangs on a black
screen after the Sega licensing screen in my current version, not sure if this
happened in earlier versions as well as I always only tested the US version
(which works fine), thinking it would have used similar booting code.
I will need to have a look at it, feel free to open an issue for this one.
Original comment by ekeeke31@gmail.com
on 1 Feb 2013 at 11:43
Original issue reported on code.google.com by
jamalc...@gmail.com
on 28 Jan 2013 at 12:34