Has anyone thought of - or even attempted - porting Allegro to html5/javascript? It would be difficult or impossible to achieve a 100% port, but I'm sure it's possible to achieve a fairly high success rate. Porting of games would require some workarounds and sacrifices along the way.

A couple of options come to mind:

• Create a javascript library.
  Allegro games would then need to be ported to javascript.

• Use GWT 2.2 or greater.
  The Allegro library would be ported to the subset of Java supported by GWT. Games would then also be ported to Java.

Discuss.

A while ago I'd say that javascript wasn't advanced enough for that, but, ever since I saw a port of Quake II to HTML 5, I'm not so sure anymore.

I'm voting HTML5, just because Java is such a pain to set up properly as a web applet and relies on third party user-installed plugins, while HTML5 does not.

You need a decent browser of course. Anything but IE should do.

You may have misunderstood the GWT option. GWT compiles a subset of Java to JavaScript. So the result of both options is HTML5 + JavaScript. The are many advantages to this approach, such as using a stricter language than JavaScript (less opportunity to shoot yourself in the foot) and the ability to leverage existing Java development tools such as NetBeans. However, the relative complexity of setting up an environment and project may scare some hobby coders.

EDIT: Beaten

EDIT:

You don't have to have a server side. GWT makes it fairly easy if you want to.

You're as mad as picollo.

Does a port mean that I can actually code in C(with some limits), and get the game running on JS/HTML5?

Then it's reinventing the wheel to some degree..
Thanks for explanation.

^ This. You can't really port Allegro because you have no low-level access. You have to use the calls available in JavaScript, and attempting to reproduce the Allegro API in JavaScript and HTML5 is probably going to produce something that is incomplete and suboptimal. A better option is to write a completely different library based on JavaScript and the HTML5 API's available. Designing the API based on what is available will give you something much more useful. JavaScript is much higher-level than C and supports a number of very useful features that should be put to use.

I'm pretty sure (read: hoping) that Dennis was just being funny to point out how stupid this is. No offense to the OP.

This is pretty much what I meant. Port was probably a poor choice of word. Essentially, the idea is to assist the porting of existing Allegro games to HTML5/JavaScript by providing an abstraction layer resembling Allegro as much as possible.

The notion that HTML5 is a fad that will soon pass is beyond ridiculous. It is simply the next iteration of the HTML standard. It just so happens that it provides an excellent opportunity to easily distribute games using open standards and no browser plugins. The standard may be in its infancy, but there are already some excellent examples.

Please explain why you believe that "resembling Allegro as much as possible" is a good thing for a JavaScript library based on HTML5. Personally, I think that the smart thing would be to study the existing HTML5 API and design a library off of that instead of trying to mimic Allegro. To assume that Allegro's API is the one true API is just silly, IMHO... Allegro was designed with dependency and language limitations kept in mind. Limitations that might not apply to JavaScript and HTML5. Why reinvent the square wheel?

I had a similar idea, but it ultimately boiled down to "create a game framework for Javascript". At which point I only flirted with the idea, creating a canvas/object/timing structure.

I also support the idea. To be honest, I'm surprised I haven't run into a html5 "game" library yet.

Relax man, relax. There is absolutely no need to get personally insulting in response to not getting an elaborate joke (with a grain or two of truth in it) and failing to see how it is a constructive contribution to the discussion (and that's what I assumed you wanted to start when you wrote "Discuss." in your OP).

Besides, I am not the one who said anything was stupid nor was I trying to point it out to be just that.

I am mocking the whole "write once, run anywhere" myth, making fun of the fact how the common solution to portability problems always seems to be to shift the problem to another layer (new VM).

With HTML5/JS and all the "run everything inside the browser" fad, the browser becomes just that, another VM (with a quite underdeveloped standard language for programming it (JS/HTML5) and sluggish performance due to all the extra layers and awesome "new" features like "local storage" wow... now we're allowed to write and read files for use by our programmes!!! omg wtf, what's next?! frozen pizza?! Sorry, I was taken away for a moment.

What's ridiculous is how it's already going into the other direction already again with technologies like Silverlight for example, marketing "can run standalone outside of browser" as an awesome new feature.

Surely, a game programming library for JS/HTML5 would be nice and useful, but for me, a huge piece of the Allegro spirit was always it's high portability. So to make that right once and for all time, an own language and an own portable VM (and eventually own chips) would be the only logical way to go.

This would ensure that existing (written in Allegro GDL then) Allegro games could be more easily ported to new platforms, long after JS/HTML5 are old/gray/outdated and obsolete, because you'd just port the VM to the new platform and get each game port for free.

I could not agree more (I should see go see a doctor. Doctor: "What's the problem?" Me: "I agreed with bamccaig." Doctor: "wtf?").

And another question is, if HTML5 is not already high level and straightforward enough to just use it directly without another layer on top of it?

If I were to port one of my existing games/apps(using Allegro) to the browser, I'd probably rather do a rewrite and use everything available on the browser platform than trying to force the old structure into the new one.

It would be like porting a C64 basic programme to C but refusing to accept the existence of functions and return values and keep using gotos and using a global variable to store the jump back label to mimic gosubs (I have actually seen someone write Pascal code like that... it works of course and shows the programmer knows something about how computers work on a low level but it wasn't the best way to use the new technology available to him).

Couldn't help it. It was a setup and, in the tradition of a.cc, I had to fix it. No personal insult intended.

Not at all. GWT at its heart is a Java to JavaScript compiler, producing cross-browser JavaScript. It is a bit more than that, though. Take a look for yourself. It has been around for a while and is considered reasonably mature now. The latest version introduces HTML5 canvas, audio and video support.