Actually, the UI is a key point of poor emulation performance when using either D3D or OpenGL due to not being able to lock the surface. Thats partly why the fullscreen menu was promptly removed.
Â
Â
It does not matter if you use Direct3D fullscreen with MFC, native Windows API or anything else. The VSync + GDI restriction/bad performance lies within Windows.
I know that both of you will be aware that optimization should be carefully targetted and the performance of the UI isn't an issue here. Not by a long shot. On this basis, fiddling around with the existing UI becomes wasted effort. Effectively, you are running on the spot to implement personal preference for minimal gain.Â
A practical, useful way of moving forward would be to decouple the core and hide it behind an interface so that it can be updated/tested/replaced with no impact on the UI.
Â
I guess the question is then: what is the long term goal?
Â
The main goal is improving the core. And doing it WITHOUT cheap per-game hacks or whatever.
Â
If that means redoing it to allow for less coupling with the GUIs, so be it. However, I do see your point. I understand your view of "what ain't broke, don't fix it", but personally I dislike MFC, for the reasons I discussed. Its utterly absurd that a GUI would effect performance majorly, but as Spacy described, Windows restrictions can have a small effect.
Â
Nevertheless, the main goal of course, is improving VBA's core, since we all know how horrid the current implementation is, thanks to Forgotten cutting corners in development, and now we are left with the damage. Thusly, its been discussed heaps of times on IRC about how we must decouple the core with the GUI and make it more abstracted. The main thing I guess, is the motivation needed to do such a thing.
Â
Though personally, I rather the whole core rewritten. But that is just my view....
Â
Actually, the UI is a key point of poor emulation performance when using either D3D or OpenGL due to not being able to lock the surface. Thats partly why the fullscreen menu was promptly removed.
Â
Correction: OpenGL DOES NOT use surfaces, or even the methodology of surfaces. The closest thing is a texture you can dynamically blit to.
Personally, I am now against a rewrite of the core, just because of the reason that it works: "Never change a running system". A rewrite would only make sense, if it was done by the people who did the first code, because they'd knew what to do better. We'd just end up doing other mistakes and letting the work Forgotten and the others did go to waste.
Â
I have started looking at the core and from what I have seen until now, it does not look too bad, apart from the missing modularization. Performance ain't too bad either, as I can achieve 400-500% speed on my CPU (C2D E8200). But I noticed there are bugs in the emulation for some games, so people, please try to solve them, as compatibility is most important for an emulator IMO.
<blockquote data-ipsquote="" class="ipsQuote" data-ipsquote-contentapp="forums" data-ipsquote-contenttype="forums" data-ipsquote-contentid="229" data-ipsquote-contentclass="forums_Topic"><div>I know that both of you will be aware that optimization should be carefully targetted and the performance of the UI isn't an issue here. Not by a long shot. On this basis, fiddling around with the existing UI becomes wasted effort. Effectively, you are running on the spot to implement personal preference for minimal gain.Â
A practical, useful way of moving forward would be to decouple the core and hide it behind an interface so that it can be updated/tested/replaced with no impact on the UI.
Â
I guess the question is then: what is the long term goal?
Â
The main goal is improving the core. And doing it WITHOUT cheap per-game hacks or whatever.
Â
If that means redoing it to allow for less coupling with the GUIs, so be it. However, I do see your point. I understand your view of "what ain't broke, don't fix it", but personally I dislike MFC, for the reasons I discussed. Its utterly absurd that a GUI would effect performance majorly, but as Spacy described, Windows restrictions can have a small effect.
Â
Nevertheless, the main goal of course, is improving VBA's core, since we all know how horrid the current implementation is, thanks to Forgotten cutting corners in development, and now we are left with the damage. Thusly, its been discussed heaps of times on IRC about how we must decouple the core with the GUI and make it more abstracted. The main thing I guess, is the motivation needed to do such a thing.
Â
Though personally, I rather the whole core rewritten. But that is just my view....
Â
Actually, the UI is a key point of poor emulation performance when using either D3D or OpenGL due to not being able to lock the surface. Thats partly why the fullscreen menu was promptly removed.
Â
Correction: OpenGL DOES NOT use surfaces, or even the methodology of surfaces. The closest thing is a texture you can dynamically blit to.
</div></blockquote>
Â
i forgot, opengl locks the buffer, d3d locks the surface
Personally, I am now against a rewrite of the core, just because of the reason that it works: "Never change a running system". A rewrite would only make sense, if it was done by the people who did the first code, because they'd knew what to do better. We'd just end up doing other mistakes and letting the work Forgotten and the others did go to waste.
Â
I have started looking at the core and from what I have seen until now, it does not look too bad, apart from the missing modularization. Performance ain't too bad either, as I can achieve 400-500% speed on my CPU (C2D E8200). But I noticed there are bugs in the emulation for some games, so people, please try to solve them, as compatibility is most important for an emulator IMO.
Â
Â
It works, but it could work better, more accurately, and probably with better performance.
Â
We can't whole blame Forgotten though, we were the ones that implemented the DynaRec into VBA-M, and while that did give a very nice boost in speed, we also killed a few games that worked before.