/emugen/ - Emulation General

The thing is I want him to use his PC normally too.

I'm talking about a 65 year old man who does not give a single shit about RA or how it works.

Make another user account for the sole purpose of launching that when signing in?

Hey my dudes. I'm about to head out and buy a new usb controller, so what 3 fightan arcade games should I emulate? What has the biggest character pool?

I was trying to use Ishiiruka Dolphin's "compile shader cache on startup" feature yesterday, but it didn't seem to work. I had it enabled in the graphics configuration menu, but there was no delay on startup, and the usual pop-in still happened when new areas were loaded. Is the feature not functional yet?

It's exclusive to RA because RA cores don't save the srm to the hdd when you save like emus made by normal humans who think clearly. Instead it only saves it when you close RA. Great for crashes!

So romcenter is saying my CPS2 roms need key files. Where do I get those?

It saves if you enable the interval or close the core/content, not just RA.

However a way to force it would be nice.

The interval should be the default if he wants RA to be plug n play friendly

The problem with the option is even with it on an interval unless you count on your fingers and toes you still can't trust it.

If it's short (ie 10 seconds) then you're raping your drive and hardly helping it stop what it was intended to do.
If it's long (ie 5 minutes) then you're highly susceptible to quitting early and then complaining you lost your save.
If it's in the middle (ie 2.5 minutes) then you're in a guessing game of whether it's been long enough or not.

The latter two get to the point where the only guaranteed way is to manually close the core, then why use the option?

If I had to throw a crude idea together, I'd start by adding an option to the quick menu of my "Force" idea and to its right (like an option but you can't configure it) the current time until it automatically writes.

Here's a suggestion: make it so when you save the game, it writes the srm

Really complex I know kek

But I already have heard SP's protest that "file-based save abstraction is old hat maan, RA is going the cool new way!"

An option for it, maybe.

I don't know the name of the game, but probably in the Mystery Dungeon series. There exists that game for the Nintendo 64 which writes to the save RAM every time you take a step.

Writing out the SRAM every time its written to globally (every game, which may vary) is questionable. Are we loading from the disk every time too?

Granted, just as much as you want RA to change and conform to you so does it.

Also before you say it
>but old emulators did it all the time and were fine
Doesn't make them any better for it.

Just have to make exceptions for weird games like that. How does PJ64 or regular mupen handle that game?

How do I make mameui show only my games that are working, instead or having to search for them in a huge list? Under available it only shows marves vs capcom, but I have a few other games that are audited, green, and working just fine.

>exceptions
Where do they stop? Who determines if an exception is needed?

If I had to guess, constantly writing it out :^)

If the game writes every 2 seconds then make an exception. If it doesn't then don't.

I'm probably fine with that even though it's HDD destroying. Not like I'll ever play that game. RA seems to do things to take the minority of cases into account even if it inconveniences people for the majority of cases, which rather makes sense given how SP wants to support even the most niche platforms, even when doing so harms the platforms which are more prevalent for emulation. He's such an odd man.

>If the game writes every 2 seconds then make an exception. If it doesn't then don't.
The only sane way to do that would be to handle them automatically... on an interval.

>save normally, write out to drive
>start the clock at 10 seconds
>if another sram update occurs in these 10 seconds store in RAM and wait
>after 10 seconds pass, write out whatever we have in RAM
>repeat indefinitely

Yeah but you only need to make games like that use the interval. For normal games you want the peace of mind of saving when you save to avoid crash loss and other things like that.

Might instead be worth making it so the core can't crash frontend or at least to the point of being fatal. Similar to how difficult it is for one program to bring down an entire operating system.

However, since it is its own libretro API implementation that's probably not going to happen.

>Might instead be worth making it so the core can't crash frontend or at least to the point of being fatal.
Seems to me that would be very hard to do.

If even the core crashes you still lose your progress though right?

Depends on how the frontend "would" handle the core's RAM.

If the core crashes, but the frontend doesn't and can keep the core's working RAM around it would be simple.

I'm no genius software engineer, though.

I kind of doubt SP has it set up so that it keeps the RAM if the core crashes though. But that's just what I suspect.

Wouldn't matter if the frontend goes down with it.

And instead of SP working on stuff like this, stability, usability, comfort features for all users, he is fiddling with experimental vulkan renderers that 20 people will use.

He's one man.

I don't want to sound like SP but it is open sores, go for it.

We're here to criticize his priorities in what he does though. He doesn't need the vulkan renderer. He could be doing better things which would benefit all users.

He doesn't work on Vulkan.
He is working on spaces. Add space, remove space, repeat next month. Very valuable thing.

github.com/libretro/RetroArch/commit/e2b27f6dc7bfa3d70c7b88b7198665ae30565df6

Can he make me a safe space?

...

Anyone know why setting RA to vulcan causes some cores to chug? Is it just because the cores that don't have a specific vulcan renderer won't actually work properly unless set to GL?

>new 2
>new 1
>new 5
>new 3
>new 4
>new 6
Seek help

The order of those news triggers my autism.

>Here's a suggestion: make it so when you save the game, it writes the srm to disk unless it was already written to less than what the interval time is set to
FTFY

Still have the problem of a stupidly long interval and being unsure of when it last wrote out.

Can't it just even if it's on intervals just close the core=final srm save?

The main problem is arbitrary crashing or closing of RetroArch where it can't catch it in time and discard it.

The former of which being the main culprit.

Setting up FF9 using PCSXR but can't seem to get the font nor the backgrounds look as good as the player models. Any advice? More concerned about the fonts than anything.

It's probably gonna sound very stupid but how about having another independent process deal with the .srm thing or mirror the .srm then even if you have RA crash or you forcequit it nothing is lost?

You'd be a master of the universe

Unless you're playing in a 640x480 window the text is gonna look a bit shit.

Those are prerendered aspects of the game. They will never look as good as uprezzed character models.

kek

>go to the wiki to check if there are any PC emulators of note I didn't know about

>86Box: Recommended
>PCem: Not recommended

Mooch, stop shilling your daddy's. It's a fuckton of revisions behind. It's only recommended if you need to use floppy disks that don't work on PCem.

>suddenly all my cgi scenes (cutscenes and intro cutscenes) are black and white
>non of the options seem to fix this

What are some games I can emulate that have good hentai porn I can jerk off to later when the characters are still fresh in my mind

I don't know how people can tolerate using either, they're so fucking painful to use and require a near endless tweaking of settings.

Dragon Quest

ePSXe is still good right?

No

Is there any reason ZSNES goes black whenever I try to full-screen it? It says direct draw error and I can't find any fix online for it. I know ZSNES is bad but I have it set up with steam where it would be a pain to switch emulators

Pretty much any mainstream fighting game familia.

Is there any way to play snes multplayer online? I just made my custom Haikyuu team in Hyper V-ball, and I'll fuck anyone up.

Snes9x has netplay if you use Hamachi to create a LAN. Otherwise you can use >ZSNES

>ZSNES
>2016

How do I find dudes to hamachi with though?

You don't. SNES netplay isn't really a standard thing and only two emulators support it, Snes9X technically only on LAN.

Unless you have friends that want to play or you can convince randos, you're shit out of luck.

Wanna play some Hyper V-ball with me?

My guess is that their vulkan code's just slow. I tried using it for frankenmupen with software renderer and it was slower than OGL... OGL is slow too, so I was disappointed that vulkan was even slower.

So vulken causes massive slowdown in Simpsons Hit and Run. And since it's a racing game, it becomes virtually unplayable.

The fine folks at Dolphin do it again.

>The fine folks at Dolphin do it again.
Maybe Vulkan itself is to blame.

mostly still shitty vulkan drivers across the board.

the graphics industry is the one at fault here, they fucked up GL before too.

Now show the zsnes input lag

You don't have directdraw's dlls installed probably

>mostly still shitty vulkan drivers across the board.
>the graphics industry is the one at fault here, they fucked up GL before too.
They will never not fuck it up because it's in their interest and every corporation's interest that people use DX12. Until you get a FLOSS GPU company who beats NVIDIA and AMD at releasing proper drivers and offers an alternative to the Microsoft monopoly on Big Gaming, open source graphics solutions will be nonstarters.

not really, vulkan is available on android, d3d12 not so much, and d3d12 doesnt help you out on ios either.

multiple reasons for companies to look beyond the direct3d ghetto. windows phone is a massive flop asis.

couldn't someone at microsoft leak the source code to D3D?

>not really, vulkan is available on android, d3d12 not so much, and d3d12 doesnt help you out on ios either.
......user. Android and iOS are irrelevant for Big Gaming. It's go PC or console or go home.

>vulkan is available on android, d3d12 not so much, and d3d12 doesnt help you out on ios either.
Remember when people said this about OGL? then it turned out OGL on Android, Desktop and IOS were so different you had to write three different OGL renders anyway or you had to go back to OGL ES 1.1?

What would that accomplish?

>tfw the nearly abandoned DirectX 12 renderer which one guy spent literally a couple of weeks on is still better than the Vulkan backend which the entire team has spent several months on

...

kys

>What would that accomplish?
I think it could revolutionize the industry since D3D always seems to be on top.

Doesn't matter when you still have no choice but to either go OGL or Vulkan on Android.

You can talk all the shit you want, but D3D ain't happening on mobile and Windows Phone is a pathetic failure that has never caught on and never will. Pathetic MS nerd stuck in his ways.

Direct3D is not on top, MS just enforces better quality out of graphics industry vendors' drivers.

Khronos' refusal or inability to do that is kinda what causes this 'misperception' that GL/Vulkan is behind when it actually isn't, it's just graphics industry companies refusing to get their shit together and treat it as seriously as a D3D driver, because they know that if they don't, MS gives them a good right spanking. And that's how you should treat GPU companies as a platform holder, a pimp giving his hoe the proper bitchslaps from time to time.

It wouldn't, you couldn't just compile D3D on Linux or something, It's tightly integrated into other subsystems.

You can't utilize stolen code anyway and D3D's documentation is readily available, we know exactly how it works internally.

>it actually isn't
But it objectively is, GL's tooling is literally non-existent, the documentation is a level beyond bare bones and the API is archaic.

Even Carmack admits that D3D is better than OpenGL nowadays.

>Even Carmack admits that D3D is better than OpenGL nowadays.

That's news to me. Kind of refreshing to hear, considering all these people shilling OGL and Vulkan, claiming false positive things about them. I remember recently reading a leddit post saying Dolphin's Vulkan backend is faster than D3D12's, yet people here are saying otherwise..

>You can't utilize stolen code anyway and D3D's documentation is readily available, we know exactly how it works internally.
I guess that's good that we know how it works. Do you think it's possible to improve OGL / Vulkan by studying how D3D works? It's sad that I can't even use OGL for blitting w/o seeing a performance decrease, compared to using DirectDraw or even D3D.

Let's be honest here, Carmack is not relevant anymore. His megatextures gamble flopped big-time and it started to seem around the mid-00s that he was turning more and more corporatist shill.

Who wants to go work for a garbage company like Facebook anyways when you have that kind of resume.

Also, the new id Software tech leads say the opposite, that Vulkan is much better than D3D12. id Software managed to live on post-Carmack, and other good engine leads took his place.

Plus I think you are taking Carmack's comment on D3D out of context anyway, he might have said this back in the D3D9 vs. GL 2.x era, which, yeah, that would be the case. D3D vs. GL/Vulkan is far more evenly matched now. Khronos just screwed up a bunch of times in the past with 'GL reboots' that didn't go anywhere and just led to a massive delay.

Most OGL shills are indie game devs who are writing very simplistic game engines with little regard for performance, support or stability.

Wolfire is the prime example of this, they have had to rewrite the entire graphics portion of their game multiple times because extensions they used extensively barely work on some platforms/drivers/card combos.

I was using nestopia and just found it to be less smooth.

>per game hacks

Fuck off.

Anyone wanna play some Hyper V-ball?

What's the current standard for PS1 emulation on Android? Retroarch is hiding the contoller overlay every time I sneeze for some reason and is generally uncontrollable, and epsxe fucking freezes every time I try to switch to another app.

PSXRearmed I think. Check the wiki. There's a page about emulating on android.

> Most OGL shills are indie game devs who are writing very simplistic game engines with little regard for performance, support or stability.

id Tech 3 (the cornerstone of COD game engines) started out as an OpenGL renderer.

Source engine is still a heavily modded Quake 1 engine all things considered, and that one received an OpenGL port before it ever received a D3D port.

So you're talking a bunch of shit honestly. Most of the 'major engines' still are essentially dusted off Quake engines, and therefore still vindications for OpenGL.

>If it's short (ie 10 seconds) then you're raping your drive

Nope. It only saves if the save changes in memory.

github.com/libretro/RetroArch/blob/master/tasks/task_save.c#L150

>Most OGL shills are indie game devs who are writing very simplistic game engines with little regard for performance, support or stability.
I have definitely seen some shills disregard performance, support, and stability. They provide no solutions other than buying new nvidia hardware, or the generic "upgrade your drivers"... It irks me when they're in denial about the problems, or when they flat out lie and say OGL / Vulkan is faster when it really wasn't.

flopped? DOOM still uses it.
They never made their engines with third party licensing in mind.

The problem with Vulkan is that people who are trying to get an edge over the competition sell it like snake oil. If your software supports Vulkan and the competition doesn't you're going to try to oversell it as the 2nd coming of christ in silicon form.

Vulkan is nice from a dev standpoint, it lets you do some things more cleanly without having to worry about obscure driver behaviour. It breaks this hellish loop of drivers trying to 2nd guess what games are doing in order to run faster, only for the next game to 2nd guess what the driver is doing in order to run faster, etc... Now the game devs can be explicit about what they want to do with the hardware instead of doing dark magic and hoping that the various drivers will catch on. The bad part is that it's new and still not extremely well supported compared to, say, OpenGL 3.

But from an end-user perspective it doesn't really matter. Shit coders are still going to make shit code and good coders are still going to make good code. Vulkan might get a slight edge in certain corner cases when it lets you do something in a more optimal way than GL or D3D but nothing ground breaking.

The truth is that gamers, especially the PC "master race" retards like to pretend that they know a lot about technology but most of them are just parroting what they've heard elsewhere. Be it Vulkan vs. OGL vs D3D or nvidia vs. ATI/AMD or Windows vs. Linux. The practical reality is always more nuanced and if you're a behaving like a fanboy for a 3D API or a semiconductor manufacturer you should reevaluate your life choices.