Java-Gaming.org Hi !
Featured games (83)
games approved by the League of Dukes
Games in Showcase (521)
Games in Android Showcase (127)
games submitted by our members
Games in WIP (589)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  faster way to do that  (Read 5434 times)
0 Members and 1 Guest are viewing this topic.
Offline Ruflinger14

Junior Newbie




Java games rock!


« Posted 2002-12-23 08:24:21 »

in advance:sorry for my bad english! Grin
what i have:
a canvas(800*500)
and two thread which do a lot of painting on this one canvas!
the one is leeping 50ms!
the faster 20ms!
both do their their own paiting!
it's flickering like mad you can imagine!
so what can i do to "get that flickering out of my canvas"?
Offline princec

« JGO Spiffy Duke »


Medals: 421
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #1 - Posted 2002-12-23 10:33:07 »

Double buffer it!
Only paint with one thread!
Sorted!

Cas Smiley

Offline Ruflinger14

Junior Newbie




Java games rock!


« Reply #2 - Posted 2002-12-23 17:27:08 »

now i have done the painting in one thread and the "mathematics" in two threads!
the flickering is better now!thanks!but what is double buffering?
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline SpongeBob

Junior Devvie




Who lives in a pinnapple under the sea


« Reply #3 - Posted 2002-12-23 17:47:32 »

Double buffering will remove all flickering.  Heres the basic concept:

You create one blank image the size of your viewable area (Canvas).  You do all your drawing to this image's graphic context.  When you are ready, draw this giant image onto your viewable area.

This prevents alot of blits being done in the viewing area which is causing flicker.

Creating a double buffer is pretty easy.  Here's an example:

           db = createImage(width, height);
           dbg = db.getGraphics();

The first line creates a blank image of some known height and width.  In your case those values come from the size of the canvas you are using.  The second line gets the graphical context for that image.  This context allows you to manipulate that image.  As such:

       dbg.setColor(new Color(79,205,251));
       dbg.fillRect(0,0,width,height);

When you are all done manipulating the background image, you can draw it to the current viewable area using its graphical context:

       g.drawImage(db,0,0,this);

Remeber to also override the update method for the component though.  It should look like this:

public void update(Graphics g)
{
    paint(g);
}

This prevents the image from being destroyed if the component is repainted (if I remember right).

Last note:  avoid using threads.  Threads suck the life out of a Java games speed.  If you can, try to do everything within the main thread.
Offline EgonOlsen
« Reply #4 - Posted 2002-12-23 18:05:46 »

Quote
Last note:  avoid using threads.  Threads suck the life out of a Java games speed.  If you can, try to do everything within the main thread.
I disagree with that. Threads are very handy and not that bad if used right. This applet http://hannover.stadtmagazine.de/games/numbers uses up to 5 threads (if the server is not down, which happens quite often) (max of 3 at a time) and runs quite good.
Edit: Fixed the BS numbers i had in here before... Wink

Offline Ruflinger14

Junior Newbie




Java games rock!


« Reply #5 - Posted 2002-12-23 18:40:11 »

yeah!i've done it with dublebouffering!very cool!thank u 4 help!
Offline SpongeBob

Junior Devvie




Who lives in a pinnapple under the sea


« Reply #6 - Posted 2002-12-24 01:36:39 »

I disagree with that. Threads are very handy and not that bad if used right.

C/C++ programmers have wrote games for years without threading.  They still do till this day.  Why does someone really need them in a Java game?

Seriously, Threads have issues:

1)  Speed loss.  I wrote a stupid fish aquarium program one time in Java.  Gave each fish its own thread.  It worked but was not very quick.  I removed all the threads and just ran in a loop on the main thread: big increase in speed.  After some testing I found that with each new thread there is a slight loss in the total CPU processing speed due to the JVM having to handle each thread seperately.

2)  Synchonization.  This can cause unexpected bugs in an ill prepared program.  It also effects speed if you write your methods synchronized.

3) Oddities between JVM's and OS's using threads.


This applet http://hannover.stadtmagazine.de/games/numbers uses up to 7 threads (if the server is not down, which happens quite often) at a time and runs quite good.


I was not very impressed by this demo.  IMOH it ran rather slow for what it is doing.  From my understanding its using a pure Java 3D api.  Though a pure Java 3D approach (outside Sun's Java3d) is interesting its also rather lame at the same time in that it lacks hardware acceleration.  Try using an OpenGL port (like GL4Java), Sun's Java3D,  or even Direct3d (Wildtangent) to get some real power.  The alien will really boogy then.
Offline SpongeBob

Junior Devvie




Who lives in a pinnapple under the sea


« Reply #7 - Posted 2002-12-24 02:52:14 »

C/C++ programmers have wrote games

"Have written"  (Smacks head)

Save me Patrick!
Offline EgonOlsen
« Reply #8 - Posted 2002-12-24 05:50:36 »

You don't really need threads, but they have their benefits (that's why somebody invented them... Grin ). The key sentence in my post was "if used right"...putting every fish in a single thread doesn't seem to be a great idea then. But that doesn't mean that threads are a bad idea in generell.
What else do you want to do to make the AI calculate its move and still render the scene??
Anyway, everyone may do it i a way he/she likes the most. The same is true for the decision software/hardware. You say the applet is quite slow for what it's doing and i say it's quite fast for what it's doing, because it does render the board and the MD2-alien with texture mapping and lighting and bumpmapping all in software and in a 100KB applet. It runs without any hassle under everything that support Java 1.1 or higher. At least it is there and it works and it is "fast enough". That can't be said about most of these virtual Java 3D games.
Anyway, this discussion is as old as mankind, so....merry Christmas!  Cheesy

Offline princec

« JGO Spiffy Duke »


Medals: 421
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #9 - Posted 2002-12-24 07:03:00 »

I'm not going to resort to a huge font again this time! So listen up and listen carefully:
[size=1]Threads were designed to interleave disk and network I/O with processing tasks, among other things. Their primary purpose is to ensure that the CPU is always doing some work if it can. What they don't do is provide you with time-sliced task sheduling, which is what you want threads for. There is no such facility in Java. If you try to use threads to simulate this, it won't work, because it's not designed to. What you need to do is actually devise a time-slicing sheduler yourself, running in a single thread, which will then behave in a consistent manner on all platforms and all configurations. Limit your use of threads to do what they are designed for: network and disk I/O.[/size].

And merry Christmas to everyone too Wink

Cas Smiley

Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline EgonOlsen
« Reply #10 - Posted 2002-12-24 10:36:35 »

First, i have to correct myself. The applet above uses 5 threads and only 3 of them are running at a time at max.. During normal gameplay, 2 threads are active.
I disagree that threads are designed for I/O only. If that would be the case, multithreading would be rather useless for number-crunching tasks. Or were you refering to Java-threads? If they were designed with I/O in mind...so be it. I don't see a reason not to use them in places where it makes sense though. And doing AI calculations while something is rendered is such a situation IMHO.
How should it work otherwise? The AI may take up to some seconds to calculate its move, depending on the speed of the machine and the depth of thought one choses. Meanwhile, the rendering should not be stopped, because that looks shitty...i had it that way before. Putting the calculations in an extra thread at low priority may increase the time it takes to calculate the move, but the game as a whole feels more responsive that way. What is so bad with that?
BTW: When the hyperthreading P4 becomes more popular, multithreading (native and in Java) will become more popular too for "normal" applications and even for games, IMO.
Anyway, this thread somehow went OT... Tongue


Offline princec

« JGO Spiffy Duke »


Medals: 421
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #11 - Posted 2002-12-24 12:14:15 »

Multithreading is indeed reasonably useless for number crunching tasks. (Java threading is neither here nor there, it works more or less like an O/S thread by and large). When does one thread finish a piece of work?
It's very difficult to disagree on the purpose of threads! They're an operating system fundamental concept, as a book on such things would go on to explain in tedious detail.

How many threads is it sensible to make? How much overhead does synchronizing multiple threads have? How does your application behave differently on uni- and multi-processor systems? Or with green threads? And so on.

A good example is SQL server, which has an option to use "Fibers". These are basically ... time slice scheduled tasks running in a single thread! You use Fibers to do intensive numerical work in SQL server instead of threads to get more even response times and increase efficiency; great for OLAP.

And by coincidence, great for games.

As a matter of interest, the terrain demo has a hidden multithreading option in it somewhere. It gets slower on single processor systems by about 5%, and gets faster on dual processor systems by about 5%. Definitely not worth the vast increase in complexity.

Cas Smiley

Offline EgonOlsen
« Reply #12 - Posted 2002-12-24 12:38:53 »

That may all be very true, but please: How do you want to complete the task above (AI calculations taking place while rendering) without using threads? You can't interrupt the renderer and you simply can't jump out of the recursion of the AI calculations just to render half the image and then return.
I'm not saying that threads should be used everywhere but if you can benefit from them...why not do so? In the task i'm describing, no synchronizing is needed and i've tested this on Mac, Linux, Windows 98/NT/2000/XP under Java 1.1, 1.2, 1.3 and 1.4 and i had not a single problem with it.
And about the number-crunching: Why are programs like 3DS using threads then???
Threads are a tool. Use them where it's appropiate. Don't "overuse" them but don't condemn them either. I remember a program i had to write for a Solaris machine back in the days at the uni...we had to use threads and we had to synchronize them. That wasn't fun at all, so i do understand what you are saying but i disagree on the absoluteness of it.
 

Offline SpongeBob

Junior Devvie




Who lives in a pinnapple under the sea


« Reply #13 - Posted 2002-12-24 13:41:29 »

May original statement about threads was a bit short on detail and may have seemed absolute.  Sorry about that.  I was not trying to be absolute about using threads.  Threads for network connections and streams is understandable since they can block (and thus lock up your game).  Also, using them in a game is understandable if you are not having speed issues.  But as a general rule, I try to avoid threads at all costs due to the performance loss if I am creating something where speed will possibly be an issue.  If speed is not an issue, using Threads can make life easier.
Offline cknoll

Junior Devvie




Flame On!


« Reply #14 - Posted 2002-12-26 01:31:17 »

I'm with Cas on this one, avoid multiple threads in game programming.   Threads are not guarunteed to run at any particular time.  Do you want that behavior for game AI?  It's possible your AI will never make a decision because the thread never gets signaled to start.  Do you want that behavior for paints?  You'll never get a predictable framerate.  Do you want that behavior for processing user input?  The user's actions may never get recieved, or recieved later than the player wants.  _Just don't do it._

'nuff said.

-Chris
Offline princec

« JGO Spiffy Duke »


Medals: 421
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #15 - Posted 2002-12-26 08:09:53 »

It's time we made that FAQ / "10 commandments" official and got it stuck up here as an article.

Cas Smiley

Offline EgonOlsen
« Reply #16 - Posted 2002-12-26 12:21:55 »

Quote
I'm with Cas on this one, avoid multiple threads in game programming.   Threads are not guarunteed to run at any particular time.  Do you want that behavior for game AI?  It's possible your AI will never make a decision because the thread never gets signaled to start.  Do you want that behavior for paints?  You'll never get a predictable framerate.  Do you want that behavior for processing user input?  The user's actions may never get recieved, or recieved later than the player wants.  _Just don't do it._

'nuff said.

-Chris
Sorry, but i really don't get it. I've explained what i'm doing and why. It works in each an every case i've tested and does EXACTLY what i want without any problems or hassle. Now you are telling me, that i shouldn't do it, because it may fail. You can be sure that i wouldn't do it, if it would fail somewhere...but it doesn't. It works perfectly on every machine/OS/VM i've tested it on. So basically you are trying to tell me that i shouldn't do it, because...i just shouldn't do it. Sorry, but that's like saying "use 4bpp only, because anything higher may fail" or "avoid using fullscreen, because it may fail (which it does quite often on my machine btw)."
Anyway, i think that  this discussion leads nowhere... Grin

Edit: None replied to my question how to do it in a different way then. On the one hand, i've a rendering engine which is basically a black-box (it's my own work, but that doesn't matter here) where i can setup my scene and then say "engine.doIt();" and some ms later i'll get a rendered image. On the other hand, i've the AI which can be a human player or a network player too (they all implement a player-interface and can be "plugged in" on demand). So please: If threads are so evil...how can i achieve what i want to in a different way? I can't think of a proper way of doing this without using threads.

Offline Matzon

JGO Knight


Medals: 19
Projects: 1


I'm gonna wring your pants!


« Reply #17 - Posted 2002-12-26 14:54:01 »

Hmm I acknowledge that threads can be used wrongfully in games, however I think that there are instances where they can be used ( I am not talking Java here - but generally).
Having two threads isn't a bad idea (TM). When using one thread one does not  use all resources availeable, especially with in these times using smp/smt machines (wow this took a long time to write, even considering how (christmas) drunk I am Smiley))

Cheers - and f**king merry christmas Cheesy

Offline rreyelts

Junior Devvie




There is nothing Nu under the sun


« Reply #18 - Posted 2002-12-26 15:59:59 »

Multithreading is indeed reasonably useless for number crunching tasks.
Uh what? That's a naive statement at best.

When does one thread finish a piece of work?
That question is pretty much non-sensical. Yes, the use of threads requires synchronization - that's why we have synchronization primitives.

It's very difficult to disagree on the purpose of threads!
Apparently it's not as hard as you think considering the disagreement floating around. Obviously, one purpose of threads has to be to utilize multiple processors. The only other alternative would be multiple processes, and I hope we can all agree that that's just plain stupid in a large majority of cases - especially including that of games.

How many threads is it sensible to make?
It's very reasonable to say that you want roughly the same number of threads as the number of processors in the system plus a small constant. Of course, this varies by the application and the type of work being done.

How much overhead does synchronizing multiple threads have?
If you've written your program well, very little. For example, in a previous life I wrote medical imaging software based on wavelet compression techniques optimized for MMX. On a dual processor machine, I was able to achieve almost exactly twice the performance than on a single processor machine.

How does your application behave differently on uni- and multi-processor systems?
Umm... it runs faster on the multi-processor?

Or with green threads?
That's just plain ludicrous. This is akin to saying, what about DOS? Such systems exist, but that doesn't mean they should be part of your target market.

A good example is SQL server, which has an option to use "Fibers". These are basically ... time slice scheduled tasks running in a single thread!

NT fibers are the equivalent of green threads - They are literally user level threads. You can't use multiple fibers to utilize multiple CPUs. They suffer from their own problems, just like any other user level threads package.

As a matter of interest, the terrain demo has a hidden multithreading option in it somewhere. It gets slower on single processor systems by about 5%, and gets faster on dual processor systems by about 5%. Definitely not worth the vast increase in complexity.

That's a bad comparison, Cas. The terrain demo doesn't have any compute-bound logic in it. Rather, it's just a pixel pushing demo. Almost any real game will require serious CPU - the most obvious application being for all sorts of AI techniques.

What are you going to do when manufacturers reach clock cycle barriers on their chips and they move to serious multiprocessing? Are you just going to give up all of your lower level programming to move to a platform like Java3D, where the engineers know how to use threads?

It disturbs me that you would ignore and encourage others to ignore the growing audience of users with multiprocessors (including me). That is akin to encouraging others to ignore the users who bought GeForce4's. Good engineers take advantage of the extra processing power that is present.

God bless,
-Toby Reyelts

About me: http://jroller.com/page/rreyelts
Jace - Easier JNI: http://jace.reyelts.com/jace
Retroweaver - Compile on JDK1.5, and deploy on 1.4: http://retroweaver.sf.net.
Offline cknoll

Junior Devvie




Flame On!


« Reply #19 - Posted 2002-12-27 01:52:26 »

Quote

Sorry, but i really don't get it. I've explained what i'm doing and why. It works in each an every case i've tested and does EXACTLY what i want without any problems or hassle. Now you are telling me, that i shouldn't do it, because it may fail. You can be sure that i wouldn't do it, if it would fail somewhere...but it doesn't. It works perfectly on every machine/OS/VM i've tested it on. So basically you are trying to tell me that i shouldn't do it, because...i just shouldn't do it. Sorry, but that's like saying "use 4bpp only, because anything higher may fail" or "avoid using fullscreen, because it may fail (which it does quite often on my machine btw)."
Anyway, i think that  this discussion leads nowhere...


Sorry you don't get it, I gave 3 instances where it fails.  I'm just using real-life experience to come to my conclusions.  If you need other's testimonies, look no further than all the posts in the 2d and newbie forums asking why the f' their animations run so jerky and the answer is to do all painting in a single thread.  I helped put together a racing car game where 3 of the cars had their own collision avoidance and track-following code, and do you know what would have happened if they were just blindly put into separate threads?  the'd be driving into walls and into other cars all over the place because the 'game' thread would move the cars' positions while the AI was deciding where to drive.  It's madness.  The solution there would have been implementing the proper thread synchronization, but that's extremly prone to errors and would it have really gained anything?  Maybe if there was 1 cpu per car and everything was being figured out in parrallel.  I could imagine a system that uses multiple threads for each AI in a game, but you'd need to craft some sort of message queue to recieve commands from the various threads and synchronize the messages.  Sounds more complicated than it needs to be.

-Chris
Offline leknor

Junior Devvie




ROCK!!!


« Reply #20 - Posted 2002-12-27 02:54:25 »

I once read a quote that goes something like:
Quote
Begining programmers think programming is hard.
Average programmers think programming is easy.
Good programers know programming is hard.

I think I saw it in the book Code Complete but I couldn't find it to make sure I got it right.

Anyway, the point is that as we pass though different stages of understanding of something we have different views of the subject. To a beginier, programming may well be greek, he doesn't understand it. An average programer can make his program do what he wants and works in the situations he can think of to test it in. An expert understands the process and can see the possible problems that he himself may never experience.

I'm not a thread expert but I think there is a lot of oversimplification of threads going on in this discussion thread. If you don't have a complete understanding of all the nuances of threads, someday they will lead to obsure problems.

EgonOlsen: To at least somewhat answer your question, the collection of input, be it from the player or the network, need to be done with threads. The thing is these "input threads" should never directly touch the state of you game. The "main game loop" asks each of these input threads via a queue if they have new input at the start of a iteration. This way everything is consistant when you render a frame or calculate a npc's next move.

Quote
you simply can't jump out of the recursion of the AI calculations just to render half the image and then return.
(the bold is my edit)
This is why AIs tend to be written so they execute iterativly. Have you ever looked at the A-Star and asked "why does it only consider the spaces around the unit? Why not just figure out to my destination and be smarter about pathing?" The reason is in a game we need these cheap little steps that won't interupt the flow of game play as the computer does the number crunching.

Now you could use threads and wait() and notifyAll() at the right points and let many things run in parellel but it's very easy to make mistakes.
Offline EgonOlsen
« Reply #21 - Posted 2002-12-27 05:02:20 »

Quote

EgonOlsen: To at least somewhat answer your question, the collection of input, be it from the player or the network, need to be done with threads. The thing is these "input threads" should never directly touch the state of you game.

Of course not...how dumb do you think i am? I'm not asking this question because i don't have a clue about how to use threads, i wanted a know why people here around hate them with a passion.

Quote

The "main game loop" asks each of these input threads via a queue if they have new input at the start of a iteration. This way everything is consistant when you render a frame or calculate a npc's next move.

Exactly what i'm doing...

Quote

This is why AIs tend to be written so they execute iterativly. Have you ever looked at the A-Star and asked "why does it only consider the spaces around the unit? Why not just figure out to my destination and be smarter about pathing?" The reason is in a game we need these cheap little steps that won't interupt the flow of game play as the computer does the number crunching.

You mean i should rewrite the AI to build the decision tree in an iterative manner and then do what? Put an "engine.renderIfXMillisecondsHaveBeenElapsed();" every now and then? This uglyfies code and is not longer good OO IMHO. I would do it that way or similar if it would fail with threads. But it doesn't and that's exactly my point. I wouldn't put every car in cknoll's example into a single thread, but maybe i would put all cars in one and the rendering in another (albeit it isn't really required in this case, so i may not doing it). The "car-thread" would execute the game-logic and the renderer will render the current state. I'm NOT talking that each and every AI component has to be put into threads...but that it's very usefull for some kind of games like the applet above (somewhere...).

Edit: About the "cheap little steps"...i'm talking about a board game here, not about something like AOE...more like chess. So the requirements are totally different.

Offline princec

« JGO Spiffy Duke »


Medals: 421
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #22 - Posted 2002-12-27 09:18:57 »

Argh! What a can of worms.

Threads goes right back to O/S fundamentals. I'm being told to use threads "in case" someone's got a multiprocessor system. They don't, nearly no-one has a multiprocessor system. Yes, I do. No, it's not a gaming machine any more, it's a server. My iPaq didn't even have O/S level threads, they were green. Etc.

And fundamentally your graphics card only has one thread context, so you'd be pretty crazy to try writing to it in different threads as the performance will be killed stone dead. As mine is under XP when it tries to do all these stupid fancy effects everywhere.

What games programmers need is not threads it's fibers (sic). Fibers behave consistently on every system, and that's what you need in games programming. I'm not talking about writing servers and raytracers here! This is a games programming forum! Threads are not generally useful for compute crunching; although cache coherency and such is helped along by hardware these days in the general case you've got only one processor and you're much better off designing algorithms for client machines optimised for that case. Java might get all clever with a JIT but it can't optimise the O/S and hardware for you when you write a two-thread task that tries to execute effeciently on a uniprocessor machine.

If people want to know how to write games they should know this:

Design with one Thread in mind, and use only that Thread to do all input, computation, and rendering.

And that's genuinely the best advice you can give anyone. It's so simple it beggars belief that people are so persistently trying to make life difficult for themselves and others, coming up with ever more fantastic and complex ways of achieving the same result, only less consistently.

Unfortunately fibers are not exposed in Java so you need to figure out a way to do time-slice sheduling. There was an excellent article on Gamasutra I think which dealt with how they achieved this on PS2. It's not trivial but games programming has never been trivial; it's probably the hardest discipline there is, and a hacked shortcut like threads won't save you.

The terrain demo's not as bad an example as you'd think, as it's very likely that a game doing serious graphics will be graphics-bound anyway. That's the kind of multiprocessing games programmers need to understand: how to keep a graphics processor busy whilst you're thinking about what to feed it - and that is indeed what happens with OpenGL, for example, almost without you thinking about it.

Cas Smiley

Offline EgonOlsen
« Reply #23 - Posted 2002-12-27 10:07:22 »

Ok, i give up. I'll continue to use the "hacked shortcut" that threads are in situations where i find it applicable while i'm waiting for your chess program that allows the user to rotate the board while the AI is processing the decision tree and all that in one thread. Have fun and happy new year...may it be multi- or single-threaded.

Offline princec

« JGO Spiffy Duke »


Medals: 421
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #24 - Posted 2002-12-27 10:41:20 »

'sfunny you should say that, because that's exactly how XAP works, minus A*...

..and my new year looks like being multithreaded, because I've got to do some tedious consultancy work for The Man to pay the sodding mortgage. Trouble is, that thread never seems to pre-empt XAP and get executed...

Cas Smiley

Offline EgonOlsen
« Reply #25 - Posted 2002-12-27 12:41:39 »

After figuring out what XAP is, i can only say that

a defender clone != a chess program

I was talking about AI that may take seconds to make a move, not milliseconds...but that doesn't matter because i've already given up on this topic. I just had to add this one thing... Roll Eyes

Offline the2bears

Senior Devvie


Projects: 2


Little Bear: Code Fu!


« Reply #26 - Posted 2002-12-27 13:35:19 »

I'm as green as it gets with game programming... so I'm just lurking and enjoying the discussion regarding threads.  Can't say how they fit into games yet, I can see some valid points being said here - and I don't think people are necessarily disagreeing, just talking about different situations.

I will say that in doing distributed Jini stuff threads are my friend:)  But after classloading they're generally one of the most misunderstood bits of programming.

Anyway, I hope anyone doesn't think this thread has been too off topic or useless.  I've found it very interesting.

Regards,

Bill

the2bears - the indie shmup blog
Pages: [1]
  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.

xFryIx (55 views)
2014-11-13 12:34:49

digdugdiggy (34 views)
2014-11-12 21:11:50

digdugdiggy (29 views)
2014-11-12 21:10:15

digdugdiggy (23 views)
2014-11-12 21:09:33

kovacsa (46 views)
2014-11-07 19:57:14

TehJavaDev (50 views)
2014-11-03 22:04:50

BurntPizza (49 views)
2014-11-03 18:54:52

moogie (65 views)
2014-11-03 06:22:04

CopyableCougar4 (63 views)
2014-11-01 23:36:41

DarkCart (148 views)
2014-11-01 14:51:03
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

List of Learning Resources
by SilverTiger
2014-07-31 16:26:06
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!