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 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mailman.us.netrek.org/pipermail/netrek-dev/attachments/20150508/2529a950/attachment.html>