/emugen/ - Emulation general

>Just emulate a frame ahead for every possible button combination on the controller, and then when the user presses whatever buttons for that frame load the state that matches.
You would need a PC that could run a SNES emulator at 3,715,041,853,440fps to do that.

NES only has 2^7 (128) combos (dpad only really needs 3 bits), which is already pretty doable.

>3,715,041,853,440fps
Where the fuck did you even get that number? It would only need to be 2048 for single player SNES.

youtube.com/watch?v=lBwLSPbHWoc

Predictive emulating of every possible input is absolutely absurd. And assuming inputs are not buffered for an equally absurd amount of time before running anything, it would shave off less than a single frame.
Such techniques are still useful however, for netplay. But predictive specifics rather than just emulating every single possibility.
en.wikipedia.org/wiki/GGPO

But you don't even need that shit to beat FPGAs. Just using frame delay to wait to process everything, inputs included, until near the end of the frame, then pushing the entire screen out with as little buffering as possible, can already cut down almost all latency.

Using a monitor with a higher refresh rate to scan out that screen in a fraction of the time helps even more.
Using a CRT at 120fps or higher would be fuckawesome for the double scanout rate, and still great for motion if every other frame is blacked out.

I could sperg on this nonsense all day.

Absolutely absurd, sure, but not impossible.

truly a dead general

Not impossible, but quite infeasible for most systems, and incredibly wasteful regardless.
Even using NES=128 and SNES=2048, that's still a large exponential increase in performance cost. One large enough it could be overshadowed by simple frame delay.

If you could run 128 different variations of the same frame within 16ms, you could easily just wait 15ms or so to do anything, before quickly sampling all inputs, and running that one frame RIGHT THEN before vsync.
And you know what? RetroArch can already do that.

Yeah, but that's still 1ms plus 16ms of emulated latency. You would have to do way better than 128frames/16ms, but if you did you could do predictive emulation AND frame delay and go below 16ms.

Can I run gamecube games from disk on WiiU using nintendont?

can't get full speed in star wars episode 1 racer but world driver championship runs at like 300 VI/s. wtf?

16ms from what, exactly? Graphical buffering before scanout? Predictive emulation wouldn't prevent that whatsoever.
For emulation's sake, with just frame delay, the single frame should be entirely finished AND output within that 1ms.
You should have 0-16ms delay while scanning out, and any amount of frames for buffers with modern systems, but again, that's irrelevant to the argument here since predictive emulation itself does not stop it.

Predictive emulation would remove a lot of frame delay's use.
You would only use inputs to lookup which pre-emulated frame to keep. It would no longer have to WAIT to run the whole frame all at once. Just to look it up. That's like the entire benefit, to the avoid real time cost. But it's so intensive that realistically nothing can benefit from doing so.

It would be nice to have a open source backed MAME level accuracy FPGA board for old school arcade games with a jamma connector. An instant on low powered cabinet would be great.

On NES and SNES and probably other systems games almost always buffer input for 1 frame.

youtube.com/watch?v=x2Y9orESg8A

You want to get rid of that input buffer lag too? You'd have to either hack out that buffer so inputs are direct, which would be useful even without this predictive emulation; or emulate BOTH frames in advance, with ALL possibilities from each, then rollback and do it again. Which doubles the performance cost yet again, while also adding extra overhead.

Again: Stupid, but not impossible.

And again, incredibly infeasible. Try running NES at 25600% turbo right now. Not even counting the overhead to manage 128 variations of 2 different frames, it's actually intensive.
SNES at the hypothetical 409600% would be downright impossible on modern hardware.

>SNES=2048
What is the calculation for this number? Are you taking into account that realistically only two directions can be pressed at once?

To be fair you could prune that pretty aggressively and still manage 99% of the cases. On a NES you can probably assume that latency on start and select is not too critical for most games, that leaves you the direction keys and A/B.

The number of direction buttons active at the same time is limited by the hardware itself, then you have A and/or B pressed.

So for the directions that's 9 possibilities (nothing pressed + 4 directions + 4 diagonals) and for the buttons it's 4 possibilities (none, A, B, A+B). That's 36 possibilities for every input sampling.

For the SNES it would be 9 directions times 2^6 button combinations (not counting select/start) or 576 possibilities.

Just going by You know, a bit for every button, then 3 bits for the dpad since it has 8 possible directions.
Though now that I think about it, no dpad is also an option, making that part x9 instead of x8 (3bit), so it's 2304.
Still not too happy about 7200%.
It would probably be wiser just to hack out the buffer and make games work without it, rather than emulate it all so redundantly.
>not counting select/start
So what do you do when those are pressed? Just drop the predictive emulated frames and run a new one?

>Just drop the predictive emulated frames and run a new one?
Not him, but yeah you could. You could have per game setting for low priority buttons, that would just drop some frames, and even buttons to just flat out ignore. Sonic comes to mind as you really only need one button.

Also thinking about it, you couldn't do a dpad in 3 bits; it needs 8 directions AND no directions. Though for Sonic again you could drop the up input and that's only 6 states including none.

>It would probably be wiser just to hack out the buffer and make games work without it, rather than emulate it all so redundantly.

I'm not sure NES games significantly buffer input. If it works like on the game boy the buttons are simply available in a register (one bit per button), you just have to say if you want to read the direction or start/select/A/B because there's only 4 dedicated pins and 4 buttons so they share. I think the real latency is between the moment the game reads the input and the moment it's done generating the frame (updating the game logic, updating the sprite/background/whatever position and then waiting for the GPU to draw the frame).

On an emulator this could be done super quickly but then you have to make sure that the frame gets displayed immediately on the monitor instead of waiting for a vsync. High framerate monitors would help with that I suppose.

>So what do you do when those are pressed? Just drop the predictive emulated frames and run a new one?

Yeah, you'd have to rewind which would probably cause a small glitch. If you really value super low latency and the game doesn't use select/start a lot it might be worth it I suppose.

But in the end I like the technical challenge of doing something like that but I'm not sure it's really practically necessary for anything. I know people like to masturbate a lot on input latency but I highly doubt that most people could really detect a

But again, outside of multi-frame prediction to alleviate any potential game-side systematic buffering, frame delay more than covers the issue entirely without the absurd cost.

On multiframe buffering for that point though, wouldn't that require reading values from those buffers to check against immediate inputs?
Meaning hacks to directly write to them could be written anyway, without absurdly emulating several possibilities per frame.

zeromus did literally nothing wrong.

>last paragraph
this

Most of this shit is just the death rattles of the hardware collecting trend, and the people who bought in trying to justify spending so much money. Just like retarded audiophile shit is just the remnants of people who spent ridiculous sums in the late 70s on reel-to-reels and other analog equipment that would be completely outclassed in 10 years.

>the death rattles of the hardware collecting trend
Oh I don't think it's going anywhere. People are collecting stamps and bar coasters, I'm sure they'll keep collecting old consoles as well.

I don't have any problem with people collecting stuff and preferring the real thing over an emulator because of sentimental reasons, what's annoying is when they try to rationalize it with terrible technical arguments.

>what's annoying is when they try to rationalize it with terrible technical arguments
That's always the case. The guy who spent thousands of dollars collecting CRTs is going to shit on shaders, regardless of how advanced they are, just like 'cycle accurate' is never going to be good enough for the guy who spent $200 on earthbound.

I don't know if someone will ever be able to make use of this but I decided to drop it anyways.
It is a .patch file (Watchdog_V3_3934+.patch) that it's supposed to add an option called "Watchog" to Dolphin.
I remember that messing around with its values allowed to get some insane performance boosts on extremely low-end hardware.

I just found it saved in my old af external hard drive and decided to share it instead of just letting it die over there, specially because it's kind of a miracle that it still works.

I don't know how it's used (maybe you have to use it along Dolphin's source code and compile a special build? idk) so good luck.
a.doko.moe/mozqhl.7z

Heh, well that doesn't sound sketchy as fuck or anything.

>Distributing source code patches in 7zip archives on some random website
What the fuck are you even doing.

The patch itself looks harmless, although I don't fully understand what it does exactly.

>helios wants to remove exclusive ubershaders from the ui
Has there ever been a single positive change he's been responsible for?

>What the fuck are you even doing.
Sharing an addon for an emulator in a place about emulation, that's what I'm doing.
I'd appreciate some suggestions on how should I share this kind of stuff, if I ever need to, in the future.

For plain text use one of the many, many paste bins out there. There are a few dedicated to hosting source code with proper syntax highlighting as well. gist.github.com is a possibility: gist.github.com/anonymous/a97bfb957e265f5d6d450f7671d8aed8

I didn't even notice that it was a fucking text file, thanks dude.
pastebin.com/QAL9TLdT

How do I stop audio crackling in project64? I'm trying to play ep1 racer but it always crackles in the player select screen no matter what I do.

Plugins I'm using:
Azimer .70 WIP 10
Angrylion rdp plus
Hatcat RSP/PJ64 RSP

I've tried messing with advanced options in the audio plugin but don't know what to change. I've tried both RSPs but still get the same issue. On the wiki it says angrylions should run every game full speed so it should not be an issue. I'm using an 8700k.

Maybe if you donate enough shekels they'll add dynamic rate control.

>ep1 racer
Why play the really shitty, heavily gimped console port? pcgamingwiki.com/wiki/Star_Wars:_Episode_I_–_Racer

well if it happens there then I'm sure it happens in tons of other games to so better to fix it now.

You "fix" it by going with parallel for now.

apparently I need pj64 2.4.0.452 which isn't available anywhere because rdp plus is fucked on newer versions. Banjo tooie for example either doesn't boot or has severe graphics duplication.

His suicide in a few years

ya but that is slow as shit compared to pj64. Can't even run world driver championship at full speed.

Works on My Machine™

specs?

...

Stock i7 7700k + GTX 980

Thanks, but I'll wait for beetlestation or ruststation-next.

how does it run without discrete graphics?

Maybe he should fix hybrid mode for non-AMD users then.

I have no idea since I've never even installed intel's drivers

>Remove options from the UI
I hate this shit. If you don't think the common (IDIOTIC) users can handle the options, shove them into an 'advanced tab' and put up a warning to not fuck with the shit. NEVER just remove them for fuck's sake.
Thankfully forks allow shit to be visible and usable, like ishiiruka with DX9, async shaders, texture scaling, and whatever other silly little things they add.
But I still wish mainline Dolphin wouldn't fag so much over options.

>But I still wish mainline Dolphin wouldn't fag so much over options.
It's just Heelios being a bitch.

github.com/dolphin-emu/dolphin/pull/6196
github.com/dolphin-emu/dolphin/pull/6208

>Still not merged
Disgusting.
There is also still no way to disable or configure that mipmap heuristic thing without recompiling the program, to my knowledge.
Bad UX my ass, display ALL the options available.

I just love how dolphin devs try to pretend everybody listen to others opinions when in reality there's always the one cunt that thinks he knows better.
It was already bad with neobrain but he at-least had the excuse of making meaningful contributions outside of that, now you have readme editors making "works on my machine"-tier modifications.

>the one cunt that thinks he knows better.
*strongarming everyone else.

forums.dolphin-emu.org/Thread-vulkan-hybrid-ubershaders-or-exclusive-ubershaders?pid=464220#pid464220
>GL does not have issues with ubershaders. All backends work fine with ubershaders in both settings. There is some small issues with ubers on nvidia GPUs on Vulkan and GL but apparently only in extreme cases.
>but apparently only in extreme cases
>"""apparently""" only in extreme cases
He doesn't even understand the issue.

> Software emulation can never match the latency of FPGAs.

> Hold my beer

forums.libretro.com/t/an-input-lag-investigation/4407/597

>extreme cases
>Nvidia GPU
>OGL/Vulkan backend
>anything that does shader compilation at all meaning everything
Xtreme Usecases™

> Software emulation can never match the latency of FPGAs.
> Hold my beer pt. 2

reddit.com/r/emulation/comments/7xh249/input_lag_compared_snes_mini_vs_retropie_vs/

How much input lag is there by plugging a PC to a CRT TV through a VGA -> RGB SCART cable and using RetroArch?

Without a high-end CPU, probably 2 frames (~32ms or 3.2% of a second) over hardware.

depends on the cable

anything that isn't an intel integrated gpu is an extreme user case for those retards.

>Level 6-1 has an infamous bug with pushing a green button. Which hangs most emulators and relies on unstable behavior.

romhacking.net/hacks/3875/

Which emulators?

Everything that isn't Higan/bSNES accurate.

A
Y
Y
Y
Y

MAME is a failed project and everyone involved should kill themselves.

Recaptcha is going to return with Mednafen 64 and will blow out all the haters and losers.

Ebin

forums.dolphin-emu.org/Thread-ui-remove-fullscreen-resolution-ui-pr-6196-from-helios747-no-no-noooo

MAME more like LAME am I right

I'm noticing a very large trend amongst all the issues in Dolphin, every single one has the user trying to run Dolphin, maybe we should remove the ability to run Dolphin.
t.Helios

It's always a slippery slope to enable your users to be retarded. You'll always find somebody dumb enough to fuck up the most basic tasks. So you end up with Gnome-tier retardation where clueless users are always incompetent enough to break things and "power" users can't get shit done because the options are too well hidden (or even disabled completely).

UI design is complicated and it shouldn't overwhelm people with options (but anything that's not RetroArch has ways to organize options decently). Removing options altogether because you're worrying that people are going to mess it up is completely stupid however. Hide it an advanced menu, add a more descriptive text etc...

>but anything that's not RetroArch has ways to organize options decently

But options are organized in submenus in RetroArch too

Not core options unfortunately. Also you can't have any kind of inline hint/description for what the option does, and since all options are lists of strings under the hood it's a bit of a pain if you want to have a numeric option, IP addresses, file paths etc... It's really a sore point of the libretro API.

Oh and while I'm thinking about it: I always thought that the "Quick Menu" was oddly named. To me it implies that it contains shortcuts to commonly used functions and options that are otherwise accessible through the normal menu. Except as far as I know it's not the case, for instance I think that the Core Options are only accessible through the QM.

Quick Menu is used for stuff that applies at runtime only like shaders or control remapping.

Right, but the naming doesn't really reflect that which is my point. Quick Menu reminds me of the thing you find in some videogames (especially when using a gamepad) where some functions are made quickly accessible. Sometimes you can even configure which functions go there.

Instead RA's "Quick Menu" is no quicker than any other and is the only way to access these runtime functions. It's a very minor nitpick but I remember that I thought it was slightly confusing when I started using RA. "Runtime options" would be a bit more descriptive, although I'm not sure if the average user would would know what it means.

forum.fobby.net/index.php?t=tree&th=1639&start=0&
>retroniggers are still reporting retroarch only issues to standalone developers

How retarded do you have to be? The guy even states that it works in standalone so he's perfectly aware of the difference.

>How retarded do you have to be
he is a windows 10 user

There's literally nothing wrong with Win10 as long as you use the right version

>as long as you use the right version
The only right version is the one that isn't installed
Windows 10 is a piece of shit

>the one frame delay that real hardware has
nigga what you smokin

He's right, meme less and think more.

this is exactly how RA's GGPO-style netplay works... except it emulates several frames with several different guessed button combos... that's why your machine need to be able to run the game at 5x the native framerate to netplay with that core

What's wrong with LTSB then?

I didn't know it guessed input. That seems absolutely unworkable for consoles with analog input.

>nothing wrong
randomly reboots itself no matter what you're doing, whether you ask it to or not. even server 2016 does it

That's not how it works at all. It emulates normally with your inputs and whenever it receives inputs from the other player, it will load a state from the time they actually pressed it (rather than when you received it) and run really fast to catch up to the current time using your and the other's recorded inputs.