<div dir="ltr">Just a quick note that I just merged master into the phonegap branch, so it should have the most recent UI and Netrek protocol support now. It runs *very* slowly on my Android emulator; I'm going to test it on a physical device soon.<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, May 14, 2015 at 11:40 AM, Andrew Sillers <span dir="ltr"><<a href="mailto:apsillers@gmail.com" target="_blank">apsillers@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Lawrence,<span class=""><div><br></div><div>> <span style="font-size:12.8000001907349px">If we take the HTML5 route, I think that the server should be modified to support websocket connections. It would make HTML5 clients life much simpler and would remove the actual HTML5 client dependency on the proxy-adapter.</span></div><div><span style="font-size:12.8000001907349px"><br></span></div></span><div><span style="font-size:12.8000001907349px">I completely agree. There was some (very brief) discussion about Websocket server support when I was originally working on the client. There is actually a `ws-direct` branch on the Github repo as well that doesn't use my custom proxy, but assumes a direct Websocket port on the server. You can accomplish WS support easily with websockify (<a href="https://github.com/kanaka/websockify" target="_blank">https://github.com/kanaka/websockify</a>) which is a very straightforward WS-to-TCP proxy. (The difference between my proxy and a websockify proxy is that my proxy has lots of unnecessary Netrek-specific cruft and is also a Web server. The `ws-direct` branch was modified to eliminate my proxy-wrapper protocol and just contact the server directly.) I don't know what kind of performance impact a WS-to-TCP proxy has, but it's a very easy first step, and it can be run on the same machine as the real server, so there's no second network hop.</span></div><span class=""><div><span style="font-size:12.8000001907349px"><br></span></div><div><span style="font-size:12.8000001907349px">> Do you think that the phonegap tree of your code can be compiled and loaded on Android, as it is?</span><span style="font-size:12.8000001907349px"><br></span></div><div><span style="font-size:12.8000001907349px"><br></span></div></span><div><span style="font-size:12.8000001907349px">I think so, but (1) it needs to merge in master to update to the most recent UI and Netrek protocol support and (2) it was designed to run on an older version of Android so you might need to tweak the target-platform settings when you set up a project. Otherwise, yes, I would expect it to compile and run okay. Also, I'm not sure what happens if the screen is too small to show the whole UI. I designed the UI to scale down to a certain point (note: that functionality is not present in the current phonegap branch; it needs to be merge in from master), but it caps out at some limit, so you might not see the entire UI on a small screen.</span></div><div><span style="font-size:12.8000001907349px"><br></span></div><div><span style="font-size:12.8000001907349px">If you want to see how the client UI does on a mobile device, you can just navigate to <a href="https://netrek-apsillers.rhcloud.com/" target="_blank">https://netrek-apsillers.rhcloud.com/</a> in a mobile browser. It should work, for some definition of "work". Tap to shoot, and drag your finger out from your ship to steer. I think you can shoot phasers by holding a finger on your ship and then tapping elsewhere simultaneously.</span></div><div><span style="font-size:12.8000001907349px"><br></span></div><div><span style="font-size:12.8000001907349px">> </span><span style="font-size:12.8000001907349px">Cordova compatible, "better" WebView</span></div><div><span style="font-size:12.8000001907349px"><br></span></div><div><span style="font-size:12.8000001907349px">Neat! This indeed looks like a drop-in repalcement for Cordova that might be better.</span></div><div><span style="font-size:12.8000001907349px"><br></span></div><div><span style="font-size:12.8000001907349px">> </span><span style="font-size:12.8000001907349px">openGL-js wrapper/library, looks good</span></div><div><span style="font-size:12.8000001907349px"><br></span></div><div><span style="font-size:12.8000001907349px">The HTML5 client uses a canvas library called CAKE.js which is badly out of date, but still works. It might be worthwhile to replace it with another graphics library like this one to get performance improvements and a better UI-event interface. I would personally place this lower on the priority list than getting a working mobile prototype Android app and mildly refactoring the UI, but it definitely seems worthwhile.</span></div><span class="HOEnZb"><font color="#888888"><div><span style="font-size:12.8000001907349px"><br></span></div><div><span style="font-size:12.8000001907349px">Andrew</span></div></font></span></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Wed, May 13, 2015 at 6:41 PM, Lawrence Brass <span dir="ltr"><<a href="mailto:lbrass@gmail.com" target="_blank">lbrass@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div>Hello Andrew,</div><div><br></div><div>It was James that mentioned that your work could be a good starting point for a mobile client. It would be great to have a common code HTML5 client running on desk, lap and mobile platforms.</div><div>I launched the demo from the project's page in github and actually played with the bots at pickled for a while!</div><div>I have not actual experience with Cordova or Phonegap but have done, or at least tried to do, things with WebViews on mobiles with mixed results. My concern is about achieving fluidity comparable to actual clients. I guess we should do some minimal implementation just to test that.</div><div>Do you think that the phonegap tree of your code can be compiled and loaded on Android, as it is?</div><div><br></div><div>If we take the HTML5 route, I think that the server should be modified to support websocket connections. It would make HTML5 clients life much simpler and would remove the actual HTML5 client dependency on the proxy-adapter.</div><div><br></div><div>Some interesting links that I found during research:</div><div><br></div><div>Cordova compatible, "better" WebView: </div><div><span style="white-space:pre-wrap"> </span><a href="https://crosswalk-project.org" target="_blank">https://crosswalk-project.org</a></div><div><br></div><div>openGL-js wrapper/library, looks good:</div><div><span style="white-space:pre-wrap"> </span><a href="http://www.pixijs.com" target="_blank">http://www.pixijs.com</a></div><div><br></div><div>Regards,</div><div>Lawrence.</div><div><div><div><br></div><div><div>On May 8, 2015, at 10:06 AM, Andrew Sillers <<a href="mailto:apsillers@gmail.com" target="_blank">apsillers@gmail.com</a>> wrote:</div><br><blockquote type="cite"><div dir="ltr">I saw that my HTML5 client (<a href="https://github.com/apsillers/html5-netrek" target="_blank">https://github.com/apsillers/html5-netrek</a>) was already mentioned earlier in the Netrek Forever thread. I just wanted to weigh in a little on on the shape of that code.<div><br></div><div>The code could be turned into a mobile app with Cordova/Phonegap (<a href="https://cordova.apache.org/" target="_blank">https://cordova.apache.org/</a>), and in fact, it already has been, for an other version of the code: <a href="https://github.com/apsillers/html5-netrek/tree/phonegap" target="_blank">https://github.com/apsillers/html5-netrek/tree/phonegap</a>. The code is set up so that the message stream is abstracted away, and you can easily replace the Websocket-based networking with any other message source (e.g., TCP). (Compare `/assets/www/js/net_phonegap.js` in the Phongap branch and `/js/net.js` in master.)</div><div><br></div><div>Back then, I wrote my own Android TCP plugin for Phonegap, but at least one cross-platform TCP plugin has matured since then: <a href="https://github.com/Tlantic/cdv-socket-plugin" target="_blank">https://github.com/Tlantic/cdv-socket-plugin</a>.</div><div><div><br></div><div><div>However, as a client, it's a bit feature-incomplete; in particular, I recall that ship-refitting and plasmas are totally unimplemented, as is UDP support. (The code assumes only one, reliable message source, so you'd need to expand it a bit to accept two message sources.)</div><div></div></div><div><br></div><div>It's not clear to me whether it would be less work to modify the C code to interface correctly on mobile devices, or to modify the JavaScript code to include a more complete feature set.</div><div><br></div><div>One potential easy win (again borrowing from the thread on NT Forever) would be to modify the HTML5 client to implement observer mode, which would provide a quick way to observe games directly in-browser. If you want to invite someone to watch the game, you could send them a URL to tune in immediately.</div><div><br></div><div>Andrew</div><div><br></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, May 7, 2015 at 12:22 PM, Lawrence Brass <span dir="ltr"><<a href="mailto:lbrass@gmail.com" target="_blank">lbrass@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><div>Copied this fragment from netrek-forever...</div><div><br><blockquote type="cite"><blockquote type="cite"><font><span style="background-color:rgba(255,255,255,0)">On May 6, 2015, at 7:50 PM, James Cameron <<a href="mailto:quozl@us.netrek.org" target="_blank">quozl@us.netrek.org</a>> wrote:<br></span></font></blockquote></blockquote><blockquote type="cite"></blockquote><blockquote type="cite"><blockquote type="cite"><font><span style="background-color:rgba(255,255,255,0)"><br></span></font></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><font><span style="background-color:rgba(255,255,255,0)">On Wed, May 06, 2015 at 05:19:33PM -0300, Lawrence Brass wrote:<br></span></font></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><font><span style="background-color:rgba(255,255,255,0)">I agree, the matrix has us all. <br></span></font></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><font><span style="background-color:rgba(255,255,255,0)">I browsed the COW-XP client sources last night and liked what I<br></span></font></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><font><span style="background-color:rgba(255,255,255,0)">saw. It seems that the game logic is isolated from the video stuff,<br></span></font></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><font><span style="background-color:rgba(255,255,255,0)">the "W_" module implements the glue code between the classic Windows<br></span></font></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><font><span style="background-color:rgba(255,255,255,0)">API, GDI graphics, inputs and the game. Keyboard and mouse events<br></span></font></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><font><span style="background-color:rgba(255,255,255,0)">are enqueued in a (single?) event queue. Very clear and classic C,<br></span></font></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><font><span style="background-color:rgba(255,255,255,0)">even with Allman bracketing style! (tip of the hat).</span></font></blockquote></blockquote><blockquote type="cite"><font><span style="background-color:rgba(255,255,255,0)"><br></span></font></blockquote><blockquote type="cite"><font><span style="background-color:rgba(255,255,255,0)">Yes, in those days we did peer code reviews. The "W_" module was<br></span></font></blockquote><blockquote type="cite"><font><span style="background-color:rgba(255,255,255,0)">added to the client on Unix before it was ported to Windows in 1996.<br></span></font></blockquote><blockquote type="cite"><font><span style="background-color:rgba(255,255,255,0)"><br></span></font></blockquote><blockquote type="cite"><blockquote type="cite"><font><span style="background-color:rgba(255,255,255,0)">If the "W_" module graphics functionality is reimplemented in say,<br></span></font></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><font><span style="background-color:rgba(255,255,255,0)">openGL(ES), and the proper native framework code is used to capture<br></span></font></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><font><span style="background-color:rgba(255,255,255,0)">the events and feed them into the game event queue, is very probable<br></span></font></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><font><span style="background-color:rgba(255,255,255,0)">that the "game code" could be ported almost untouched to OSX/iOS,<br></span></font></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><font><span style="background-color:rgba(255,255,255,0)">Plain C is actually a subset of objC and fits nicely. On Android I<br></span></font></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><font><span style="background-color:rgba(255,255,255,0)">am not that sure (of the cost). The same strategy could be applied<br></span></font></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><font><span style="background-color:rgba(255,255,255,0)">using the NDK to hold the C game loop and logic, and feed the input<br></span></font></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><font><span style="background-color:rgba(255,255,255,0)">event queue from the native framework, but it may be harder. Porting<br></span></font></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><font><span style="background-color:rgba(255,255,255,0)">from the Java clients is a competitive alternative for Android.<br></span></font></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><font><span style="background-color:rgba(255,255,255,0)">The nice thing about this *hypothetical* scheme is that the game,<br></span></font></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><font><span style="background-color:rgba(255,255,255,0)">network, and video(using openGL) code would be common and game and<br></span></font></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><font><span style="background-color:rgba(255,255,255,0)">network stay almost untouched.<br></span></font></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><font><span style="background-color:rgba(255,255,255,0)">Sounds crazy?</span></font></blockquote></blockquote><blockquote type="cite"><font><span style="background-color:rgba(255,255,255,0)"><br></span></font></blockquote><blockquote type="cite"><font><span style="background-color:rgba(255,255,255,0)">Yes. Especially because the input devices are entirely different.</span></font></blockquote><div><br></div><div>There should be a mapping, before queuing control events, that would convert swipes and taps into meaningful synthetic keystrokes and mouse movements and clicks that the current game code would understand. This mapping is were the "feel" of the game would be defined.</div><br><blockquote type="cite"><font><span style="background-color:rgba(255,255,255,0)">The "W_" API presumes too much about the input devices and the<br></span></font></blockquote><blockquote type="cite"><font><span style="background-color:rgba(255,255,255,0)">underlying graphics libraries.</span></font></blockquote><br></div><div>Yes, this would be the hard part. The API should be divided into 2 modules, one for Graphics in open GL, common to all platforms and the other for the input event handling, particular to each platform.</div><div><br></div><div>I will focus on the "W_" module. I guess that I should look at both unix and win implementations to get more insight.</div><div><br></div><div>Regards.</div><span><div><br></div><div>On May 6, 2015, at 11:32 PM, Lawrence Brass <<a href="mailto:lbrass@gmail.com" target="_blank">lbrass@gmail.com</a>> wrote:<br><br></div><blockquote type="cite"><span>Hello again, I have just subscribed to the dev-list.</span><br><span>Should I copy content from from netrek-forever google group?</span><br><span>Regards,</span><br><span>Lawrence (LarryX).</span><br><span></span><br></blockquote></span></div><br>_______________________________________________<br>
netrek-dev mailing list<br>
<a href="mailto:netrek-dev@us.netrek.org" target="_blank">netrek-dev@us.netrek.org</a><br>
<a href="http://mailman.us.netrek.org/mailman/listinfo/netrek-dev" target="_blank">http://mailman.us.netrek.org/mailman/listinfo/netrek-dev</a><br>
<br></blockquote></div><br></div>
_______________________________________________<br>netrek-dev mailing list<br><a href="mailto:netrek-dev@us.netrek.org" target="_blank">netrek-dev@us.netrek.org</a><br><a href="http://mailman.us.netrek.org/mailman/listinfo/netrek-dev" target="_blank">http://mailman.us.netrek.org/mailman/listinfo/netrek-dev</a><br></blockquote></div><br></div></div></div><br>_______________________________________________<br>
netrek-dev mailing list<br>
<a href="mailto:netrek-dev@us.netrek.org" target="_blank">netrek-dev@us.netrek.org</a><br>
<a href="http://mailman.us.netrek.org/mailman/listinfo/netrek-dev" target="_blank">http://mailman.us.netrek.org/mailman/listinfo/netrek-dev</a><br>
<br></blockquote></div><br></div>
</div></div></blockquote></div><br></div>