Thank for the info as soon as is merged to master will merge it here.
Thread Rating:
|
[UNOFFICIAL] Ishiiruka-Dolphin Custom Version
|
|
07-30-2014, 04:12 PM
(07-30-2014, 04:04 AM)neobrain Wrote:(07-30-2014, 02:20 AM)Linear Wrote: I'm not saying that I'am an expert here, but a few years ago I've talked to one of the developer of MGS Twin Snakes and he told me that this game is running in fps async mode and controls its speed by audio speed. He explained that in this way sudden fps drops will not affect general gameplay. Sometimes console hardware are not capable of running rendering at constant 30 fps.Just because these things all contain the expression "async" doesn't mean they are the same or even just work similarly. Please don't say stuff like "this is how it works on the real console" if you don't know what you're talking about. If you are thinking that I talking about something that I don't know about - then why ex-developer of GC title said that specific thing about speed control by audio unit and proved this ? I'm not a coder or developer, but also - I'm not a noob in technical specifications... And i was first who discovered proper speed configuration for MGS3 on PCSX2 - it was the similar case when you have to use SPU async mode to control gameplay by audio (and animation keyframes) because real PS2 uses this method. The same old reason - sometimes real consoles can't provide rendering at constant 30/60 fps, and sudden framedrops should not affect sound stream or general gameplay mechanic. (P.S. - looks like Audio framelimit + VBeam + EFB2Ram is the only proper config for Wii SHSM game... Only in this case it acts like real Wii... I tested it many times already) The man will die, but not his ideas
07-30-2014, 05:53 PM
Linear: Stop making an ass of yourself, you don't understand how emulators work. PCSX2's most accurate form of audio, guess what, is synchronous. As a bonus, they implemented other audio methods that have the possibility of crashing BECAUSE THEY ARE NOT HOW THE CONSOLE INTENDS IT. Same thing with GameCube/Wii, it uses synchronous audio.
You'll notice in games like Last Story, when the Wii actually slows down, and Dolphin emulates that slowdown, the sound doesn't get choppy. The only time the sound gets choppy is when Dolphin slows down because of the computer not being strong enough. When the real console can't handle 30/60, Dolphin emulates it right already, and audio won't chop up. Period. Play the Spyro games if you want proof of that. P.S. Saying that a game works only on audio framelimit + Vbeam + EFB2Ram is really useless if 1: You don't explain why, 2: You don't report the issue, 3: ... I don't know why I'm wasting my time. I feel bad for the developer you talked to that you're misconstruing their words, I'm certain they knew what they were talking about. 07-30-2014, 07:35 PM
(07-30-2014, 05:53 PM)JMC47 Wrote: Linear: Stop making an ass of yourself, you don't understand how emulators work. PCSX2's most accurate form of audio, guess what, is synchronous. As a bonus, they implemented other audio methods that have the possibility of crashing BECAUSE THEY ARE NOT HOW THE CONSOLE INTENDS IT. Same thing with GameCube/Wii, it uses synchronous audio. First of all - I don't like the way you talk and the way you think that I don't understand emulation ! - my modchips for previous generation of consoles works well enough ! Looks like all my discussion is offtopic here so I will finish it. But to make things clear: 1) Things that you explained here is about synchronous audio, but I talking about asynchronous video speed, limited by audio unit !!! Skidau did a great job by making VBeam speedhack, which help to run many games more smooth and fast, but this thing require a proper speed control function... And the only one which is works correct in this case - audio framelimit ! 2) Looks like you need some proof of this case = I already explained and reported here. And check this games to see for yourself = Wii SHSM with audio framelimit + Vbeam + EFB2Ram and ReZero with audio framelimit + Vbeam + EFB2Ram. (some other games need additional config, but looks like even LastStory runs better with this configuration too) 3) When real ex-developer of GC title says that their video pipeline limits their fps in game by audio unit and when SPU developers (PCSX2 or Dolphin) creates this function in their audio backends for situations like this - all this is a solid proof. ------------------------------------------------ P.S. - many thanks to all real Dolphin developers and plugins (backends) developers ! You guys are real heroes ! There are many things that your software emulator makes a lot better than original hardware does ![]() P.P.S. - Tino, sorry for the flood in this thread, I just tried to inform about some important features. The man will die, but not his ideas
07-30-2014, 08:12 PM
I really didn't want to comment on this but here goes.
I have often used the vbeam speed hack to make certain games run smoother, but it has only ever worked with the audio frame rate limiter also being on. If, when using the hack, I set the limiter to auto or some other value the game will run at anything up to 200% speed directly corresponding to the frame rate limiter. Gamecube games especially. In some cases, the perceived pitch of the audio will also be affected. So the removal of the audio frame rate limiter stops the vbeam hack from being useful, and I haven't yet found a workaround. On the games that need it I am sticking to an earlier revision until the PR is reverted, or I get a faster PC. I will leave the debate as to whether or not people should be using speed hacks in the first place for another day. I don't necessarily agree with what Linear says either, even though myself I have written professional audio software that uses the real time audio stream as a clock source. I suppose someone might have written a game that works that way but its not for me to say. 07-31-2014, 05:42 AM
(This post was last modified: 07-31-2014, 05:43 AM by marcosvitali.)
Well, My post was deleted, but to clarify some part was not off topic. Im programming a DX11 bytecode shader generator to solve the slowdown because of compilation time in games, and side effects like FIFO Resets in games like FZero and Metroid Prime. If this functionality works fine will be merged in Ishiruka with Tino help, some devs in IRC has different opinions about it.
07-31-2014, 06:38 AM
(07-31-2014, 05:42 AM)marcosvitali Wrote: Well, My post was deleted, but to clarify some part was not off topic. Im programming a DX11 bytecode shader generator to solve the slowdown because of compilation time in games, and side effects like FIFO Resets in games like FZero and Metroid Prime. If this functionality works fine will be merged in Ishiruka with Tino help, some devs in IRC has different opinions about it. I'm not seeing the point either. What were the arguments? (Made by what I assume delroth, neobrain and degasus?) 07-31-2014, 06:43 AM
(07-31-2014, 05:42 AM)marcosvitali Wrote: Well, My post was deleted, but to clarify some part was not off topic. Im programming a DX11 bytecode shader generator to solve the slowdown because of compilation time in games, and side effects like FIFO Resets in games like FZero and Metroid Prime. If this functionality works fine will be merged in Ishiruka with Tino help, some devs in IRC has different opinions about it. Wait, you did some Fifo work for this branch, and there won't be a pr to merge with master due to difference in opinions if i understood corectly? 07-31-2014, 07:03 AM
If neobrain and co disagree with something that automatically means it's shit and you should stop.
|
|
« Next Oldest | Next Newest »
|
Users browsing this thread: 5 Guest(s)


The man will die, but not his ideas 


