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. On Thu, May 14, 2015 at 11:40 AM, Andrew Sillers <apsillers at gmail.com> wrote: > Lawrence, > > > 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. > > 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 ( > https://github.com/kanaka/websockify) 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. > > > Do you think that the phonegap tree of your code can be compiled and > loaded on Android, as it is? > > 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. > > If you want to see how the client UI does on a mobile device, you can just > navigate to https://netrek-apsillers.rhcloud.com/ 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. > > > Cordova compatible, "better" WebView > > Neat! This indeed looks like a drop-in repalcement for Cordova that might > be better. > > > openGL-js wrapper/library, looks good > > 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. > > Andrew > > On Wed, May 13, 2015 at 6:41 PM, Lawrence Brass <lbrass at gmail.com> wrote: > >> Hello Andrew, >> >> 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. >> I launched the demo from the project's page in github and actually played >> with the bots at pickled for a while! >> 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. >> Do you think that the phonegap tree of your code can be compiled and >> loaded on Android, as it is? >> >> 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. >> >> Some interesting links that I found during research: >> >> Cordova compatible, "better" WebView: >> https://crosswalk-project.org >> >> openGL-js wrapper/library, looks good: >> http://www.pixijs.com >> >> Regards, >> Lawrence. >> >> On May 8, 2015, at 10:06 AM, Andrew Sillers <apsillers at gmail.com> wrote: >> >> I saw that my HTML5 client (https://github.com/apsillers/html5-netrek) >> was already mentioned earlier in the Netrek Forever thread. I just wanted >> to weigh in a little on on the shape of that code. >> >> The code could be turned into a mobile app with Cordova/Phonegap ( >> https://cordova.apache.org/), and in fact, it already has been, for an >> other version of the code: >> https://github.com/apsillers/html5-netrek/tree/phonegap. 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.) >> >> Back then, I wrote my own Android TCP plugin for Phonegap, but at least >> one cross-platform TCP plugin has matured since then: >> https://github.com/Tlantic/cdv-socket-plugin. >> >> 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.) >> >> 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. >> >> 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. >> >> Andrew >> >> >> On Thu, May 7, 2015 at 12:22 PM, Lawrence Brass <lbrass at gmail.com> wrote: >> >>> Copied this fragment from netrek-forever... >>> >>> On May 6, 2015, at 7:50 PM, James Cameron <quozl at us.netrek.org> wrote: >>> >>> >>> On Wed, May 06, 2015 at 05:19:33PM -0300, Lawrence Brass wrote: >>> >>> I agree, the matrix has us all. >>> >>> I browsed the COW-XP client sources last night and liked what I >>> >>> saw. It seems that the game logic is isolated from the video stuff, >>> >>> the "W_" module implements the glue code between the classic Windows >>> >>> API, GDI graphics, inputs and the game. Keyboard and mouse events >>> >>> are enqueued in a (single?) event queue. Very clear and classic C, >>> >>> even with Allman bracketing style! (tip of the hat). >>> >>> >>> Yes, in those days we did peer code reviews. The "W_" module was >>> >>> added to the client on Unix before it was ported to Windows in 1996. >>> >>> >>> If the "W_" module graphics functionality is reimplemented in say, >>> >>> openGL(ES), and the proper native framework code is used to capture >>> >>> the events and feed them into the game event queue, is very probable >>> >>> that the "game code" could be ported almost untouched to OSX/iOS, >>> >>> Plain C is actually a subset of objC and fits nicely. On Android I >>> >>> am not that sure (of the cost). The same strategy could be applied >>> >>> using the NDK to hold the C game loop and logic, and feed the input >>> >>> event queue from the native framework, but it may be harder. Porting >>> >>> from the Java clients is a competitive alternative for Android. >>> >>> The nice thing about this *hypothetical* scheme is that the game, >>> >>> network, and video(using openGL) code would be common and game and >>> >>> network stay almost untouched. >>> >>> Sounds crazy? >>> >>> >>> Yes. Especially because the input devices are entirely different. >>> >>> >>> 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. >>> >>> The "W_" API presumes too much about the input devices and the >>> >>> underlying graphics libraries. >>> >>> >>> 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. >>> >>> I will focus on the "W_" module. I guess that I should look at both >>> unix and win implementations to get more insight. >>> >>> Regards. >>> >>> On May 6, 2015, at 11:32 PM, Lawrence Brass <lbrass at gmail.com> wrote: >>> >>> Hello again, I have just subscribed to the dev-list. >>> Should I copy content from from netrek-forever google group? >>> Regards, >>> Lawrence (LarryX). >>> >>> >>> _______________________________________________ >>> netrek-dev mailing list >>> netrek-dev at us.netrek.org >>> http://mailman.us.netrek.org/mailman/listinfo/netrek-dev >>> >>> >> _______________________________________________ >> netrek-dev mailing list >> netrek-dev at us.netrek.org >> http://mailman.us.netrek.org/mailman/listinfo/netrek-dev >> >> >> >> _______________________________________________ >> netrek-dev mailing list >> netrek-dev at us.netrek.org >> http://mailman.us.netrek.org/mailman/listinfo/netrek-dev >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mailman.us.netrek.org/pipermail/netrek-dev/attachments/20150515/56612e6e/attachment-0001.html>