Hi !
Featured games (84)
games approved by the League of Dukes
Games in Showcase (604)
Games in Android Showcase (171)
games submitted by our members
Games in WIP (654)
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 3D / Re: SGS on: 2006-04-01 00:29:25
Therefor, ona sever, you can not use the vecmath operations and Transform3D (we do this in the
BattleTrolls demo) but you **cannot** use the scenegraph unless you knwo you wil lbe deploying on servers with X11 and a graphics screen,

On linux  you can use Xvnc which mimics the graphics card and everything works great. I did this on a production game server and never had any problems (once I got it configured). This was quite a while ago. Before Xvnc and on Sun I used to start XWindows from the rc scripts and have the xhosts + command in the .dtrc (I think it was .dtrc) file. This also worked great, but is not recommended unless you are behind a properly configured firewall. There always seemed to be security issues with X and Tooltalk.

Xvnc is typically part of the default X11 install so it should already be installed.

2  Java Game APIs & Engines / Java 3D / Re: How to manage Pitch, Roll and Yaw for a "first-person-shooter-view" ? on: 2006-03-29 23:11:49
I'm teaching a class on gaming at Chapman University and I'm not sure what you are asking, but it sounds similar to a problem one of my student's was having.

Basically you have to base the yaw, pitch and roll movement on your current orientation. For pitch, you take a vector along the x axis (1,0,0) and transform it with the current orientation transformation matrix (t3dYPR). Use that to create an AxisAngle (basically a type of quaternion) with a rotation in the direction you want (forward or backward pitch) and use that to create another transformation. Then multiply your orientation transformation (t3dYPR) by that transformation and that adds the pitch.

You can download the complete code here:

    if (keyPitchDown)
      // create a vector in the x direction

      // rotate that vector into the current orientation
      // create axis to rotate around that x axis in our orientation coordinate space
      // set a temporary transform
      // multiply the current view by that rotation

I hope that helps,


3  Java Game APIs & Engines / J2ME / Re: Form Clearing and List Implementations? on: 2005-04-11 20:35:08
This is the code I use when I create a new or repopulate an existing form.

    if (validationForm==null)
      // validation failed
      validationForm = new Form("Validation");
      // clear out the current menu
      while (validationForm.size()>0)
4  Java Game APIs & Engines / J2ME / Re: Images in MIDP 1.0 on: 2005-03-30 20:59:44
You had it in the earlier code sample, but make sure you have a / in front of your file names. That one bit me once.


You can also dump the contents of your jar to make sure it does have the file in it. You never know.

jar -tvf yourfile.jar

5  Java Game APIs & Engines / J2ME / Re: my appln with tiledlayer is too slow in nokia6 on: 2005-03-18 16:53:20
I'm just saying that TileLayer might be part (or most) of the problem with performance. You may have to implement your own TiledLayer so you  have more visibility into the actual problem.

In general you should expect significant slow down between the emulator and the actual device. The trick is to make your code do as little as possible to get the job done.

6  Java Game APIs & Engines / J2ME / Re: Fadingin in and out on: 2005-03-15 20:01:44
How about using setClip to only draw small 2x2pixel or 4x4 pixel sections of the image in random order over a specific amount of time into an offscreen bitmap. Keep track of which ones have been drawn so far and then over time the complete image will appear to fade in.

7  Java Game APIs & Engines / J2ME / Re: my appln with tiledlayer is too slow in nokia6 on: 2005-03-15 19:57:17
I use my own Tile system and have done a ton of work to only draw the tiles that change and I only redraw offscreen maps on tile boundaries. It's quite complex, but I can run it on very low power phones and it tends to work pretty well. If you are redrawing all the tiles on the screen (or the whole map for that matter!) it just isn't going to perform well on a phone. I'm not sure what the internal implementation looks like for the TileMap class, but I'm sure your mileage is going to vary between vendors.

8  Java Game APIs & Engines / J2ME / Re: Design woes: Inheritance or Interfaces? on: 2005-03-15 19:53:48
I'll probably get beat up for this, but my games have three or four classes.

A main class which contains all the data, typically static.
A canvas class.
A menu class (because List sucks).

I keep all of my data in arrays and allocate it up front. On lower power phones memory is very limited and you don't want to be creating and droping objects all over the place.

I always have a tick thread attached to the canvas class. This is for animation.

On games with a networking componenet, I put another thread on the main class which handles the networking.

On a game that had to share data between two different midlets, I did create a data class so I could share the data code between the two midlets.

Those are my simple rules for keeping size down.

9  Java Game APIs & Engines / J2ME / Re: Strange Sprite Animation on: 2005-03-15 19:47:44
Looks like I missed that as well.

The doDraw3(g) should be in your paint method. If this is using the 3d apis, it may be different. I've not used them, so someone else will have to chime in.  If it's just a regular midlet, then put the doDraw3 in the paint method.

You may want to call serviceRepaints() after the repaint() method. This should (it has problems on some phones) wait at that point until the screen gets refreshed. I use it in all my games and have used wait()/notify() on phones that it doesn't work on.

10  Java Game APIs & Engines / J2ME / Re: Strange Sprite Animation on: 2005-03-10 19:54:36
You are changing randInt every tick and using that to choose which image to display.

You need to separate randInt from the current Y location and only change the randInt and the beginning of the process when the image reaches the bottom and starts again from the top.

public void run()
  long st=0;
  long et =0;  
  st = System.currentTimeMillis();

  if (y==bottom)
    // the current falling image has reached the bottom
    // choose a new image and reset the image location
    // to the top
    randInt = Math.abs(rand.nextInt()%2);
    y = top;
    y = y + 10;
  System.out.println("name ID = "+nameID);
  et = System.currentTimeMillis();
  if ((et-st)<rate)
  try { Thread.sleep(rate-(et-st));} catch (Exception exp) {}
11  Java Game APIs & Engines / J2ME / Re: Animation moving from top to bottom on: 2005-03-10 19:37:24
I almost wrote a sample, then went looking as ameano recommended. There are good samples that come with the sun wireless toolkit j2mewtk:

One of them is under games, called worm. The other is under demos called ManyBalls. Both of these do what you are looking for. If you want to post specific questions about the code on any of those I'm sure many around here like me would be happy to answer them.

12  Java Game APIs & Engines / J2ME / Re: Thrust and Gravity... on: 2005-03-01 16:29:22
Okay. Could you please explain how I can get my little spaceman to move more slowly around the screen whilst using a speed that is less than 1 pixel per cycle?

Using the fixed floating point math (two methods listed above), you are really only using the upper 16 bits for your current position. Shifting the number down before using it as the current position. The lower 16 bits are the fractional component. So your thrust would be less than 32000 and you add it to your position everytime through your loop. If the thrust is around 8000, your position would move by 1 pixel every four ticks.

You should also multiply your thrust by the number of milliseconds since the last tick before adding it to the position. This will allow you to base your movement on pixels per millisecond and the game will have similar performance across different platforms. Your thrust values will have to be adjusted down accordingly, but this is a very important aspect in order to make the game work better across different speed phones.

13  Java Game APIs & Engines / J2ME / Re: Thrust and Gravity... on: 2005-02-28 16:33:37
For the fixed floating point, I've used ShiftFP2D in the past and been happy with the results. It helps manage the data and makes the code a little easier, but as you can see above, it's still pretty simple to do by hand.

I'm not sure of the status on ShiftFP2D as the author said he would post it on sourceforge/ last year. here is a link to a hopefully working version.

14  Java Game APIs & Engines / J2ME / Re: midp 1.0 animation on: 2005-02-16 19:59:21
It should be noted that Samsung phones have weird issues with setClip and I have also heard (and seen) similar problems with a Sony phone.
15  Java Game APIs & Engines / J2ME / Re: midp 1.0 animation on: 2005-02-16 19:55:57
This is what I use:
  public void drawSubImage(Graphics g,Image src, int x, int y, int subx, int suby, int width, int height)
    // added the +40 here because we may be drawing to an offsceen
    // which has +1 tile and may have a partial tile each = 20

Where g is the screen/image you are drawing into. src is the image with all your animation frames. x,y are the onscreen location and subx,suby are the location within your animation frames.

16  Java Game APIs & Engines / J2ME / Re: Image loading/holding optimizations on: 2005-02-16 19:50:13
Both systems are bad and I was not trying to state what was best. I would personally like to use a precompiler as I think it is much better when you have design changes late in the process.  For long term both methods are just plain broken and subject to all sorts of human errors.

17  Java Game APIs & Engines / J2ME / Re: Image loading/holding optimizations on: 2005-02-16 13:28:19
One thing I do to limit this is limiting the use of dynamic variables. My games typically have no more than four class files and all my data is stored in arrays. I know it's arcane, but it does relieve a lot of these problems on underpowered phones.

The classes on my last game were: Main (which included a network thread), Data, Canvas (which included an animation/tick thread), and Menu.  I have my own custom menu system because the List class requires a new instance for every menu. I like having one instance and repopulating it and it uses arrays internally.

I have some instances where I have to use strings, I try to limit them as much as possible. I try to keep most strings static final, but there is always the case where you need to concatinate two strings and I typically don't use +, I create a new StringBuffer, just so I know exactly what is happening, not relying on a translation. That's typically the only dynamic allocation I allow in my games. Everything else is locked down up front.

im doing porting for about 25 phones so code splitting has already happened (though i really, really hate it)

This is actually the worst possible development scenario I could possibly imagine and I hate it too. I don't think Sun really cares though? Conditional compilation (#ifdef) would tend to make life much much easier, but that seems to be taboo to even mention. Sort of like saying the Emperor isn't wearing any cloths and Java is so portable that conditional compiliation has no place in such a perfect system.  That said, I'm sure I could build some sort of Ant system to preprocess the conditional stuff for me, but as I've said in earlier posts, I'm lazy and that sort of Ant system would require a ton of work. Especially to get it front ended on WTK which I use for my final builds. Just the thought hurts my brain.

I noticed recently that NetBeans has some sort of code splitting management system to make this easier. Seemed like a sledgehammer to drive a carpet nail that conditional compilation would easily solve.

18  Java Game APIs & Engines / J2ME / Re: midp 1.0 back-buffering on: 2005-02-15 20:39:58
i'm not sure i understood your answer ;(

Performance Enhancement 1:
If you are having performance problems, the first thing you do is start drawing offscreen and bliting the offscreen image to the screen on update. That's what you are already doing.

Performance Enhancement 2:
If you are still having problems then you have to look at where else you can cut out drawing. One of my solutions is to draw one offscreen image with another being offset in the direction the screen is moving, then only update the edges. Instead of redrawing the entire offscreen image everytime three is a change.

Performance Enhancement 3:
The next step is to keep a larger than screen set of offscreen images and offset the offscreen blit until you reach and edge, then do the redrawing of the edges in #2 above and reset the offset.

I have yet to launch a game where I have not had to do all three of these steps for at least one of the devices and now I just do all 3 for all devices as it makes the game faster on all the devices.

19  Java Game APIs & Engines / J2ME / Re: Game project due dilligence on: 2005-02-14 15:16:50

It's not the phone, it's the carrier. They often have wierd limitations/blocks on their networks.

I thought so too except that it worked on one phone and not another on the same network. The 3650 is the only phone that seems to have this issue.  I even tried it on my freebee 3595 and it worked just fine.
20  Java Game APIs & Engines / J2ME / Re: Image loading/holding optimizations on: 2005-02-14 13:23:56
I think your only choice is a different set of art for the under powered phones. Essentially a different app.  Something with smaller characters and possibly less frames per animation.

Hopefully in doing something like this you could keep a lot of the existing code, but it would still require a heavy port and a splitting of the source.

21  Java Game APIs & Engines / J2ME / Re: midp 1.0 back-buffering on: 2005-02-14 13:20:40
I have solved this by not redrawing the entire back buffer every time. I draw the front  buffer into the back buffer with the offset and then only draw the edges of the back buffer. Once I have the edges drawn, I swap front and back buffers.  This is only useful for the background, but drawing the dynamic items directly on the screen after bliting of the background has worked well for me.  My back buffers are typically 20 pixels larger than screen size and I scroll them smoothly on the screen and only update/swap the back buffer on 20 pixel boundaries.

This doesn't work on a Samsung phone I have, but I do have a work around which I posted in another topic. Otherwise, it has worked well for me on every other phone.

22  Java Game APIs & Engines / J2ME / Re: Game project due dilligence on: 2005-02-14 13:12:49
I've done it.

The simple http connections that are just periodic seem to be fairly straight forward. I was tunneling some binary data in the http stream and the only phone I have had trouble with was the Nokia 3650. It seems to only allow PNG images as binary data. The work around was to change the reply header to PNG. I have two games which make about three connections per game (2-5 minute games) and it works just fine on real phones.

I've written two separate server products for J2ME. The first I lost to a bad business partner. The second is still in development. I'm sure there are hundereds of these types of servers out there.  I created both http and socket clients and initial testing seems to have them working fairly well. I would expected anything better that 2-3 second latency on the socket side and more on the http side, but I do have such a system working on ATT phones, Cingular phones, Nextel phones and T-mobile.

Getting the carriers to accept your games is a whole different matter and I don't have any ideas for you there. Out one side of their mouth they want multiplayer, and out the other side they are so afraid you will swamp their network that they turn and run.  Not to mention that device certificate with non-network games is extremely expensive I'm not looking forward to getting my network clients certified.

23  Java Game APIs & Engines / J2ME / Re: Inconistent or missing stackmap at target? on: 2005-02-14 12:57:21
preverify is for class files, not source (.java) files. I don't ever use it directly, but looking up the options, I think it would be more like this:

preverify c:\wtk21\lib\cldcapi10.jar;c:\wtk21\lib\midpapi20.jar -d f:\mobile\proto1\output F:\MOBILE\PROTO1\boundbox.class

That said, I keep all of my source under the wtk21 directory. I'm not using 2.2 yet. It just makes life easier and the wtk doesn't seem to want to use any other directories. Or I'm to lazy to go digging.  All of my projects are under c:\wtk21\apps.  When I start a new project I first create the project with wtk, then create the same project with NetBeans in the same directory. Source files are under c:\wtk21\apps\<appname>\src. I dev with NetBeans (I used to use codewarrior), and I create my final releases with wtk.

24  Java Game APIs & Engines / J2ME / Re: Inconistent or missing stackmap at target? on: 2005-02-10 16:30:19
I would have to see the code to make a better estimate. Maybe try the netbeans preferences/platform tab and set the Device Configuration to CLDC-1.1 and the Device Platform to MIDP-2.0.  Just a wild guess from very little information you've given us.

25  Java Game APIs & Engines / J2ME / Re: how can we abtain sin and cos methods ? on: 2005-01-27 14:39:10
I looked into this when I started my last game. It was a 2d, so I'm not sure what your requirements are?  I ended up doing some odd contortions to make my collision detection logic happen. ShiftFP2D was very handy to do what I needed, but no sign/cos or sqrt.

For distances I ended up keeping all my measurements squared and measuring against values that were also squared. It worked for me.

For cases where I needed to know direction, I ended up using unit vectors and in some cases dot products to calculate facing values. Like I said, not pretty, but it did work.

If you can use cldc 2.0, that would also solve the problems.

26  Java Game APIs & Engines / J2ME / Re: Samsung e317 bug on: 2005-01-26 13:13:27
Just a note on one of my work arounds. Rewriting the fillRect with drawLine calls did not fix the problem. I'm betting the same bug exists in drawLine in that you cannot draw into an offscreen image in the areas that are larger than screen size.

The only solution I see is to have three offscreen images. One will be screen size, the other two will be my tile width/height and I will draw the second two on the right and bottom. I have not yet implemented this and may or may not depending on distribution.
27  Java Game APIs & Engines / J2ME / Re: Binary Data Files on: 2005-01-26 13:06:44
This makes sense to me.

1. Writing a UTF may be a little longer because there is string lenth information being transmitted where in your text file this may not be the case. Also, Unicode may be larger than ascii. I don't know the exact format of writeUTF, but my bet is that there is a little bit of overhead.

2. Writing an int may also be longer because to represent the number 9 in ascii only takes 1 byte where as an integer is 4 bytes.  The same goes for 10, 2 bytes in ascii and 4 bytes as an integer. Larger numbers will be larger in ascii, but I find that most of my programming numbers 1-4 digits making the average smaller than 4.
28  Java Game APIs & Engines / Java 2D / Re: Reviving Mini Adventure on: 2005-01-24 15:30:41
I'm interested in this project as well. Please inform me when the project is approved and public.

29  Java Game APIs & Engines / J2ME / Re: Help: Unable to load image on: 2005-01-24 12:48:51
The code looks fine to me. My guess would be a case sensitive file name?  Maybe your file is named title.PNG or something like that? I'm pretty sure J2ME is case sensitive with file names, I know J2SE is, but I'm very careful to always use lowercase so I have never tested or cared to look it up.

If the case is correct, I think it would be helpful to see the jar -tvf output posted here.

30  Java Game APIs & Engines / J2ME / Re: Help: Unable to load image on: 2005-01-21 18:47:58
Make sure the image is actually in the jar file using the command.

jar -tvf filename.jar

if you are using the SunWtk then the image needs to be placed in the res directory, not the src directory. if you are using netbeans, then I'm pretty sure the image can be in the src directory. I only use netbeans to develop, for my final jars, i use sunwtk.

Pages: [1] 2
bilznatch (27 views)
2015-08-04 11:03:17

SHC (44 views)
2015-08-01 03:58:20

Jesse (25 views)
2015-07-29 04:35:27

Riven (48 views)
2015-07-27 16:38:00

Riven (26 views)
2015-07-27 15:35:20

Riven (28 views)
2015-07-27 12:26:13

Riven (19 views)
2015-07-27 12:23:39

BurntPizza (42 views)
2015-07-25 00:14:37

BurntPizza (56 views)
2015-07-24 22:06:39

BurntPizza (35 views)
2015-07-24 06:06:53
List of Learning Resources
by gouessej
2015-07-09 11:29:36

How Do I Expand My Game?
by bashfrog
2015-06-14 11:34:43

List of Learning Resources
by PocketCrafter7
2015-05-31 05:37:30

Intersection Methods
by Roquen
2015-05-29 08:19:33

List of Learning Resources
by SilverTiger
2015-05-05 10:20:32

How to: JGO Wiki
by Mac70
2015-02-17 20:56:16

2D Dynamic Lighting
by ThePixelPony
2015-01-01 20:25:42

How do I start Java Game Development?
by gouessej
2014-12-27 19:41:21 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!