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 timer.zip 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...

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;

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.

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.

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)

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.

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.

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

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.

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.

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.

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.

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.

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.

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:

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.

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 http://astronomy.swin.edu.au/~pbourke/dataformats/tga/. 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.

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

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.

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?

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.

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.

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.

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