Java-Gaming.org    
Featured games (79)
games approved by the League of Dukes
Games in Showcase (476)
Games in Android Showcase (106)
games submitted by our members
Games in WIP (530)
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  
  Is this still considered "right"???  (Read 3321 times)
0 Members and 1 Guest are viewing this topic.
Offline beowulf

Senior Newbie




got root?


« Posted 2003-08-01 14:59:53 »

Ok...some of my ideas of game development are a bit dated.   Embarrassed I have only done game development at a hobby level, and the last time I put any significant time into it was in the Win32 days (prior to DirectX).  I'm trying to get back into it and some of that involves un-learning what is no longer appropriate.  So...

My project (as I've mentioned in a couple other threads) is a strategy game along the lines of Civ, Master of Orion & Heroes of Might & Magic (community building, resource management, etc).  The core UI is a "command center" screen that gives you high-level info and lets you click off to other screens or pop-ups for details. I have considered using AWT for doing the interface, but I really don't think that's the most appropriate method.

In the "old days" many such games used a single bmp for all the static graphics on the UI.  This had "cut outs" for buttons, resource counters, a main map, etc. You then had other images for those objects and when the user clicked on the screen you determined if the coordinates for that click were within the bounds of one of your buttons and executed the code for that.  Additionally, you can add miscellaneous sprites for eye-candy (flashing lights, background movement, etc).

It would seem to me that this is still a valid implementation. No need to worry about chopping my main Frame into smaller containers. A single listener could handle all mouse events (from what I've tried so far). Drag-n-drop may be easier to implement (I haven't tried this yet)...etc, etc.  Now, as admitted I might be overlooking a great oportunity w/ AWT, or I may be causing myself unnecessary headaches going down this road.

Any feedback, opinions or experience is greatly appreciated.  

-Lawrence     Huh
Offline kevglass

JGO Kernel


Medals: 120
Projects: 23
Exp: 18 years


Coder, Trainee Pixel Artist, Game Reviewer


« Reply #1 - Posted 2003-08-01 15:07:06 »

AWT/Swing can be useful for dialogs and the like, but generally games want to have their own feel and style. In my opinion (being very careful not to offend anyone), the things you've said above are all still valid.

Kev

Offline bmyers

Junior Member





« Reply #2 - Posted 2003-08-01 16:41:28 »

I think Swing has a lot to offer.

If you are writing an action game, or a FPS, or something where you expect a lot of graphics changes pretty much every frame, then you probably don't want to use Swing.

However, if you are writing a strategy game where most of the graphic content is static, or are things like buttons, then Swing will reduce your development effort by a *huge* amount, and will also reduce your bugginess.

Swing will let you develop your own look and feel -- every component can be easily customized with borders, fill graphics, etc.  So that argument is outdated (unless you want to make trapezoidal or hex buttons or something like that).

That said, Swing still has problems in fullscreen mode, so that might be a reason to not use it.  I expect those will go away at some point.

For our current project we are using Swing for half of our interface, and Java3D for the other half.  We are working on an MMO strategy game, so most of our Swing graphic content is relatively static (as compared to the 3D content).

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

JGO Kernel


Medals: 120
Projects: 23
Exp: 18 years


Coder, Trainee Pixel Artist, Game Reviewer


« Reply #3 - Posted 2003-08-01 16:46:25 »

I kinda meant feel in terms of "tactile feel" as opposed to "Look & Feel (tm)". All swing GUIs feel the same whether they look the same or not. At least in my view.

Kev

Offline bmyers

Junior Member





« Reply #4 - Posted 2003-08-01 17:48:46 »

I saw some very impressive Swing demos at JavaOne, including one that I would never have believed was Swing because the feel was very different -- a picture chooser that had a semi-circular scrolling "thumbwheel", and a fish-bowl style image viewer, all on a translucent background with animated gradients flowing through it.

There were no "buttons" anywhere, or even any of the normal Swing widgets.  Except everything was actually fairly straight-forward Swing components, with some tweaking of backgrounds, transparency, gradients, etc.

IIRC, the speaker said it took them about a day or two to create it.

Offline kevglass

JGO Kernel


Medals: 120
Projects: 23
Exp: 18 years


Coder, Trainee Pixel Artist, Game Reviewer


« Reply #5 - Posted 2003-08-01 17:50:50 »

Coo, I thought I knew quite a bit about swing, but I wouldn't have the foggiest how to get some of those effects...

I doth stand (sit) corrected.

Is there anywhere we (humble, poor) people can see the demos?

Kev

Offline Kommi

Junior Member




All opinions will be lined up and shot!


« Reply #6 - Posted 2003-08-01 18:11:58 »

Yeah I would definately like to glance at such cool sounding Swing UI's.

Kommi
Offline beowulf

Senior Newbie




got root?


« Reply #7 - Posted 2003-08-01 18:33:25 »

First, thanks for the input so far!!! Smiley

That 'feel and style' issue is the biggie that I'm worried about.  I know I can replace generic buttons with a graphic and such, but I don't know if it's really flexible enough.  I am a firm believer that for what I'm working on I do not want any part of the UI to look like a "normal" Windows/XWindows/MacOS interface.  If the game is based in a fantasy situation for example, there should be nothing on your screen that distracts from the suspension-of-disbelief.  A generic looking frame, menu, etc does that.

Example:  One key limitation I have heard about with AWT / Swing is the shape and placement of some components.  In a fantasy-set game for example, I may want to have my "buttons" be various colored crystals (w/ basic animation to create a feel of depth, sparkel and "magic").  Some would be oval, round, square or hex shapped.  They're not the same size and I may not want them lined up perfectly. Additionally, I don't want a bounding-box situation where you can click "outside" of a crystal, yet still within an imaginary rectangle drawn around it, and have that count as a click.  

Could something like this be done w/ just extending AWT and/or Swing components?? I know it could be done by creating a background image for the crystals to sit on, then creating some basic sprite animation for the cyrstals themselves, and just rendering it.  I then map all mouse clicks and determine what objects to call based on what crystal's image was clicked.  It's more work than just extending a button, but...   Huh  If it matters, I am doing my game in an undecorated AWT frame modeled after this: http://www.java-gaming.org/cgi-bin/JGNetForums/YaBB.cgi?board=share;action=display;num=1036791657 )

As always,  advTHANKSance!!!!
-Lawrence
Offline beowulf

Senior Newbie




got root?


« Reply #8 - Posted 2003-08-01 18:36:27 »

Dang it!!!  I got distracted by work and by the time I actually hit "post", there's already a full discussion going on about what I'm writting.   Sad

I would DEFINETLY be interrested in seeing such examples, especially if we can see HOW they did it as well!!!

-Lawrence
Offline bmyers

Junior Member





« Reply #9 - Posted 2003-08-01 21:16:37 »

In theory, you *could* create your own custom components to handle weird shapes, sizes, placements, etc, which you could use for your "crystal buttons".  I haven't done this myself in Swing, but there's probably someone here in the forums who has.

As for seeing the JavaOne demos, you can click here to get the Java Desktop slides, if you are a JDC member.

The name of the presentation with the cool demo is: Get Rich Quick: Taking Advantage of Java 2DTM API in Your Rich Client Application  (PDF form)

Unfortunately, the Demo itself is not there, just some examples of how to do scaling, gradients, animation, etc...  Sad

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

JGO Coder




Where's the Kaboom?


« Reply #10 - Posted 2003-08-02 02:22:19 »

Yes you can do all that with Swing..

Use a null layout manager.

Set components to be NOT opaque so that the background shows through when they don't fill their bounding box.

See the Java Tech Tip for Round Buttons to get an idea how to make the hit tests only work within the bounds of the actual graphic, not the bounding box.
http://developer.java.sun.com/developer/TechTips/1999/tt0826.html#tip1

Check the Java2D demos.

Offline trembovetski

Senior Member




If only I knew what I'm talking about!


« Reply #11 - Posted 2003-08-04 06:53:15 »

Check out this JavaOne presentation slides:
http://servlet.java.sun.com/javaone/sf2003/conf/sessions/display-1493.en.jsp

The demos mentioned above were written for this presentation.
Offline Abuse

JGO Coder


Medals: 11


falling into the abyss of reality


« Reply #12 - Posted 2003-08-04 10:46:14 »

eek!

Quote

Swing profiling demo written on Linux. When run
on Windows, saw startup regression when going
to 'improved' version
* Profiled app, saw time going to
GraphicsDevice.getConfigurations()[0]
* Used to grab default GC to create
compatible image
* This call relies on PixelFormat calls, which (on
Windows) load/call OpenGL APIs
* BIG time hit on initialization
* Result: use getDefaultConfiguration()


I assumed getting a GraphicsConfiguration that is specific to the Device you intend to be rendering onto is the *right* way of doing it.
Yet, the slides tell you to forgo the *right* way, and use the lazy way cos its quicker :S

What would happen if you have multiple different GraphicsDevices?
By my understanding, wouldn't using getDefaultConfiguration cause all sorts of bugs?


Quote

* Things are getting better all the time...
* Swing/2D are adding and accelerating new
features with every release
HOWEVER
* No matter how fast we go, you need to make
sure you are making the best use of our APIs
* Profile on your target environments


The last statement here is abit disturbing as well Shocked
Doesn't having to profile on every environment you intend deploying on defeat 1 of the major advantages of Java.
Write Once, Run Anywhere Huh

Make Elite IV:Dangerous happen! Pledge your backing at KICKSTARTER here! https://dl.dropbox.com/u/54785909/EliteIVsmaller.png
Offline bmyers

Junior Member





« Reply #13 - Posted 2003-08-04 20:47:08 »

Quote

The last statement here is abit disturbing as well Shocked
Doesn't having to profile on every environment you intend deploying on defeat 1 of the major advantages of Java.
Write Once, Run Anywhere Huh


It'll still run on the various platforms, but it may not run fast.  The profiling recommendation is for when you need to get optimum performance on all of your target platforms.

This is something that'll likely never go away, because each platform will have it's own weird quirks based on both the hardware and software.  Java really just guarantees that any 100% compliant JVM will run bytecodes that were created by a 100% compliant Java compiler.

Offline swpalmer

JGO Coder




Where's the Kaboom?


« Reply #14 - Posted 2003-08-04 21:03:55 »

Right.  Java can't equalize the performance of dissimilar platforms if the OS imposes certain restrictions and delays.  Different platforms will always have different performance characteristics. Java or anything like it will never change that.

It IS mostly "write once, run anywhere" but you must test.  "Write once, test everywhere, tweak stuff, run anywhere" is closer to the actual development cycle Smiley

Offline Abuse

JGO Coder


Medals: 11


falling into the abyss of reality


« Reply #15 - Posted 2003-08-04 23:56:16 »

if that is always going to be the case, then i believe Java has failed Sad
IMO comparable performance on comparable hardware *should* be a requirement of any JVM.

The current OSX JDK is a good example of this.

mid-range Windows machine in a standard desktop resolution - several thousand image blits/second @30fps.
mid-range Mac in a standard desktop resolution - can you even get 30fps with 0 blits/second?Huh

If its going to run at that kind of speed.
It might as well not run at all Roll Eyes

I know that particular example is a short-term issue that will probably[it bloody better!] be fixed by the next JDK release.

However, the problem remains.

You write a game that makes use of image rotations [through AffineTransform] with the expectation that they will be accelerated. (once they eventually become accelerated...)
Some1 runs your code on a machine that doesn't support hardware image rotation.
The game will be unacceptably slow.
What do you do?
rewrite your game so it pre-caches every single rotation? in a game of any scale, this will be totally impractical.

You end up having to say, sorry it won't run on your machine configuration.
Ofcourse you can still say 'Write once, run anywhere', but as in any realtime system, a late answer is a wrong answer Tongue

Make Elite IV:Dangerous happen! Pledge your backing at KICKSTARTER here! https://dl.dropbox.com/u/54785909/EliteIVsmaller.png
Offline swpalmer

JGO Coder




Where's the Kaboom?


« Reply #16 - Posted 2003-08-05 03:38:37 »

No, Java hasn't failed.  Java never made any promises about relative performance on each JRE implementation.  Because it simply is not possible.

Even in C/C++,assembler,etc.. it is NOT possible.  Even on the exact same hardware.  Different operating systems will have different constraints.  Mac OS X displays are always double buffered for instance.  On Mac OS certain pixel formats will blit faster than others because of how they fit into the display architecture and the use of OpenGL for the native Mac UI.  No programming language or runtime environment is going to change that.

Same with your hardware acceleration example for AffineTransform.. what do you expect?  I see this as not much different than the standard "System Requirements" that you see on the bottom panel of any packaged software.  Remember when 3D games came with software only engines that required a certain CPU speed.. OR they would print on the box, requires a 3D accelerator (with a slower CPU)?   The only problem is that the cross-platform nature of Java exposes more variables like those.  It's not like this is something new.

I agree that it makes things difficult sometimes for developers, but tough, that's simply the way it works.

Offline trembovetski

Senior Member




If only I knew what I'm talking about!


« Reply #17 - Posted 2003-08-05 05:16:03 »

Quote
You write a game that makes use of image rotations [through AffineTransform] with the expectation that they will be accelerated. (once they eventually become accelerated...)
Some1 runs your code on a machine that doesn't support hardware image rotation.
The game will be unacceptably slow.


How's that different from a game developed in C++ with DirectX/3D/OGL? If your hardware doesn't support features required by the game, it'll run through sw loops and will be slow. OpenGL failed, then.

I understand that this is not a 100% correct comparison, but you get the point.

Offline trembovetski

Senior Member




If only I knew what I'm talking about!


« Reply #18 - Posted 2003-08-05 05:19:20 »

I've managed to forget to post a link to this great app which was used in that presentation:
https://mu.dev.java.net/

The source code is available, and the app webstartified:
http://mu.dev.java.net/latest/mu-rich.jnlp
Offline Abuse

JGO Coder


Medals: 11


falling into the abyss of reality


« Reply #19 - Posted 2003-08-05 11:31:34 »

ok, maybe I was a little harsh blaming Java for problems that are realy caused by the evilness that is abstration Wink

Java still needs a way of getting hardware Capabilities though.

For instance, if your platform supports hardware images, but doesn't support hardware alpha compositing.
Making use of much alpha compositing at all, is going to be so detremental to speed, that it would be much better to forget hardware acceleration altogether, and keep your images in main memory.

Is getCaps() (or something similar) going to feature in 1.5?

Incidentally, BufferStrategy always gives you a hardware accelerated backbuffer if its available, even when you request a software backbuffer.
Which makes encapsulating a pain, cos you have to create a regular BufferedImage and do the back buffering yourself if you don't want acceleration.

1  
2  
3  
 frame.createBufferStrategy(2, new BufferCapabilities(new ImageCapabilities(false),
                                                                   new ImageCapabilities(false),
                                                                   null));



Make Elite IV:Dangerous happen! Pledge your backing at KICKSTARTER here! https://dl.dropbox.com/u/54785909/EliteIVsmaller.png
Offline swpalmer

JGO Coder




Where's the Kaboom?


« Reply #20 - Posted 2003-08-05 14:26:19 »

Yep, what we need to shoot for is that whatever acceleration mechanisms are available on each platform are actually implemented.  E.g. managed images for opaque or translucent images should be supported on the Mac.  I suspect that they will be soon, it's just that the Apple folks were rushing to catch-up  with their 1.4 release so naturally some things had to wait.

We know that Sun is working on acceleration via OpenGL on the Linux platform, so hopefully we will have a more even playing field soon.

A set of flags/properties that could be read to indicate what sort of acceleration is available might help a bit... but really for most games I suspect all it will lead to is a dialog that says your system isn't good enough to run this game Smiley...  even in a few years when the software methods would be fast enough anyway Cheesy

Remember those games from Seirra that basically profiled the system in the installer so that they knew you could blit fast enough, and that your CD ROM would read fast enough etc..?   Maybe we need something like that for Java?

Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #21 - Posted 2003-08-05 18:06:09 »

Quote
if that is always going to be the case, then i believe Java has failed Sad
IMO comparable performance on comparable hardware *should* be a requirement of any JVM.


You've got a good point. Unfortunately, given how controversial it could be, you have to be very careful how you phrase it (takes one to know one Wink ...I've made I think about 5 posts on JGO which were perilously close to flame-bait because I didn't phrase them carefully enough  Embarrassed)

To illustrate, when I first read your point:

Quote

Doesn't having to profile on every environment you intend deploying on defeat 1 of the major advantages of Java.
Write Once, Run Anywhere Huh


I instinctively disagreed. When I realised the full import of what you were saying, I agreed (flippant, aren't I? Smiley). I've been here before, in the 1.0.x and 1.1.x days of java, when there were MANY more JVM's than there are now. In particular, I was trying to code to DOS and RISC-OS JVM's, which were ... um ... crap. The performance was so bad that e.g. something as innocent as new String() was a killer (String was much slower back then in general, so this is not a great example, but I can't remember the really nasty ones any more). I occasionally thank whatever deity that's to hand that most JVM's got dropped...it's better for a JVM not to exist, than to be so poor as to be unusable AND make it harder to write java code (because you, as developer, get the support headaches from people who's performance or bug problems are due to massively over-worked and under-performing JVM maintainer).

To para-phrase A C Clarke (badly): "Any sufficiently poorly-performing function is indistinguishable from it's non-implementation". (if the String constructor gets too slow, for instance, effectively there is no String class in Java since no-one can ever use it).

It is important to recognise the validity of this.

The WORA concept does not explicitly guarantee this within the word "run". It probably does imply it, though. Anyone who says "this is not guaranteed, and never will be" has a good point too - but this is largely because the word guarantee is too strong to be used with WORA, and shouldn't come into the equation: for hte most part, no-one ANYWHERE is in a position to guarantee any aspect of Java, not even Sun. You can fairly say that you can "never guarantee equivalent performance, even on one platform", but unless you pay them a very large amount, no one vendor would stick their neck out and "guarantee" any aspect of Java.

OTOH, if you talk about what WORA means in practice, then this performance aspect should always be considered part of "running successfully". Note that Java is expected not just to run, but to run properly, and to a minimum level of bug-less-ness (although that minimum level is not very high, cross-platform). It's fair to say it should also run at a minimum speed.

malloc will be first against the wall when the revolution comes...
Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #22 - Posted 2003-08-05 18:18:40 »

Quote
... but really for most games I suspect all it will lead to is a dialog that says your system isn't good enough to run this game Smiley...  even in a few years when the software methods would be fast enough anyway Cheesy

Remember those games from Seirra that basically profiled the system in the installer so that they knew you could blit fast enough, and that your CD ROM would read fast enough etc..?   Maybe we need something like that for Java?


It's an excellent, well-engineered, high-quality approach to application development. Sadly it won't get implemented on an individual-game basis in general, because capitalism doesn't like high-quality without solid financial justification. And if it's not being implemented by games devs, it's unlikely that anyone will make a generic version (and even less likelyh that devs will bother to use it, if they had so little need for it in the first place).

For most off-the-shelf games these days, 90% of the sales are made in the 3 months after release (sourced from various trade-press, can't remember which in particular - might even be the ELSPA surveys; probably slightly out of date). The only way they make more money is by releasing sequels or "deluxe"/"gold" editions. If you're going to re-release a gold edition (which only happens rarely in practice - it isn't effective for games which don't have a large hardcore contigent who would buy the same game twice just to get the version with the gold-foil on the box), you have to make some bugfixes anyway, and updating the "requirements check" is easy to do at the same time.

For subscription-based games you have to have online distribution / automated patching of some sort anyway, else you can't in practice charge a subscription. So, as soon as a sufficiently large number of players can't start the game but should be able to, you issue a patch that probably just disables all perf-checking entirely.

There is, of course, value to the dev studio's "brand" to have games that are still playable years later. My opinion of Bullfrog (and hence Lionhead) decreased considerably when I discovered I couldn't play Syndicate any more. I paid for the game, and I'd like to re-play one of their best games ever, but not a chance. Every time I want to but am rebuffed, their brand suffers. But they've got much bigger brand-affectors to worry about! I heard they aren't doing multi-player B&W2  because it's not justified in terms of expense / sales...if they're making decisions like that, how do you think they'd justify making their game "run well in 5-10 years time"?

malloc will be first against the wall when the revolution comes...
Offline swpalmer

JGO Coder




Where's the Kaboom?


« Reply #23 - Posted 2003-08-05 18:27:59 »

You know, maybe a system profiler to determine a few scores for various aspects of Java gaming performance would be a good project for this group on java.net.

If we had a free standard library that could do some blitting tests with various image formats, check various things like fullscreen support, hardware acceleration, sound tests, IO, etc.  Check for availability of various optional packages...

That might be useful.

Offline trembovetski

Senior Member




If only I knew what I'm talking about!


« Reply #24 - Posted 2003-08-06 03:30:14 »

Quote

Incidentally, BufferStrategy always gives you a hardware accelerated backbuffer if its available, even when you request a software backbuffer.
Which makes encapsulating a pain, cos you have to create a regular BufferedImage and do the back buffering yourself if you don't want acceleration.


yeah, this is a known bug. It'll give you a buffer strategy with accelerated buffers, but it'll be Blit strategy, not Flip.
Offline swpalmer

JGO Coder




Where's the Kaboom?


« Reply #25 - Posted 2003-08-06 04:35:19 »

Quote
I've managed to forget to post a link to this great app which was used in that presentation:
https://mu.dev.java.net/

The source code is available, and the app webstartified:
http://mu.dev.java.net/latest/mu-rich.jnlp


I just thought I would point out that this app fails spectacularly on Mac OS X with Java 1.4.1... totally unusable.  It's kind of hard to imagine how they managed to get it to behave so poorly.  Could be Apple bugs.. but I've never seen anything else on the Mac do anything like this.

Offline campbell

Junior Member




Java games rock!


« Reply #26 - Posted 2003-08-06 04:53:25 »

Quote


I just thought I would point out that this app fails spectacularly on Mac OS X with Java 1.4.1... totally unusable.  It's kind of hard to imagine how they managed to get it to behave so poorly.  Could be Apple bugs.. but I've never seen anything else on the Mac do anything like this.


[I'm the author of Mu...]  I agree that it's mostly unusable on Mac OS X, which is pretty disappointing since that's my primary development platform (when I'm not at work).  Fullscreen is especially broken with Apple's 1.4.1... I submitted 3 or 4 bugs to Apple that affect Mu, and I think they've been resolved for their next release.  I also brought up the fullscreen issues to their 2D lead last time I saw him, and he's aware of them.  He's hoping to have some of those resolved for the next release as well.

Thanks for checking out the app... Part of the goal of Mu is to demonstrate some "best practices" when using 2D, Swing, fullscreen, etc. all in conjunction.  If you get a chance to try it on another platform, let me know how it goes, or if you have any suggestions/comments.

Thanks,
Chris
Offline Abuse

JGO Coder


Medals: 11


falling into the abyss of reality


« Reply #27 - Posted 2003-08-06 10:34:13 »

Quote


yeah, this is a known bug. It'll give you a buffer strategy with accelerated buffers, but it'll be Blit strategy, not Flip.

Is it a known bug that is going to be fixed? Wink

Make Elite IV:Dangerous happen! Pledge your backing at KICKSTARTER here! https://dl.dropbox.com/u/54785909/EliteIVsmaller.png
Offline swpalmer

JGO Coder




Where's the Kaboom?


« Reply #28 - Posted 2003-08-06 13:07:59 »

Quote
Fullscreen is especially broken with Apple's 1.4.1... I submitted 3 or 4 bugs to Apple that affect Mu, and I think they've been resolved for their next release.  I also brought up the fullscreen issues to their 2D lead last time I saw him, and he's aware of them.  He's hoping to have some of those resolved for the next release as well.


I am running the latest publicly available Developer Preview (DP102)..   Are you running some later build that you know the issues have been fixed in? (would you be allowed to say if you were? Smiley )
It's good news though, that many fullscreen issues will be fixed in the next release.  I have high hopes that the Apple guys will get compatibility and performance of their JRE back on track with comparable windows and linux systems.

Offline campbell

Junior Member




Java games rock!


« Reply #29 - Posted 2003-08-06 18:37:49 »

Quote


I am running the latest publicly available Developer Preview (DP102)..   Are you running some later build that you know the issues have been fixed in? (would you be allowed to say if you were? Smiley )


I haven't tried the latest DP102 yet, but I'm pretty sure the fixes I mentioned haven't gone into that one.  I'll keep my fingers crossed for the next one I guess (we don't usually get early access to Apple's DP builds).

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

pw (12 views)
2014-07-24 01:59:36

Riven (10 views)
2014-07-23 21:16:32

Riven (11 views)
2014-07-23 21:07:15

Riven (12 views)
2014-07-23 20:56:16

ctomni231 (43 views)
2014-07-18 06:55:21

Zero Volt (38 views)
2014-07-17 23:47:54

danieldean (32 views)
2014-07-17 23:41:23

MustardPeter (34 views)
2014-07-16 23:30:00

Cero (50 views)
2014-07-16 00:42:17

Riven (50 views)
2014-07-14 18:02:53
HotSpot Options
by dleskov
2014-07-08 03:59:08

Java and Game Development Tutorials
by SwordsMiner
2014-06-14 00:58:24

Java and Game Development Tutorials
by SwordsMiner
2014-06-14 00:47:22

How do I start Java Game Development?
by ra4king
2014-05-17 11:13:37

HotSpot Options
by Roquen
2014-05-15 09:59:54

HotSpot Options
by Roquen
2014-05-06 15:03:10

Escape Analysis
by Roquen
2014-04-29 22:16:43

Experimental Toys
by Roquen
2014-04-28 13:24:22
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!