Hi !
Featured games (91)
games approved by the League of Dukes
Games in Showcase (757)
Games in Android Showcase (229)
games submitted by our members
Games in WIP (844)
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
1  Java Game APIs & Engines / Java 2D / Re: the ticks inside a timer loop on: 2003-08-03 23:31:59

1. Do *not* call System.loadLibrary. The timer calls it on its own. A second call will merely result in an exception.
2. Make sure that timer.dll is either in the same directory as you are running the code from, or that it's in the system PATH (e.g. c:\winnt\system32)

If you look above I only put it in their for a quick test. after that didn't fix it I removed it and looked at the java classes that came with timer and saw that it was loaded in nativeTimer. But it didn't throw any new errors including it in there a 2nd time.

Also I've got the timer.dll is in my program directory and I still get the error- I've pretty much put the timer.dll everywhere possible after this didn't work-still nothing. Only thing I can think of is maybe the jar file is older then the .dll and something was changed recently in the timer .dll? I didn't get the jar file with the latest download of the but found it somewhere else. If this isn't the problem I'm seeing no other reason why it shouldn't be working. jar file is being imported and dll is being loaded...
2  Java Game APIs & Engines / Java 2D / Re: the ticks inside a timer loop on: 2003-08-01 15:28:06
Ok good point, but still having problems with the same error, when I just import that timer.jar file.

I can compile and I don't throw an error when it loads in the dll, I have access to all the timer classes but still when running I get the unsatisfied link error: getResolution when asking for the GAME_TIMER.getTicksPerSecond()/60;

Any suggestions?

3  Java Game APIs & Engines / Java 2D / Re: the ticks inside a timer loop on: 2003-08-01 04:42:02
I'm checking out the gage timer for our game and I get a unsatisfied link error: getResolution

I'm calling System.loadLibrary("timer"); before hand and I get no error with this call so it is loading the timer.dll-I know I don't have to do this because its done inside the WindowsTimer class, its there just for testing.

I'm also compiling the AdvanceTimer, NativeTimer and WindowsTimer java files with my own files so I don't have to import anything. I changed the Package to my package name as well, everything compiles fine, just getting the runtime error.

4  Games Center / Archived Projects / Re: So.. who's here who's actually going professio on: 2003-07-31 18:36:11
Well I'm about in the same bout as cas (so your not entirely alone). I'm working pretty much fulltime developing our java based game but do odd jobs for cash when needed. Our game was supposed to be demo'ed at the JavaOne conference this year and I was suppose to participate in a round table discussion but finance problems and conflict with a release of our last beta round prevented it.

Our game is pretty much geared as a web based, strategy/war simulation killer.  If you have ever played games like Utopia, once we get our game released there will be no reason why anyone would want to play webbased strat games again. Everything is graphical based in our game and our server bandwidth problems are greatly reduced with our model vs web based games (means more players can play on each server).  Not to mention our game includes a rts battle engine (ala warcraft 2 style) where your army can battle any other player in the world, and are starting to work on a jogl port.

I seriously hope that sometime within the next 6 months(planned game release) we will start making a lot more money. I think we have a good business strategy (ad revenue and subscriptions) and we are already producing revenue though we haven't started selling subscriptions to our MMOG.  We actually need one more beta round (2 months) before we will release our game.

Those who play our game (about 150 active players so far) really enjoy it but we have the problem that the game becomes a ton more fun if we had 1500 players (new realms open up, not always battling the same kingdoms/players).  Because of this issue we are growing slowly because we are only gaining a few more players then we lose each week. So some type of production release would really help our game.

btw you can check out our game at
5  Java Game APIs & Engines / Java 2D / Re: isometric map question on: 2003-07-31 17:55:28
Its best to keep the map file as small as possible because these files, if not designed and managed correctly can get huge.

One way to do this is to have a header section where you read in all of your info about the map.  width/height, tile names (if you wish), etc..

After you do this then you should read in each layer one after the other. For example our maps have layers for tiles, objects, units. All this contains info about where units can walk and such using positive numbers for tile/object/unit ids and negative numbers telling us movement areas that are blocked with that tile/object/unit (the negative number will match the id's by simply negating it.

we store this info as byte for tiles, objects and units (128 unique ids/with negation). so we have a greatly compressed file with just that. But this isn't enough because each layer you add increases your file size by 1/layers.

So we use a simple compression algorithm as follows:

if(readValue == 0)
 skipbytes(nextReadValue() );

when you are saving your file and come across a grouping of 0's then then just write out the first 0 and write out how many zeros follow.

Since with units and objects your map will have a ton of zeros in it then this compression will reduce your file size exponentially.

You will end up with huge maps saved on disk in 10-80k vs 2+ mbs (from my personal experience)
6  Java Game APIs & Engines / JOGL Development / Re: java.lang.UnsatisfiedLinkError: gluPerspective on: 2003-07-29 03:43:48
Ok I fix the problem by checking out where java.library.path is pointing. My library path appears to have been modified from my sdk1.4.2 to a jre1.4.2 that I recently installed.

Thanx for the responses hope this helps others who might end up installing a new sdk or jre and forget to move the jogl jars/dll's to the new path.
7  Java Game APIs & Engines / JOGL Development / java.lang.UnsatisfiedLinkError: gluPerspective on: 2003-07-28 19:39:16
I started getting this error after I installed the lastest release of jogl's libraries, but I've reverted back to the previous release and I get the same error as well so I'm not sure what the problem is.

Basically it is telling me that the glu native methods have not been loaded, which is strange because this code was working before just fine.
8  Java Game APIs & Engines / Java 2D / Re: Thanks Kevin, look what you did ;) on: 2003-07-23 01:27:32
Its very fast if you are using acclerated images with alpha transparency accelerated.

Just create a black image the size of your screen. Start the image at full alpha (painted over the top of your current drawing surface), fade to no alpha(at desired speed). Strop drawing old image and start drawing new background. Fade back to full alpha and discard black image until you need it again. takes no time to create this image and with 1024x768 will take 4mb of ram so I just destroy it and recreate it when needed.
9  Java Game APIs & Engines / Java 2D / Re: Iso tile size quesion on: 2003-07-23 01:20:49
150x75 will blit faster then 32x64. upto about 250x250 is optimal after going over that size I don't notice much speed improvement and actually starts to slow down a bit. This is from my experience with 1.4.1 not sure if anything has changed with 1.4.2
10  Java Game APIs & Engines / Java 2D / Re: 2D Glowing Effects on: 2003-07-21 14:19:41
Well ya but you could have planets or stars in the background and you lose nothing with alpha blended images using directdraw (windows anyway).

Kryto the alpha blending works great for magic effects and actually saves you video memory because you have fewer images loaded into memory and it looks a ton better.
11  Java Game APIs & Engines / Java 2D / Re: 2D Glowing Effects on: 2003-07-21 00:50:39
He might be using a color background in the future and its really best to take advantage of translucent images that won't slow your game down.

System.setProperty("sun.java2d.translaccel", "true");
System.setProperty("sun.java2d.ddforcevram", "true");

This allows you to create translucent effects on the fly. I'd start by adding a ALPHA variable to for each of your effects that can be dynamically changed based on the current effect state.

Then in your drawing do something like:
g.setComposite(AlphaComposite.getInstance(AlphaComposite.SRC_OVER, SHIELD_ALPHA));
                 g.setComposite(AlphaComposite.getInstance(AlphaComposite.SRC_OVER, 1.0f));

then modify SHIELD_ALPHA based upon the glowing effect your after.

You will need at least java1.4.03 or greater to enable accelerated transparancy.
12  Java Game APIs & Engines / Java 2D / Re: some 2d scaling and mapping to relative co-ord on: 2003-07-21 00:36:14
There is no reason why you have to have more then one image of each piece included with your game.

Simply create a new image after the player releases the piece based off a scaled version of your original piece. I'd keep 2 images of each piece in memory though so you are using the original piece as you create a new scaled image or your image will start looking pretty crappy after a few moves.

something like:
Image scaledPiece[piece] = graphicsConfig.createCompatableImage(scaledwidth, scaledHeight, Transparancy.OPAQUE); //or use translucent if you are have dirtect draw features enabled for alpha acceleration
Graphics2D g = (Graphics2D) scaledPiece[piece].getGraphics();

//Something like this, been awhile or scale with other drawing primitives
g.drawImage(originalPiece[piece], x,y, scaledWidth, scaledHeight, 0,0,originalwidth, originalHeight);


your scaledPiece's are what you always draw to the screen buffer and originalPieces are only used for scaling
13  Java Game APIs & Engines / Java 2D / Re: some 2d scaling and mapping to relative co-ord on: 2003-07-20 13:32:58
Really depends if you are using smooth sliding or if you just need to scale piece once at destination. If you are doing the later I would load in all pieces and save them as reference images and apply scaling to image after you move it and save the scaled version as a new image. That way you are only producing one extra image for each piece and won't notice any speed hits.

For smooth sliding you can probably do it on the fly and save the new image after you arrive at your desitnation and since its only the one piece that you need to scale it shouldn't hurt performace much.

For your polygon grids.. you just need to create a chessboard class that holds all the positions and set it up so you know the center point for each grid (can be precomputed based on the plane/slant of your board). Then just create vectors for movement for a piece between the two board points and draw your piece movement along this vector.
14  Java Game APIs & Engines / JOGL Development / Re: bmp loader on: 2003-07-20 13:14:54
If I need to put my jpeg compression down to about 8 or my gif color table down to 64 or 128 colors, sacrificing quality I get a lot smaller file sizes then zipping TGA or png files. About 1/4 of the file size for jpegs without sacrificing much in quality.

There are instances where it would be useful to load in textures in the format that I origionally saved them in because that already yielded the best quality/size ratio I could get.

Looking forward to your loader with any image type.

15  Java Game APIs & Engines / JOGL Development / Re: bmp loader on: 2003-07-20 02:03:56
TGA images are nice but lets also remember that many java games for the forseeable future will be dowloaded not purchased on a cd. If you were to create any type of large scaled 3d game these textures alone would probably require over 100mbs. Not acceptable for a downloaded game when you also have to add into that the code, sounds, data files, map/lvl files, model files etc...

With this in mind its important to be able to load jpegs and for textures with an alpha component to be able to use gif.

16  Java Game APIs & Engines / JOGL Development / Re: jogl vs. lwjgl speed test on: 2003-07-16 18:31:10
I only develop for windows initially so I don't know about linux.  After I have a windows version any code that needs porting i.e. our exe (autoudates, checks jvm version sets paths ecodes all java files, etc..) and our actually game code will be ported at that time.

So if this doesn't work under linux that is good to know but it isn't a very big concern for those working with this under windows which IMO is probably the vast majority of developers.
17  Java Game APIs & Engines / JOGL Development / Re: jogl vs. lwjgl speed test on: 2003-07-16 16:09:11
Maybe I'm missing something here but in the Threaded example I only need access to the GLDrawable to load in the textures.

If this is threaded why can I load textures in a seperate thread and set an animator to start the openGl rendering and only break into my progressbar rendering as textures are being loaded?
18  Java Game APIs & Engines / JOGL Development / Re: jogl vs. lwjgl speed test on: 2003-07-16 12:31:29
um, ok your right pass in GLDrawable to the threaded loader and there you go.
19  Java Game APIs & Engines / JOGL Development / Re: TGAImage on: 2003-07-16 03:54:51
Just to address the Texture issue, you can load any texture format that is supported by Java's new ImageIO utilities. For more information on ImageIO see:

Within a couple of days I'll post up a class called ImageLoader that will handle most of the common formats as OpenGL Textures.

That would be great. Loading the image into a bufferedImage is not a problem the problem lies in creating the openGl bindings for the texture. I create JVM errors in native code when trying to bind the texture to external GL_RGB and I don't produce errors when using external format of GL_RBG8 but I get no texture displayed.

gl.glBindTexture(GL.GL_TEXTURE_2D, texture[0]);

InternalFormat is GL_RGBA8 or GL_RGB8 for gifs and 'dest' is a ByteBuffer
20  Java Game APIs & Engines / JOGL Development / Re: jogl vs. lwjgl speed test on: 2003-07-16 03:13:50
Not in the rendering loop, no. But you can't for example have a method like this in Jogl:

public void init()
   for (int i=0; i<texturesToLoad(); i++)

That is why with jogl you would use another thread for resource loading and thus have the same effect as others have stated as a good idea.

public void init(GLDrawable drawable) 
    loadTextures = new TextureLoader();
public void display(GLDrawable drawable)

21  Java Game APIs & Engines / JOGL Development / Re: TGAImage on: 2003-07-07 18:55:52
Thanks for the info, I've added the code for loading different types of images but I'm now stuck with how to get the BufferedImage.TYPE_BYTE_INDEXED (for gifs) converted properly. In the case I've added:

case BufferedImage.TYPE_BYTE_INDEXED:
                       byte[] data = ((DataBufferByte) img.getRaster().getDataBuffer()).getData();
                       dest = ByteBuffer.allocateDirect(data.length);
                       dest.put(data, 0, data.length);

if I ask it to load a .gif it breaks into the BufferedImage.TYPE_BYTE_INDEXED and stores the pixel data in the ByteBuffer I then create the texture with:

gl.glTexImage2D(GL.GL_TEXTURE_2D, 0,  3,  img.getWidth(),  img.getWidth(), 0,  GL.GL_RGB8,  GL.GL_UNSIGNED_BYTE,  dest);

I got it to load without causing a native exception but It doesn't display the texture.
22  Java Game APIs & Engines / Java 2D / Re: 2D Image Transform on: 2003-07-06 18:59:26
It has been my experience that any transformation done to images at runtime would require the image to be copied from vram to system memory, perform the calcualtions and then hopefully get accelerated again sometime in the near future (assuming managed image in the first place).

I have no personal experience with PerspectiveTransformations and little with the JAI api so if that is able to do this trick in vram I'd be interested in hearing more about it.

A hack that I've come up with for arcade type shooter is to simply pre-transform the images and store the different sizes in and image array that is index by distance. Not perfect solution I know as your memory will start bloating quickly the more accurate you make the perspective calculations and the more images you have.
23  Java Game APIs & Engines / JOGL Development / Re: TGAImage on: 2003-07-06 18:46:34
I'd have to build the tga Image on the fly rather then preconvert the images as that program does. I've actually found the TGA header info and image data at It's my understanding that TGA images have to be 32 bit (uncompressed) for them to work with the jogl TGA class loader.

Only problem is that the TGAImage class only takes in a filename at this point. So I'd have to write the conversion back to disk as a TGA image then reload it producing unexceptable startup times.

I'll move on to building the engine loading the TGA textures and hope a better solution shows itself in the near future.
24  Java Game APIs & Engines / JOGL Development / Re: TGAImage on: 2003-07-06 07:08:55
Only problem with using TGA that I can see is when you have 30 different unit images with 300-400 frames of animation each and you have 2d sprites of these (high poly) already rendered out and the file size of the TGA images are 10-20mb each compared with their gif file sizes of 400-800kb each. Our program is downloaded and I don't think people would appreciate us going from 33mb to a 300mb download size Shocked

No doubt I'd have to drop some frames but even still the download would be at least a 4x increase in size just for unit images, not to mention buildings, terrain and terrain objects.

So I will have to write my own gif-to-TGA file format conversion class. Has anyone already done this who could share their code? Or at least provide a link for the TGA format, after a few searches on this I've come up empty. If one of the developers could comment about the possibility of future support in this area I'd shelf my plans in this area and wait for a Sun solution.
25  Java Game APIs & Engines / JOGL Development / TGAImage on: 2003-07-05 17:37:14
Is this the only Image option for loading textures currently available for jogl? If so when will there be support for other image options, like the Texture class that lwgl uses?

I'm only asking because I am interested in porting our 2d rts game engine over to jogl. We already have all of our 2d images sprite rendered so I am looking at building a 3d engine that simply displays the unit sprites as images on a transparent Rect.  So all unit Rects would always be facing the user and depending on their move direction/camera angle I'd simply change the Rect with a different unit facing (ala Myth 1/2).

I've never used TGA images but I'm guessing that they only have opaque support. Any tips available?

26  Java Game APIs & Engines / JOGL Development / Re: jogl fps lock on: 2003-07-05 17:24:28
keeping CPU usage down is always a good thing if you want to increase stablity on all systems. I've notice on one of my systems that I will lockup occassionally playing games or doing cpu intensive stuff that run at full cpu usage for prolong periods of times. Its my guess that I lock up because of the extra heat that my cpu/video card is producing.

IMO I'm thinking a frame lock might not be a bad idea since I'm sure it would have much tighter accuracy then me placing a sleep in my code. I know gage has a more accurate timer and a native timer could be used but we are talking about a Java 3d gaming API and ease of use/robustness of its current framework should be one of its aims.

Just a though,
27  Java Game APIs & Engines / Java 2D / Re: Drawing lots of shapes at once (in a JPanel)? on: 2003-07-03 03:04:39
Yes having a graph image that you simply update and display to the screen is the best route.

Something like:

private void resetPoints()
//gc (Graphics Configuration)
Image tempGraph = gc.createCompatibleImage(Width, Height, Transparency.BITMASK);
Graphics2D g = (Graphics2D)graph.getGraphics();
drawGraph(g); //this is where you will draw your cirles/lines and any background art to this image
graphImg = tempGraph;

Then simply render your graphImg in your repaint and when you need to add more points call this method again.
28  Java Game APIs & Engines / Java 2D / Re: should I use Panels or not? on: 2003-07-02 05:19:42
There is no reason to add awt/swing buttons to your game. Most games will want to turn the awt repainting off anyway for improved rendering, using your own buffers or the bufferstrategy.

Simply create your own button class that takes an image file and coordinates (rect) and give it basic button functionality like contains(x,y), and draw(g).

For even better effects pass in a mouseclick image and add mouseover effects as well as unique sound depending on the button type when clicked.

If you are going to be using a lot of your own custom buttons you should create a button manager that holds all the currently active buttons that have focus for easier mouse event testing.
29  Java Game APIs & Engines / Java 2D / Re: Aplha and Performance on: 2003-07-02 04:56:40
I've been using it for the last month or two and works great on 1.4.2 but doesn't doesn't produced accelerated images with 1.4.1 (not sure about exact version) even though it was said to be working on even earlier verisons. Something must of been changed in 1.4.2 and that is why they finally felt comfortable to give us the extentions for enabling it.
30  Java Game APIs & Engines / JOGL Development / Re: Jogl & Swing on: 2003-07-01 05:39:03
btw where are the docs for JOGL? I'm playing around with it and have added it to a JFrame with some mix results.

1) I notice some skips in the rendering where my 2d frame buffer shows for a split second every now and then. (the rendering loop for the 2d buffer is turned off when I switch over to the glCanvas).

2) I'm also having trouble closing down the glCanvas. I'm calling dispose on it and trying to switch back to my 2d rendering pipe with not much luck.  It appears the canvas is being disposed but setting focus back to my JFrame and starting the 2d rendering loop back up isn't doing the trick.

Also should I remove my mouse listeners and keyboards listeners from my original Jframe? and reset them after I dipose of the glcanvas. It works without doing this so I'm wondering if it is a good idea or not.
Pages: [1] 2
EgonOlsen (74 views)
2018-06-10 19:43:48

EgonOlsen (55 views)
2018-06-10 19:43:44

EgonOlsen (74 views)
2018-06-10 19:43:20

DesertCoockie (254 views)
2018-05-13 18:23:11

nelsongames (154 views)
2018-04-24 18:15:36

nelsongames (154 views)
2018-04-24 18:14:32

ivj94 (895 views)
2018-03-24 14:47:39

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

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

Solater (172 views)
2018-03-17 05:04:08
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!