Network lag (dc)

[inada-s]

goal

• Players under 50ms ping can play smoothly on 5fr pad-delay limit.

[inada-s]

PS2 version address note.

fix gp address for broken ps2dis:)

lui a0, $0058
addiu gp, a0, $6370

buffer frames

00382e34 CalculateDefaultValue
005802BC DefaultValue
005802AC CopyOfDefaultValue
00aa9618 CurrentValue

[inada-s]

The problem that flycast doesnt work smoothly can be solved by increasing modem poll rate.
But pad-delay issue there is.
I have found that this pad buffering mechanism can be solved on ps2.
But dc version doesn't have debugging symbol so it's hard to find patchable address.

[inada-s]

hacked!
https://gyazo.com/296e318a9d8056eb83eb188de8bae9d2

[inada-s]

@gh0stl1ne
Sorry I should have left information..

• TO BUILD FLYCAST
  the build.sh and build.bat may help you to build flycast.
  https://github.com/inada-s/flycast/blob/994a4390459ff88a3b3943838bfe71166564721f/build.sh
  https://github.com/inada-s/flycast/blob/994a4390459ff88a3b3943838bfe71166564721f/build.bat

I call build.sh from git bash.

This is based on original appvayor.yml

Note:
When I first time compiled it with a different version of mingw, build was succeeded but the build was unstable, sometimes freeze.
If you have already added PATH linx-like toolkit, make sure to use
specific version of mingw. x86_64-7.2.0-posix-seh-rt_v5-rev1\mingw64\bin

[inada-s]

This is my investigation of DC version DX.
If you have more good way, please share me.

Setup ghidra

1. Extract 1ST_READ.BIN from track03.bin.
   jc-gd rom-explorer-v1.5.1 is fine tool.
2. Open ghidra latest version, create new project
3. import 1ST_READ.BIN with following setting.

• Select Language to SuperH4 32bit little VisualStudio.
• Click options and set BaseAddress 0c000000. (this may wrong)
  click OK then the import is completed.

4. Run All auto analyze.
5. Select Edit -> Tool Option -> Search setting. Increase Search limit to over 10000.

You have to learn SH4 operations.
This document is pretty good.
http://www.shared-ptr.com/sh_insns.html

If you really need analysis, I recommend to do decompiling a small function by hand.

How to serach.

Firstly, search ps2 version with ps2dis, and find the corresponding function with Ghidra.

In SH4, a signed 1-byte constant may be used in an immediate instruction.
Constants of 2 bytes or more are placed as literals near the function used.

• Select Search-> Memory.
• Enter Search Value (characteristic 1 byte constant works surprisingly well)
• When performing a 1 byte search, the part used by the cmp instruction is given priority.
• When performing a 2 or more bytes search, click the line and jump to xref.
• Read ops to determine if it is the function that you are looking for.

[inada-s]

Function starting with 0c0366ce is ReflectMsg function.
There are instructions to check current pad-lag values.

Address 0c3abb91 probably stores current pad-delay.
When update pad-delay, new pad-delay candidate value is storead on 0c3ab522.

The new pad-delay value is compared with the upper limit before set. (see 0c03534c ~ 0c03534e)
I edited the limit value, then I could manage the in-game pad lag :)

[inada-s]

inada-s/flycast@994a439
inada-s/flycast@0ce1311
sorry for dirty commit.

With modem polling rate fix and pad-lag fix, The game is now playable level on local server.
But I guess that some overheads still alive in flycast, so detailed investigation and tuning is needed.

[inada-s]

The final target is:
Players under 50ms ping can play smoothly on 5fr pad-delay limit.

This is the same of zdxsv.
I'll edit this issue.

[AM2petterk]

Know only some things about the Kddi DC games but happy to help.

[inada-s]

O, Oh..? Sega-AM2 Co., Ltd ..?
I don't know what it is.

I'm working on this project while I'm staying at home because of the coronavirus.
We are unearthing the history of 20 years ago.
Every time I discover something, I respect the person who made it.

[inada-s]

First, I dumped the PPP communication during a 4 players battle.
entire log: flycast.log

[inada-s]

I found ppp_recv still has some overhead.

• time from modem write completed to begin ppp recv (7~16ms).
• time from ppp_recv begin to read a ppp frame to end read the ppp frame (0~10ms)

02:15:344 :98 I[MODEM]: [pppdumper][modem_write][0ms]data:1221000490eb31003604000452c232003704
02:15:352 :98 I[MODEM]: [pppdumper][modem_write][0ms]data:1223000490eb31003604000452c232003704
02:15:354 :98 I[MODEM]: [pppdumper][modem_write][0ms]data:1222000490eb31003604000452c232003704
02:15:355 :98 I[MODEM]: [pppdumper][ppp_read][4ms]data:1221000490eb31003604000452c232003704
02:15:360 :98 I[MODEM]: [pppdumper][ppp_read][4ms]data:1223000490eb31003604000452c232003704
02:15:365 :98 I[MODEM]: [pppdumper][ppp_read][4ms]data:1222000490eb31003604000452c23200370

[AM2petterk]

Yes, official..

However I can help you out on spare time, like now.

Is this the whole packet log(s) you captured?

What is Flycast..?

EDIT: I checked it out, emulator. I dont need it, have a Katana 5.24 right here.
Where in Tokyo are you?

[inada-s]

game server

90% of lobby server and battle server have been implemented.
The wiki has instructions on how to build a server. (It's not exhaustive).
https://github.com/inada-s/gdxsv/wiki

game client

This server does not implement the ppp server. Only above tcp.
So if you use a real machine, you need to prepare a ppp server and connect from your Dreamcast to the lobby server via it.(I have never tried this.)

Flycast is a Dreamcast emulator. The modem emulation and is also working.
Flycast includes a ppp server implementation and can connect to the server with tcp.
The forking flycast has some tricks to make the Dreamcast version of the game connect to the server (ex: rewrite original server address) .
see about the tricks: https://github.com/inada-s/flycast/blob/9ebe657b18c8921fd736aaf495c6824f54d3f6e2/core/gdxsv.cpp#L95-L127

current problem

We can play on the local network, but if it's over the internet, network lag becomes a problem.
I'm trying to research and tune the flycast modem code.

I live within walking distance of Tokyo Station.

[AM2petterk]

(ex: rewrite original server address)

I can do this in realtime on Katana development hardware.. Anyway, for regular consoles, one can use codebreaker codes OR vmu save, or even a patcher disc like BluCrab PSO Patcher disc, which also was done for Alien Front Online to patch address to connect to.

Let me know if you need help with something specific.

[inada-s]

The game connects to the Internet using a hard-coded KDDI phone number, PPP login ID and password. After that, connect to the game server with TCP over PPP.
So I think it's very difficult to make it playable on a real dreamcast. (It looks like it can be done using DreamPi)

My current goal is to be able to play on the emulator.
When I need to work the game on a real dreamcast, I may ask you to help :)

[inada-s]

Flycast modem

flycast's modem have a number of receive overhead factors that are difficult to eliminate
completely.

The biggest problem is interrupt callback jam.
The modem code fetches the received data byte by byte in the interrupt callback.
For some reason, the chance to call the interrupt callback is significantly delayed.

UpdateSystem() delay

This is caused when Synchronous Rendering is enabled.
Should disable this realtime online games(?)

rend_end_sch block

https://github.com/flyinghead/flycast/blob/836780d8a74c880c1cfdf3ddb0d19a5d031a0963/core/hw/pvr/Renderer_if.cpp#L438
This re.Wait() waits the end of current rendering.

Increasing the delay of sh4_sched_request(render_end_schid, n) may reduce the block.
I tested sh4_sched_request(render_end_schid, 500000*6) then the block is very reduced (still alive but improved).

AicaUpdate blocks

tested on:

• disable video Synchronous Rendering
• enable sound
• enable Limit emulator speed
• use audio driver

this blocks ~18ms. Waiting for audio buffer(?)
The audio wait is necessary for synchronization with the screen, so it's not easy to get rid of this jam.This only happens once per frame.

On second thought, even if the emulator accept receiving modem data for entire frame,
the game can check the data only once per frame, so it wouldn't be a big improvement.
(It has some effect, but I can't test it.)

Next step

For the time being, I leave this problem and continue developing gdxsv with 8fr padlag .

movie: https://youtu.be/I9rtGcymcRA

• 8fr padlag
• tokyo(4client) - osaka(server gcp) ping 15ms

[inada-s]

I came up with the idea that insert short-sleep interrupt so that a single frame process ends in just one frame time.
(I'll leave this as just an idea memo.)

[AM2petterk]

Well done!

[ultramecha]

@inada-s Great job on this server! I wanted to share with you that with a few modifications were made by a developer named Shuouma, and now the game works very well on real Dreamcast Hardware! Hope to see more Japanese Dreamcast game servers reversed engineered! Thank you for your hard work!

https://youtu.be/3OetC4dmiN8

[inada-s]

I'm surprised to see the news.
Well released without documents :)
I have to buy a dream pi kit.

[inada-s]

I didn't think about the release yet, so I didn't put the license file.
If there is no particular harm, I would like to use AGPL as the parent project zdxsv.
Do you have an opinion?

[ultramecha]

I'll forward that question to Shuouma. He wanted your permission before releasing any code. Its just hosted on a private server for now :)

[ShuoumaDC]

It was pretty much ready to go, just needed to increase the SetReadDeadline timeout in the mcs from 10 to 30, due to the DC loading time. I deployed it just to help out on this issue.

If you still want to do a UDP Proxy I would gladly help setting up a TCP<->UDP on the actual dreampi.

[inada-s]

It was pretty much ready to go, just needed to increase the SetReadDeadline timeout in the mcs from 10 to 30, due to the DC loading time. I deployed it just to help out on this issue.

thanks I'll fix it.

If you still want to do a UDP Proxy I would gladly help setting up a TCP<->UDP on the actual dreampi.
That is very interesting idea.
Installing a UDP proxy on dreampi is very interesting.

The effect of UDP proxy is very good.
In addition to that, it would be nice if we could introduce a patch to reduce the in-game input delay described in this issue. Is there an easy way to patch the game?
I have no knowledge of Dreamcast.

[ShuoumaDC]

We will test more, but I cant "feel" any input delay when playing on the actual hardware.
I even played against one with 300ms latency and the TCP stream freezed sometimes but still very playable. But I added the support to play 1vs1, so lets see how it is with 2vs2.

[vkedwardli]

@ShuoumaDC for your information, the input lag reduction memory hack is here: https://github.com/inada-s/flycast/blob/e000712ba3d31d75eb0a2c4b4e33f2b21ed4d86b/core/gdxsv.cpp#L60-L61

[inada-s]

By installing a patch in the game and bypassing the modem implementation, we were able to get zero modem overhead.
https://github.com/inada-s/flycast/tree/gdxsv-dev2/gdxsv_patch

I didn't really want to do this (because it didn't contribute to the flycast)