@ fir

JavaScript is a simple scripting language, however it lacks many of the features java/c# has. Many folks make up for the lack of "features" by using many different server side languages such as PHP, Ruby, e.t.c.

I use it a lot at work to quickly protoype stuff for mobile. It is much more convenient than writing for native Android, or iOS.

wouldnt you mind to tell how your environment for doing that is set up?

I was also thinking recently that it could be possibly good for prototyping, but had no experience in any www-related development

Are you firing that just as a webpage in your browser?, how do you load assets there? or maybe there is some way to doing such javascript games in a more standalone way, without using the browser? I would like to experiment maybe, also liked a javascript at first view (more then java/c# it looks more flexible and consistent)

In my line of work, I sometimes have to setup quick prototypes of apps on mobiles. Programming on IOS & Android is a pain, and you have to pay up-front with boilerplate code work. (I have to upgrade my xCode everytime a new IOS version comes out. Once I even needed to upgrade my OSX to program for a new IOS version).

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/.

Well, my experience with WebGL thus far has been pretty positive,

Haven't tried webgl in quite some time. I had severe performance problems with it on mobiles. Especially on Android. Has this gotten any better?

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...

[1] 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?

[2] Can be such assets/images read from local disk

through giving some local file path to that or this

is not possible?

[3]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 ?

1: I use WAMP server on my computer, however you canopen a HTML page containing JavaScript with your web browser with out an active server.

2: Most folks use a server side API such as PHP, Ruby, e.t.c.

3: You do not need any special libraries for game creation. Many good 2D games have been created with pure JavaScript.

You can get good frame rate with Super Nintendo / Sega Genesis style games, and as far as pixel drawing goes, I haven't messed with that. I'd amuse you can easily make Atari or Commodore style games that way.

Is it possible to test smal games without setting up
a server ?

Yes, but at some point you get missing permissions running from a local file.

Then you either have to reduce browser security, or raise a simple server.

For games, I'm not sure if you'd hit that barrier.

Also, if you want to run on mobiles, setting up a server on your PC. IS much simpler then embedding HTML pages on your device. I'm talking about a simple file server. No need for PHP or SQL or JAVA.

But you can definitely start running on a PC without a server, and upgrade as you move along

TNX for answers. -
Would it be possible to rotate sprite image from under such javascript browser environment (I mean get image.png from local disk or remote server, rotate it right by 5 degree, put the result to the screen at 100,100) ? What is base api in such javascrip environment, what graphics operation one can do with that, where is reference to that api ? - can sounds be played ? can savegame files be stored ? (sorry for lame questions but that would be tha last I think)

Two Options:

1. You can either take a regular image html tag, and add a CSS style for rotation.

2. You can either take a regular image html tag, paste it in a canvas.

The canvas interface is very rich, and similar to other programming languages.

CSS is a bit like bending over backwards when games are concerned, but it has much better performance on mobiles.

If you are working on a desktop, you should read all about canvas.

Would it be possible to rotate sprite image from under such javascript browser environment (I mean get image.png from local disk or remote server, rotate it right by 5 degree, put the result to the screen at 100,100) ?

2D canvas is probably the most advanced 2D non-GPU rendering API I've ever seen, even moreso than what Allegro pre-5 had. It's freaking overkill, at that. The only real problem is how good are browsers regarding its performance.

There's also CSS transforms but that's if you decide to go with the DOM, which is quite slow. Beware.

What is base api in such javascrip environment, what graphics operation one can do with that, where is reference to that api ?

As I said, 2D canvas. There's also WebGL, which is pretty much OpenGL ES 2.0.

can sounds be played ?

Yes, although it seems browsers aren't very good at handling the Audio API properly... (the only one I've seen that handled it perfectly was Opera, and I don't know if that got trashed with the move to webkit) Both Firefox and Chrome have their own custom audio APIs too, but honestly that seems just like a way to encourage lock-in to me >_> (yes, they're also more advanced, but for most cases the standard audio API should do if browser developers bothered to care about it)

can savegame files be stored ?

Try cookies or local storage, assuming it isn't saving to the server. Or you could always just have the user write down a password, like old console games used to do =P

fir, on 17 Aug 2013 - 10:26 PM, said:

can savegame files be stored ?
Try cookies or local storage, assuming it isn't saving to the server. Or you could always just have the user write down a password, like old console games used to do =P

Some new browswers allready support client-side sqlite storage.