PureBasic Forums - English

tj1010 wrote:OpenFL and HaxUI are too reliant on Flash. XDK is HTML5 which always has problems publishing on IOS store.

How are they "reliant on Flash"?
Flash is one of their possible targets not a dependency.

the.weavster wrote:

TI-994A wrote:The JavaScript code runs atop an embedded Rhino Engine which acts as an interpreter to the Java environment. It is not compiled to Dalvik bytecode.

Dave Smart (the developer of DroidScript) wrote:Google’s introduction of the V8 engine is a real game changer, it allows JavaScript running in Chrome browsers and Android mobile devices to be compiled to machine code before execution. This means is runs blisteringly fast, enabling a whole host functionality that was previously out of reach for JavaScript based applications. You can now do amazing things involving image processing, 3D graphics and physics simulation that were simply impractical before the creation of V8.

Source

I'm pretty sure that there's a point that's going to be torn to shreds in that post of yours.

If there's even a point to begin with.

TI-994A wrote:I'm pretty sure that there's a point that's going to be torn to shreds in that post of yours.

If there's even a point to begin with.

This DroidScript and this droidscript are not the same project.
Repeat after me: "DroidScript uses V8 not Rhino"

Have I explained that clearly enough for you? I know you struggle.

the.weavster wrote:This DroidScript and this droidscript are not the same project.
Repeat after me: "DroidScript uses V8 not Rhino"

Incorrect, as usual. One DroidScript uses Rhino, while the other uses V8.

And still no point.

the.weavster wrote:

tj1010 wrote:OpenFL and HaxUI are too reliant on Flash. XDK is HTML5 which always has problems publishing on IOS store.

How are they "reliant on Flash"?
Flash is one of their possible targets not a dependency.

You're correct it's just a build option.

I'll eventually do test builds with these two engines and see about UI support. They have GPS and sensor support for sure, but I want to see the range of widgets there is, and how much like Java they look.

Something with a range of UI widgets that works on Android and IOS would be ideal. Most of the 'easy' languages out there don't even implement sensors.

The current economics of indy dev for apps is a nightmare, unless it's primitive screen switching button apps like you see some people churn out in a week and act like they're launching a business with..

TI-994A wrote:

the.weavster wrote:This DroidScript and this droidscript are not the same project.
Repeat after me: "DroidScript uses V8 not Rhino"

Incorrect, as usual. One DroidScript uses Rhino, while the other uses V8.

And still no point.

First, let me remind you of the context because that's a real failing of yours:

the.weavster wrote:DroidScript makes creating apps for Android very easy.

tj1010 wrote:I suspect their "native" builds are just static JS resources and they sub-class webview like others. If you don't need short-term port to IOS it's probably the best option I've seen.

I'm wondering how they pay for development though? No ads and no sales regulations. It's also beta.

See which DroidScript was being discussed?

Then let's look at what you said:
First you said this:

TI-994A wrote:The JavaScript code runs atop an embedded Rhino Engine which acts as an interpreter to the Java environment. It is not compiled to Dalvik bytecode.

and then immediately followed up with this:

TI-994A wrote:There's an APK-builder plugin that's offered as an in-app purchase.

Are you saying you knew you were talking about two different projects?

tj1010 wrote:You're correct it's just a build option.

I'll eventually do test builds with these two engines and see about UI support. They have GPS and sensor support for sure, but I want to see the range of widgets there is, and how much like Java they look.

Something with a range of UI widgets that works on Android and IOS would be ideal. Most of the 'easy' languages out there don't even implement sensors.

See also the hundreds of available libs at Haxelib (cross-platform, and target-dependent ones).

And projects like HaxeD and Dax for conversion to/from D. Interesting stuff for languages-interested people.

the.weavster wrote:Are you saying you knew you were talking about two different projects?

No. I believe that the current version of DroidScript is a fork of the original version which ran on the Rhino engine. The fact that it had upgraded to the V8 engine has no bearing on the comments that I had made.

Which brings me back to the elusive question: What's you point?

TI-994A wrote:No. I believe that the current version of DroidScript is a fork of the original version which ran on the Rhino engine.

Why do you believe that? There's absolutely no similarity between the APIs never mind the underlying JavaScript engine.

TI-994A wrote:Which brings me back to the elusive question: What's you point?

It was a very simple point for most people to understand but let me help you out (again). This:

TI-994A wrote:The JavaScript code runs atop an embedded Rhino Engine which acts as an interpreter to the Java environment. It is not compiled to Dalvik bytecode.

is incorrect.

the.weavster wrote:There's absolutely no similarity between the APIs never mind the underlying JavaScript engine.

This:

TI-994A wrote:The JavaScript code runs atop an embedded Rhino Engine which acts as an interpreter to the Java environment. It is not compiled to Dalvik bytecode.

is incorrect.

Besides the difference in the underlying JavaScript engine, which we've established, how so?

As he said, the V8 engine is used, which compiles to native machine code (i.e. x86, ARM, etc)

This is one of the earliest powerful tools I came across, but the license costs are steep and the most economical language is object pascal.

http://www.embarcadero.com/products/rad-studio

I'm looking at the Intel tool right now.

tj1010 wrote:I'm looking at the Intel tool right now.

I'm intending to figure out a nice workflow between SpiderBasic and the XDK but I've got wrapped up in something else at the moment (and it's summer). It will be better once this feature request has been implemented anyway.

the.weavster wrote:

tj1010 wrote:I'm looking at the Intel tool right now.

I'm intending to figure out a nice workflow between SpiderBasic and the XDK but I've got wrapped up in something else at the moment (and it's summer). It will be better once this feature request has been implemented anyway.

I have a game done in SB. I basically did a 800x480 fixed borderless screen and put it in a iframe. I use PHP and SB/JS timers but no long-polling or websockets because I use cheap hosting for the back-end.

I'll probably eventually scale the screen using HD bitmaps and detection I didn't have time to research screen mode switching though. No way I'm going to try and hack SB css.

To me it's all about economics. This is the bottom line of doing stuff around markets and employers. SB is pretty good but I'd imagine it'd be hard to get on to IOS store or signed using a webview even if you put it all in a resource and don't use networking.

Tenaja wrote:As he said, the V8 engine is used, which compiles to native machine code (i.e. x86, ARM, etc)

And as I've said, we've established that the underlying JavaScript engine for this new version is different. Either way, the statement holds true:

The JavaScript code runs atop an embedded Rhino/V8 Engine which acts as an interpreter to the Java environment. It is not compiled to Dalvik bytecode.

Rendering his post pointless; as always.