Jump to content
LaunchBox Community Forums

mothergoose729

Members
  • Posts

    180
  • Joined

  • Last visited

Posts posted by mothergoose729

  1. Xbox controllers are xinput devices. Windows keeps track of your connected controllers and gives them priority. Usually its a first come first served basis, but it can get weird of windows thinks there are more controllers connected then there actually are. 

    Other controllers use the dinput standard, which gives no preferences. Each device has a unique ID and each button on the controller has a specific button index ie 'A' might be 0, 'B' might be 1, ect. 

    When registering inputs in an emulator it generally just correlates a device and a particular input with certain controls. You can pretty easily configure player one to be a combination of button inputs from two different controllers if you want. Emulators that are Xinput aware are able to read the correct profile from the driver automatically, as every Xinput device is basically treated like a 10 button Xbox pad with button indexes 0-9, a digital Dpad, and two analog inputs. Dinput devices not need follow this standard. Any particular index can correspond to any random button on the controller, and the emulator needs your help in order to figure out the correct mapping. 

  2. I emulated most of the CPS3 games in MAME. The first time you load the game it takes forever. After the first time it loads pretty quickly. 

    I have not tried the stand alone emulators, but from what I come to understand, most of the best code from standalone emulators was integrated into MAME ages ago. 

  3. The standalone emulators are almost always more feature rich. Retroarch is ideal for a few reasons:

    • Easier to setup
    • Generally, lower latency and input lag
    • Support for hotswapping controllers
    • Support for lots of shaders
    • Unified interface for save states, disc swapping, ect. 

    Most retroarch cores are just as good as their standalone counterparts when it come to game compatibility and performance. Many emulators integrated in retroarch  do lose some features, usually related to debugging, but rarely anything you are likely to notice.  For the most part, retroarch brings more to the table then it takes away. With a few exceptions mentioned above, I recommend using retroarch when you can for, in my opinion, the overall best experience. 

    There are also some cores in retroarch that do not have a standalone release. Mednafen PSX Hardware and Parrellel 64 come to mind. Both are excellent emulators. 

    I have read that the PPSSPP core in retroarch got a reboot a couple months ago, but I haven't tried it. It might be worth trying to retroarch core is you prefer to keep things under the RA umbrella. 

    Some obscure systems are really hard to setup properly in retroarch. I could never get disk swapping working correctly for bluMSX (although almost all the games you want to play are on flash carts, which work fine). Some obscure 8bit computer are only support in MAME or in standalone emulators. Mednafen wondwerswan has trouble switching aspect ratios for games like Klanoa (although there are some workarounds). 

    To add to the list of standalone emulators:

    Mupen64.io is going to be preferable for most people over the two retroarch n64 cores. It has really good compatibility and much better performance, and it upscales to whatever resolution pretty easy. Lots of eye candy. If you are looking for the n64++ experience that is the way to go, if you are looking for accuracy, and you have a 4.0ghz plus quad core CPU, then parallel with the angrylion plugin is by far the best. You can also track down that plugin for mupen64.io  or project 64 if you prefer. 

    The VICE64 core in retroarch is pretty bad. Use standalone for commodore 64 emulation. The DOSBOX core is also a pain to setup correctly because it automatically binds keyboard inputs to your controller in weird ways, and it is hard to track down and configure the config files properly and other weirdness. The DOSBOX SVN build is a better way to go. The mainstream 0.74 release works fine for 96% of games or something like that, but it is missing five or six years of ongoing development in the SVN builds. 

    Dolphin in retroarch is not very good. Use the standalone. 

    The Mednafen Saturn in retroarch is still missing analog support, which makes some games virtually unplayable. There is also a config hack you can do to decrease latency that is not available in retroarch. IMO use the standalone. 

    There is an argument to be made that MAME standalone is better than MAME retroarch. They are close enough to one another that I prefer to use MAME retroarch out of convenience. If you are doing anything other than arcade emulation though, like emulating obscure systems only supported by MAME, then the standalone is much easier to configure. The MAME config files are hidden in weird places and require enabling particular settings that are hidden in text files. The documentation and support just isn't there. It required a lot of googling on my part and trial and error to get the colecovision working in MAME. I can't really recommend it. 

    For some kinds of peripherals, in particular the atari 2600 paddles, stella standalone is definitely better. 

    The 3d0 Emulator in retroarch has some issues. Phoenix standalone is much better. 

    So what does retroarch do really well? All of the popular 8 bit and 16 bit consoles and handhelds, as well as the PSX. For most people that is all they are looking for. Retroarch is a one stop shop for SNES, NES, MD, GB/GBC/GBA, ect ect. 

     

  4. 19 hours ago, TheMadMan007 said:

    ah ok bummer, thanks for the info though. I'd rather play with the clarity for most games, than the "accurate emulation" when I very rarely would be able to tell. I see why people would want it, but there is no way I'm playing Zelda looking like Angryliion makes it look, its just too blurry. It's weird because Angrylion looks way worse to me than if I just hookup my N64 directly to my TV

    You should use the mupen64.io build instead. It is very accurate for HLE and allows for internal resolution upscaling and AA and all that jazz. 

    Personally, I prefer the authentic look of angrylion . The dithering effect is not properly emulated anywhere except in angrylion and parrallel 64, and without the dithering all the games look super off in their colors to me. Unfortunately, the checkered dithering is really distracting without all the VI blur as well. So IMO you need both for the right look. 

    I would say that angrylion with VI overlay looks a lot like a real n64, with the caveat that a blurrier image definitely looks better on a CRT compared to upscaled on a LCD monitor. 

  5. Parrallel 64 get the dithering effect right, but it skips all of the VI emulation. For that you will need angrylion, which is available as a secondary plugin choice. 

    With the latest multithreaded patch you can run pretty much any game at full speed with it, and it is pixel accurate to the n64, but it requires a 4.0ghz+ intel CPU, ideally skylake or later. 

    There are other issues as well. The n64 uses a variable resolution, scaling from 240p to 480i, sometimes within the same game. There isn't a good way to address this. My advice would be to try and set retroarch to push out a 480pixels on the height and use super resolution on the width. This won't give you the quite the correct look at 240p, because it will be interlaced, but it will make menus and the odd scene rendered at 480i crisp like it is supposed to. 

    I am building my CRT setup now. Not in a place to test it, but for me I think I am just going to pony up for real hardware.  

  6. 19 hours ago, Special T said:

    Thank you both for the quick reply. I tested some of the games in the link you posted but they look normal to me if I display them at 320 x 240. Have you noticed any games that need specific resolutions to look normal or do you just play all your genesis games at 320 x 240 and all your SNES games at 256 x 224?

    Wouldn't the games all get stretched to a 4:3 resolution on real televisions anyway? I don't recall playing any games on real hardware in letterbox mode although it's been a long time since I played any retro games on real hardware.

    Its a bit complicated. 

    CRT tvs don't have pixels, they have scan lines. A typical NTSC television can display as many as 480 scan lines interlaced. 240p game used half the scan lines drawn, with half the scan lines left blank (that is the pixel gap everybody loves so much). 

    The resolution on the console is merely the size of the framebuffer. Everything on a TV is overscanned to fit the 4:3 aspect ratio, or in the case with many NTSC to PAL conversions (PAL TVs have 576 scan lines), letterboxed on the top and bottom to pad the output to 288p or 576i. 

    A lot of older consoles didn't necessarily used a fixed resolution even for the same game, although AFAIK all MD games were displayed in progressive mode. 

    If you are using retroarch you can set the aspect ratio to 4:3 and use an integer scale to fix the screen as best it can without artifacts. If you are using something like composite out of a RPi3, then you set the height to a fixed 240p, and then you can set the width to a much higher values, like 1800 pixels, which I guess helps get more detail out of the frame buffer. 

    If you are using CRT_Emu driver or similar, then there are other options. MESS has MD support, which you can integrate with groovy MAME and then you should be able to get a native Gens, 15khz variable resolution output. I haven't tried it. I am not really sure how MESS compares with Gens GX Plus or other popular emulators in terms of compatibility, accuracy, and performance. 

  7. 9 hours ago, Lordmonkus said:

    Brunnis over on the Retroarch has done some more input lag testing and has some very interesting results. It is a bit of a long, mathy and technical post but the TLDR version is this;

    Properly setup emulators and an LCD monitor has no more input lag than an actual SNES hooked up to a CRT TV.

    https://forums.libretro.com/t/an-input-lag-investigation/4407/524

    I read that too, and it is very encouraging. 

    There were some speculative bits in the testing. Emulator authors identify 1 -2 frames of lag inherent in their emulation, so I tend to go by that number. Emulators other than retroarch also can introduce additional overhead, depending on how they handle frame buffers and peripherals (dolphin has tested their own stuff, and identified 1 frame of lag from real hardware, or even less lag than real hardware in some cases, depending on the accuracy of the frame buffer emulation). 

    With retroarch though, with a hard GPU sync and a touch of frame delay, you can expect to be within 1 -2 frames of real hardware on a CRT which is amazing. 

  8. I have a GPD  X D and I love it. I posted a detailed review of it on these boards, you can search for it in the "monkeys" sub if you like.  The reason I like it best of the devices you listed is:

     

    Flexible and powerful 

    Touch screen with android

    Small and light

    decent to excellent buttons

    long battery life

     

    I have bought plenty of cool devices before and never actually used them. I use my X D all the time. It is wonderful for traveling (I am traveling now, its a life saver for  all stages of travel tedium). 

    Highly recommended. 

    Sometime soon GPD is releasing an updated model of the X D that includes a 64bit processor, more power overall, and andriod 7. I have the older version and I love it to pieces, so don't hesitate to pick one up whenever you need it. 

  9. You really 

    2 minutes ago, markinsand said:

    MAME, NES, Genesis, SNES, Neo Geo... those are the main ones.

     

    thanks

    You really don't need more than the 55$ Pentium for those systems. MAME  supports as many as two CPU threads, and the rest are single threaded applications. A 3.0ghz+ clock speed will be fine for all but a tiny minority of MAME Roms and everything else is trivial. 

     

    If you prefer to have a quad core CPU for general use, then you can consider an AMD R3 CPU to save a little bit of money, or you can get this CPU which will do you just fine:

    https://www.newegg.com/Product/Product.aspx?Item=N82E16819117730 

  10. 18 minutes ago, markinsand said:

    so using newegg...which i5 fits the bill?  I am below a 'newb' when it comes to these things...

     

    https://www.newegg.com/Product/ProductList.aspx?Submit=ENE&IsNodeId=1&N=100007671 50001157 601295141

     

     

    Which systems do you want to emulate? You can spend somewhere between 50$-400$ and each makes sense, depending on the software that you want to run. 

    The relative performance only matters for benchmarks. You should buy the CPU you can afford that fits your needs. 

    With the motherboard I suggested, you need a skylake or kaby lake i5 CPU. That would be a  6XXXX or 7XXX series CPU. It is in the nomenclature. 

  11. For 500 dollars this is a good starter PC. It will emulate pretty much everything you want, and has a good upgrade path for later. 

    Case/power supply combo. Rosewill is pretty decent

    https://www.newegg.com/Product/Product.aspx?Item=N82E16811147099&ignorebbr=1

    GTX 1050 is a decent gaming card for emulation

    https://www.newegg.com/Product/Product.aspx?Item=N82E16814125951&ignorebbr=1

    8gb of memory

    https://www.newegg.com/Product/Product.aspx?Item=N82E16820232241&ignorebbr=1

    Decent motherboard

    https://www.newegg.com/Product/Product.aspx?Item=N82E16813130918&ignorebbr=1

    Low cost CPU that is good for emulation

    https://www.newegg.com/Product/Product.aspx?Item=N82E16819117625&ignorebbr=1

    SSD boot drive

    https://www.newegg.com/Product/Product.aspx?Item=N82E16820313864&ignorebbr=1

    2TB storage drive

    https://www.newegg.com/Product/Product.aspx?Item=9SIA5AD3KE4297&ignorebbr=1

     

    478$ including shipping but before taxes. Cost of Windows key not included. 

    If you are shopping at a different retailer then you will get different prices for the same goods. Use this as a reference rather than a "buy exactly these things". 

  12. I had this problem recently. Having RA treat each instance of gens as a seperate core is the best way to go, but what I did instead was set one setup as my "core overrides". Then I went through each game and loaded it with this override, and saved it as a game override, and then I rinsed and repeat with each platform. It doesn't take long if you have a reasonable size collection, but it is not good for full romsets. 

     

     

  13. Other emulators create a separate virtual memory card for each game, but not demul. You can create another memory unit in the UI of the emulator and load that instead. There isn't a way to automate it through the command line. The best solution I have found is to have separate instances of demul for every five or so games. Not exactly elegant, but demul is the best dreamcast emulator by far so I put up with it. 

  14. I have a mess of adapters for different controllers right now, and most of them cost me 20$ or more per adapter. This is a much more elegant solution. 

    Such a reconnaissance in retrogaming/emulation occurring in recent years. Awesome time to be in the scene. 

    • Like 1
  15. It is the 50mhz bus on the SD card that is the bottlneck. The limited memory also doesn't help. I have found that a per image size of 1mb or less is ideal. Anything over 2MB has noticeable load lag, and if you have a bunch of them it can cause the Pi to lock up. 

    I set the maximum height on my boxart to 720px, and then resize the width to be proportional. After that I compress the PNG. Square images tend to be the largest, and some of them get up to 1.5mb or so, but it has worked so far in keeping the image sizes manageable even for a fairly large collection. I am getting a bit of a washed out effect on some of the noisier source image  (the ones that go through a high resolution scanner look the worst for it). For the most part they look pretty  decent. When I am finished with the project, I'll upload the my images and playlists for others to use if they want to. 

  16. 14 minutes ago, keltoigael said:

    Nice! Make sure to get this power supply. I had issues with mine, the board that the usb and power buttons run through demands a little more power. This fixed all my power issues.

    https://www.amazon.com/gp/product/B01L8DVOFM/ref=oh_aui_detailpage_o02_s00?ie=UTF8&psc=1

    I got a 2.5A power supply and it is working great so far. Only issues I have had is the shoddy wireless, which is just par for the course with the little Pi's. 

    Mine works great, and the Pi sits in there snug as a bug. I am spending an inordinate amount of time getting boxart and everything setup. The media you download through Lakka is way to bloated for the slow storage on my Pi, and I don't want to risk data corruption by overclocking the bus. So instead I am poaching my LB image collection, resizing and compressing all the image by hand for what will probably be about 600 games I am loading on it. 

    So far so good though. The XMB menus are responsive, and I don't get black images or unexpected crashes :D

  17. The 8600K is just as good as the 8700K for almost everything, unless you don't plan to overclock it yourself. The 8 series i3s have four cores now. An unlocked variant of those would probably be the best value. 

    The Ryzen 1700 is a perfectly good chip. The number of games that can be played on an overclocked intel chip, that can't run at full speed on a Ryzen CPU, is really small. The intel chips are definitely faster thought.

  18. Probably not, but it might make windows and launchbox more responsive. 

    There are emulators that use a lot of memory for shader caching, and you can see marginal improvements in performance when you are able to fully cache all your shaders. 8gb is a lot of memory though, and these memory leaks have largely been fixed by driver updates. So no, not likely, but it can't hurt. 

  19. 19 hours ago, zorkiii said:

    I was just wrestling with this issue myself in CCS64, since I wanted to run all of the cart files I've found for the 64. These load much faster than their .d64 counterparts, and run just fine in VICE, but are not running in CCS64. I made a list of all of the files that wouldn't run for me. I tested removing bracket characters and such, but still wasn't able to run these. 

    I sent this list to the developer of CCS64 as well, but no reply just yet. Anyways here's the ones I found that will not load in CCS64 (at least not for me):

    There are a bunch of others that will run, but from what I've found, any Easyflash games will not run in CCS64, and a few others that didn't appear to be Easyflash. I've been setting up Vice to run as a secondary emulator for C64 to run the carts that won't in CCS64, but have been wrestling with getting it to be fullscreen nicely, and also not finding a good script to use my Xbox One controller to interact with Vice and exit and such.

     

    Wait, is that maniac mansion on a flash cart O.o.

    Are there cart versions of games that were previously only available on disk or tape? 

×
×
  • Create New...