Java-Gaming.org Hi !
Featured games (83)
games approved by the League of Dukes
Games in Showcase (539)
Games in Android Showcase (132)
games submitted by our members
Games in WIP (603)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: 1 2 3 [4] 5 6
  ignore  |  Print  
  JavaScript is a scam  (Read 14012 times)
0 Members and 1 Guest are viewing this topic.
Online princec

« JGO Spiffy Duke »


Medals: 434
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #90 - Posted 2011-11-07 10:54:24 »

I think OrangyTang hit the nail on the head there. The uncanny valley of languages. It's part of the reason I hate going back to C++ so much these days.

Cas Smiley

Offline Orangy Tang

JGO Kernel


Medals: 56
Projects: 11


Monkey for a head


« Reply #91 - Posted 2011-11-07 11:20:03 »

When you write to much javascript code, then you might have to overthink your idea or change the behavior. When i look back at some old javascript code i feel really awkward about is. Because today i know ways to make it smaller, faster and neater and without any use of inheritance needed.

I think you've missed my point - Cas has summed it up nicely, it's an uncanny valley where I'm (and I suspect others) are seeing two different languages at once.

When I write Ruby code, half my brain is thinking "ah, functional language. Write functional code" and the other half is thinking "ah, functional syntax. Write functional code". All is well.

When I'm writing JS code, half my brain is "ah, functional language, Write functional code", whereas the other half is "I know this syntax! Curly brackets! Write OO code with inheritance! Where's my static typing? Why does my code look like shit? WHERE'S MY INHERITANCE? RAGE!". The C/C++/Java side having much more brain-hours wins every time.

I'll let you guess which one is more fun to program in. Wink

[ TriangularPixels.com - Play Growth Spurt, Rescue Squad and Snowman Village ] [ Rebirth - game resource library ]
Offline Evil-Devil

Senior Devvie


Medals: 2


Fir Tree Master


« Reply #92 - Posted 2011-11-07 11:34:14 »

Yea, thats true, a point i missed out. Syntax tends to mislead on the path...

Though fun is neither language. For example I really miss closures in Java.

Maybe its easier for me as i have to write php applications at work and as all know, php does not have real inheritance. And the code get bloated all the way when start using it.
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Roquen
« Reply #93 - Posted 2011-11-08 13:11:55 »

In general see two main complaints against JS.  The first is that people insist on thinking in terms of an OO abstraction model, when it isn't.  And the second is that they fail to recognize that JS is designed to be a "scripting" language and not a general purpose one.  (NOTE: Yeah I know prototype based is a special case of OO, but that just confuses too many people).

Totally agree.  From a pure expressiveness standpoint, prototype based are significantly more powerful then OO.  They were developed because the strict class hierarchies of OO is a big ugly chain on design.

Have you ever tried developing a real application without OO?
Yes.  Very many and they all worked out just fine.

Quote
It gets ugly, quickly. As your codebase grows it becomes harder and harder to maintain. OO is a necessity, but it doesn't exclude other options.
There are two major reasons for unmanageable codebases.  The first is wrong choice of major paradigm and the second is bad design.  Of these two "bad design" is by far the bigger of the two problems.  If one doesn't understand the given language(s) one is writting in, then the design will invetitably be "bad".  WRT: "OO is a necessity".  Not at all.  It is not well suited to a wide range of problems.  There is no one paradigm that address all problems.  IMHO multi-paradigm languages haven't been a big success at large projects.  This is not to say that languages like Ocaml are not useful...just pretty much everyone ignore the OO functionality.  And if meta languages were the solution then we would have stopped at LISP variants.  It's quite rare for any large project for me to be happy with a single paradigm, static vs. dynamic typing, etc.  This is why I'd love to have a good multi-paradigm high level IR with good inter language-OP support.  Choose the best tool to attack the given sub-task.

Quote
Hahahaha. JavaScript doesn't even begin to address the needs of modern software developers. Concurrency anyone?
SEE: Is a scripting language.  I certainly wouldn't open up access to raw concurrency related functionality in any wide target audience scripting language that I'd design.  With the exception of coop-task switching hints in an actor like framework.  If the embedded app wants to provide this kind of functionality...it can.

Quote
What a joke. JavaScript won't ever be anything more than scripting for clueless developers who don't know any better simply because it doesn't solve any problem that needs solving.
Well I'm far from clueless and I think that if one was creating a user-extendible single player game engine, then it would be difficult to beat embedding V8 in a native application.

Quote
I am working on a language that supports actors natively because of that.
Unless it's a learning exercise I'd suggest not bothering.  If you want actors in Java, just use kilim.

Quote
Actors as an external library exist even in Java, it is not as good as having the language itself do it for you (like in Erlang or my own language).
If the author of kilim (as well as some external people) are to be believed, then kilim outperforms Erlang.

Quote
No, it isn't. It doesn't support inheritance without horrible hacks.
SEE: Is not an OO language.  (OK, OK..class-based OO)

Quote
Prototypes only allow you to create structures for objects, and that's it.
This is a true statement about the both abstraction models of both OO and prototype based.  The only difference is where the data is stored.

Quote
Not even close to OO. Java is quite limited in the OO department and it can do a lot more than JS could ever dream of.
I find the "this is more OO than that" argument silly.  But it's hard to argue that there is a more "OO" language than SmallTalk.  JS is closer to SmallTalk than Java is.

Quote
I felt kinda scammed when Sun dropped Self and switched to such a traditional language.
Maybe that's what the author of JS was intending to say with the choice of names.

Quote
I ramble and digress, but is there really a topic to derail?
Not really.
Offline longino

Junior Devvie


Medals: 1



« Reply #94 - Posted 2011-11-08 14:55:16 »

When I'm writing JS code, half my brain is "ah, functional language, Write functional code", whereas the other half is "I know this syntax! Curly brackets! Write OO code with inheritance! Where's my static typing? Why does my code look like shit? WHERE'S MY INHERITANCE? RAGE!". The C/C++/Java side having much more brain-hours wins every time.

Functional programming and OO aren't mutually exclusive.

The problem is what some Java people mean by "functional programming" are ugly hacks involving stuffing functions inside of objects at runtime.

Functional programming != stuffing functions inside of objects.

Functional programming has to do with programming without side-effects, as in mathematics. Mathematical functions don't change state. JavaScript is not even functional by definition.

This whole thing looks like a cheap Java clone built by Perl developers. Where they ditched all the stuff that makes Java good in order to make it more "Perl-like".
Offline longino

Junior Devvie


Medals: 1



« Reply #95 - Posted 2011-11-08 15:09:44 »

Quote
It gets ugly, quickly. As your codebase grows it becomes harder and harder to maintain. OO is a necessity, but it doesn't exclude other options.
Not at all.  It is not well suited to a wide range of problems...

I would suggest you to reread my comment. Who said OO alone is the solution?

Choose the best tool to attack the given sub-task.

Yes, and that's why Javascript is unsuitable for any serious development.

Well I'm far from clueless and I think that if one was creating a user-extendible single player game engine, then it would be difficult to beat embedding V8 in a native application.

Off the top of my head I can think of many options that would beat that.

Unless it's a learning exercise I'd suggest not bothering.  If you want actors in Java, just use kilim.

I don't want it "in Java". I want a programming language where I can express what I need without having to go through pain like Javascript.

Java is cool as it is. But another language would be better to complement it in areas where it lacks.

If the author of kilim (as well as some external people) are to be believed, then kilim outperforms Erlang.

And that proves... what?

Actually, Erlang is pretty good and having actors as part of a language is just as handy as having multithreading, like Java does.

It just makes more sense.
Offline vyh

Senior Newbie





« Reply #96 - Posted 2011-11-08 15:23:53 »

EcmaScript/JavaScript harmory get's class-oop - http://wiki.ecmascript.org/doku.php?id=harmony:classes
Offline JL235

JGO Coder


Medals: 10



« Reply #97 - Posted 2011-11-08 17:03:51 »

Functional programming has to do with programming without side-effects, as in mathematics. Mathematical functions don't change state. JavaScript is not even functional by definition.
It's pretty easy to write large JS code bases where most of the functions are free of side effects. I have tonnes of re-entrant functions in my projects for handling logic.

You also need some side-effects, or nothing would appear on the screen.

The one thing I really disagree here is the idea that JavaScript can only be used for little scripts, and can't be used for building anything more advanced then that; yes it can! Google Docs is a pretty trivial example of this.

There are issues with writing JS projects, mainly around having no standardized way of modularizing your project, or building it across multiple files (there are strategies you can use, but no built in 'package' or 'import' which handles it all for you like in Java). But there are also huge gains, such as having the easiest distribution model of any runtime (as most people do run a modern browser, and it's much easier to write cross platform JS then cross platform Java).

Online princec

« JGO Spiffy Duke »


Medals: 434
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #98 - Posted 2011-11-08 17:34:46 »

Hmm, Google docs eh?

The same bugridden, inconsistent, slow, inferior, monstrous bit of code I've been using? And even if it is bugridden, inconsistent, slow, inferior and monstrous I wouldn't call it trivial. And let's not forget it lives inside the DOM and rendering engine of an incredible bit of technology itself, the browser.

Cas Smiley

Offline JL235

JGO Coder


Medals: 10



« Reply #99 - Posted 2011-11-08 17:53:43 »

The same bugridden, inconsistent, slow, inferior, monstrous bit of code I've been using? And even if it is bugridden, inconsistent, slow, inferior and monstrous I wouldn't call it trivial. And let's not forget it lives inside the DOM and rendering engine of an incredible bit of technology itself, the browser.
There was a time when Java was considered slow and inferior, same was also true with JavaFX. The fact that you have an advanced rendering system at your disposal is part of my point; JS + HTML5 + CSS allows you to build quite a lot!

Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Online princec

« JGO Spiffy Duke »


Medals: 434
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #100 - Posted 2011-11-08 18:34:44 »

I don't doubt it's quite fast and going to get 5x faster over the next decade. It's just that I don't want to write any damned code using it!! I've got a really nice simple language that does everything I need already. And when it doesn't I've got another language already too.

Cas Smiley

Offline Roquen
« Reply #101 - Posted 2011-11-09 15:02:16 »

Quote
It gets ugly, quickly. As your codebase grows it becomes harder and harder to maintain. OO is a necessity, but it doesn't exclude other options.
I would suggest you to reread my comment. Who said OO alone is the solution?
I cannot find any interpretation of your comments that I would agree with.  My main issue here is that too many OO only programmers (or with little experience in alternate abstractions) think they don't need any extra tools in their toolbox as it is, even when they're attempting to jump through convoluted hoops to get something implemented.

Quote
Quote
Well I'm far from clueless and I think that if one was creating a user-extendible single player game engine, then it would be difficult to beat embedding V8 in a native application.
Off the top of my head I can think of many options that would beat that.
Well, would you care to name of few?  And I don't mean this in an argumentative tone...I'm truly curious.  I cannot think of more than a handful of potentially viable options that I would consider acceptable.

Quote
Quote
Unless it's a learning exercise I'd suggest not bothering.  If you want actors in Java, just use kilim.
I don't want it "in Java". I want a programming language where I can express what I need without having to go through pain like Javascript.
Not wanting it in Java.  Fine.  But where's "the pain like Javascript" part coming from?  I fail to see how extending a provided base class to get actor support coupled with marking root methods with @pausable is much of a burden or some kind of syntax pollution.

Quote
Quote
If the author of kilim (as well as some external people) are to be believed, then kilim outperforms Erlang.
And that proves... what?

Actually, Erlang is pretty good and having actors as part of a language is just as handy as having multithreading, like Java does.

It just makes more sense.
Well it "proves" nothing.  But it indicates that if you know java and want an actor framework, then you don't necessarily need to run out and learn or create a new language.  My point was that I don't find your statement: "it is not as good as having the language itself do it for you (like in Erlang or my own language)" to be generally true.

Erlang is a very cool language that virtually nobody should go bother to learn.   Is your next project code that runs on a bank of servers that requires 100% uptime?  Fine, check-out Erlang.  Otherwise it would appear pretty far down my list of language one should get a working knowledge of.

WRT: Actors.  They are not black-magic that solve any real modern concurrency problems other than a simple model for the programmer.  (which, of course, I'm not spitting on)

Quote
Functional programming has to do with programming without side-effects
I'd agree that simply having first class functions != functional programming.  On the other hand I don't only consider "purely functional" languages to be the only ones that qualify.  (This is sorta like the OO vs OO argument)

Quote
There was a time when Java was considered slow and inferior...
Today expect slight showers with unseasonably warm weather....

Offline sproingie

JGO Kernel


Medals: 202



« Reply #102 - Posted 2011-11-09 16:29:08 »

Pretty sure longino likes being angry more than being informed or correct, so good luck with the argument.

If you're looking for actors in java, look no further than Akka.  Won't get the "built in to the language" feeling (i.e. an infix operator for message send) until you use it in scala, but you still get the actor model, remote nodes and supervisors and all.  Also has Software Transactional Memory, which is really yummy for some concurrency problems.

Offline longino

Junior Devvie


Medals: 1



« Reply #103 - Posted 2011-11-09 19:07:26 »

Pretty sure longino likes being angry more than being informed or correct, so good luck with the argument.

If you're looking for actors in java, look no further than Akka.  Won't get the "built in to the language" feeling (i.e. an infix operator for message send) until you use it in scala, but you still get the actor model, remote nodes and supervisors and all.  Also has Software Transactional Memory, which is really yummy for some concurrency problems.

Seems more like a convoluted mess to me. Transactional memory is not a good solution. It is just a sign that so-called "scientists" are running out of ideas.
Offline longino

Junior Devvie


Medals: 1



« Reply #104 - Posted 2011-11-09 19:16:18 »

Quote
It gets ugly, quickly. As your codebase grows it becomes harder and harder to maintain. OO is a necessity, but it doesn't exclude other options.
I would suggest you to reread my comment. Who said OO alone is the solution?
I cannot find any interpretation of your comments that I would agree with.  My main issue here is that too many OO only programmers (or with little experience in alternate abstractions) think they don't need any extra tools in their toolbox as it is, even when they're attempting to jump through convoluted hoops to get something implemented.

And where I say something else is not needed?

Not wanting it in Java.  Fine.  But where's "the pain like Javascript" part coming from?  I fail to see how extending a provided base class to get actor support coupled with marking root methods with @pausable is much of a burden or some kind of syntax pollution.

Actors have properties that imperative languages (including Javascript) can't provide, such as encapsulation between actors. In Java (or Javascript) it would always be possible to change the state of an object. But you could always implement a Runnable and call it an Actor, I guess.

There are differences between a language like Erlang and a "framework" that looks more like a bandaid for an hemorrhage.

Concurrency is a necessisity at a language level.

Erlang is a very cool language that virtually nobody should go bother to learn.   Is your next project code that runs on a bank of servers that requires 100% uptime?  Fine, check-out Erlang.  Otherwise it would appear pretty far down my list of language one should get a working knowledge of.

That explains a lot about your opinions on Javascript.

I'd agree that simply having first class functions != functional programming.  On the other hand I don't only consider "purely functional" languages to be the only ones that qualify.  (This is sorta like the OO vs OO argument)

That is not important. I am just pointing out that "dynamic languages" fans aren't really programming in a different way. They are programming imperatively, stuffing functions inside of objects.

Just like they would do in Java, but stupider.
Online princec

« JGO Spiffy Duke »


Medals: 434
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #105 - Posted 2011-11-09 20:02:12 »

Rant now descending into farce Smiley Time to stop!

Cas Smiley

Offline JL235

JGO Coder


Medals: 10



« Reply #106 - Posted 2011-11-09 20:47:39 »

Not wanting it in Java.  Fine.  But where's "the pain like Javascript" part coming from?  I fail to see how extending a provided base class to get actor support coupled with marking root methods with @pausable is much of a burden or some kind of syntax pollution.

Actors have properties that imperative languages (including Javascript) can't provide, such as encapsulation between actors.
Comments like this show how little you really know about concurrency in JavaScript, because your just flat wrong. In JavaScript objects cannot be shared between threads. All communication is performed using messages, which are copied when sent, and this cannot be circumvented. It's just like Erlang.

One thing I do hate about JavaScript is the name. It's much better name then the original name, 'LiveScript', but lots of people presume it's related to Java, when it's not.

Offline pjt33
« Reply #107 - Posted 2011-11-09 22:34:10 »

Rant now descending into farce Smiley Time to stop!
It was an obvious troll from the get-go. The only reason I'm reading it now is curiosity to see how it kept going so long.
Online princec

« JGO Spiffy Duke »


Medals: 434
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #108 - Posted 2011-11-09 22:59:23 »

Troll it might be but many people share the sentiment Smiley But now it's descending into people arguing about each other's abilities/knowledge etc which is only going to turn nasty. Moderator!

Cas Smiley

Offline Eli Delventhal

JGO Kernel


Medals: 42
Projects: 11
Exp: 10 years


Game Engineer


« Reply #109 - Posted 2011-11-09 23:41:58 »

My entire company now develops only in Javascript, both for client and server code. There are some issues with it, sure, but everything you're saying is ignorant. We use node.js for everything, which makes inheritance, class file importing, etc. possible with very little fuss. Also, servers running on top of node and with mongo are faster than Rails, Java, etc. servers. It's the absolute best option for games due to JS being so good at event-driven code.

We're making some very high quality mobile titles with it.

See my work:
OTC Software
Offline sproingie

JGO Kernel


Medals: 202



« Reply #110 - Posted 2011-11-10 02:11:03 »

It is just a sign that so-called "scientists" are running out of ideas.

Whereas your endless pissing and moaning and griping really advances the state of the art, doesn't it?  Geez, you can't even put the effort into trolling well.
Offline Riven
« League of Dukes »

« JGO Overlord »


Medals: 840
Projects: 4
Exp: 16 years


Hand over your head.


« Reply #111 - Posted 2011-11-10 02:18:52 »

Moderator!
You, sir, are a moderator Smiley You might want to review that ancient PM about it.

Hi, appreciate more people! Σ ♥ = ¾
Learn how to award medals... and work your way up the social
Offline Evil-Devil

Senior Devvie


Medals: 2


Fir Tree Master


« Reply #112 - Posted 2011-11-10 09:32:41 »

In Java (or Javascript) it would always be possible to change the state of an object.
As from my understanding it is possible to create an immutable Object in Javascript. So you can't modify any inner states without using accessors.
Offline appel

JGO Wizard


Medals: 68
Projects: 4


I always win!


« Reply #113 - Posted 2011-11-10 09:56:31 »

Adobe dumping flash for "devices", will focus on HTML5.

Adobe's Flash Surrender Proves Steve Jobs And Apple Were Right All Along With HTML5
http://www.forbes.com/sites/greatspeculations/2011/11/09/adobes-flash-surrender-proves-steve-jobs-and-apple-were-right-all-along-with-html5/

You know what that means. HTML5 = JavaScript.


Really, you guys should get a wider perspective than just "doesn't compile".  Roll Eyes

Check out the 4K competition @ www.java4k.com
Check out GAMADU (my own site) @ http://gamadu.com/
Offline kappa
« League of Dukes »

JGO Kernel


Medals: 81
Projects: 15


★★★★★


« Reply #114 - Posted 2011-11-10 10:12:53 »

Adobe dumping flash for "devices", will focus on HTML5.

Adobe's Flash Surrender Proves Steve Jobs And Apple Were Right All Along With HTML5
http://www.forbes.com/sites/greatspeculations/2011/11/09/adobes-flash-surrender-proves-steve-jobs-and-apple-were-right-all-along-with-html5/
Also Microsoft is Killing Silverlight too. They're also putting their weight behind HTML5 (e.g. as seen with Metro).
Offline appel

JGO Wizard


Medals: 68
Projects: 4


I always win!


« Reply #115 - Posted 2011-11-10 11:28:09 »

Adobe dumping flash for "devices", will focus on HTML5.

Adobe's Flash Surrender Proves Steve Jobs And Apple Were Right All Along With HTML5
http://www.forbes.com/sites/greatspeculations/2011/11/09/adobes-flash-surrender-proves-steve-jobs-and-apple-were-right-all-along-with-html5/
Also Microsoft is Killing Silverlight too. They're also putting their weight behind HTML5 (e.g. as seen with Metro).

HTML5 is huge. It's sad some people don't realize how big it is. I've been web developing since 1995, and been fighting limitations of the browser, trying to push the limits. Seeing what HTML5 offers is just mind-blowing, the limitations of what you can do on a web page are almost gone. In combination with CSS3, JavaScript...web pages become a very powerful view form for a lot of things. Canvas provides you with that extra you'd otherwise need Java/Flash for.

In a few years, 3-5, nobody will ever consider using Java/Flash for anything on a web page. What you need proprietary technologies for today will be standardized via HTMLx.

HTML5 is only one stepping stone towards this. HTML6 will come as well, and the evolution will continue. The trends are clear, both for HTML and Java (web embed), HTML is evolving at a faster pace than ever before, while Java seems to be pretty much stagnant, for a long long time. The attempted JavaFX is only a proof of that, they cannot fix it, or maybe don't care, and browser makers don't care much for Applet support (Firefox removing Applet support? http://www.java-gaming.org/topics/mozilla-planning-to-kill-java-applets/24849/view.html).

Seriously... people should stop hating and start loving JavaScript, because it will play such a big role in this trend. Not knowing JavaScript in a few years will be equivalent to "not able to make web pages", and let's face it, most of what programmers do nowadays is web page related.

Check out the 4K competition @ www.java4k.com
Check out GAMADU (my own site) @ http://gamadu.com/
Online princec

« JGO Spiffy Duke »


Medals: 434
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #116 - Posted 2011-11-10 11:30:44 »

I think I will ultimately love it, myself. As soon as Eclipse development becomes as awesome for Javascript as it is for Java. And when it gets a few more bells and whistles for performance like the equivalent of Unsafe, direct bytebuffers, synchronized & concurrency stuff built in, etc. Can't be that long. I'm going to stay the hell away from HTML5 though. That's for the designers and luvvies of this world, not robots like me.

Cas Smiley

Offline Evil-Devil

Senior Devvie


Medals: 2


Fir Tree Master


« Reply #117 - Posted 2011-11-10 11:52:12 »

CSS3....when it is fully supported in IE11+ the web could look much better.
HTML6? I thought HTML5 will be the last draft and anything after will just be seen as an addon to html5. Is that idea allready dumped?
Offline appel

JGO Wizard


Medals: 68
Projects: 4


I always win!


« Reply #118 - Posted 2011-11-10 12:59:25 »

CSS3....when it is fully supported in IE11+ the web could look much better.
HTML6? I thought HTML5 will be the last draft and anything after will just be seen as an addon to html5. Is that idea allready dumped?
Well, eventually they'll make HTML6 Smiley The web will evolve, beyond HTML5.

Check out the 4K competition @ www.java4k.com
Check out GAMADU (my own site) @ http://gamadu.com/
Offline loom_weaver

JGO Coder


Medals: 17



« Reply #119 - Posted 2011-11-10 14:03:55 »

appel,

Does HTML 5 support Open GL?  Does it allow full handling of both left and right mouse button events?
Pages: 1 2 3 [4] 5 6
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

rwatson462 (30 views)
2014-12-15 09:26:44

Mr.CodeIt (23 views)
2014-12-14 19:50:38

BurntPizza (50 views)
2014-12-09 22:41:13

BurntPizza (84 views)
2014-12-08 04:46:31

JscottyBieshaar (45 views)
2014-12-05 12:39:02

SHC (59 views)
2014-12-03 16:27:13

CopyableCougar4 (57 views)
2014-11-29 21:32:03

toopeicgaming1999 (123 views)
2014-11-26 15:22:04

toopeicgaming1999 (114 views)
2014-11-26 15:20:36

toopeicgaming1999 (32 views)
2014-11-26 15:20:08
Resources for WIP games
by kpars
2014-12-18 10:26:14

Understanding relations between setOrigin, setScale and setPosition in libGdx
by mbabuskov
2014-10-09 22:35:00

Definite guide to supporting multiple device resolutions on Android (2014)
by mbabuskov
2014-10-02 22:36:02

List of Learning Resources
by Longor1996
2014-08-16 10:40:00

List of Learning Resources
by SilverTiger
2014-08-05 19:33:27

Resources for WIP games
by CogWheelz
2014-08-01 16:20:17

Resources for WIP games
by CogWheelz
2014-08-01 16:19:50

List of Learning Resources
by SilverTiger
2014-07-31 16:29:50
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!