Re: The Revenge of the Geeks
Date: Sat, 26 Jan 2013 17:04:35 -0600
Message-ID: <ke1ngi$g80$1_at_news.albasani.net>
On 1/26/2013 3:34 PM, Arne Vajhøj wrote:
> On 1/26/2013 2:22 PM, BGB wrote:
>> dunno about an app working in a browser, I haven't personally really
>> looked much into this. the one thing I had noted which I felt might make
>> this worthwhile was "Google Native Client", but given it is Chrome-only
>> at this point, this is a drawback (better if Firefox supported it, but
>> the FF people apparently oppose it).
>>
>> Adobe Flash sometimes seemed like a possible option, but isn't
>> particularly compelling, and the development environment apparently
>> costs money.
>
> Java applet, Flash, SilverLight, Google Native, JavaScript - there
> are plenty of options.
>
yep, not saying that there aren't a lot of options here.
the main advantage of Native Client would be that it would be easier for me to target it, mostly because it wouldn't require largely rewriting a bunch of stuff (all the C parts of the project could be kept intact, and compiled fairly directly, ...).
but, many of the other options could likely require writing code specifically for them (in contrast to directly porting preexisting code).
Silverlight could work, but AFAIK C++/CLI doesn't work with it (sadly, not that it really works great with .NET in general). the main thing here is basically using C++/CLI to compile C code into CIL bytecode, but using C++/CLI tends to reveal apparent ugly issues...
but, even as such, it is a little less work IME to port code between C and C# than it is to port code between C and Java.
Flash at least theoretically has a C compiler for it (people have shown some of the Quake-series games, namely Quake and Quake 3 Arena, running on Flash before).
HTML+JS was fairly limited in the past, but should be more capable now (like with WebGL and similar, ...).
I have actually written some small Java applets in the past (very long ago), but nothing more recent.
both would (fairly likely) require a fair bit of porting effort (and/or a trans-language compiler).
a further limitation in the JS case though is that, given code is sent and recompiled from text form, this puts effective size limits on it (trying to give it a giant mass of trans-compiled code probably wont work very well, and some other areas of JS give a lot of room for doubt).
between them, trans-compiling to JVM bytecode would probably work better, but performance is less certain (since pointers and structures need to be simulated, ...).
probably going through an intermediate stage could be easier: C -> BSVM bytecode -> JVM bytecode.
mostly as, at both stages, things would fit nicer (and the C->BSVM conversion would lift out the vast majority of the pointers, namely by converting most of the pointers to object references, ...).
still a lot of hassle though in either scenario.
> The Adobe GUI development tools cost money.
>
> But you can actually develop MXML and AS with any
> editor/IDE and you can build with ant and the Flex SDK.
>
yes, ok.
may look into this. Received on Sun Jan 27 2013 - 00:04:35 CET