You are not logged in.
Pages: 1
This feature request seems to be stuck in limbo?
You say it's up to OpenEmu
http://sourceforge.net/p/desmume/feature-requests/141/
They say it's up to DeSmuME
https://github.com/OpenEmu/OpenEmu/issues/597
Any ideas?
Thanks
Offline
it isnt stuck in limbo. it's openemu's problem. we're not going to rearchitect desmume's innards to be able to do rotation itself. Rotation is just one of dozens of window transformations that nds users want. The core can't do all of these; so it is the frontend's job.
Offline
Cool, I've also raised the issue with those guys as they say you need to do some work to support it
Offline
If we need to do any work then it's in the OSX frontend
Offline
OK, now we're getting somewhere.
See: http://twitter.com/openemu/status/497200924838723584
Perhaps the extra display modes are required in this code of yours?
Offline
Have you simply tried the DeSmuME official Mac frontend instead?
Offline
matt, there seems to be some misunderstandings with who has what responsibility, so let me explain.
For a plug-in architecture like OpenEmu, there are three things that our plug-in needs to do OpenEmu in order to integrate with it. Those three things are:
1. An API that allows the plug-in to hook our code into OpenEmu's. This is OpenEmu's responsibility.
2. A UI feature in OpenEmu that exposes the feature to the end user (could be a drop-down menu, button, hotkey, etc.). This is also OpenEmu's responsibility.
3. The existence of the actual feature in our plug-in's code. This is our responsibility.
If all three of these requirements are not met, then it does not matter how many whiz-bang features DeSmuME has -- OpenEmu won't support them. Remember, it takes two to tango at this party! If the other person refuses to dance, then it won't be very fun, will it?
So let's get back to the question: Who's holding up the support for DeSmuME features in OpenEmu? Is it us or is it them?
Answer: It's them. OpenEmu's frontend simply doesn't support all of DeSmuME's features.
For example, if we look at the extra display modes, all of that code is already in the DeSmuME plug-in, so we have met Requirement #3. And that link you used to suggest what code that we should add to our plug-in? That code was mine. In fact, OpenEmu's clobber helped me get into OpenEmu's debug mode to test out this particular feature via a hotkey. However, if the end user is not using debug mode (and most don't use debug mode), then the ability to change display mode will not be exposed to the end user. In this, OpenEmu fails to meet Requirement #2.
As for the separation of screens, all three requirements are not met for this feature. In the case of OpenEmu, it would take some reengineering effort just to support this feature in the first place, and then they would have to create a UI for it and additional API so that we could hook into it. After OpenEmu does those things, then there is the effort to make our plug-in work with it. So don't expect to see this feature coming to OpenEmu anytime soon!
So here's a summary of mentioned display features that aren't supported and why:
- Display mode change: No OpenEmu UI (only exists as a hotkey in debug mode)
- Side-by-side screens (horizontal layout): No OpenEmu UI (this is purely a frontend issue)
- Screen rotation: No OpenEmu UI (this is purely a frontend issue)
- Screen separation: No API, no OpenEmu UI, and no plug-in code
Hope this clears things up.
If you do need certain features that OpenEmu doesn't provide, then you are always welcome to use the official Mac version. It will always be ahead of OpenEmu in terms of features. All of the features that you seem to want already exist in the official Mac version.
Last edited by rogerman (2014-08-08 16:10:44)
Offline
Thanks @rogerman
Hopefully this does it.
Offline
matt, whether you're intentionally doing it or not, the language you're using ("limbo" or "stalemate") and the way you've presented this issue (as "he said, they said") makes it sound as if there is some kind of back-and-fourth conflict, when there really isn't. It almost comes off as pestering, which certainly won't move things along. FYI, rogerman and I usually communicate via IRC and we haven't done so in quite some time. So he probably isn't aware that the "Display Mode" hotkey is available to all users since the 1.0 release last December and no longer a debug-only thing (more details here https://github.com/OpenEmu/OpenEmu/wiki … play-Mode).
Anyway, rogerman, if you need me to add a ROT90/180/270 to the API I can do that. Can side-by-side be supported the same way as the current Display Mode change method? Though I'm not really too concerned about side-by-side. Rotation is definitely needed for those games that make you do so. The screen separation stuff isn't something we'll support. That's about it.
Last edited by clobber (2014-11-17 09:10:19)
Offline
Hi,
Thanks for the positive outcome.
The tone of my requests was unintentional. When I originally filed this issue/enhancement request, over one year ago, I was not aware that the two teams were working closely. Actually, I still wasn't until right now. All feedback I got on this was that each party said it wasn't their responsibility and I was simply trying to help things along. As a mediator, if you will. There has been back and forth but I would not describe it as a conflict. As an outsider, not on IRC or involved at a code level, it's difficult to know what is going on in the project.
Forgive me if it's a bad thing that I have just (before reading this) started a new issue:
https://github.com/OpenEmu/OpenEmu/issues/1714
Thanks again, much respect
Last edited by matt (2014-11-17 13:03:01)
Offline
I discussed the issue with clobber on IRC, and there was a misunderstanding on how the NDS screen features were implemented. He now understands that the NDS screen features are implemented purely within the frontends, and that the DeSmuME backend doesn't handle the NDS screen features at all. Keep in mind that DeSmuME's OpenEmu plug-in only contains the backend code. There is no frontend code present in the plug-in. OpenEmu exists to provide that frontend for DeSmuME.
So I want to state for the record that it's not that I'm withholding these features from the plug-in -- it's just that I can't add them there. The NDS screen transformation code doesn't exist in the DeSmuME backend code, and it wouldn't be appropriate to put it there. As zeromus has already posted, these features are supposed to be handled by the frontends.
Offline
Pages: 1