Open Zombie-Ryushu opened 10 years ago
thats kinda hard to do atm. even the standalone has its own problems with link and some games. but thats something that's thats gonna happen.
This has been an issue for several years. Do you think going about this the TGB-DUAL Way is more feasible? Game Link does work in TGB Dual, But it is only feasible in LAN settings, or Split screen?
Hi,
1°) VBA-M GBA Link code doesn't run correctly : they tried to use my code of my project VisualBoyAdvance Link project but they had applied it badly ^^"
However, I have successfully since several months an version of vbam-libretro that have my working code of GBA Link. I want just that you wait that I finish my updates of the source codes of Ludum. I will test my works on the latest vbam-libretro and tell you if it works.
2°) About Game Link on GB/GBC, I use my modified version of Gambatte that fixes Link issue on Linux and Windows. TGB Dual is Split screen ( the 2nd player receives the 2P screen from 1P computer ). Gambatte uses LAN settings.
The best way is the TGB/Sameboy way. A single libretro core that runs 2 instances of the emulator. As far as I know VBA-M has far too much global state for that to be possible.
Regarding your changes, I think the intention here is to keep the core upstream friendly now, so changes must be agreable with upstream
I'm working on a netplay awareness callback that will allow the core to know it shouldn't display the second output and play the correct sound.
I got the GBA linking working successfully using the current code of libretro/vbam-libretro and little modifications :p Now I have on this core the LAN capacibility.
I have one question for you guys : I see on GBALink.cpp functions for GB Linking. How does it work ? Someone have tested it with wxvbam ?
Note for fr500 : TGB Dual is the bad way for me. Every user must have the capacibility to have his personnal save and personnal instance of the emulator. The "2 in 1 instances of the emulator" like TGB is the bad way...
So I checked the issues about Link GBA. And I see that --" . https://github.com/visualboyadvance-m/visualboyadvance-m/issues/322#issuecomment-435004198
So much optimism like always in VBA-M team members. So I will continue with my official method of GBA link that works on Windows and Linux computers. Gambatte will be perfect for GB/GBC link. VisualBoyAdvance Link, my project, will be perfect for fully functionnal GBA Linking. If people will be interested by VisualBoyAdvance Link, I will post you the project page.
@JackoboLeChocobo as upstream project lead (sadly I wasn't the one that tried to merge your fork in at the time, funny enough back then I was merely a user), if there is anything you could suggest to improve, please let me know. I'd be happy and willing to land any improvements you think are needed.
I hope netplay support can be a possibility in the future.
Question : Where did it go ? https://github.com/visualboyadvance/vbam-libretro . I could access to it yesterday. Can someone confirm the death page on this link ? ( libretro/vbam-libretro was a fork of this project )
@ZachBacon, the solution is simple : as you can see, many people in your projects meets issues about Linking : I have tested too your project with the latest source code because the GB link feature didn't existed in the start of VBA Link. And after modifications on your codes, the client and server could see each other but in GB games, we can't launch a multiplayer game... Your current code of linking needs to be reseted from the start... But you said that "It's not overly a high priority item to fix" ... Some of your team members had used a part of my code but for the result you know today that...
For information, I have with the latest https://github.com/libretro/vbam-libretro code successfully restored my GBA linking functionnality with some features that are not present on the official code. So I don"t use SFML Library and Joybus and GB linking will not be here. BUT my GBA linking was tested and was approved since several years ago too by some people of the forums.
For now, because of some team members on some projects, I prefer keeping my fork, publish all in open source and write notes about my fixes, instead of sending patches to people on their projects and see that because I removed some functionalities that don't work, the patch will be refused. Like I said to Desmume team before about my Wifi code and many others projects like MPlayer for my DVD fix support, if you want to know how I did it, do like i did : research, tests and works.
If people want to test my works, I will be happy to send him my project page.
@JackoboLeChocobo that's the old repo, I've been working with the libretro devs to use the proper upstream https://github.com/visualboyadvance-m/visualboyadvance-m EDIT: Also I'm open to anything, we already know that some things would need to refactor, it wasn't a high priority item due to the fact a lot of us on the team have left, It's myself and 2 other people that are doing our best to maintain the project.
@ZachBacon , Sorry if I was rude with you : It was my personnal experience that was talking when I contributed on some opensource projects :/
Do you prefer to continue the discussion here on an new ticket or on https://github.com/visualboyadvance-m/visualboyadvance-m with a new ticket ? I have some questions about the code. I will try to help you as much as possible. I will publish some news about what I have for the moment successfully done on your code and discuss about the actual code. We need to understand some datas and needs some tests/results.
I want to share that but I hesitate about the location of the new ticket. I will prepare before your answer the text.
Go right ahead, I think it would be best since I think this repo either will be archived or removed and upstream recloned for better Pull Request management between downstream and upstream
@ZachBacon, so you want a new ticket on https://github.com/libretro/vbam-libretro/ if I understand ? Can you share me the Github names of the 2 other people who are with you on the project please ?
@JackoboLeChocobo no on https://github.com/visualboyadvance-m/visualboyadvance-m/issues
@ZachBacon Okay thanks ^^
@retro-wertz and @rkitover are the other two people, retro-wertz typically looks after the libretro stuff and rkitover and I been mainly taking care of the interface.
@ZachBacon, @retro-wertz, @rkitover and for other people too : go here now to follow this subject https://github.com/visualboyadvance-m/visualboyadvance-m/issues/356
1°) VBA-M GBA Link code doesn't run correctly : they tried to use my code of my project VisualBoyAdvance Link project but they had applied it badly ^^"
False, your project was written in JRE, your project was not the basis for BGK's attempts at correcting the link code.
False, several years ago, my project used a Java GUI as command launcher ( I used Java as terminal command to launch the SDL version that had my GBA Link code ) . Nice try : i know my previous versions of MY project better than you.
See here too : https://github.com/visualboyadvance-m/visualboyadvance-m/issues/356#issuecomment-462079583
Nice try : i know my previous versions of MY project better than you.
Obviously not well enough.
The code in vba-m including the basis for bgklink branch was the 1.7.2l source files refactored for 1.8, obviously not working because there were things missing that we never got source code for (1.8l source was never available)
bgk and adamn both worked on their branches individually and it was bgk's changes that got merged back to trunk with many parts working for GBA Linking at the time.
The first versions of VisualBoyAdvance Link used VisualBoyAdvance 1.7.2 and 1.8.0 ( and noyt VBA-M ) project and denopqrihg's Windows works ( www.vbalink.info/download/V172lsrc.zip ) . Like I said, my project used before a Java GUI as command launcher ( I used Java as terminal command to launch the SDL version that had my GBA Link code ).
Once again, nice try : i know my previous versions of MY project better than you.
There appears to be a language break down here, nobody is talking about what you used in your project.
We are talking about your continued claims that we used code from yours which you made on the desmume forum in 2017
Your VBA-M project has a very bad and slow Linux version, and the multiplayer mode doesn't work at all (it wasn't necessary to provide you the code : before, you had tried with the method "copy/paste" , but only a part of the code ... )
Ve can also talk about the fact that you are harassing anyone who does project forks correcting the issues of the project and you can not stand it (both VBA-M and Desmume forks, in my case VisualBoyAdvance Link and Desmume-Reloaded). I'm not alone in finding out ...
https://github.com/visualboyadvance-m/visualboyadvance-m/issues/356#issuecomment-462107416
I don't need to prove to you new things that I already shared and showed here... If you have a problem with ( French only? ) people for creating better forks, that's not mine.
For another instance, it is because of people like you that Luigi / Arisotura stopped to contribute to Desmume and created his own DS emulator MelonDS. If you don't support that, don't publish source codes of your project.
ugh... why bring this issue here....
You can ask that to Squall here or here too : https://github.com/visualboyadvance-m/visualboyadvance-m/issues/356 . Now it isn't my problem. Like I said, I will continue my works on my fork from today.
I prefer to independently continue to develop my code (GBA/GB/GBC link support , etc. ) on my fork rather than having to justify myself on the creation of my project and the work I have done since the beginning of my fork for several years
Hey there @JackoboLeChocobo , I just want to say that after talking with him, @ZachBacon feels pretty bad about all this happening and I would like to ask you to give the VBAM team another chance in terms of collaboration. Squall Leonhart is not part of that project anymore and Zach and others would certainly welcome any and all contributions. There can always be disagreements about implementation, but never should things turn vitriolic like this and unprovoked too.
I am sure that if he causes issues again, that either Zach or somebody else with moderator status will take care of it in terms of moderation.
Hi @twinaphex . Thank you for your message. I understand what @ZachBacon feels about the situation :( . I read your message about Squall Leonhart, and about collaboration with VBA-M.
I decided from now to restart the collaboration with VBA-M team, to share my works based on denopqrihg works.
@ZachBacon, my code actually doesn't use SFML. I will create a new ticket for that and make here a schedule / list of things that i will do, test and apply to ensure a smooth transition of Link support in VBA-M.
And sorry for my english if I do mistakes in my sentences.
Bump
Would like to see updates on this. I'm surprised with how far the overall project has come that this hasn't been completed just yet.
Still interested in 2023. I'm so surprised that trading still isn't possible in Retroarch.
It is possible to Trade Pokemon and do other Game Boy and Game Boy Color multiplayer in RetroArch with TGB Dual. You put the Emulator in Split screen mode and then do normal netplay with player 2 as the right game boy, (Super Game Boy excluded, different setup using VBA-M with it seeing a second SNES Controller port) GBA is still not working for this.
It is possible to Trade Pokemon and do other Game Boy and Game Boy Color multiplayer in RetroArch with TGB Dual. You put the Emulator in Split screen mode and then do normal netplay with player 2 as the right game boy, (Super Game Boy excluded, different setup using VBA-M with it seeing a second SNES Controller port) GBA is still not working for this.
That feature isn't available on certain devices especially ones with small screens. It specifically needs to be added with VBA-M. Anything less is unacceptable.
VBA-M's module supports Game Boy Link in WX mode, but only in WX Mode. I think that you should Game Boy Link Mode as a Core Option under RetroArch, and use the underlying VBA-M code to accommodate this