I know you've probably been bugged by people on this before, but how hard would multi-player be to implement? More importantly, do you think that there is enough bandwidth, and low enough lag, to allow a host-client multiplayer setup to be playable? (ie, with one psp "hosting" the game and doing the emulation, while the other(s) just receive screen-captures and send back user-input) Or do you think that distributing the computational workload would be a better approach? (at the very minimum, the audio processor shouldn't be too horrible to move to the client psp(s) )
I have thought about multiplayer a great deal, but I've never made any plans to work on it - there didn't seem to be much point getting multiplayer working before there were a few multiplayer games running quickly and glitch free. Now that MarioKart and Super Smash Bros. are both working reasonably well, there's obviously going to be a lot more demand for multiplayer support. Before I raise expectations and get anyone's hopes up, I should mention that this isn't likely to happen any time soon.
It would be possible to go down the route of having a host psp which performs emulation and broadcasts the screen to client psps. Sony's Remote Play between the PS3 and PSP shows that this kind of 'dumb terminal' approach can work in the right situations. That's with the PS3 doing the grunt work of compressing the framebuffer and sending it over to the PSP. For for a PSP running Daedalus as a host, I'm not quite sure there would be enough spare horsepower to compress the framebuffer and audio and then send it to 1 or more connected clients.
Also, I don't think that it would be possible to decouple the audio processing from the main cpu thread so that this work could be distributed to one of the clients. Although the audio and graphics processing is notionally run in parallel on the RSP (the N64's coprocessor), access is still serialised between audio and graphics tasks so they have to be completed in order. Performing audio processing on a client PSP would just mean that graphics processing on the host would have to wait until the results of the audio processing were received.
The approach that I'd been considering was running Daedalus in lockstep across 2 or more connected PSPs. As I mentioned previously Daedalus can run deterministically if external inputs such as pad input and timing sources are synchronised. What this would mean would be that every time the rom queried the pad status, each connected psp would have to synchronise its view of the pad input with the host. This would mean sending just 64 bytes across the network from the client to the host and back. This information would have to be sent over a TCP connection rather than UDP as we have to ensure that every PSP sees the exact same input (actually, client->host communication is a bit less critical so it may be possible to transmit this information over UDP if it helps improve lag.)
One really cool feature about this approach is that as each PSP would be responsible for rendering its own display, it would be possible to scale up each viewport to fill the display; rather than playing 4-player Mario Kart or Goldeneye at 160x120, you'd be able to play at 320x240 (or 480x272 if you wanted to scale it up to entirely fill the PSP's screen).
As I said at the start of the post, this isn't something that's likely to happen any time soon, but if and when it does happen, it will be amazing :)
-StrmnNrmn
31 comments:
That sounds more than freaky. If that should work out sometime, i bet there will be a few games challenging original psp titels! But as you said, that will probably steal a lot of time - so imho speeding up und debugging are the features i am lookig the most forward to! Again big thanks for your never ending work on this project.
Hello, i'm thinking that the second option wouldnt be so complicated. In the two diferents psp can have generate a diferent real code because the lag between the net but as it would be reasonable litle time to get an tcp syncronisation packet from the imput of every psp unless the code generated by the both psp are diferent the state of the game will be the same i think this philosophy is used by kaillera, i suggest you to see some examples of it an consider to implement it.
offtopic
will you go on holidays to spain like some months ago?
Yeah that's great news for the future, I just hope in the near future DKR is worked upon. Hey it might even be voted the most in the poll, if the Zelda fans don't overwhelm the votes. Anyway great work as usual, and I hope you have some good luck with speedups in the very near future.
OH MY GOD PLEASE LET THIS HAPPEN!!!!! NOW ITS PRAYING TIME!!!! :D
this would be a great Christmas gift for psp gamers and n64/daedalus fans ^^
...
So happy right now there is a release date for next weekend or a few days later just suggesting if you take a look at snes9xtyl 0.4.2 they have a pretty solid multiplayer system for the super nintendo maybe when u consider doing multiplate in a while from now you could take a look at that emulator for the psp
It will be incredible to do that. However, i really think that you should take a break, as Exophase has said that you are a busy man.
OFCOURSE I'M NOT SAING THAT YOU SHOULD QUIT. YOU ARE A REALLY GOOD DEVELOPER. By this i mean that we appriciate your hard work on this Emulater, which is fantastic.
However, my question is that will you add savedata support?. As, if we can't save a game we can't progress which i didn't really like about the emulator. I'm not saing that you haven't done a great job, however it will be wonder full to add savedata support. Please reply.
Your Sincerely,
shuaib000
@japo freak: I remember reading about kaillera a few years ago. I was actually trying to remember the name (for some reason I was getting it confused with Kallisto which is something quite different :) I'll check it out, thanks.
Yup, off to Spain again, near Murcia :)
I think games is gonna run a lot faster if daedalus had a way to change CPU speeds.
keep up the good work
i like to help StrmnNrmn actually i'm ending a computer degree and i like a lot the tech post ;). Also i'm a coder for psp too i'm called saulotmalo. I think you'll make a very good emulator.
if you pass castellon going to murcia you got a free beer ;)
You need to vacation in Arizona. That way you could come visit me and we could play PSP and PS3 and PS2! Then you could stay at like Embassy Suites or something.
BTW, I think that would be amazing for the second multiplayer idea. I mean, that would be like the first of it's kind, getting just your own screen!!! My question is, maybe i didn't understand it, but how would it know who's first, second, third, etc and where exactly the screen is?
Also, i greatly appreciate SSBs coming along greatly. Thx for all the work and you really deserve vacation time. Keep it up!!
i would prefer to have a higher fps speed and multiplayer afterwards, than have a multiplayer and low fps ;)
but keep the good work up !!
@duffman: Daedalus already runs at the highest possible clock speed.
@tyler: When you connect to the person hosting the game, their psp would tell you which pad you were controlling (2, 3 or 4). There would have to be a specific multiplayer settings file for each rom that said "player 2 is top right, player 3 is bottom left, player 4 is bottom right" etc.
@lorenz: I agree - I think speed and compatibility have to come first!
fwiw, I've worked on a number of network console games before, and virtually all of them used the lock-step approach and only relayed controller input.
Would there be any possible way this could ever work with infrastructure mode??
You'll have to make sure all of the PSPs are using the same settings. Someone could disable sound or up the frameskip due to personal preference, etc.
third option, maybe - dedicated server. whether this be a computer running a program with a wireless dongle, or another psp belonging to the guy who just nipped off to the loo and will play next round using the losers handheld... i dont know. perhaps an idea.
Hello Again, I have only one question:
In the next version of your emulator, how fast and compatible will be Zelda Ocarine Of Time?
Thanks, and keep the good work!!!!
To me, Multiplayer idea is great. It is great to see someone sticking with there project, and great process. And I would also like to add that I had Super Smash Bros. Running on R11. Now, don't tell me if people all ready know this or not, but I had it running, and I was able to do one target practice. Which allowed me to see my chacter. But anyways, I just wanted to say congrats on the great work, and the ideas, and I cant wait for R12 and any other versions to come out.
here i come with another ill conceived idea...
just make a Daedalus server that runs on the PC... then it just sends the framebuffer and audio to the PSP clients... or even just sends the display lists and textures and stuff and lets the PSPs render it themselves...
what could possibly go wrong?
--
cms108
Is it possible that you can work on Paper Mario next and get that working on full speed as I'm sure many people would enjoy playing that game.
Hey Guys,
Thought you might wanna be involved in the Spiffup.org Wiki :)
www.spiffup.org/mediawiki (for now)
Read instructions and let me know..
Do not touch comments / R12 stuff until R12 is out
Are you talking about Ad Hoc multiplayer or Infrustructure?
I haven't seen N64 multiplayer on any emulator, yet.
A little off subject but.... after you master everything and make all the roms work could you create something like a dynamic smoothing and sharpening so we could have the best game play experience? I know that n64 was meant for a bigger screen so that's why I'm asking this. Also can I be a beta tester lol?
@Steve: That's a good point - there are some settings that will have to be identical between psps (dynarec is one of them). Having said that, enabling/disabling sound of adjusting the frameskip shouldn't affect the determinism of the emulator. This is because the audio and graphics processing are both emulated at a high level, so from the emulated n64's point of view there's no observable difference between audio being enabled or disabled.
Definitely something to be take into consideration though!
@cms108: Hey mate - long time no speak! Are you on facebook? Add me!
@tim: Well I do scale rendering up to the PSP's native display of 480x272, but the textures are still restricted to their original resolution.
One possibility I've been considering is a magnification filter such as hq2x. Another possibility is to support high-res texture packs (i.e. allowing user-defined textures to override the original n64 textures).
Both these are some way off in the future however.
It would be really cool if StmnNrmn could get Donkey Kong 64,Super Mario 64,Mario kart 64,Diddy Kong racing,and super smash bros. working at full speed with perfect textures.I think this is what he should do on r13.just maybe that will make alot of games run.
Hey Strmnnrmn,
Running in lockstep deterministically is definitely the way to go. It's pretty easy to implement, and, as others have pointed out, lots of stuff uses this networking method: Kaillera, lots of console games, heck, even Doom did networking this way.
I've actually been implementing this in a game right now, so maybe you some of what I've learned could be helpful:
As you noted, fluctuating framerate shouldn't break anything, since all the PSPs will be running in lockstep, and you'll only be ticking once all inputs have been received. You've just got to make damn sure that everything is deterministic -- but an emulator is pretty deterministic by nature, so that makes it easy for you. :)
I implemented it with queues -- a player has input queues for himself and every other player. Inputs are enqueued on these queues as they are generated or received from other players. If everyone has some inputs waiting in their queue, you can dequeue them and tick the next frame.
You could be avoid TCP and use just UDP by sending the past N frames of input between players, instead of just 1 frame per message. Each packet will have a frame # timestamp. This way, a dropped packet or two won't change a thing. The next packet will have all the missed inputs, which will then be enqueued. (If you drop all N packets, it's probably time to disconnect, anyway. :) )
Also, to keep the game running smooth, it can help to let each client generate a few inputs ahead, for the frames in the future. It delays input response a few frames, but it gives the input buffers the breathing room they need to run smoothly despite lag.
Sorry if a lot of this was obvious to you! But maybe some of it is helpful. Keep up the awesome work! :)
Post a Comment