Jump to content

  • Log In with Google      Sign In   
  • Create Account


#Actualcr88192

Posted 17 August 2013 - 10:39 AM

 

 

Environment Setup:

1. I setup a regular APACHE server on a PC.

2. I do everything client side.

3. I load all my resources statically from the apache server (img tags for pictures, etc...) .

4. Make sure you add all the special meta-tags that prevent zooming,scrolling,etc...

5. If I need 3rd party AJAX calls to other servers, I setup a PROXY_PASS on my apache server to prevent XSS exceptions.

 

Workflow:

1. Work with Webstorm (paid) or Netbeans (free) on my PC.

2. Run and debug in chrome on my PC.

3. Run and debug on my mobile. On rare occasions when the PC debugger is not enough I use http://people.apache.org/~pmuellr/weinre/docs/latest/.

 

 

 

Excuse me my totally lame question in those fields 

(I come from c/asm world and I totaliy do not know nothing

about javascript related environments):

 

Is it possible to test smal games without setting up 

a server ?- I would like just get some most simplest

 javascript running environment where I could load images, read keystrokes mouse etc

 

Is the usage of any browser simplest way of running that?

 

Can be such assets/images read from local disk 

through giving some local file path to that or this

is not possible?

 

As to some libs, are some libs handy/necessary for

writing simple games ? I understand it should be mainly

sprite based game, per pixel drawing (plots or something)

 i understand is not to much possible? Can such sprite be

scaled/rotated ? Decent framerates can be acheivable in 

simple cases ?

 

(sorry for lame question I am totally nevbie person in

the topic of javascript based games )

 

 

 

ADD: (it seems it was auto-stripped, probably due to notation).

there are "file" URIs, which basically tell the browser to pull contents off the local HDD.

this allows using the browser to access pages and possibly apps stored on the users' local drive, and can generally often be used for testing things prior to putting them up on the internet (or for things like local-documentation, ...). the main thing is mostly using relative file references rather than absolute URLs, then the browser will look for things relative to wherever the page was loaded from.

 

 

but, as others have noted, JS has a few drawbacks, many of which still apply to its use as an intermediate language for compiling other languages.

 

 

the ES6 draft does apparently have a few things in the works to help remedy some of the problems, like adding static types and class/instance OO support.

 

AFAICT: a lot of this is already supported with SpiderMonkey.

 

the merit of static types here is that it makes using it for large apps (and getting usable performance and a not-absurd memory footprint) at least a bit more plausible.

 

 

 

a remaining problem though is still that you would have to push down and compile a big glob of code for the app.

 

a ZIP file would help with sending the code to the user, but you still need to compile it on the client end (not free).

 

bytecode would generally be a better solution here, but then we basically have something more like Flash or Silverlight again.

granted, there is still theoretically the option of sending down code as bytecode and, as-needed, converting it to JS and feeding it into the JS engine.

 

say, for clients which lack the appropriate VM or plugin, we send down a JS version of the VM along with the app.

 

or, alternatively, having alternate compiled versions of an app, then using probing to detect which one to send to the client (either the bytecode versions for users with the appropriate VM, or the JS version for others). the JS version could possibly be sent as a ZIP with a bit of JS code to extract its contents and feed them into the browser.

 

better yet would be a standardized bytecode, with direct browser support.

 

 

the main advantages bytecode has are:

naturally more compact than textual code representations;

generally cheaper to convert to native code.

 

even at best though, all this would probably still give a "mediocre" development experience (vs targeting native, and staying clear of the browser and all its funkiness).

 

 

granted, we would need a "good" bytecode (my personal thoughts on the subject have generally drifted in the direction of something sort of resembling Dalvik hybridized with LLVM...). the front-end language would then be ideally "whatever we can write compilers for".

 

 

or such...


#1cr88192

Posted 17 August 2013 - 10:33 AM

 

 

Environment Setup:

1. I setup a regular APACHE server on a PC.

2. I do everything client side.

3. I load all my resources statically from the apache server (img tags for pictures, etc...) .

4. Make sure you add all the special meta-tags that prevent zooming,scrolling,etc...

5. If I need 3rd party AJAX calls to other servers, I setup a PROXY_PASS on my apache server to prevent XSS exceptions.

 

Workflow:

1. Work with Webstorm (paid) or Netbeans (free) on my PC.

2. Run and debug in chrome on my PC.

3. Run and debug on my mobile. On rare occasions when the PC debugger is not enough I use http://people.apache.org/~pmuellr/weinre/docs/latest/.

 

 

 

Excuse me my totally lame question in those fields 

(I come from c/asm world and I totaliy do not know nothing

about javascript related environments):

 

Is it possible to test smal games without setting up 

a server ?- I would like just get some most simplest

 javascript running environment where I could load images, read keystrokes mouse etc

 

Is the usage of any browser simplest way of running that?

 

Can be such assets/images read from local disk 

through giving some local file path to that or this

is not possible?

 

As to some libs, are some libs handy/necessary for

writing simple games ? I understand it should be mainly

sprite based game, per pixel drawing (plots or something)

 i understand is not to much possible? Can such sprite be

scaled/rotated ? Decent framerates can be acheivable in 

simple cases ?

 

(sorry for lame question I am totally nevbie person in

the topic of javascript based games )

 

 

 

but, as others have noted, JS has a few drawbacks, many of which still apply to its use as an intermediate language for compiling other languages.

 

 

the ES6 draft does apparently have a few things in the works to help remedy some of the problems, like adding static types and class/instance OO support.

 

AFAICT: a lot of this is already supported with SpiderMonkey.

 

the merit of static types here is that it makes using it for large apps (and getting usable performance and a not-absurd memory footprint) at least a bit more plausible.

 

 

 

a remaining problem though is still that you would have to push down and compile a big glob of code for the app.

 

a ZIP file would help with sending the code to the user, but you still need to compile it on the client end (not free).

 

bytecode would generally be a better solution here, but then we basically have something more like Flash or Silverlight again.

granted, there is still theoretically the option of sending down code as bytecode and, as-needed, converting it to JS and feeding it into the JS engine.

 

say, for clients which lack the appropriate VM or plugin, we send down a JS version of the VM along with the app.

 

or, alternatively, having alternate compiled versions of an app, then using probing to detect which one to send to the client (either the bytecode versions for users with the appropriate VM, or the JS version for others). the JS version could possibly be sent as a ZIP with a bit of JS code to extract its contents and feed them into the browser.

 

better yet would be a standardized bytecode, with direct browser support.

 

 

the main advantages bytecode has are:

naturally more compact than textual code representations;

generally cheaper to convert to native code.

 

even at best though, all this would probably still give a "mediocre" development experience (vs targeting native, and staying clear of the browser and all its funkiness).

 

 

granted, we would need a "good" bytecode (my personal thoughts on the subject have generally drifted in the direction of something sort of resembling Dalvik hybridized with LLVM...). the front-end language would then be ideally "whatever we can write compilers for".

 

 

or such...


PARTNERS