/emugen/ - Emulation General

emulation.gametechwiki.com/index.php/Main_Page

Read the General problems FAQ before asking questions. If you still need help, post your specs (Speccy screenshot), operating system, emulator version number and details of what's wrong.

Please contribute to the wiki if you discover any inaccuracies or have relevant information to append.

READ THE WIKI BEFORE ASKING QUESTIONS LIKE:
>Where do I get games
OR
>Where do I get games
OR
>Where do I get games
OR
>Where do I get games
OR
>Where do I get games
OR
>What is the best emulator for...

Check out the wiki for the emulator you're using if you run into trouble, there may be a solution there too, often including recommendations for optimal game settings.

Remember to submit bug reports or shit won't get fixed.

Other urls found in this thread:

github.com/project64/project64/issues/1322
pastebin.com/m8q4mSpu
web.archive.org/web/20161120010732/http://wiki.pcsx2.net:80/index.php/Complete_List_of_Games
romhacking.net/translations/1947/
youtube.com/watch?v=BtRfMSYtYsE
twitter.com/SFWRedditVideos

>At this rate, every N64 game will have an HLE implementation
Who is going to HLE World Driver Championship? That guy rage quit LOL.

I'm genuinely doubtful that every single inaccuracy in the HLE implementation will be fixed. That's why I appreciate LLE. I can just enable that and enjoy high-accuracy gameplay. HLE is overkill for modern hardware, save for maybe a few odd games like Conker's Bad Fur Day.

>and the only thing that will need fixing will be the LLE triangle rendering for the whopping two Rareware titles that send triangles without a display list.
How do you expect them to get HLE to work fine for games like Factor 5, when the LLE implementation's inaccurate?

>Who is going to HLE World Driver Championship? That guy rage quit LOL.
He didn't rage quit. There are some ongoing disagreements over the best way to implement yielding in HLE. Also, there is a second programmer who has been working on ucode stuff, albeit less proficiently.
>I'm genuinely doubtful that every single inaccuracy in the HLE implementation will be fixed.
Why?
>That's why I appreciate LLE. I can just enable that and enjoy high-accuracy gameplay.
Without enhancements, and with immense and arguably unnecessary performance overheads.
>HLE is overkill for modern hardware, save for maybe a few odd games like Conker's Bad Fur Day.
No it's not. It serves two purposes. One, it's insanely fast. Two, it grants an understanding of how these games function.
>How do you expect them to get HLE to work fine for games like Factor 5, when the LLE implementation's inaccurate?
Because the LLE side of things is completely irrelevant for such games. Someone merely needs to reverse engineer the ucodes and write an HLE implementation. This is not a trivial task, but consider that we're rapidly running out of games that DON'T have an accurate HLE implementation.

>Someone merely needs to reverse engineer the ucodes and write an HLE implementation.
How will they implement proper triangles? That makes 0 sense to be able to do accurate HLE and fail at LLE. THat's like making a recompiler that is more accurate than your interpreter..

>One, it's insanely fast.
I'm sure most people do not care about being able to run at 500 VI/s.

>Why?
Because it is a lot of work. It also requires a deep understanding of the RSP, which few people seem to have.

>There are some ongoing disagreements over the best way to implement yielding in HLE.
The guy is worried that HLE won't work at all, simply because he is over-complicating it. That's incredibly silly to nitpick and worry over a minor performance gain/loss.

>Also, there is a second programmer who has been working on ucode stuff, albeit less proficiently.
Who is that?

>How will they implement proper triangles?
By caring enough to rewrite the LLE triangle code. It's not like it's some huge technical challenge -- it's just that nobody cares enough to do it. LLE in GLideN64 is an afterthought, and if current progress continues it will completely redundant before long.
>That makes 0 sense to be able to do accurate HLE and fail at LLE.
>THat's like making a recompiler that is more accurate than your interpreter.
That analogy doesn't work. The way HLE video and LLE video work are completely different.
They're extremely different. If GoldenEye and Killer Instinct didn't exist, there would be no need for low level triangle rendering because normal N64 games use display lists for everything.
>Because it is a lot of work. It also requires a deep understanding of the RSP, which few people seem to have.
Improvements are coming at a steady rate. That really isn't an issue currently.
>The guy is worried that HLE won't work at all, simply because he is over-complicating it.
World Driver Championship is an extremely touchy game. He wants some guarantee that the yielding issue will be solved for HLE. This is an RSP issue, and it also affects Gauntlet Legends. It's hard to properly debug a ucode if the game is hard locking on boot. It's a chicken and egg situation, to some extent.
>That's incredibly silly to nitpick and worry over a minor performance gain/loss.
The game refuses to boot in HLE largely because the plugin spec doesn't handle yielding. It's hardly a nitpick.
>Who is that?
Gillou68310.

>He wants some guarantee that the yielding issue will be solved for HLE.
I think it's silly to worry and think HLE won't work simply because the game freezes when you skip DLists. Why would you skip important code in the first place??

>The game refuses to boot in HLE largely because the plugin spec doesn't handle yielding. It's hardly a nitpick.
it is nitpicking because a surefire method has already been proposed and he seems to not be convinced.

>That analogy doesn't work. The way HLE video and LLE video work are completely different.
HLE requires LLE knowledge, when you reverse engineer it.

>Improvements are coming at a steady rate. That really isn't an issue currently.
For anyone who cares deeply about accuracy, it will still be an issue. With certain games, you can see a visible difference between LLE and HLE.

>It's not like it's some huge technical challenge -- it's just that nobody cares enough to do it
Why do you think it's not a huge technical challenge? How would someone figure out how to fix it?

>I think it's silly to worry and think HLE won't work simply because the game freezes when you skip DLists. Why would you skip important code in the first place??
HLE won't work if the CPU goes into an infinite loop like it does with WDC.
>it is nitpicking because a surefire method has already been proposed and he seems to not be convinced.
Nobody has successfully handled RSP yielding in HLE yet. Until they do, this is completely academic. It's not "surefire" if all attempts to do it to date have failed.
>HLE requires LLE knowledge, when you reverse engineer it.
Yes and no. Knowledge, yes. Execution, no.
>Why do you think it's not a huge technical challenge? How would someone figure out how to fix it?
The important thing to remember about the N64 is that it doesn't use vertices. It doesn't draw polygons in the way other hardware draws polygons. Instead, it uses edges and slopes. The end result is effectively the same, but converting edges and slopes to polygons is the sticking point.

In an HLE microcode implementation, the polygons are drawn traditionally. There's no fuss. With an LLE implementation, you require some code to convert these edges and slopes into polygon vertices, and this is where GLideN64 trips up, because it has a half-baked, flawed implementation that was originally created for the purpose of rendering the sky in GoldenEye, since GE sends commands for rendering the sky directly to the RDP instead of including them in the display list.

tldr

>Nobody has successfully handled RSP yielding in HLE yet. Until they do, this is completely academic. It's not "surefire" if all attempts to do it to date have failed.
One guy specifically said he HLE'd the functions that required yielding. HLE can do anything LLE can do, so I do not understand why anyone would be concerned about getting HLE to work. It's ridiculous for him to rage quit like that, when clearly knowledgeable people are sharing information and offering help.

> flawed implementation that was originally created for the purpose of rendering the sky in GoldenEye
Didn't he just port the triangle code from z64gl?

Which emulators work perfectly with my laptop?

My specifications are.

Windows 10 Home single language

Processor: AMD E1-2100 APU with Radeon (TM) HD Graphics


RAM: 2.00 GB (1.47 GB usable)


System type: 64-bit operating system, x64 processor


In Windows (C:) I have 386 GB available from 440


And in RECOVERY (D:) I have 2.69 GB available 24.0 GB

ZSNES

>One guy specifically said he HLE'd the functions that required yielding.
That's... not as simple as it sounds. LegendOfDragoon is essentially arguing that the ucode should be reverse engineered, and then "someone else" will take care of yielding. Which is a pants-on-head retarded attitude. The yielding issue needs to be fixed FIRST, and THEN the ucode can be reverse engineered.
>HLE can do anything LLE can do
Not under the current plugin specification, it can't.

His second suggestion is updating the plugin spec, which is simple on paper, but would require some negotiation with Zilmar, who doesn't really care about anything but Android at this point.

See this conversation for details:

github.com/project64/project64/issues/1322
>Didn't he just port the triangle code from z64gl?
Yes. And that's the problem. This... issue goes all the way back to 2007-ish, when Glide64 copied z64gl's triangle code.
>It's ridiculous for him to rage quit like that, when clearly knowledgeable people are sharing information and offering help.
He's being a drama queen. They're being obstinate. It is necessary to be able to run the game in HLE mode before he can reverse engineer the ucodes. Currently, the game does not boot in HLE mode. It only boots in LLE mode thanks to a dirty hack. I think there might be a slight language barrier, too.

And what super nintendo Games do you recommend?

I like soccer games (provided have Canada.)

I hate RPG games

race games.

Easy games

And games that are for all ages and all audiences (Rated K-A Kids to Adults in the ESRB)

Is this a joke? I'm not laughing.

It's not any joke.

My laptop is low range


And I'm looking for emulators for low-end laptop's.


That work to perfection in Laptop of low resources like mine

why isn't this the first time you posted this?

>I like soccer games (provided have Canada.)
what the fuck

>LegendOfDragoon is essentially arguing that the ucode should be reverse engineered, and then "someone else" will take care of yielding. Which is a pants-on-head retarded attitude.
I think the idea was to work as a team. Anyone with half a brain can port small pieces of code from LLE to HLE. I'm sure he would have been willing to do it, if no one else was willing anyway. He already posted the functions where yielding currently needs to happen.

>His second suggestion is updating the plugin spec, which is simple on paper, but would require some negotiation with Zilmar, who doesn't really care about anything but Android at this point.
Why does zilmar have to be the one to do it? Nothing stopping anyone from using a different RSP/emulator, in the worst case scenario. Not saying he shouldn't do it / accept a PR, but I don't think he HAS to do anything about it. Others are capable.

>Not under the current plugin specification, it can't.
True, but it's apparently easily to fix.

>It is necessary to be able to run the game in HLE mode before he can reverse engineer the ucodes.
What's the point of testing a game if the HLE implementation isn't anywhere near complete? The microcode can easily be dumped, so anyone can read the file and implement HLE based off that.

Is that I do like Canadian soccer.

any problem?

>AMD E1-2100
NES, SNES, GB/GBC/GBA, NDS (NO$GBA, if it doesn't it's a lost cause), PS1 (PSX v1.13 or epsxe), N64 (Pj64 and some hardware rendered plugin) and that's pretty much it.

>Why does zilmar have to be the one to do it?
Because Zilmar dictates the plugin specification. If he refuses to support whatever changes are necessary, it won't happen.
>Nothing stopping anyone from using a different RSP/emulator, in the worst case scenario.
Said RSP would then no longer be complaint with the Zilmar spec. N64 emulation politics are bullshit, but they are what they are.
>What's the point of testing a game if the HLE implementation isn't anywhere near complete?
Because...
>The microcode can easily be dumped, so anyone can read the file and implement HLE based off that.
You need to actually run the game in order to dump the ucode. Especially since sometimes N64 games use more than one ucode. You need to be able to study the game running to get a clear picture of how it works.

I was told that my laptop is very poopy for the PS1 emulator or Nintendo 64


And I just downloaded the ZSNES


And recommend me super nintendo games?


I just play video games Rated K-A (KIDS TO ADULTS) on the ESRB


I hate RPG's


I hate the games of the legend of Zelda.


I like soccer games


I like Racing games


And I do not like violent games at all

I think he just reversed-memed on you guys

>You need to actually run the game in order to dump the ucode.
You can do that with PJ64's RSP. It has the option to dump microcode, when using LLE.

>Said RSP would then no longer be complaint with the Zilmar spec.
Still better than nothing, right? The scene needs competition anyway. There's nothing worse than having a monopoly.

>If he refuses to support whatever changes are necessary, it won't happen.
I honestly doubt he would refuse anyway. For one, he loves HLE. He also does not mind having per-game settings. He did a workaround in the RSP to force LLE for Resident Evil's mpeg video or w/e it's called, because HLE graphics plugins don't handle that ucode.

Does anyone know what the actual differences are between recent dev builds of Desmume and the 0.9.11 official release?

should I even try playing nes game or just skip it and start with snes

you should always try

has anybody else successfully used retroarch vulkan on ubuntu 17.04? I get these error messages:
pastebin.com/m8q4mSpu

I'm using the daily ppa.

forgot to mention I'm using intel graphics on mobile haswell

Is it a bad idea to put your emulators on your SSD and your ROMs/ISOs on your storage drive? I do it and occasionally experience hitches in PPSSPP and PS1 emulation in Retroarch.

>I was told that my laptop is very poopy for the PS1 emulator or Nintendo 64
As I said, PSX v1.13 or epsxe for PS1 and Pj64 with some hardware rendered video plugin is the lowest you can go, if those don't work, PS1 and N64 on your PC will be a lost cause.

>And recommend me super nintendo games? I hate RPG's, I hate the games of the legend of Zelda And I do not like violent games at all
Nope. Also, the super reddit spacing's quite annoying, cut it out.

Mostly bug fixes for different games, probably.
I think changelogs are only posted when there's a jump from one stable version to another one-

Let's begin with the basics, did you checked if your iGPU is compatible with Vulkan?

>Let's begin with the basics, did you checked if your iGPU is compatible with Vulkan?
yes I have successfully used this configuration on archlinux and got vulkan on retroarch working fine there.

All worthwhile nes games have superios versions on later platforms.

better be a feminine penis under there

Someone should upload redump's PC collection to Archive.org.

What's wrong with you?

>no screenshots
shitty thread

Is it possible to transfer my PPSSPP save to my PSP? Going out of town and felt to continue game I played somewhat emulated.

0.9.11 is ancient. It doesn't even have the internal res options, does it?

This is what /r/emulation wants

help

bump

>PPSSPP
System > Cache full ISO in RAM
>PS1 emulation in Retroarch
Options > CD Image Cache

Then it wont matter if you have the ISOs on an SSD, HDD, or an ancient USB.

how the fuck am i supposed to use pcem? I boot it up and it gives me something called "sinclair". Where the fuck is windows?

I AM THIS MAD RIGHT NOW

thanks man

Hey guys I'm trying to set up PCSX2 and its all fine but it keeps running on my second monitor instead of my first monitor which is what I'd prefer, but I can't find out how to change this - does anyone here know how? Thanks.

Oh by the way, is there a way to access the Beetle Mednafen core options in Retroarch without needing to do it for specific games during gameplay? I tried to use the Quick Menu after loading the core but it says there are no options available.
Would be nice to not have to enable CD Image Cache individually for every game and need to restart each time.

Those options aren't pergame options.

It says it's creating config files for the individual games though, and when I enabled CD Image Cache while playing Crash 2 it wasn't enabled for other games I tried.

Mine always does this too. It's a mystery.

busy playing this beaut, next is live a live

In mame I am trying to play Mrs. Pacman (speedhack). When I begin the game, the game itself skips every level and I dont have a chance to play.

Does anyone know what is happening? Strangely enough I couldnt find anything relevant on Google. I was able to play this game fine for the first few days that I had it.

Well I hope they can afford a machine which can emulate PS3 and Xbox-Xbox 360 games.

So I setup retroarch. For some reason roms wouldn't show up even though I could start them straight from the directory.
>"retroarch needs no-intro roms"
Oh okay. Got that. So I got myself some no-intro romsets and scanned the folder.
>Still won't add all games to the list. For NES games Ducktales 2 is recognized. Ducktales 1 isn't

What the fuck. How?

Possibly one file has headers. Or not.

>DraStic becoming playable
What did whoever wrote that poll mean by that?
DraStic is extremely usable, it just needs a UWP Port at the very least (Exophase mentioned it could happen at some point, but that was around September of 2016, iirc) and multiplayer capabilities which I don't think they'll happen at this point.

Gtfo you retard

He meant Decaf.

Can I do something? Or do I just have to get another rom with headers?

Zeromus did nothing wrong.

>Zeromus did nothing
Yep, it was all yopyop.

correct

>use latest dev build of Desmume
>games are unplayable, running at wildly varying speeds with audio massively distorted no matter what settings used
>use 0.9.11 stable release
>everything works perfectly
Where does the "always use dev builds" meme come from again?

You can edit playlist file and add it.
What is crc/sha1 of Ducktales 1?

Works fine for me. These sort of issues are always a case of PEBCAK.

>These sort of issues are always a case of PEBCAK
Of course, using both versions in the exact same way with the same settings (ie. the defaults) is obviously a case of user error.

web.archive.org/web/20161120010732/http://wiki.pcsx2.net:80/index.php/Complete_List_of_Games

There you go.

>06B994B2
romhacking.net/translations/1947/

Get proper file.

RHDN for some ungodly reason somtime lists the unheadered roms hash for NES romhacks, even when you need an headered rom to apply the patch

No matter what I do, which options I change, Final Fantasy VII just runs horribly slow with Pete's OpenGL2 v2.9.
It runs at 7-9 FPS in the "Sony Computer Entertainment America Presents" and it just gets stuck right there.
Pic's my configuration, the only special game fix I've enabled is "Ignore small framebuffer moves", in case it's worth mentioning.

>epsxe

What emudevs that don't do anything emulation-related anymore you guys miss the most?

Rachel.

(You). Also, the exact same plugin works exactly the same on PCSXR.

You got a shit laptop.

>pcsxr

pcsxr is shit

Use a real emulator

youtube.com/watch?v=BtRfMSYtYsE

um is mednafen saturn emulation stalled? No new fixes in the recent releases.

Riddle me this

May 25, 2017:
SS: Synchronize end of SMPC clock change commands to beginning of vsync instead of beginning of vblank, per tests on a SS.

May 23, 2017:
SS: Reworked how the VDP2 rendering thread waits, to make Saturn emulation usable with the default OpenBSD kernel.

SS: Added emulation of the light gun("Stunner"/"Virtua Gun").

uh ya not much going on

I already am, thanks though.
Pointless answers aside, any way to fix it?
I already finished the game once with PSX v1.13 which is basically the same as completing it with Mednafen, but I'd like to go through it again with some visual enhancements and I don't have much free space left on my hard drive.

>any way to fix it?
See

If you can't run it on PCSXr or ePSXe you've got a shit laptop, there's no fixing that. Play the PC version instead.

The progress this emulator has made in the last 6 months is astonishing.

if he can't run an emulator hes not going to run the pc game

Maybe not the steam ver, but the original should be fine.

It's amazing what devs can do when they expect to be paid for it.

>I already am, thanks though.
I already am, thanks though.
Pointless answers aside, any way to fix it?

Oh, I see, I forgot to mention it. It DOES run onthe DX Plugins, the problem only happens with the OGL ones.

FFVII is a pretty cheap game and I can emulate it on the 3 emulators: PSX v1.13, Mednafen and epsxe.
I didn't noticed that I did not mentioned that it runs with the DX Plugins at the beginning, my fault, sorry.

Problem solved.

Not at all.

>i can't run the game
>the game runs by the way

Yeah, problem solved.

Heavy. But not as heavy as the coffin

>Ican run this game on X Emulators or with X Plugins but I'm trying to find a way if I can run it with Y Plugin instead because I already finished the game with X Plugin and it doesn't allow me to use graphical enhancements like Y would.
As I said, not at all.

You're kind of retarded for saying "not much" after reading the other post

nobody cares about openbsd