openGame Project Update Thread

Post all general things in here.

Moderator: Moderators

Real Member
User avatar
Posts: 42
Joined: 11 May 2015 03:22

Re: openGame Project Update Thread

Postby Marcos » 28 May 2015 04:38

Statrill,You can eliminate the lag and the low FPS of GC in windows 8?

Board-General
User avatar
Posts: 303
Joined: 05 Mar 2012 06:32
Location: United States

Re: openGame Project Update Thread

Postby stAtrill » 28 May 2015 17:27

Marcos wrote:Statrill,You can eliminate the lag and the low FPS of GC in windows 8?
Well, GC already runs slowly in Win8 because Microsoft is deprecating support for DX7 in Win8 forward. However, it runs even slower because of GameRanger's hooks, and the GameRanger-based lag is what we are eliminating. The speedup should be enough to have some of the old vets play with us again (Justinian, Ninja, BD, etc).

In this thread, Justinian talks about methods he discovered to get around Windows 8 slowness, but he never manages to get around GameRanger slowness: viewtopic.php?f=7&t=7232

-Stat

Board-General
User avatar
Posts: 303
Joined: 05 Mar 2012 06:32
Location: United States

Re: openGame Project Update Thread

Postby stAtrill » 30 May 2015 13:17

Okay, an interim update:

I wanted to have at least routing and deployment solved in time for the weekend games, but I somehow lost a day and thought yesterday was Thursday until later that evening. Oops.

Anyway, I managed to do a quick test with BD yesterday - he grabbed a screenshot (though forgot to post it). If I recall correctly, he was managing 30 FPS on Windows 8.1 and had a 162 ms ping to me (!!!). I don't know how we managed that on a Friday evening, of all days, when the internet is most crowded.

The reason I pushed this update is because I made a lot of changes, and only have a limited space to describe things on the versioning software. Since I got a bunch of small things done (which turned out to be not-that-small), they get their own mini-update ^^

Changelog, from Github:

-Program should now reliably execute the shutdown function before closing (need to test)
-TunTap data threads are now daemons
-Peerlist now tracks the socket used to connect to the peer
-setPeerStatus() rewritten, far more stable
-Beginnings of address translating / routing class
-Diagnostics improved
-Misc Improvements

Or, in real terms, I tried to fix the program so that it could handle disconnected peers. Well, it turns out that this didn't happen, and so I ended up rewriting the function responsible (I needed to do it anyway as I had a list of improvements I needed to make to it). I also learned from testing with BD that the program does not properly shutdown, so I have made a potential fix in this update as well. Additionally, the underpinnings of address translation (which is the underpinning of routing) are being added.

Also, it has occurred to me that, since I built the .exe in x64 python, that people on winXP or 32 bit vista will not be able to run it. I don't know why I didn't just build it as 32 bit from the start, since it will run on both machine architectures. I have added this to the TODO list.

-Stat

Board-General
User avatar
Posts: 110
Joined: 26 Feb 2012 17:42

Re: openGame Project Update Thread

Postby Satch » 31 May 2015 00:25

stAtrill wrote:In this thread, Justinian talks about methods he discovered to get around Windows 8 slowness, but he never manages to get around GameRanger slowness: http://gcvets.net/viewtopic.php?f=7&t=7232


I actually completely solved my low FPS problems — caused by running GC on a high spec Windows 8 machine — this evening due to re-reading Justian's post and fannying around for half an hour. Basically, having two monitors and/or having an SLI setup causes major problems. Justinian's workaround involved extending the display on to two monitors, although you don't have to do this.

In order to run GC at 60FPS, I need to:

1. Disable SLI (I was doing this before of course, but this is only the first step to getting it running correctly)
2. Have each monitor connected to a different GPU (this is crucial)
3. Have both monitors at the same resolution (previously I had one 1440p and one 1080p)
4. Make sure that the secondary GPU is chosen as the GPU to use in the GC start dialogue. The game then runs on the opposite/correct GPU (don't ask me why), at a solid 60 FPS.

Running through GameRanger does lower the FPS, however running GC through openGame should not cause any FPS drops.


Image

Note this screenshot is running GC via openGame against Stat, and not Gameranger. The 30FPS cap you see in the bottom right was before I found the solution mentioned above. The screenshot is just included to show that openGame is actually working.

Board-General
User avatar
Posts: 303
Joined: 05 Mar 2012 06:32
Location: United States

Re: openGame Project Update Thread

Postby stAtrill » 05 Jun 2015 20:41

Another interim update:

I made another big commit last week that I hadn't been able to post about here yet. Unfortunately, I haven't really had time to work on things since then. There will be another big version when everything is fully operational. Just need like 2 more hours (with someone around for quick testing) lol
.
Changelog, from the Github commit: <-(This is a link, btw, to the changelog history)
-Distributed DHCP implemented, now gets and sets internal IPs for theswarm
-Automatic updating of TAP adapter properties via WMI
-Switched back to cx-freeze, executable now builds successfully
-Major bugfixes
-Improvements to diagnostics


So, basically, DHCP is a method used to assign IP addresses on a network. The problem is that it requires a DCHP server, and we want to keep things as decentralized as possible. So, there is the starts of a Distributed DCHP implementation. More work needs to be done, like responding when using a guessed rather than confirmed IP, etc. The essentials are there, however.

Next, using the inferred/confirmed IP, we now automatically update the address of the adapter! Crucial functionality, of course.

Also, we switched back to cx-freeze, as I started to run into problems with py2exe building bugged executables, etc. Cx-freeze is magically working again. No idea why. Moving right along....

I already had untested code and bugfixes in from the previous commit (I wasn't able to test it before making this commit), and I knew this commit was going to need testing since it introduces new infrastructure. I spent like 3 hours ironing out bugs with my brother, I think the grand total was somewhere near 30 edits made to the file (including diagnostic/test edits, etc).


So, what remains:
-The program needs to update the routing tables, as Windows generally has no idea what routes to create since we don't respond to ARP, DHCP etc, but data 'appears' to come from remote peers with 11.X.X.X addresses. This is ultra easy, a literal 2 lines of code, but some testing needs to be done to verify the correct route is created.

The above is the only real hurdle left. There are other non-crucial but still relatively high priority things to do to improve quality of service:
-Program auto-downloads TAP adapter, installs. May or may not implement this, as I personally hate when programs do shit for me.
-This is important: This program creates a TCP tunnel. Ground control creates a TCP connnection. TCP over TCP is a terrible idea in networking - it can cause random drops, etc. Unfortunately, I couldn't have learned this sooner as I don't have anyone to test on an actual LAN/Tunngle with, and GR creates a UDP tunnel.

The worst part is that TCP tunnelling is harder to write because of it's statefulness. Even though UDP tunneling is simple, I have already written all of the TCP code :( Don't really want to delete it all out, not sure what to do with it yet.

Just a brief update!
-Stat

Board-General
User avatar
Posts: 303
Joined: 05 Mar 2012 06:32
Location: United States

Re: openGame Project Update Thread

Postby stAtrill » 28 Jun 2015 09:39

Just a small update! I don't really have too much time to write these at the moment, but rest assured I am continuing to crunch away as I can. Following are the three changelogs since my last update:

Changelogs, from the Github commit: <-(This is a link, btw, to the changelog history)
-UDP tunnel mode implemented to prevent potential TCP over TCP condition Note: this condition is now confirmed, so good thing I did this
-Fixed exception during shutdown
-Now announces assumed IP address when not known
-Now saves tunnel mode on close
-Better error handling
-General code improvements
-Fixed wrong CPU architecture in python34.dll Note: this was preventing some people from running openGame. oops.
-Updated openGame.exe

By now I realized that the 'wrong adapter problem' was due to openGame not passing ARP traffic (or, being too lazy to create static ARP entries). This update tried to resolve this, along with a ton of other things:
-No longer truncates frame headers
-Should now pass ARP traffic (resolving major issues) Note: Did not pass ARP traffic. But at least it was a valiant attempt.
-Passes tunnel-wide broadcasts now (using a isBroadcast function)
-Fix to shutdown behavior
-Better error handling
-Certain fatal errors now cause program to exit
-routeAndSend rewritten as single loop
-Major stability improvements
-Various minor improvements

And then this one from earlier today:
-Now transmits ARP packets to remote users Note: NOW it works. lol. Thanks to Nox for helping me verify this.
-Read thread will not crash if reading from adapter fails Note: This is part of preparing to diagnose the crash during room join in GC
-Looping operations streamlined
-Updates more frequently, less latency
-Now warns if admin rights needed, instead of cryptic error Note: Sometimes setting adapter fails while giving a scary looking error. Turns out it is just admin rights LOL


So, as some (or most) of you already know, openGame already works for certain other games we have tried, but Ground Control crashes the adapter. I was running a trace while testing with Nox earlier, and think I may have learned a gem.

When someone first connects to a GC room, the Host sends a massive (ha-ha, get it?) list of every map the host has installed. Since the data to send cannot fit in a single packet, the data is certainly fragmented, though I am not sure yet if GC fragments it itself, or relies on the TCP protocol to fragment it. I refuse to speculate at this point, but this could provide the mechanism behind why some people have less trouble joining when they didn't have all maps installed. This may also be the underpinning of why there is a 'connection order' when we are in GR as well.

Anyway, I am studying this further, as there are other things in the trace that don't immediately make sense to me as well. Fortunately, I have a lead to work with! I may consider testing if fragmentation is causing the crash, by creating a special build with a single map in it. Of course, if this works, then I know I need to dig deeper on TCP fragmentation.

Just another update,
-Stat

Real Member
User avatar
Posts: 42
Joined: 11 May 2015 03:22

Re: openGame Project Update Thread

Postby Marcos » 29 Jun 2015 00:15

Statrill,you can make For next GC version '' window mode '' GC has only '' full screen mode ''?

Board-General
User avatar
Posts: 322
Joined: 25 Nov 2012 12:08
Location: united states

Re: openGame Project Update Thread

Postby shpooky » 29 Jun 2015 16:05

Marcos hes not editing ground control hes making a way better version of gameranger
i only work in cyan and sometimes really really bright blue :D so bright it burns your eyes!!!!!

(if you have any questions don't be afraid to PM me or you can contact me via email ddavidshpak@aol.com)

Board-General
User avatar
Posts: 105
Joined: 27 Jan 2012 17:21

Re: openGame Project Update Thread

Postby Sarvik » 29 Jun 2015 18:51

stAtrill wrote:When someone first connects to a GC room, the Host sends a massive (ha-ha, get it?) list of every map the host has installed. Since the data to send cannot fit in a single packet, the data is certainly fragmented, though I am not sure yet if GC fragments it itself, or relies on the TCP protocol to fragment it. I refuse to speculate at this point, but this could provide the mechanism behind why some people have less trouble joining when they didn't have all maps installed. This may also be the underpinning of why there is a 'connection order' when we are in GR as well.

Anyway, I am studying this further, as there are other things in the trace that don't immediately make sense to me as well. Fortunately, I have a lead to work with! I may consider testing if fragmentation is causing the crash, by creating a special build with a single map in it. Of course, if this works, then I know I need to dig deeper on TCP fragmentation.

Would it maybe be a good idea to do a bit larger testing (4+ people) for GC connection issues? Like replicating that 'connection order' issue with only 2 people probably wont work. If you believe that it would help then Im pretty sure that enough people would be willing to donate some of their normal GC playtime for the cause.

Board-General
User avatar
Posts: 322
Joined: 25 Nov 2012 12:08
Location: united states

Re: openGame Project Update Thread

Postby shpooky » 30 Jun 2015 16:34

when ghat hosts in GR i have to join before nox or i cant get in the room

so could we see if things run better when ghat hosts a game over opengame?
i only work in cyan and sometimes really really bright blue :D so bright it burns your eyes!!!!!

(if you have any questions don't be afraid to PM me or you can contact me via email ddavidshpak@aol.com)

PreviousNext

Return to Ground Control - General

Who is online

Users browsing this forum: Bing [Bot] and 1 guest