Forum Replies Created

Viewing 35 posts - 351 through 385 (of 418 total)
  • Author
    Posts
  • dankcushions
    Participant

    my guess is that the rewind_enable setting killed their performance more than anything else – I think that basically buffers the last few moments of gameplay (by memory dumps?) so you can reverse. I imagine it kills the poor pi(2)

    dankcushions
    Participant

    good news!

    floob, i said i think video_threaded should be true – my understanding that it puts the video process to a seperate thread, which is good for multicore systems like the pi2.

    i was curious so i just checked and i have it set in fba/mame and psx already. i don’t believe i ever changed it, so i’m thinking it must have changed in 3.0 final.

    https://github.com/RetroPie/RetroPie-Setup/blob/master/scriptmodules/emulators/retroarch.sh
    iniSet “video_threaded” “false”

    you can see that jools set it to false in this change: https://github.com/RetroPie/RetroPie-Setup/commit/f86c4b233efe1660ef5d9f0408d9f455607c4f32

    reasons are given – i’m not sure i’ve had any out of sync stuff (only in mupen64plus, which isn’t libretro anyway), but i can’t also be sure that it boosts performance noticably. it’s difficult to test given that none of the frame rate counters seem to work in libretro!

    in reply to: Problem with DukeNukem 3D and SEGA 32x #104599
    dankcushions
    Participant

    with 1), if you try again, have a look in /tmp/runcommand.log and paste the contents here? that file logs the last error, which is useful for when things just don’t start!

    not sure about 2)

    in reply to: RETROPIE vs RECALBOX? (THOUGHT 4 THE DEVS) #104597
    dankcushions
    Participant

    yeah i think this thread has been a little harsh on recalbox! it looks good and i think it’s great we have two different approaches to the same thing – competition helps everyone :)

    i’d love to see a distribution using the ‘attact-mode’ interface (http://attractmode.org). it’s a beautiful interface more like hyperspin, with videos, fancy fonts, sound effects, etc. someone has got it running on a pi (based on retropie, in fact) in the video below, and it looks so good!

    it would be great as a multi-boot with emulation station. you could use the attract-mode UI for a more curated list of games, but ES for access to your entire library.

    anyway, that’s the dream :)

    in reply to: Multi tap support #104595
    dankcushions
    Participant

    re: psx multitap support – it is currently not supported in pcsx-rearmed (the psx emulator that retropie uses). there is an issue logged here: https://github.com/notaz/pcsx_rearmed/issues/43 – it looks like the main developer does not have time to work on the project, unfortunately. perhaps someone could get stuck in? :)

    in reply to: Power Questions #104594
    dankcushions
    Participant

    1) the icon means there is not enough power being supplied, so it looks like your hub doesn’t output enough power for the pi. strangely, that hub model appears in the ‘working’ list of RPI hubs (http://elinux.org/RPi_Powered_USB_Hubs#Working_USB_Hubs) with a comment that it powers the pi fine, but perhaps they’ve not tested with the pi2, or using applications that push the system as much as emulation.

    not sure about 2!

    in reply to: F4 to command prompt slow #104593
    dankcushions
    Participant

    how many roms did you have when it happened? how many do you have now? had you scraped data for your roms before/now?

    with emulation station, the only exit options that save all the metadata changes (“last played”, anything you’ve edited manually, etc), are F4, and “exit emulation station” in the ‘start’ menu. if you shutdown/restart your system, it will just terminate the process and not save anything. there is an issue raised about this – both why it takes so long, and why the other exit options don’t save the metadata.

    in my experience, having a lot of roms will mean that terminating ES ‘properly’ (ie, via F4 or ‘exit emulation station’) takes ages.

    dankcushions
    Participant

    hi haze303 – weird you don’t get the core options menu stuff! perhaps retropie 3.0 still doesn’t have retroarch 1.2? no matter, i’ve had a look at your cfg and have the following suggestions:

    video_threaded = “false” (change this to “true”)
    rewind_enable = “true” (change this to “false”)

    if this helps, please let me know :)

    dankcushions
    Participant

    hmm, there are a few options that will reduce performance. perhaps one of these is mistakenly set in retropie 3.0 final? because i’m running an updated 3.0 beta 3 with retroarch 1.2.2 with lr-pcscx-rearmed r22 and my performance is fine.

    here’s a few things that might sort it

    hotkey (usually select) + triangle/Y to get to the RGUI

    quick menu > core options
    frameskip should be 0
    dynamic recompilier should be enabled
    interlacing should be disabled
    enhanced resolution should be disabled
    enhanced resolution should be disabled

    quick menu > shader options
    shader passes should be 0 (you can get away with some shaders with minimal performance impact, so if you know what you’re doing, go ahead!)

    settings > video
    HW Bilinear Filtering should be OFF (this turns off smoothing of the screen – has a performance impact)

    settings > driver
    input = udev
    joypad = udev
    video = gl
    audio = alsathread
    audio resampler = sinc

    if any of this works, post it here so we can get the relevant scripts updated :)

    in reply to: Mamedroid (0.139u1) Emulator #104410
    dankcushions
    Participant

    this thread is a bit difficult to follow but generally speaking later versions of mame will run worse as the emulation becomes more accurate (heavier load). I’m not convinced this would be the panacea for perfect mame on the pi.

    we already have a libretro version of imame4all on the pi, so if someone really wanted to get this later version merged in, they could do that without the original developers help (don’t email them if they’ve already said they can’t do it!!). first step would be to get it off google code and onto GitHub.

    in reply to: ES Number of Times Played not saving #104408
    dankcushions
    Participant

    I’m afraid that ES doesn’t seem to save metadata changes (of any sort) when you shut down via the shutdown option (or command line). the only way it will terminate correctly and save is if you choose the ‘close emulation station’ option or hit f4 to exit to terminal. you’ll notice that both take ages if you have a lot of games.

    this is logged as a bug on the ES github but it seems the owner of this project doesn’t have time to work on it at all.

    dankcushions
    Participant

    as with all the libretro versions of emulators, you’ll find that they’re branches of the main emulator developments. I doubt that the libretro hooks add in much overhead, but the chances are high that because it doesn’t include the most current version of emulator, it runs worse as a result.

    that said, for this emulator I get almost perfect emulation with the libretro version (some very small hiccups in tekken 3). what’s happening for you? what games? perhaps your overclock is too aggressive.

    in reply to: Uneven scanlines with CRT-hyllian #104074
    dankcushions
    Participant

    for gngeo, you’ll find that all games are 224 lines high, and use the entire space for important info (scores etc). so with 720p your options are:

    integer scaling on, 1280×720 x3 overlay png. this will leave you with black borders at the top and bottom.

    integer scaling off, 1280×720 overlay png with 224 lines (you’ll have to generate one, and use linear scaling to get the best result), and retreat resolution set to video output. this will leave you with slight artifacting to how the scanlines appear, but a full screen image. for me the corruption is not noticeable in 1080p, but it might be in 720p.

    for mame, there is not standard resolution, so you really have to configure each game (or each arcade board) separately. I am planning on generating (and releasing) a load of scanlines, and appropriate rom cfgs, but not started yet!

    dankcushions
    Participant

    small update on this:

    bad news: the android open gl es version of yabause is using opengl es 3.0. the raspberry pi’s videocore IV GPU has only opengl es 2.0 support. i asked devmiyax (the guy coding it) if it would be possible to port it to opengl es 2.0, and the answer is no (https://github.com/devmiyax/yabause/issues/36) – it seems it needs a specific es 3.0 command that is proving difficult (impossible?) to replicate in es 2.0 – gl_FragDepth.

    good news: eric anholt and others have been working on an open graphics driver for the raspberry pi – http://dri.freedesktop.org/wiki/VC4/ – i have hope that this new driver will allow for the possibility of gl extensions that can paper over these gaps in the existing open gl spec. eg: GL_EXT_frag_depth, or maybe even a full ES 3.0 implementation. i believe this driver is already open gl 2.0 (NOT ES) capable, which possibly allows for different approaches.

    anyone interested in open gl programming? could be an interesting project for someone :)

    also, there are improvements that devmiyax is doing to the saturn emulator that should already prove helpful to the pi – eg, using multicore CPUs at full capacity. we may still see a good improvement.

    in reply to: Update Retroarch #103749
    dankcushions
    Participant

    Yeah one thing – you won’t suddenly get the posh GUI that’s in the newest retroarch screenshots – it will default to the regular 8-bit-looking menu, although like herbfargus says, it will have the new ‘quick menu’ option.

    i’m not sure how you enable the new GUI, if you even can on the pi.

    in reply to: N64 Compatibility List! #103642
    dankcushions
    Participant

    I’m a bit lost with the various mupen64plus versions now – I can’t find the github/whatever page for ‘mupen64plus-testing’, but mupen64plus core (https://github.com/mupen64plus/mupen64plus-core) and the various video plugins:
    https://github.com/mupen64plus/mupen64plus-video-glide64
    https://github.com/mupen64plus/mupen64plus-video-glide64mk2
    https://github.com/mupen64plus/mupen64plus-video-rice
    …all have received updates.

    when you rebuild mupen64plus does it grab the latest builds of the plugins? because they’re on separate repos it seems.

    i’m not sure what mupen64plus-testing rebuilds from?

    in reply to: Uneven scanlines with CRT-hyllian #103547
    dankcushions
    Participant

    what’s your retroarch video output resolution? (i think the bottom setting in the menu when you press ‘x’ during launch) you should set it to “video output”

    in any case, you should probably use an overlay anyway! they have a predictable outcome and also have less of a performance impact (ie, none!)

    in reply to: N64 Compatibility List! #103467
    dankcushions
    Participant

    that’s fair enough! i confess i sidelined n64 testing when i got odd issues with sound lag in mario 64 – i get a small delay in sound effects (but otherwise perfect performance), compared to videos online which seem perfect. i feel like the n64 emulators are more GPU dependent so things like resolution, GPU memory split, and all manner of config settings, could explain it, but i gave up fiddling.

    right now it works great with the mupen64plus (vanilla) for 4 player mario kart and f-zero, which is all i really wanted. i’ll do a fresh install when 3.0 goes final and try again from there :)

    in reply to: N64 Compatibility List! #103465
    dankcushions
    Participant

    [quote=103252]Should I have two columns for the plugins? or should I just leave it with the one column and have people choose which plugin works the best? (I think how it is right now is probably simplest)
    [/quote]

    for me i think we should have 2 columns for the plugins, and arguably 2 more for the plugins of the regular mupen64plus (the testing is for just that, no? or is it actually going to be mergedback into the regular, or made into a proper branch?). maybe even another 3 for the libretro version!

    right now i feel like it’s not obvious that the plugin used is the best one – has the other even been tested? anyway, just my opinion :)

    dankcushions
    Participant

    you can do rom-specific config files, but you will need to ugprade to the latest version of retropie, I believe.

    dankcushions
    Participant

    [quote=103048]I think the ROM I had was already MSX. Now I finally found out how to change the emulater. So I chose lr-fba. But now performance is worse than before. The slowdown now affects the music wich it didn’t before and it occurs more often. :(

    [/quote]

    try the pifba emulator. it’s faster than lr-fba/gngeo, although lacks retroarch features.

    also, you say you’ve overclocked to the ‘maximum’ – is it stable? if the pi is struggling for volts or temperature, you’ll see a flashing graphic in the corner and it downclocks briefly, slowing everything down (not sure about for volts – it might just crash!)

    in reply to: Playstation dual shock 4 #102900
    dankcushions
    Participant

    Hi,

    This is a known issue, although it doesn’t appear to have anyone interested in fixing it, yet! https://github.com/libretro/fba-libretro/issues/46

    dankcushions
    Participant

    [quote]And I’m trying to get you to appreciate the wide variance with which CRTs were calibrated, which you don’t seem to understand. The 224 line thing is truly pulled from nowhere with no source to back it up (this is a criticism of the wiki you linked to, not you). You need to understand that CRTs were analogue- controlling the paths of individual electrons with magnets. It wasn’t an exact science. As such, even individual TVs of the same manufacturer and model number could vary widely in the amount of overscan they displayed.[/quote]this is why nes/snes/md game developers always ensured they render 224 lines, as that catered for the average TV (that’s a mean average, not mode average, which is what you seem to be arguing against), and restricted gameplay-critical information to the centre 216, where they could make a reasonable assumption that this would ALWAYS be shown.

    this 224 number is important – almost every pre-HD consume console renders this amount of lines visible (their actual output resolution may differ, eg 240 lines for the snes), in most games. even PSX, saturn, etc. they’re not just putting borders beyond 216 lines, they’re outputting graphics. a great example is the PSX – some games let you adjust the video output position, but it’s normally a 224 line high image.

    what you seem to be arguing for is only showing 216 lines, which is almost a ‘worst case’ scenario for a CRT. i don’t see why you have a problem with me choosing to view all 224 lines of graphics! if you want to show just 216, ok!

    [quote]Nope, I’m afraid you are mistaken. The output seen in the screenshot is 240 lines with crop overscan off. That’s how many lines are being put out by the emulator in the screenshot I provided. 24 of these lines get cropped off by stretching the picture with 5x scaling so that the edge of the picture extends beyond the edge of the screen. So I’m displaying 216 lines but the output is the full 240.[/quote]crikey. you’re displaying 216 lines on your TV – 216 divides into 1080, and you have one scanline per pixel line, so your scanlines cannot be stretched, so your point about nearest-neighbour filtering is not illustrated. if you do it correctly you get the effect i’ve shown – that’s how nearest neighbour works! it cannot work any other way!

    [quote]And it will result in artifacts. Sorry, but there’s no method other than the one I described that won’t result in artifacts. Bilinear filter results in artifacts by definition, that’s just a function of how it works. It takes the average of four adjacent texels and determines the color based on that.[/quote]i’ve never said that it doesn’t – obviously it does. i just feel that for me (and I would guess others), the artifacts with a properly linear scaled 1080p scanline overlay, and a native 1080p retroarch output, are not severe, or worth letterboxing your output to avoid. i’ve got screenshots to illustrate this. it’s not perfect, but it works for me. if it doesn’t for you, that’s fine. other threads are available.

    can this please be all! :)

    dankcushions
    Participant

    looks like the source is available:
    https://github.com/devmiyax/yabause

    this appears to be a fork from standard yabause:
    https://github.com/Yabause/yabause

    and the libretro version (on retropie) appears to be a fork from the standard:
    https://github.com/libretro/yabause

    it seems like the libretro version had a merge from the standard version a while back, and the standard version is getting the new stuff merged in when it’s stable (from the comments in https://github.com/Yabause/yabause/issues/17)

    not sure if it’s worth me opening an issue in the libretro version to request a merge when it’s all still in flux – don’t want to step on anyone’s toes! :)

    dankcushions
    Participant

    weirdly I don’t get the “core input remapping” option in the FBA-lr quick menu (either for neogeo or fba). it DOES appear when playing other systems, but I don’t have a problem with those! I’m not sure if it’s the core that’s hiding this option, or some other configuration (nothing jumps out)

    EDIT: I smell a retroarch issue, so raised https://github.com/libretro/RetroArch/issues/2000

    dankcushions
    Participant

    [quote=102338] All opacity does is adjust the darkness of the overlay. The artifacts are most likely there even at lower opacity; you’re just not able to notice them at that opacity.[/quote]exactly!

    [quote]Furthermore, the number of lines displayed by the TV has no bearing on what the internal resolution of the system is, or what it should be set to. NES for example put out 240 horizontal lines, no exceptions. The TV would display anywhere from 90-100% of these lines so anywhere from 216-240 lines would wind up being displayed. There is no “more accurate,” here, since the amount that got displayed varied widely by manufacturer, model, and individual set. [/quote]
    what I’m doing is giving the settings for a CRT TV that would display 224 lines, whereas you prefer the settings for a one that would display 216. like you say, neither is “more accurate” so it’s personal preference/experience.

    [quote]

    clearly you haven’t tried it. here’s what nearest neighbour scaled (224 lines in 1080) scanlines look like close up:

    Clearly I haven’t tried it?

    It looks like you’re scaling up from the wrong resolution and/or using bilinear filter on the overlay in Gimp. Here’s what nearest neighbor looks like with the 5x scanline overlay I’ve provided at 5x scale, using 240 as the native resolution. It’s fine. It seems like you’re doing something strange on your end that is causing the issues you’re describing.

    http://s1309.photobucket.com/user/Patrick_McCleery/media/image.jpg1_zpswuxdykgm.jpg.html[/quote]

    you’re not understanding what’s going on here. your screenshot is displaying 216 lines (you can tell by the amount of ‘ground’ is displaying – compare to my screenshots above of a 224 line in 1080p scaled version). your scanlines are displaying 1:1. you won’t see any scaling of the overlay unless you turn off integer scaling – ie attempt to stretch 224 or 240 lines on a 1080p.

    a nearest neighbour filter always produces the results i showed – that’s the definition of a nearest neighbour filter.

    [quote]It’s a fact that the safe area is defined as 90% of the screen- see the link I provided above. This is the area that console developers used when designing graphics. Of course, arcade games are going to be different because they were designed to run on arcade monitors which were better made and didn’t have overscan. In other words, most arcade games probably don’t use padding, which is why important stuff gets cropped off at the edges when you use 5x scale on an emulator. Another factor complicating this is that arcade monitors often used different resolutions than standard CRT TVs.

    If it really is 224 with no overscan (I think this is true for CPS) then the best you can do on a 1080p display if you want *perfect* scaling is scale up to 896, and have letterboxing equal to 184 lines, which is more than 17% of the total display area dedicated to letterboxing.[/quote]
    …or you use my method. you’re welcome!

    in reply to: FBA Retroarch core – coin controls #102289
    dankcushions
    Participant

    [quote=102192]There is a solution in the latest retroarch- called core input remapping: if you reinstall retroarch from menu 5 in the setup script (after updating the setup script of course) and open up into the rgui (by pressing select+x)- under the quick menu you can change which core options do what- so you could switch start and select so start is the coin input and select is start or any other variation that is comfortable. That way you don’t have to give up a control if you wish to still be able to put coins in. You’ll just have to make sure that the RGUI saves the configs on exit.

    [/quote]i have the latest version of retroarch but not sure what you mean? in ‘armored warriors’ (a game that suffers from this issue) in ‘quick menu’ > ‘core options’, I have a ‘controls’ option but it’s just the option for ‘gamepad’ or ‘arcade’ ? doesn’t seem to be anything else i can set here

    dankcushions
    Participant

    Are you using the right mame4all emulator? imame4all-lr is the retroarch/libretro version, and will use your config, but mame4all-pi is not, and will use its own config file (mame.cfg, I believe)

    i don’t use advmame but it doesn’t seem like it’s retroarch/libretro, so again will have its own config files.

    in reply to: lr-gpsp segmentation fault #102274
    dankcushions
    Participant

    i had a similar issue where lr-gpsp didn’t run certain pokemon games, but gpsp did. my guess is that the version of gpsp that the libretro version is built from is older, or that the porting process introduced some bugs. you can just run these games in gpsp instead, but that’s a bit annoying as it means you can’t use shaders, etc.

    logging it as an issue with lr-gpsp is probably your best bet!

    in reply to: Slowdown issues (psx, snes) #102222
    dankcushions
    Participant

    that “pi2” overclock setting is also pretty aggressive. i’d suggest toning it down until you’ve got a stable system – should be able to run all snes and PSX games without major issue on a default pi2.

    if you want to overclock later i’d suggest following some of the reported ‘stable’ configs here: http://linuxonflash.blogspot.co.uk/2015/02/a-look-at-raspberry-pi-2-performance.html

    in reply to: Improve performance in iMame4All-libretro! #102190
    dankcushions
    Participant

    you need to go to option 5 in the setup menu (install individual emulators) and then choose lr-imame4all, then rebuild from binaries :)

    in reply to: FBA Retroarch core – coin controls #102184
    dankcushions
    Participant

    :)

    I logged the issue here: https://github.com/libretro/fba-libretro/issues/46

    It seems it was already logged for the Mame4All Libretro core: https://github.com/libretro/imame4all-libretro/issues/9

    It might be a retroarch issue, though…

    dankcushions
    Participant

    [quote]It’s a feature of the image you’re using and the type of scaling that you’re applying. I just confirmed this by looking at the full size image you linked to- check the blue area in the Sonic screenshot. The scanlines in this area should be uniform at 800% zoom, but they aren’t- this can create the described moire effect.[/quote]yes, but as i said (4 times, now), I a similar effect because of my TV, even when using no scnaline. I do NOT get this effect when using lower opacity on the scanlines, scaling or not. Apparently you are unable to take my word for it, so here’s some screenshots (ignore the vertical white ‘ovals’ as they are just an effect of my phone camera):

    Wii.png scanlines, 1.00 opacity at 6×5 integer scaling (216 line image)

    Wii.png scanlines, .35 opacity at 6×5 integer scaling (216 line image)

    at 1.00 I get a strange variance between the scanlines that is distracting, to me. lower the brightness and it goes away. This was before I started messing with scaling or any scanline pngs. The scanlines are more visible in real life than the second screenshot, but I don’t get the effect.

    [quote]That isn’t related to nearest neighbor per se, it’s a function of how the image is being scaled. Nearest neighbor will result in the most accurate scaling with the fewest artifacts.[/quote]clearly you haven’t tried it. here’s what nearest neighbour scaled (224 lines in 1080) scanlines look like close up:

    compare that to my scanlines posted in my screenshots.

    [quote]You seem to think that the padding is meant to be displayed, when it gets cropped on a CRT. Just because the graphics aren’t glitched at the top/bottom doesn’t mean it’s not padding. Notice how the score/time/rings display and the Sonic lives display is not right at the edge? That’s because some TVs would drop right up to those graphics. Heck, I’ve got a cheap Sanyo CRT that crops even more than this- the top two lines where it says “score.” This is not an old TV, but one from the mid 2000s.

    Since CRTs varied in how much they cropped, the game developers had to allow for this by placing all important graphics within the safe area. If they put those graphics right at the edge, they’d be cut off most of the time on a CRT.[/quote]
    i say again, most TVs displayed the centre 224 lines. http://wiki.nesdev.com/w/index.php/Overscan: “Actual TVs show about 224 lines of the signal, hence the commonly reported 256×224 resolution. But the vertical position may be slightly off center.” – this is why almost all games will render the playing field for the full 224 lines, knowing that most users would see it, rather than show borders because some users wouldn’t. “In fact, even some CRT SDTVs made in the 2000s show more of the bottom than the top; this may be so that tickers on cable news channels aren’t cut off.” – this might account for your TV, but for those of us who want to emulate TVs from the era, showing the full 224 lines is accurate (and shows more of the game).

    [quote]I haven’t looked at windjammers, but nothing important should be cropped at 5x integer if crop overscan is on the right setting for the core being used and you are scaling up from the right resolution.[/quote]
    i posted a screenshot, dude! All neogeo games are like this – go check for yourself. you even posted this earlier in the thread
    [quote]I haven’t tested Neo Geo, but I think it varied, with the most common being 264 with overscan (240 without)[/quote]
    240*5=1200, which means a 1080p TV would crop out 60 pixels (12 lines) from the top and bottom of the ‘post overscan’ image.

    examples:
    windjammers (neogeo), integer scaled at 5×224

    sf3 (cps3), integer scaled at 5×224

    I’m about done with this conversation. If you’ve found a solution that works for you – great! For people who want to play neogeo or (many) arcade games, at full screen, without cropping information – this is the only solution. The rest comes down to personal opinion about what parts of the screen are important/not important, and what CRTs you are used to.

    in reply to: FBA Retroarch core – coin controls #102073
    dankcushions
    Participant

    another (sort of) solution for this issue is to use player 2’s coin button. eg, if i have two USB SNES controllers plugged in, I can hit ‘select’ on player 2 and it puts a credit in. you have to be careful to then press start on player 1, or you might end up with 2 players joining the game (if you’re playing alone!)

    it looks like the fba/mame libretro cores don’t like having the hotkey as the same key for the coin button. that makes the above make sense, as only the p1 controller has a hotkey (you can’t start-select quit with p2, by default).

    has anyone logged a ticket with retroarch? with a bit of luck this issue is fixed in 1.2 already.

    in reply to: Game Specific Configs #102072
    dankcushions
    Participant

    there is, but there’s currently a bug with it: https://github.com/RetroPie/RetroPie-Setup/issues/899

    that said, i have the same controller and mario all stars works fine for me in snes9x (which I think is the default?). perhaps you’ve accidentally created a rom-specific config for this, which it’s using instead of the proper one, causing neither to be read, or some other weird issue? if you look in your roms directory, is there a .cfg file with the same name as the rom?

Viewing 35 posts - 351 through 385 (of 418 total)