Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 18 Oct 2005
Offline Last Active Yesterday, 09:25 PM

Posts I've Made

In Topic: Is it possible to use Dart lang for Apach server?

Yesterday, 10:50 AM


In the release article, there is this disclaimer:

Note: I wouldn't put this on a public host for now, there are probably bugs!

Also, the last commit was 2 years ago, so I don't think it's actively maintained.

That being said, if you clone it and build it and install it for your Apache host, you can likely use Dart in Apache:


If you go the other how to access PHP code from dart client, how to implement it?

Easiest is to decide on an intermediate representation, such as XML or JSON.
Then write POST handlers in PHP, and POST to your Apache/PHP server from your Dart client.


Then a more specific question. Is it possible to Dart to send POST request to a server, and then accept the result at the same place in the script and not updating the page?



yes it is.


In Topic: Is it possible to use Dart lang for Apach server?

19 December 2014 - 07:35 PM

It sounds like the OP wants to use a Dart client with a PHP server and communicate between them, which would mean that the server really is irrelevant.

In Topic: Paradox Impressions?

19 December 2014 - 04:30 AM

Regarding the licensing discussions, my understanding is that if you want to modify the engine itself, then yeah you have to contribute those changes back to the engine, which is fair enough seeing as you're using it for free. However if you use their signed binaries, which really is the default way of working with Paradox anyway, then you have no obligation to share your code with anyone, whether your project is commercial or non-commercial.


You don't have to contribute your changes, the GPLv3 only requires you to provide the sourcecode to those who buy or receive binaries from you (in practice it is easiest to just make it available to everyone since one of your customers will eventually do that anyway but there is no such requirement), code you release under the GPLv3 may not be used in the proprietary version of the engine without your permission.


If you want them to include your fixes/improvements/changes in the official version however you will need to give them additional rights (as per their contributor agreement) and if they don't include your changes in the official version you will have to re-integrate them each time you upgrade the engine (effectively forcing you to maintain your own fork of the engine which can be quite alot of extra work)

In Topic: Implementing pathfinding... server or client?

16 December 2014 - 11:51 AM

There's a server/client RTS engine called ORTS. In one of their documents, "On the Development of a Free RTS Engine", they mention basic gameplay tasks, like pathfinding, are implemented client-side ("Low Level AI Components" section of the document linked below).


This sounds like a good idea because it offloads pathfinding (a potentially expensive task) to the client, leaving the server free to take care of other tasks. However, wouldn't this give an unfair advantage to clients with a faster CPU?


One option is to force pathfinding to take a max number of frames on all clients. But wouldn't this take away part of the advantage of using a server/client architecture (not waiting on the slowest client)?


ORTS doc: https://webdocs.cs.ualberta.ca/~furtak/pub/ORTS-GAMEON_NA_05.pdf


most RTS games use a lockstep model so it wouldn't matter (if a player falls behind the game pauses to wait for him to catch up), even if you use a client server architecture you probably want to use lockstep for RTS games to allow for massive armies (the amount of bandwidth required can grow quite rapidly otherwise)

In Topic: Is Java a good Language for Games?

15 December 2014 - 05:39 AM

        I am quite experienced with Java, i made several bukkit plugins and a few complex programs. I already have almost 2 years with Java as my main programming language. From my point of view i am quite ready to start game development. So here is my question. Is Java a good programming language for game development?

         I already read a lot of articles that there is no "special language for game programming" and that you should use the one your more comfortable with. But In my expirience making programs with java and deploying them was quite awful, i had to create a launcher with launcher4j and this wasnt working always also there were some permance issues(maybe my fault) but Java doesnt and compatibilities with the JRE.

        I tried C# with XNA Framework and it was quite intresting because of my experience with java and Java and C# similarities it was quite easy for me. So I should stick with Java with Slick2d to make a 2D game or I should use C# with XNA? Although i dont know hows XNA deployment.

Thank you


Here are some useful tips for Java performance: 


1) Avoid dropping references inside your game loop and try to allocate outside it when possible, re-use objects from a pool instead of reallocating inside your game loop. (The garbage collector is a huge source of Java performance issues, you want to keep it from running inside your game loop and the only way to do that is to not generate any garbage), if you generate garbage while the app is loading you can attempt to force the gc to run before entering the main loop by abusing weak references, sleep, and the system.gc() method (The spec doesn't guarantee that it will work but in practice it works on most JVMs, just make sure you limit the number of attempts made)


2) Strings are immutable, a new string will be created and the old one garbage collected if you modify a string, use stringbuffers if the text has to change inside your game loop and stringbuilder to assemble longer strings.


3) Always reserve space in your containers when you create them (this avoids expensive allocations/re-allocations when you fill them with data), use the right container for the job (Lists have horrible cache performance and are almost always the wrong choice)


4) trig operations in Java require a precision that x86 cpus fails to match outside the -pi/4 - pi/4 range, Java will do a very accurate and fairly expensive argument reduction for values outside that range on x86, the further you stray from the accurate range the slower those calls become so it helps to keep angles within the -PI - PI range (instead of the 0 - 2*PI range or -infinity - infinity range)


5) Native calls are quite expensive in Java, if you have to use native functionality you should write or use a fairly high level native library rather than wrapping low level native functions directly.


6) Don't use dynamic dispatch if you don't need it, even though it is cheaper than in native languages it usually isn't free.