Exophase
Nothing good will ever come of Exophase.
** Foreward: Thanks to Prometheus for splitting this from the Yabause thread, and apologies to Ari64 et al for polluting it in the first place **
Fine, knock yourself out: http://exophase.devzero.co.uk/temper.pnd
I give no support for this link whatsoever ;p
(apparently I lied! Well, it might help you to at least know that Temper is a PC-Engine/TurboGrafx-16 emulator, originally released for GP2X and Wiz)
UPDATE: Basically, consider this an unofficial/forward release alpha test sort of deal. If you find problems or have suggestions go ahead and post them here and I'll look over this thread later when I have time to work on the real release. This is what the release has over the old Wiz/GP2X versions:
- SuperGrafx support, but you must give your games the .sgx extension instead of .pce for Temper to know it's supposed to be in SGX mode
- Pandora keys: 'm' will always get you into the menu, 'enter' will always work as pause, 'esc' will always exit (afaik..)
- The menu has some very basic keyboard support, probably the most useful is using letters to seek ROM titles in the file loader
- Width scaler works right for the other two horizontal resolutions, not just the common 256 one (but the aspect ratio is a little different on the 341 mode)
- Netplay support.. scroll down for more details..
Of course it's not all finalized or else I'd have released it properly. So this is what it does NOT have:
- Fast video code. That is, it's using an experimental new approach to rendering 2D tile based stuff, and I only got around to writing the C version and not the ARM ASM one. The approach ended up needing more weird stuff to work for PC-Engine than I thought it would, and the ARM code was more painful than I expected too. In my limited tests things aren't actually that much slower on Pandora than the old renderer/ASM was. I'd have switched back for this but then you'd lose the new scaling and SGX. Anyway, this isn't really a big deal on Pandora that's still fast enough, but is holding back a GP2X and to a lesser extent Wiz/Caanoo release, and god forbid I give Slaanesh this code for the GP32 port he's patiently waiting on me to let him do.
- Netplay needs more attention to really be a useful feature. Most importantly, I want to do it in UDP with custom reliability features so you don't get your performance killed by any dropped packets like you do now. But it needs some other stuff too, like right now there's zero checking for if both sides are actually running the same game. And the ability to do more than 2P would be nice.
- Some of the GUI stuff is still a little dodgy, the interface for entering the netplay parameters especially.. at least I bothered to implement keyboard at all here, at the last minute, heh
- Fixes for bugs DaveC found :e
Okay, here's the info on netplay if anyone is brave enough to try it. Actually this is written from memory so it might not be 100% correct >_>
1) Decide on who is going to serve the game, they are "server" and the other guy is "client." If one is behind a router and the other isn't you'll have better luck making the one not server.. otherwise make sure server makes the serving ports open. (okay, granted, most people using a Pandora will be behind a router)
2) Client needs to know what server's IP is. If server is behind a router this is the EXTERNAL IP, not the local network one. You can get it from sites like http://www.whatismyip.com/
3) It's helpful to know your latency with the person, roughly, to pick a good starting point. Try pinging the other person using the ping command in a terminal, preferably on the Pandora itself and not over a computer because the wireless will add latency. When you get the number, use the formula (ping / (2 * 16.7)) to get the one-way latency in frames. Round that number up to the nearest integer, and maybe add another one for safety, but it's up to you.
4) Server needs to start serving: go to the netplay tab and under type choose server. Enter in a username. Select a port (the default one is probably okay). Don't worry about setting IP to anything. Set the latency value to something reasonable, possibly as determined in step 3 - if you didn't do step 3, just pick something and refine it later. NOTE: If you save your settings everything BUT the netplay type field will be saved. So every time you want to start netplay you have to go in and set that option.
5) Server should save their settings and exit the netplay settings menu, then go load the game you want to play. Temper will wait for a client to connect. If you get impatient you can go back to the menu and exit or change the netplay type back to none and load a new game.
6) Client needs to connect: go to the netplay tab and under type choose server. Enter in a username. Select a port - it has to be the same as the one the server picked. Enter the server's IP. You do NOT have to enter the latency value, the server's setting will decide that.
7) Client should save their settings and exit the netplay settings menu, then go load the game the server loaded (it'd better be the same game too! If in doubt both sides should run md5sum on it). It should connect immediately, if the server is serving.. otherwise you'll get an error and it'll start playing the game w/o netplay. I think.
While you're in netplay you can do the following:
- Send a message to the other person by pressing t, typing the message, and pressing enter
- Going into the menu will pause netplay for the other side, it'll dim the screen and bring up a message
- Loading a savestate should work like you expect it to, but you'll have to wait for it to finish sending
- Resetting the game does NOT work like you probably expect it to, it'll exit the netplay session afaik; if you want to reset you've got to get the server to start serving again (I might change this..)
If you picked a latency value that's too low you'll get spikes whenever it can't catch up, where the game suddenly pauses. But if your wifi connection isn't rock solid you'll get these anyway; a dropped packet will look like a ~250+ms latency spike. If you pick a latency value that's too high there'll be a lot of lag between when you press a button and when it happens on the screen. I find that for typical games pushing latency beyond 5 or so starts to really hurt playability, but it depends an awful lot on the type of game.
Latency isn't totally constant so there's no perfect number globally, but often it does stay pretty stable. I tried making a system of auto-detection on this but it was pretty dodgy. Note that the reason the system works this way is because it's peer to peer instead of client/server (even though there's client and server, that's only used for negotiating connections). This is different from most netplay schemes where one side is the server and all transactions have to go round trip to it. This allows for adaptive latency handling and less bandwidth, but gives double the worst case latency and an unfair advantage to the server who would have almost no latency (but this is very nice for watching other people play). An alternative to this is to use a remote server that's ideally in between both sides latency-wise, but good luck setting that up (and it requires more work to maintain). The approach I used sends out data one-way while having an implied fixed latency that requires results be seen within a few frames or stalls happen. This is more like the approach ZSNES used, which some of you may recall had pretty legendary netplay for its time.
So yeah, let me know if anyone actually successfully gets it to work. I haven't tested it in ages.
Fine, knock yourself out: http://exophase.devzero.co.uk/temper.pnd
I give no support for this link whatsoever ;p
(apparently I lied! Well, it might help you to at least know that Temper is a PC-Engine/TurboGrafx-16 emulator, originally released for GP2X and Wiz)
UPDATE: Basically, consider this an unofficial/forward release alpha test sort of deal. If you find problems or have suggestions go ahead and post them here and I'll look over this thread later when I have time to work on the real release. This is what the release has over the old Wiz/GP2X versions:
- SuperGrafx support, but you must give your games the .sgx extension instead of .pce for Temper to know it's supposed to be in SGX mode
- Pandora keys: 'm' will always get you into the menu, 'enter' will always work as pause, 'esc' will always exit (afaik..)
- The menu has some very basic keyboard support, probably the most useful is using letters to seek ROM titles in the file loader
- Width scaler works right for the other two horizontal resolutions, not just the common 256 one (but the aspect ratio is a little different on the 341 mode)
- Netplay support.. scroll down for more details..
Of course it's not all finalized or else I'd have released it properly. So this is what it does NOT have:
- Fast video code. That is, it's using an experimental new approach to rendering 2D tile based stuff, and I only got around to writing the C version and not the ARM ASM one. The approach ended up needing more weird stuff to work for PC-Engine than I thought it would, and the ARM code was more painful than I expected too. In my limited tests things aren't actually that much slower on Pandora than the old renderer/ASM was. I'd have switched back for this but then you'd lose the new scaling and SGX. Anyway, this isn't really a big deal on Pandora that's still fast enough, but is holding back a GP2X and to a lesser extent Wiz/Caanoo release, and god forbid I give Slaanesh this code for the GP32 port he's patiently waiting on me to let him do.
- Netplay needs more attention to really be a useful feature. Most importantly, I want to do it in UDP with custom reliability features so you don't get your performance killed by any dropped packets like you do now. But it needs some other stuff too, like right now there's zero checking for if both sides are actually running the same game. And the ability to do more than 2P would be nice.
- Some of the GUI stuff is still a little dodgy, the interface for entering the netplay parameters especially.. at least I bothered to implement keyboard at all here, at the last minute, heh
- Fixes for bugs DaveC found :e
Okay, here's the info on netplay if anyone is brave enough to try it. Actually this is written from memory so it might not be 100% correct >_>
1) Decide on who is going to serve the game, they are "server" and the other guy is "client." If one is behind a router and the other isn't you'll have better luck making the one not server.. otherwise make sure server makes the serving ports open. (okay, granted, most people using a Pandora will be behind a router)
2) Client needs to know what server's IP is. If server is behind a router this is the EXTERNAL IP, not the local network one. You can get it from sites like http://www.whatismyip.com/
3) It's helpful to know your latency with the person, roughly, to pick a good starting point. Try pinging the other person using the ping command in a terminal, preferably on the Pandora itself and not over a computer because the wireless will add latency. When you get the number, use the formula (ping / (2 * 16.7)) to get the one-way latency in frames. Round that number up to the nearest integer, and maybe add another one for safety, but it's up to you.
4) Server needs to start serving: go to the netplay tab and under type choose server. Enter in a username. Select a port (the default one is probably okay). Don't worry about setting IP to anything. Set the latency value to something reasonable, possibly as determined in step 3 - if you didn't do step 3, just pick something and refine it later. NOTE: If you save your settings everything BUT the netplay type field will be saved. So every time you want to start netplay you have to go in and set that option.
5) Server should save their settings and exit the netplay settings menu, then go load the game you want to play. Temper will wait for a client to connect. If you get impatient you can go back to the menu and exit or change the netplay type back to none and load a new game.
6) Client needs to connect: go to the netplay tab and under type choose server. Enter in a username. Select a port - it has to be the same as the one the server picked. Enter the server's IP. You do NOT have to enter the latency value, the server's setting will decide that.
7) Client should save their settings and exit the netplay settings menu, then go load the game the server loaded (it'd better be the same game too! If in doubt both sides should run md5sum on it). It should connect immediately, if the server is serving.. otherwise you'll get an error and it'll start playing the game w/o netplay. I think.
While you're in netplay you can do the following:
- Send a message to the other person by pressing t, typing the message, and pressing enter
- Going into the menu will pause netplay for the other side, it'll dim the screen and bring up a message
- Loading a savestate should work like you expect it to, but you'll have to wait for it to finish sending
- Resetting the game does NOT work like you probably expect it to, it'll exit the netplay session afaik; if you want to reset you've got to get the server to start serving again (I might change this..)
If you picked a latency value that's too low you'll get spikes whenever it can't catch up, where the game suddenly pauses. But if your wifi connection isn't rock solid you'll get these anyway; a dropped packet will look like a ~250+ms latency spike. If you pick a latency value that's too high there'll be a lot of lag between when you press a button and when it happens on the screen. I find that for typical games pushing latency beyond 5 or so starts to really hurt playability, but it depends an awful lot on the type of game.
Latency isn't totally constant so there's no perfect number globally, but often it does stay pretty stable. I tried making a system of auto-detection on this but it was pretty dodgy. Note that the reason the system works this way is because it's peer to peer instead of client/server (even though there's client and server, that's only used for negotiating connections). This is different from most netplay schemes where one side is the server and all transactions have to go round trip to it. This allows for adaptive latency handling and less bandwidth, but gives double the worst case latency and an unfair advantage to the server who would have almost no latency (but this is very nice for watching other people play). An alternative to this is to use a remote server that's ideally in between both sides latency-wise, but good luck setting that up (and it requires more work to maintain). The approach I used sends out data one-way while having an implied fixed latency that requires results be seen within a few frames or stalls happen. This is more like the approach ZSNES used, which some of you may recall had pretty legendary netplay for its time.
So yeah, let me know if anyone actually successfully gets it to work. I haven't tested it in ages.
Last edited by a moderator:
