Go Back   Project64 Forums > General Discussion > Open Discussion

Reply
 
Thread Tools Display Modes
  #1  
Old 19th March 2015, 01:55 AM
HatCat's Avatar
HatCat HatCat is offline
Alpha Tester
Project Supporter
Senior Member
 
Join Date: Feb 2007
Location: In my hat.
Posts: 16,256
Default

I meant to get around to redoing my keyboard plugin for cross-platform, but Project64 and Mupen64 0.5 use completely different signals for WM key codes (Windows system keyboard codes versus SDL key codes), so in short of writing a SDL-dependent plugin I had no idea how to do cross-platform input plugin.

I am not an Adaptoid owner, by the way, so I'm of no help here.

Quote:
Originally Posted by Falkoner View Post
Whatever I end up choosing for the plugin's starting point, what I know is I want cross-platform compatibility, I want it to work for CEN64, Mupen64Plus and PJ64, I'd like the features of NRage as far as memory pak and gameboy paks are concerned,
It doesn't really sound feasible since Mupen64Plus abolished their conformance to the cross-emulator plugin specifications a long time ago and, if I haven't heard just gossip, are thinking about removing the plugin system altogether (possibly out of some inspiration from their "CENification" restructures. Similarly, CEN64 has no concept of plugins, just static modules.

So I guess the only cross-emulator solution would work on Project64, 1964, Apollo, Mupen64 0.5 and friends, but not Mupen64Plus or CEN64 since they've left the boat.
Reply With Quote
  #2  
Old 19th March 2015, 02:32 AM
Falkoner Falkoner is offline
Junior Member
 
Join Date: Mar 2015
Posts: 11
Default

Quote:
Originally Posted by HatCat View Post
It doesn't really sound feasible since Mupen64Plus abolished their conformance to the cross-emulator plugin specifications a long time ago and, if I haven't heard just gossip, are thinking about removing the plugin system altogether (possibly out of some inspiration from their "CENification" restructures. Similarly, CEN64 has no concept of plugins, just static modules.

So I guess the only cross-emulator solution would work on Project64, 1964, Apollo, Mupen64 0.5 and friends, but not Mupen64Plus or CEN64 since they've left the boat.
Good information there, however, I was aware that CEN64 was doing something new, so my plan was to essentially make wrappers for each major emulator. Also, CEN64 supposedly uses a format similar to Mupen64Plus's plugin system, so it shouldn't require any major modifications.

Following the zilmar spec was of course not feasible, since it was somewhat Windows-centric, so cross-platform compatibility was shot from the start.

Last edited by Falkoner; 19th March 2015 at 02:35 AM.
Reply With Quote
  #3  
Old 19th March 2015, 03:18 AM
HatCat's Avatar
HatCat HatCat is offline
Alpha Tester
Project Supporter
Senior Member
 
Join Date: Feb 2007
Location: In my hat.
Posts: 16,256
Default

Quote:
Originally Posted by Falkoner View Post
Following the zilmar spec was of course not feasible, since it was somewhat Windows-centric, so cross-platform compatibility was shot from the start.
Mupen64 0.5 conforms to the spec on all operating systems it was released for. Mupen64Plus changes to the plugin system had less to do with giving up on Windows types, more to do with the introduction of their own "M64P API" where they wanted to have more things done inside of the core and less things inside the plugins, like callbacks for enumerating hardware support and some optional ideas.

I have always thought it naive to create a standard to encourage all N64 emulators using plugins to comply to, while at the same time also defining it off of Windows operating system types, which really have nothing to do with the RCP or anything N64 in general. However, this never created the need to completely restructure the plugin specs, as the types themselves never truly fixated the standard to only work on Windows. (e.g., a DWORD on Win32 is always a `u32` or a `uint32_t`, which is exactly the size of all RCP registers, or `unsigned long` is also acceptable as it is always >= 32 bits in size). So the plugin spec headers themselves are indeed horrendously biased to a single, closed-off operating system, but the functional bodies of it have worked on other operating systems. So in the end I just revise the plugin spec headers to never use windows.h types when I include them with plugins I release.
Reply With Quote
  #4  
Old 19th March 2015, 03:29 AM
oddMLan's Avatar
oddMLan oddMLan is offline
Alpha Tester
Project Supporter
Senior Member
 
Join Date: Jan 2009
Location: Parappa Town
Posts: 210
Default

Reply With Quote
  #5  
Old 19th March 2015, 11:56 AM
Frank74's Avatar
Frank74 Frank74 is offline
Alpha Tester
Project Supporter
Senior Member
 
Join Date: Aug 2013
Location: UK
Posts: 828
Default

Quote:
Originally Posted by Falkoner View Post
I would later plan on adding actual voice recognition using something like Sphinx.
Well according to this, http://krikzz.com/forum/index.php?topic=2259.0.

All decoding for words is done by the game.
Reply With Quote
  #6  
Old 19th March 2015, 03:03 PM
HatCat's Avatar
HatCat HatCat is offline
Alpha Tester
Project Supporter
Senior Member
 
Join Date: Feb 2007
Location: In my hat.
Posts: 16,256
Default

Quote:
Originally Posted by oddMLan View Post
Pretty much dude. That's exactly what every emulator intent on offering some concept of plugin support, either statically or dynamically linked, has intervened that chooses not to have any compatibility with the venerable (albeit flawed) standard every other emulator has been using. Actually Project64 had to do it too, because Nemu64's plugin system was closed-source with no documentation, but even then at least the available, open spec we have as a result is somewhat loosely based on Nemu64 spec and resembles it for partial compatibility attempts.

You take 14 competing standards, and try to solve the problem with your own completely different standard, it expands the problem further. Any new plugin system must maximize the amount of structural similarity to the venerable ones of today, not arrogantly try to rebel everything for scene bigotry like what happened with plus and cen.
Reply With Quote
  #7  
Old 19th March 2015, 04:06 PM
Falkoner Falkoner is offline
Junior Member
 
Join Date: Mar 2015
Posts: 11
Default

Quote:
Originally Posted by Frank74 View Post
Well according to this, krikzz.com/forum/index.php?topic=2259.0.

All decoding for words is done by the game.
Yeah, however, emulating the way the VRU converts the analog data for the game is extremely difficult, so my plan is to simply create a database of VRU outputs and then use a modern speech-to-text tool to get it to look up what you say in the database using your computer's mic. What's interesting about this idea is it would allow you to translate the game into different languages and could greatly improve Pikachu's recognition of words.

I'm sort of brute-forcing it, and it truly is HLE, but at least this fun game would work. What would be really awesome is if someone could do what I talked about in #2 of the first post, that is, successfully extract the game's contents(it looks like someone already did since that list of commands exists, so it's definitely feasible), and see if the underlying code already has some kind of array of the possible inputs. Although, if the game processes the text like you said, that means reverse-engineering the processing a bit :/

Quote:
You take 14 competing standards, and try to solve the problem with your own completely different standard, it expands the problem further. Any new plugin system must maximize the amount of structural similarity to the venerable ones of today, not arrogantly try to rebel everything for scene bigotry like what happened with plus and cen.
Yup, that's why I just intend to support the most common standards, rather than attempt to make my own.

Last edited by Falkoner; 19th March 2015 at 04:23 PM.
Reply With Quote
  #8  
Old 19th March 2015, 06:32 PM
V1del V1del is offline
Project Supporter
Senior Member
 
Join Date: Feb 2012
Posts: 442
Default

@Hatcat

I know we've been over this a thousand times and we'll end up having to agree to disagree, but you're really stretching completely different here. Most of the API relevant to emulation is exactly the same apart from the obvious type conversions. The only major thing that changed is that configuration is handled in the core and that's where you have to make adjustments but this gives greater flexibility as you don't have to provide this yourself and can rely on platform specific frontends instead of having to code a GUI for each of them yourself.

The wiki also outlines pretty transparently what has been changed https://github.com/mupen64plus/mupen...2.0-Plugin-API
Reply With Quote
  #9  
Old 19th March 2015, 06:59 PM
HatCat's Avatar
HatCat HatCat is offline
Alpha Tester
Project Supporter
Senior Member
 
Join Date: Feb 2007
Location: In my hat.
Posts: 16,256
Default

Quote:
Originally Posted by V1del View Post
Most of the API relevant to emulation is exactly the same apart from the obvious type conversions.
This is where plugin system changes become relevant: changes to how emulation is being done. The plugins are all emulators after all, or emulator plugins that emulate things within a core emulator.

If they had reasons to change the way the emulation was being done, then the changes would have been relevant. Instead, they created their own "M64P API" which has nothing to do with N64 emulation and imposed their customizations on the plugin specs, revoking them of their immediate compatibility.

Quote:
Originally Posted by V1del
The only major thing that changed is that configuration is handled in the core and that's where you have to make adjustments but this gives greater flexibility as you don't have to provide this yourself and can rely on platform specific frontends instead of having to code a GUI for each of them yourself.
It does not give greater flexibility--it takes away that flexibility in exchange for possible chances of portability (which is more of the key idea to their intentions, so far as that). Historically, all plugins have always had to create their own context initialization or do their own framework handling. Mupen64Plus may have created an option for plugins to no longer be required to do this, but this is a fundamental and unnecessary structural addition and complication to the specs, which really would have served a lot more purpose back in the beginning before all of these plugins came out. Nowadays it's too late for any project to benefit from it that isn't new, freely licensed and/or maintained on the same level as Mupen64Plus authors' ideals.

The purpose of an emulation plugins' specifications is to provide a standard for which emulation functions should be communicated, not to add on to the size of the specs with what functions could be communicated (abstracting GUI frameworks, operating system conventions etc. and other things that have nothing to do with emulation). I have not even seen a need to impose GUIs of any type in any of my plugins--the ideal plugin does not have that much to configure or tweak about them or the need for complex, fancy, eye-candy DLL configuration since it revolves around accurate emulation--none of these additions that are specified on that Wiki you linked to are mandatory or even useful for N64 emulation improvements, they are personal decisions and personal ideals about how things could be done for portability. Even better portability: Don't force ourselves to have to include GUIs in the plugins to begin with.

"The only major thing that changed is that configuration is handled in the core"

And you think I am stretching the truth here?
What about the fact that the Wiki you linked to proves that they both added AND removed functions to and from the spec? They removed/renamed way over half of the RSP and other plugin types' functions from the spec when there was no necessity for removing them, only to replace them with even less historically compatible functions and optional extra additions that do not benefit RSP emulation at all. Said functions which were removed had nothing to do with "configuration handled in the core", so it's stretching the truth to justify.
Reply With Quote
  #10  
Old 19th March 2015, 07:09 PM
HatCat's Avatar
HatCat HatCat is offline
Alpha Tester
Project Supporter
Senior Member
 
Join Date: Feb 2007
Location: In my hat.
Posts: 16,256
Default

It's already well-established that there are many ways to implement configuration--have a M64P core that can feedback tabs/buttons/input forms within a GUI, or support most common features to make the plugin not be forced to do it within the plugin. This really is just a method of adding extra code to the core itself, as well as the specs, in exchange for the possibility that the plugin won't need any lower-level control than that, or any more control. At the point by which it could, these additions become redundant.

It's also established that the more things a standard includes definitions for, the more restrictive it is: To comply to that standard, you must comply with EVERY definition. It's already hard enough that there are different perspectives to define messaging and threading for the RCP's datum; when you add shit about configuration and doing frameworks within the core optionally instead of making the plugin do it, you specify even more--like your own opinion on what most frameworks for most operating systems "should" have in common: Do we implement tabbing/text input forms within the specs/core, or leave the plugins to do it? If your answer is the former, your emulator core can never truly be portable because there are operating systems that do not necessitate facilities for graphical text input forms or tabbed configuration GUIs--you cannot assume what every operating system does. So actually no you have it backwards: Mupen64Plus changes are more restrictive and less flexible, not the other way around.

On the other hand, if a plugin was ported to an operating system that didn't support tabbing, graphical text input or other elements of non-emulation-related features, the author porting it would simply remove the need for such extra optional eye-candy. With the core proposing this extension, the core cannot be ported without contradicting their own specifications. It's just stupid--if plugins and plugin systems in N64 are really that arrogant, some conspiracy for spec authors to dominate the scene or whatever, exactly how does both adding unrelated functions and removing related functions make the situation any better?
Reply With Quote
Reply

Tags
adaptoid, hey you! pikachu

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Forum Jump


All times are GMT. The time now is 12:25 PM.


Powered by vBulletin® Version 3.7.3
Copyright ©2000 - 2020, Jelsoft Enterprises Ltd.