Hi !
Featured games (90)
games approved by the League of Dukes
Games in Showcase (753)
Games in Android Showcase (228)
games submitted by our members
Games in WIP (842)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
   Home   Help   Search   Login   Register   
  Show Posts
Pages: [1] 2 3
1  Java Game APIs & Engines / Java 2D / Re: TGA image reader for ImageIO Available on: 2006-06-01 22:03:53
I have made available additional source (via the RealityInteractive website) that contains a workaround.  The source of the plugin itself does not need to be changed.

Perhaps you should make an enquiry (on the bug itself?) as to which version the Java bug is fixed in.

Good luck!
2  Discussions / Jobs and Resumes / Talented Graphic Artist Needed for Short Term Cont on: 2005-05-31 11:38:15
Reality Interactive, Inc. ( a visionary leader in interactive applications is currently working on their next application that combines software development with rich visual environments.  The need has arisen for a talented and visionary graphic artist familiar with user interfaces to help us flesh out our mock ups.

We are posting to game developers for two reasons:  to tap into the visionary talent found in the gaming community and to provide an alternative source of income to those struggling to make first-class games.

Applicant Requirements:

  • Excellent graphic design skills (Photoshop preferred)
  • Previous experience designing user interfaces
  • Familiarity with Java, OO and UML (Coding will not be required.)
  • US applicants only (unless you have experience with international contracts and can facilitate the process)

No on-site work is required.

We currently have a small budget for this work and we will only require a few hours of time over the next month.  If you're in need of a few extra bucks and have the necessary requirements then please send a link to your portfolio to for consideration.

Thank you.

(If you know of any other board that we can post to for free please let me know.  I would prefer have my budget go into the pocket of an artist.)
3  Game Development / Shared Code / Re: "BufferWriter" on: 2004-08-23 13:20:34
True, but there's nothing to produce a writer for a buffer there, so AFAICS no use at all in this case...?

Combining my points one and two should pretty clearly define a path.  

I'd like to divert from the topic for a moment here and simply say:  blahblahblahh, you are the sole reason that I rarely read and contribute to this forum.  I constantly feel that I have to be on the defensive when writing posts and I constantly feel that I am being torn into with your responses.  As to if this is your intent, I cannot say.  Since my time spent on this forum is purely voluntary, I simply do not wish to feel this way so therefore I will turn my rarely into never and bid you all adieu.
4  Game Development / Shared Code / Re: "BufferWriter" on: 2004-08-23 12:12:12
I'd like to point out a few things:

  • Most people miss java.nio.channels.Channels.  There's some goodies in there.

  • In terms of design and intent, ByteBuffer, CharBuffer, etc are to byte array, char array what ReadableByteChannel, WritableByteChannel are to InputStream and OutputStream, Reader and Writer, etc.  This isn't exact, but I'm trying to motivate an understanding of how you end up using NIO rather than an exact analogy.

  • CharBuffer is-a CharSequence.  You can wrap a CharSequence or a char array in a CharBuffer.  Typically, this gets you 90% of the conversions that you want.

  • provides some information on charsets.
5  Game Development / Shared Code / Re: NIO, IO, and SSL facilitation code on: 2004-08-20 16:05:04
Ask and ye shall receive:;action=display;num=1093025002
6  Game Development / Networking & Multiplayer / java.nio.channels.Pipe information on: 2004-08-20 16:03:22
blahblahblahh mentioned that I should start a post on some of the Pipe information that I have.

Rather than regurgitate the information here, I will point you to some relevant links:

from the main entry:

(so that you get some motivation as to why I did all of this).

There is some code concerning Pipes available at:

in the "NIO converter to faciliate SSL".  Look in "test-java/com/realityinteractive/nio/io".  Specifically and

I hope this is helpful!

7  Game Development / Shared Code / Re: NIO, IO, and SSL facilitation code on: 2004-08-20 15:37:38
As for what it is .... there's not one answer.  Originally I wanted to get SSL working with NIO using 1.4 since I have a lot of NIO code that now needs to work over SSL.  That's obviously not going to happen out of the box.  So I started to determine how close I could get and that led to "Converted IO" (which essentially converts InputStream and OutputStream to a ScatteringByteChannel and GatheringByteChannel, respectively, using Pipes).  Pipes turned out to be a fiasco.

There's a bunch of Echo servers in there (using IO, NIO, Converted IO and Converted IO with a Selector) and sutiable clients.

Oh, and there's a couple of factories for creating SSL and plain sockets to simplify the whole ugly process.

I'm still sorting out what a best answer is, especially given the crappy performance of the Converted IO with Selector.
8  Game Development / Shared Code / Re: NIO, IO, and SSL facilitation code on: 2004-08-20 15:27:18
It annoys the snot out of me to have the same info posted in multiple locations (like having 5 different forums with the same questions and answers).  We have these wonderful hyperlinks for a reason  Grin

Thanks for putting up the info blahblahblahh.

There's a goodly chunk of IO and NIO code in there and a lot of Pipe information.  If you're in need of some networking examples including SSL then it may be something to look at.

The release notes:

contain a good deal of information.

an infinite link circle cyling between two pages with no info

It's interesting that you say that.  I went to great lengths to ensure that all entries go back to the main NIO and SSL post which has references to all of the relevant information.  I'm open for suggestions (that don't involve replicating data) about how to better organize.  I will admit that it's not for the faint of heart.  
9  Game Development / Shared Code / NIO, IO, and SSL facilitation code on: 2004-08-20 13:26:06
Rather than repost a whole bunch of info, I'll just post a link:

I read these forums infrequently so if you have a question or problem, post a comment in the blog.  This way the information is centralized.
10  Java Game APIs & Engines / Tools Discussion / Re: Eclipse hang/lag? on: 2004-08-20 13:18:27
On windows, keep up the Task Manager.  Make sure that you have the "Mem Usage" and "VM Size" colums selected (View -> Select Columns ...).  If Eclipse "hangs", take a look at the "Mem Usage" column.  If it's less than (and typically much less than) the "VM Size" and growing, then it was swapped out and it being swapped back in.
11  Game Development / Networking & Multiplayer / Re: Misc NIO questions on: 2004-08-20 12:26:54
I don't have the time to check through the code for your first question, sorry.  There are many NIO tutorials out there.  Get comfy and start pouring over them  Smiley

As for the "unbind" -- you just close the channel.  Also, look into ServerSocketChannel.getSocket().setReuseAddress().  It may be useful in your case.
12  Game Development / Networking & Multiplayer / Some NIO and IO performance numbers on: 2004-08-20 12:16:57
I have posted some performance numbers based on some tests that I have run on NIO, IO and Converted IO.  You can see the results here:

There are a whole bunch of links to other things such as my NIO and SSL grievings.

I rarely check back to this forum so either contact me directly or post a comment on my blog if you have questions.

(FYI: "Converted IO" is explained in some of the links)
13  Game Development / Networking & Multiplayer / Re: Non-blocking blocking I/O? on: 2004-08-20 12:02:42
I will confirm Matlu's statement about using Socket.getInputStream's available().  I have used it many times in the past to do "non-blocking" IO with standard IO.  It works very well in a game environment since you have a polling situation (you just check it every pass though the game loop).  It's a serious pain in the butt when you don't (e.g. most enterprise applications).
14  Java Game APIs & Engines / OpenGL Development / Re: ANN: SWT OpenGL Context (Win32, Linux + Motif) on: 2004-07-03 20:56:28
The Linux + GTK version is now available via the same URL.  Please let me know if you have any problems.
15  Java Game APIs & Engines / OpenGL Development / ANN: SWT OpenGL Context (Win32, Linux + Motif) on: 2004-07-02 15:39:56
An OpenGL rendering context with shared context support for SWT that is independent of the OpenGL implementation used (for example LWJGL).

Currently Win32 and Linux + Motif versions are available. A linux-gtk version is forthcoming.

There is more information about the release at:
16  Java Game APIs & Engines / Tools Discussion / Re: Eclipse 3.0 M9 on: 2004-05-25 12:20:09
Please get into the habit of filing bug reports.  The number of bugs that I find reported in forums that are not found in bug tracking software is staggering.  Developers don't always have time to scour the forums looking for bug reports.

I have written up a quick blurb on this that will hopefully drive the point home:
17  Discussions / Miscellaneous Topics / Re: Eclipse 3.0 M8 is out on: 2004-04-02 14:23:26
The UI is essentially what MS showed at PDC 2003 for its new (essentially Eclipse clone) Visual Studio.  Having visual parity with the new VS will allow easy migration of the gazillion VS developers to Eclipse.

One thing that I think is just grand about the UI change is that the Eclipse team showed that you can make such a grand change w/o royally screwing up the API's and existing code.  If that change was "easy" then it should be easy for people to make / migrate their own "skins".
18  Java Game APIs & Engines / Tools Discussion / Re: Scripting languages on: 2004-03-22 13:14:36
The obvious fundamental problem with DSL's is that you've created a new language. Cue: all the support and re-training costs inherent to that. You can't just go out and hire people who already know it in and out.

It should be noted that DSL does not imply a new language.  Cas, for example, is saying that Java is the DSL of his choice (though the "domain" in this case is a bit broad).

If it's easier to write your FSM's in Prolog, then do so.  Some things are better in functional langauges whereas others are better in procedural languages.  Use what makes sense for the particular situation.
19  Java Game APIs & Engines / Tools Discussion / Re: Scripting languages on: 2004-03-21 14:51:25
A coupla quick followups:

  • The literature is claiming that approximately half of current game development time is spent writing tools (so, no, writing a translator, for example, is not out of scope).

  • Given the Eclipse framework (no, I'm not looking to start an IDE discussion) it's essentially trivial to write a context assisted, etc, etc, etc langauge editor.  Integrate that with the AST and you have a DSL spitting out Java in an afternoon.
20  Java Game APIs & Engines / Tools Discussion / Re: Scripting languages on: 2004-03-21 14:41:50
Well, it's good that I can still start a debate rolling!   Wink

The current track seems to be questioning the actual semantics and expressivity (sp?) of a particular language.  This is currently a hot topic all over the programming world.  If you're an OOPSLA watcher, you've seen all of the hoopla on domain specific languages (DSL's) where one definition of DSL is:

... a programming language or executable specification language that offers, through appropriate notations and abstractions, expressive power focused on, and usually restricted to, a particular problem domain.

(taken from

I'll just cut to the chase:  I use an appropriate DSL (which is sometimes custom for an application) that I either compile directly into Java byte code or first translate into Java and then compile.

21  Java Game APIs & Engines / Tools Discussion / Re: Scripting languages on: 2004-03-20 13:46:37
What scripting language do you use in your games?

That's an easy one:  Java

Why would I introduce an interpreted language on top of an already interpreted language?
22  Java Game APIs & Engines / OpenGL Development /  Re: To LWGL or not to LWGL? That's the ques on: 2003-11-27 15:57:03
Three cheers for Cas!  Hip hip Horray! .... (you get the idea  Smiley).

The main reason that this makes me so happy is that we can finally make decisions based on a set of goals rather than pulling them out of our butts.  This ensures that RFE's (request for enhancements) are accepted and rated based on a set of guidelines.

The only other thing that I'm waiting for are performance and size metrics.  That will cut out all of the unbased claims of "we can't do that because it will bloat the library" or "that will hurt performance".

Cas has been modded up a few points! Cheesy
23  Java Game APIs & Engines / OpenGL Development / Re: To LWGL or not to LWGL? That's the question on: 2003-11-22 20:58:54
I don't want to side-track more interesting points with this so I'll simply say that unchecked exceptions (be it NPE's or OpenGLException's) are a developers worst nightmare and anything that you can do to eliminate them should be persued.  Unchecked exceptions serve only to bite developers in the ass when their code goes into production.
24  Java Game APIs & Engines / OpenGL Development / Re: To LWGL or not to LWGL? That's the question on: 2003-11-22 19:29:15
The library _does_ check for nonexistent function pointers, so the GLCaps check is not strictly nescessary, as your application will bomb out with an exception if the function pointer is NULL

This is exactly what I'm referring to. Why force the developer to make the call to GLCaps? Shouldn't the library be the one that's concerned about not throwing NPE's like they're going out of style? Having the library log some sane message is better than an NPE any day of the week!

However, _not_ checking your (required) extensions before using them is not good OpenGL practice anyway, so I can't see why the extra GLCaps checks (they only need to be done once per extension at startup mind you) can be avoided in a wellbehaving application.

Developer correct / sane / defensive coding procedures weren't in question and of course the developer should check the available extensions before using them.  The root of what is in question is the need for the call.  So let's look at this the other way, if the library didn't throw on an unavailable extension and instead logged the error what would the developer lose?

In response to your threads topic, I most certainly agree that calling GL from multiple threads is a recipe for disaster.  Just to be clear, Cas was implying that you dump all threads (with some networking footnote) and that's what I'm calling into question.  Threads can be a "good thing" if used appropriately and the link I provided shows how this may be possible.  I just want to get the word out that threads aren't as bad as everyone thinks they are.  Add to that the fact that multi-core processors will be quite common in the near future.  Unless we start to get over our "threads are evil" hangups now, we're going to have a lot of idle processor time out there Smiley
25  Java Game APIs & Engines / OpenGL Development / Re: To LWGL or not to LWGL? That's the question on: 2003-11-22 17:06:14
Of course you can wrap the code that I presented but the point is that the code has to be written, debugged and maintained.  Instead of debugging and maintaining three lines of code, I'm dealing with six which are intrinsicly more complex.

And the way that I do it is found under Simulation Common at:

and essentially goes:

final Texture2DFactory texture2DFactory = new Texture2DFactoryImpl();
final Texture2D someTexture = texture2DFactory.createTexture(<some URL>);

So  Grin to you too!   Smiley
26  Java Game APIs & Engines / OpenGL Development / Re: To LWGL or not to LWGL? That's the question on: 2003-11-22 15:24:01
I mean no malice. I figued that I should present the opposing view to Cas' statements so that we understand the implications of the "pros" (i.e. a "pro" can actually be a "con").

1.  Using statics (which I'm not against in the GL layer BTW) allows any class to insert GL calls onto the stack at any point.  You cannot prevent an arbitrary class from calling into GL.  This throws "defensive coding" out the window.
 Boo hoo! to all of those that can't pass a simple reference around!  That "annoyance" provides you with the knowledge of exactly what classes can access GL.  This simplifies debugging and maintenance.
 Think of it like the American HIPPA standing (it's a medical privacy law).  HIPPA doesn't care about "who accessed the data", it cares about "who had the ability to access the data".  The difference is subtle but very important.

2.  Threads are not bad.  We all need to get out of this mindset.  Just because most people seriously fubar threads does not mean that we should eradicate them.  Since I don't want to waste space I will refer you to:

where you can get a taste of why you want threads.  (No, this isn't a product plug.)

3.  Removing the ability for a developer to make a simple (read: less error prone) call to set or retrieve a GL value via an array is just bad mojo.  See the example below:

With arrays:
        final int[] textureIdentifier = new int[1];
        gl.glGenTextures(1, textureIdentifier);
        gl.glBindTexture(GL.GL_TEXTURE_2D, textureIdentifier[0]);

Without arrays:
        final ByteBuffer buffer = ByteBuffer.allocateDirect(4 /*sizeof(int)*/);
        buffer.order(ByteOrder.nativeOrder()); // pedantic
        final IntBuffer textureIdentifier = buffer.asIntBuffer();
        final int textureId = textureIdentifier.get();
        GL.glBindTexture(GL.GL_TEXTURE_2D, textureId);

Don't forget to call rewind() between retrievals of the value from textureIdentifier.  Oh!  And be prepared for cryptic VM crashes and core dumps.  

I should point out that glGenTextures is even worse than I'm making it out to be:  there's no number parameter.  After scouring the code (as this function has no javadoc) I determined that:
nglGenTextures(textures.remaining(), textures, textures.position())

This means that if I wish to use a shared buffer of size n when I only want m textures, I need to explicitly set the position and limit of the buffer before I can make the call, so add two more calls to the already bloated code.

The bottom line is that more lines of code = larger possibility for bugs.  The second bottom line is that you're making the trade-reability-for-performance decision for me.  The developer should be provided with the ability to make that decision.

4.  "GLCaps"?  "GLCapabilities" too long to type?   Smiley  Seriously now folks, why doesn't the library protect me from making a call to an unavailable extension?  More code = more bugs.

5.  The debugging is done in a separate dll?  Oye!  The developer does not have the ability to choose at runtime nor selectively choose which set of GL functions they want debugged.  Why isn't this done in the Java layer where more control can be handed to the developer?

Now with all of this said, I stand behind the LWJGL effort 100% and I recommend it to everyone that I talk to. Those guys are doing a great job. They're handing bug reports very quickly. There are no production bugs that I have ever run into that have ever stopped me from coding.

If you're going to write a standalone game, use LWJGL.
27  Java Game APIs & Engines / OpenGL Development / Re: LWJGL support for Simulation Container on: 2003-11-22 14:14:14
Sure!  Just like code reuse through inheritance.  NOT!

I'm not picking on your directly Cas.  This is just a general gripe of mine.  Too often I see code that was written for convenience rather than taking the extra minute or so to think it through and do it right.  And you know what's funny about it?  Nine times out of ten, the shortcut requires more time to maintain and is more error prone.

28  Java Game APIs & Engines / OpenGL Development / Re: LWJGL support for Simulation Container on: 2003-11-21 17:11:54
Hey Cas!

Now if we can only get you away from using static members everywhere ....  Smiley

But seriously now folks, I would have thought that Cas would have freaked out when he saw what I did to his baby -- embedding it in another app w/o window decorations and allowing the window to be resizable and all of that.  Pure sacrilege I tells ya!
29  Java Game APIs & Engines / OpenGL Development / Re: LWJGL support for Simulation Container on: 2003-11-21 03:45:04
Demos are forthcoming.  It has always been out intention to make the source for the QuakeWorld clone available.  We're cleaning it up and making it follow the Simlet paradigm (it was a proof of concept so it differs a bit from the final Simlet definition).

Simlets are not specific to OpenGL.  I come from the enterprise software space.  The last enterprise proudct that I worked on was a real-time trading platform.  If I had to write the app again today, I would use Simlets.  This is just a very long winded way of saying that you can use Simlets for essentially anything were a unit of processing is the core component.

How does a common interface bring structure?  The same way that Servlets bring structure to web apps.  The same way that java.lang.Object bring structure to the whole Java class hierarchy.

I'm going to say flat out that most game developers are not going to "get it".  Most game developers see interfaces as a nuisance.  Inheritance for most people is a technique for code sharing / reuse and the phrase "is-a" is left forgotten in the corner.  But to everyone out there I say:  until we start coming to a common ground and using and defining standard ways of approaching these problems we're never going to have the traction we need for game development to be as common place as, say, Servlets and instead we're going to reinvent the wheel over and over.
30  Java Game APIs & Engines / OpenGL Development / LWJGL support for Simulation Container on: 2003-11-21 02:22:52
To demonstrate the flexibility of Simlets and the Simulation Container we have added LWJGL support.  This was done to show that Simlets are not tied to any one platform or GL toolkit. Check it out at:

What are Simlets?  Simlets are a modular and reusable approach to simulation (e.g. game) development. They are a bunch of classes and interfaces that define a way to approach and code simulations. Check out the Simlet javadoc at

Why do we need Simlets?  The reusability of components between games is nearly zero. Everyone and their brother are creating a game engine or their own game from scratch. This makes for hundreds of islands of code with no way to leverage the effort from one to build another. We need a way to allow game components to be shared. Enter Simlets.

Another way to look at this is to use history. Before Servlets and J2EE came about, everyone had their own way to code Java for the web. Everyone was starting from scratch and trying to build up momentum. Enter Servlets. Now everyone has a common way to talk with and about web content. You can find a servlet out there to do basically anything and you know how it works since it follows a certain pattern. Add to this the fact that people can now use energy to build toolkits on top of Servlets rather than just getting enough momentum going to write out a basic web page. Games need this type of leveler so that all the developers are playing on the same field and are talking the same language.

What do I do with a Simlet? Simlets are just a different way to think about what you're already doing. They do not impose a particular toolkit on you as a game engine would. They simply provide a common way to express a game component.

What do I get if I use Simlets? As was mentioned above, Simlets provide a common way to express a game component. As more and more people start to use Simlets and make their software available then it becomes easier and easier for people to simply pick up a component and use it in a different game. So what do you get? You begin to fulfill one of the promises that Java was to deliver:  reusability.

Give some examples of how to use Simlets in my game. I will use our QuakeWorld technology preview as an example as that is what we used to help define Simlets.

  • Console:  The console is designed as Simlets. One Simlet accepts input messages (keyboard key presses) and translates them into commands or stores them for display. Another Simlet renders the Console view.
  • Command and Variable processing: A Simlet accepts command messages from the console and network and processes them into actions.
  • Rendering: This is broken down into entity, world, particle, lighting, etc renders each as a Simlet. Just as in the tutorials provided on our site demonstrate the MVC paradigm with Simlets, the QuakeWorld clone uses MVC to achieve a very flexible architecture that supports plug-in renderers.
  • Sound: A Simlet accepts messages from the network and entities and "renders" them as sound.
  • Network: A Simlet encapsulates the sending and receiving of network packets.

Where does the Simulation Container fit into this? The Simulation Container provides a place for Simlets to live. Just as Servlets live within a webserver (so to speak), Simlets live within a Simulation Container (SC). The SC allows for individual stages (either a Simlet or a pipeline) to be reloaded on demand. This greatly simplifies and speeds up game development. How many times have you coded, compiled, built, launched, and tested your game? Imagine if you could cut out the launch part. Just code and compile and refresh the SC and it will load any changed Simlets leaving all others unchanged. No more waiting for the JVM to start. No more waiting for the content or objects to load. No more spending time to advance in the game to a point to begin testing.  Pure development bliss!

Do I need the Simulation Container to use Simlets? No. Simlets are just Java classes. You can build your own Simlet container (without the deployment descriptor processing) in about 100 lines of code but it will not have the ability to dynamically reload Simlets and all of the other juicy tidbits that we added into the Simulation Container.

But it doesn't support blah platform! Simlets are POJO (plain ordinary Java objects). The Simulation Container itself is 100% pure Java except that it uses SWT for the UI. In theory (and we're going to begin other platform testing shortly) you swap the SWT jar and libs out and it works another platform. Platform dependencies in the simulation common libraries are pretty well outlined in the code so you should be able to port them to whatever platform you want.

What's the catch? No catch. Simlets are GPL (and will most likely go to BSD). The Simulation Container is free for non-commercial use. Grab the Simlet jar and javadoc and start coding your games in a way that will allow others to leverage your work!

This is a forum so let's start getting some talking going!
Pages: [1] 2 3
ivj94 (585 views)
2018-03-24 14:47:39

ivj94 (49 views)
2018-03-24 14:46:31

ivj94 (383 views)
2018-03-24 14:43:53

Solater (63 views)
2018-03-17 05:04:08

nelsongames (109 views)
2018-03-05 17:56:34

Gornova (159 views)
2018-03-02 22:15:33

buddyBro (703 views)
2018-02-28 16:59:18

buddyBro (92 views)
2018-02-28 16:45:17

xxMrPHDxx (494 views)
2017-12-31 17:17:51

xxMrPHDxx (734 views)
2017-12-31 17:15:51
Java Gaming Resources
by philfrei
2017-12-05 19:38:37

Java Gaming Resources
by philfrei
2017-12-05 19:37:39

Java Gaming Resources
by philfrei
2017-12-05 19:36:10

Java Gaming Resources
by philfrei
2017-12-05 19:33:10

List of Learning Resources
by elect
2017-03-13 14:05:44

List of Learning Resources
by elect
2017-03-13 14:04:45

SF/X Libraries
by philfrei
2017-03-02 08:45:19

SF/X Libraries
by philfrei
2017-03-02 08:44:05 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‑
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!