![]() You're entering a completely different world of completely different pain. My general suggestion to people is: don't bother implementing netplay in emulators. It's going to vary based on several variables, absolutely none of which your emulator/game/whatever has control over. The buffering methodology Tepples describes (re: the emulator working on input 4 frames behind what's active) is commonly used, but the problem is that 4 frames is sometimes too little, or in other cases too much. I have a few, but they're all dedicated to graphics, level design, algorithms, and things of this nature. Possibly this type of thing is discussed in an actual published game development book. All I've seen are commercial companies writign their own proprietary methodologies (which makes sense to some degree), and open-source nutbags saying "look at some crap I put on github the code is the documentation" (wrong). ![]() I have yet to see anyone publish anything like this. I will not pontificate on all this this past this point my statements (especially about the code aspect) sound anecdotal but honestly I'm really preaching fact.Īll that said: if you find something online somewhere that actually documents the design and architecture of a realtime gameplay protocol (TCP or UDP, I don't care which), I'd love to read it. A common example are packets that arrive out-of-order due to intermediary routers and load balancing on the Internet (and to some degree even NAT routers) there's a common misconception that if machine A sends packets to machine B in the order of 1,2,3 that machine B will receive them in the order of 1,2,3. (The latter is somewhat difficult, which is why using a language like C makes this easier - anything that is abstracted is going to make that task even harder). The biggest problem I find is that the programmers using the underlying syscalls/code for sockets do not actually understand 1) how individual descriptor flags affect what is going across the wire, and 2) have no real familiarity with packet analysis to determine what is going on and correlating that behaviour with actual code in their application. Those reimplementations may be better for your application - it's up to you to decide and do the analysis - but it's time not well-spent, IMO. ![]() Use UDP if you want, but you're going to end up reimplementing pieces/parts of TCP like Tepples said. TCP selective acknowledgement (SACK) per RFC 2018 further extends this in the case of packet loss. The "use UDP because it's fast" mentality is only applicable in one scenario, and that's the handshaking nature of the protocol - which for large payloads isn't even used any more given how the TCP sliding window algorithm works (RFC 1323): you no longer need to send an ACK for every single packet). And for sake of example, WoW and many other modern games use TCP. Tepples wrote:By the time you've implemented reliable delivery of input packets over UDP, with error detection and retransmission and the like, you'll end up having reimplemented most of TCP. If it hasn't arrived emulation freezes until it does On current frame check get own input from buffer and check to make sure input from other player has arrived. Save own input to buffer for local machineĦ. Frame to execute = current frame + delayĥ. Send input every frame with the frame it is to execute on. Ignore first X frames where X = frame delay since you can't possibly have any input from the other player.Ĥ. Synchronize emulator startup/loading of romģ. Determine number of frames to delay input (typically half the ping rounded up to the nearest integer or +1 frame for margin) on local machine by measuring average ping time over a time interval.Ģ. Especially if more than a few frames have gone by.ġ. So the test results may be a bit misleading, but that does not mean it is not a high accuracy emulator.Typically you want to use UDP as your method for sending packets for these reasons.Īlso most NES games aren't set up to take advantage of prediction since re-emulating the frame really isn't an option in a some games. However, these test ROMs don't test everything that matters for accurate emulation (and in some cases, test stuff that doesn't matter for emulating any games). Other NES/FDS emulators, such as Mesen and puNES, have higher scores on these tests. It's one of the most popular and most compatible emulators around.Īccording to TASVideos, Nestopia is ranked as the fifth most accurate NES emulator, with 1.40 scoring a score of 82.3%. Nestopia allows graphical enhancements such as texture scaling and TV filters, as well as netplay support. Nestopia UE is an open-source Famicom (NES) and Famicom Disk System (FDS) emulator written in C++.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |