(02-28-2015, 04:51 AM)ExtremeDude2 Wrote: [ -> ]The latency would be far too high to work
I don't see why latency would matter. Just netplay the gba emulators the same way dolphin does, separately, but at the same time, and it should just work™. Assuming of course, that dolphin and the gbas properly stay in sync.
(02-28-2015, 12:30 PM)RachelB Wrote: [ -> ] (02-28-2015, 04:51 AM)ExtremeDude2 Wrote: [ -> ]The latency would be far too high to work
I don't see why latency would matter. Just netplay the gba emulators the same way dolphin does, separately, but at the same time, and it should just work™. Assuming of course, that dolphin and the gbas properly stay in sync.
Its also not like the GBA link transfers much data that quickly anyways. Anyone who has used it on console knows it can take a huge amount of time for the GBAs memory to fill up and it only has 256K DRAM. I just thought it would end up being an AMAZING thing to do. Someday, Dolphin, someday...
The real answer is that it's not handled deterministically.
(02-28-2015, 04:48 PM)JMC47 Wrote: [ -> ]The real answer is that it's not handled deterministically.
Now correct me if I am wrong here deterministic means that given the same problem then dolphin will arrive at the same answer? I know this was a problem with netplay in the past. Was it with dual core?
Anyways, I know its just wishful thinking but I figure saying anything at all may just get some -way smarter than me- type person to have their interest peaked. Some of the best feature dolphin has are because someone suggested it and someone else just ran with the idea. Either way Keep it up and rock on.
The problem is actually emulating the GBA link as if it were a half-duplex device. For example Dolphin shouldn't have to send a request for the GBA's status and then wait for a reply; the GBA should be sending the status register contents to Dolphin each time it gets updated.
I'd like to see some way to rejoin netplay sessions in the event that someone drops out of a current session or wants to join mid session (or perhaps a way to restore saved sessions in the event that someone wants to replay a session later). This is something MAMEHub does that works really well in the event that someone disconnects, especially during long play sessions. I came up with two ways this could be done. These two methods should take advantage of functions Dolphin already supports:
A.) Recorded input method
This method involves sending a replay/input recording of the current session from the host to the peer that wants to join. Here's how I envision this would work:
1.) Peer sends request to join host's game as long as the host enables the ability to do so. Dolphin would have to record the inputs of all the players from the start of the session.
2.) Game session pauses for all connected players
3.) The host then sends the peer the recorded input data
4.) Once the recorded input data is received, have the peer play the input recording as fast as possible (frame limit disabled, frameskipping max?). It'd be nice to get an estimated percentage of the progress at certain points to let the other peers know how far along the peer is.
5.) Once the peer has reached the end of the recording, they should be at the same spot as the host and the other connected peers.
6.) Unpause the game and resume.
Pros:
-Faster file transfer (input recording data should be smaller than savestate data)
-The method could make all the saves to the memory card made during the session up until that point.
Cons:
-The time it'll take the peer to sync would be dependent on the peer's ability to go through the recording as fast as possible. This could potentially make this method the longest in terms of resync time.
B.) Savestate method
This method involves sending a (compressed?) savestate of the current session from the host to the peer that wants to connect. Here's how I envision this would work:
1.) Peer sends request to join host's game as long as the host enables the ability to do so.
2.) Game session pauses for all connected players
3.) The host then creates a quick savestate and sends the data to the peer that wants to connect. (Keep track of upload progress so the other peers will know how much longer the transfer has to go?)
4.) Once the peer receives the data, load the savestate. The peer should at least be at the same position as the host.
5.) Unpause the game and resume.
Pros:
-Loading a savestate should be much faster than quickly replaying an input recording
-Could be a fast way to sync if the host can upload fast enough.
Cons:
-Data size for a saved state is much bigger than an input recording.
-The host and the peer that wants to connect should be in identical situations after the sync process, but would the two be identical to the other peers?
-Any memory card writes/reads made during the play session won't be made for the peer that connects. This could be remedied if we also send the peer memory card data too.
I'm sure someone has thought of this before ever since netplay was introduced. I understand that neither of these methods are particularly ideal since each would take a long time. These methods might also provide a nice way for the host to manually 'force' a resync for all connected peers in the event that the host suspects a desync. I believe this is something RetroArch does?
This was just an idea and probably not too well thought out. If you think there might be a better way to achieve this that would be great.
Using savestates during netplay would be a great feature and should be possible. Rewind was also brought up though.
I couldn't find it listed here but...
HLSL shaders akin to the GLSL shader enhancement screen?
D3D's native AA options absolutely destroy performance, perhaps an FXAA shader
for D3D?
Also, I notice that the inventory of shader options doesn't include "Scanlines". To me, this should
be shipped with the project as it would allow more faithful reproduction of the intended look of
some games that rely on the limits of CRT television to achieve their look. Film grain sorta works
for this purpose too, so it might be a good "HD" option. I realize that these are available in DolphinFX
but for some games and hardware D3D performs better.
Anything on the roadmap for making GL and D3D have "enhancement options" menu parity or improving
how AA is handled on D3D?
Emulated IR Sensitivity Setting
Right now there is no way to adjust cursor speed when emulating IR. In the case of using a mouse, if my render view has the same dimensions as my desktop resolution, it's totally 1:1 movement, and this cannot be changed independently. One can mess with their OS-level device settings to make it faster or slower, but that's not a great solution.
I'd really like to see a multiplier setting to adjust the default IR cursor movement. This would just change how far the IR cursor moves for every unit of actual movement, be it via mouse or otherwise. If one set this to 400, then the IR cursor would move a distance 4x greater than the default. If it were set to 50, then the distance would be half as great.
I think this will be a boon for users, as we will soon have two mouse-capable gamepads on Windows: DualShock4 and Steam Controller.
As an alternative to to the title/notes fields, add file name as an option to view and sort by, so that I don't have use a hex editor or image rebuilder to change the way games are sorted and titled (usually inconsistently between sequels, missing disc numbers on multi-disc games, etc.
I'm sure its been mentioned before but adding space in the GUI for box art would be an awesome addition as well.