Quote from: EgonOlsen on October 13, 2008, 08:36:25 PM

Quote from: dmouse on October 13, 2008, 06:07:44 PM
Feel free to add it to the projects page (i would be honored), do you need anything from me with regards to this?

Ok, i've added it. It got second place in the list. Because i wildly inserted new projects anywhere on the list in the past, i decided to reserve the first spot for my own stuff and add each new project below that. Your game is the first one that benefits from this.

Thanks for adding it, it looks great!

Do I get a prize for being second in the list?

Ben.

Quote from: EgonOlsen on October 13, 2008, 08:10:43 PM
Edit: That's an EEEPC 701, i.e. first generation with a CeleronM running on 630Mhz. The 900 and 901 ones should be faster because they either run on 900Mhz or are using the Atom CPU. I did a comparision (albeit based on the hardware renderer) and the 901 was 20-50 faster than my 701.

Thanks for the info, does that mean that the first (and presumably the following gnerations) EEEPC's built in video card (presumably intel integrated) runs jPCT hardware accelerated apps well?

Are you using the Linux or the Windows version?

sorry for going OT.

Thanks.

Quote from: paulscode on October 13, 2008, 07:54:22 PM

Quote from: dmouse on October 13, 2008, 05:59:36 PM
I am use the wheel ray-casting technique to find out where each wheel would rest, if the car is on the ground.  That is to say, that you can work out the distance from (wheel.x, H, wheel.z) to the ground model, using a straight down movement vector (0,1,0). This gives you the y position the of the wheel when touching that particular point on the ground. If you do this 4 times, once for each wheel, you can then work out the x and z rotation of the car to match those 4 height coords.

That is what I was planning to do, so it is great to see a really good working example.  One potential problem I thought of is where two caticorner wheels are higher than the other two wheels:



If no special coding were in place, a scenareo like this would result in what would appear to be two wheels falling out from under the car.  I can think of 3 ways around such a problem.  The first way would be to make sure a situation like this could never occur, by ensuring that all terrains are smooth with no sudden changes in altitude (your game seems to use this method, as I could not create such a scenareo to see what would happen).  The second way would be to use a weight distribution model for the vehicle to determine which direction the vehicle would rotate due to torque.  The third way would be to set a maximum distance that a wheel can fall in relation to the other wheels, but that could lead to some pretty unrealistic situations, such as the vehicle balancing on a single wheel.

I wanted to make a level that would have players jumping off of the top of a steep cliff edge, but at the same time, I needed to prevent them from driving (vertically) back up the cliff side after they landed (the snow level based in Austria). If I understand you correctly above, this may be similar to the potential problem you are mentioning. My (temporary) solution was not particulary realistic, but was quick and efficient, at least until I develop something better as I continue to work on the car handling engine. This solution may be similar to the 3rd option you mentioned above, where I do some specific basic checks to see if the wheel's Y positions do not differ too much (within some tolerable threshold). As I said, it's not incredibly realistic, but served my purposes well enough, perhaps until I further evolve the engine.

Ben.

Quote from: fireside on October 13, 2008, 04:32:51 PM
Wow.  Great game. 

Thanks, I do appreciate it. 

Quote from: EgonOlsen on October 12, 2008, 11:13:02 PM
I've already spotted it on Javagaming.org. It's pretty cool albeit i suck at it. I stand no chance against the AI drivers...
Do you mind if i add the game to the projects page?

I am curious as to whether it is actually running at a playable frame rate on your EEEpc, Egon, since I am considering buying one in the near future.

Also, your comments about difficulty, as well as some comments on JavaGaming.org, are making realize that I need to tone down the difficulty a bit during the early levels.

Feel free to add it to the projects page (i would be honored), do you need anything from me with regards to this?

Thanks,

Ben.

Quote from: JavaMan on October 12, 2008, 08:06:33 PM
Nice graphics. Very fast performance only jumped on time.
Could you tell me what shape your sky is? Is it a cube or half-sphere?

Thanks, I prefer to use a cube for the sky, simply because I am very economical with vertex and polygon counts. IMHO with a good texture, and it is hard to notice the difference, and therefore not worth the extra (albeit rather small) computation time to render a half sphere.

Quote from: paulscode on October 12, 2008, 03:42:50 PM
The physics in this game are very good, especially momentum and centers of gravity when the vehicles are in free-fall.  I also think the play-control is comparable to other racing games, so great job on that.  If you don't mind my asking, what method you are using to keep all four of the vehicle's wheels on the terrain and the vehicle's rotation correct as it drives over various altitudes?

Paulscode,

Thanks for trying it out, and for the kind words.

I am use the wheel ray-casting technique to find out where each wheel would rest, if the car is on the ground.  That is to say, that you can work out the distance from (wheel.x, H, wheel.z) to the ground model, using a straight down movement vector (0,1,0). This gives you the y position the of the wheel when touching that particular point on the ground. If you do this 4 times, once for each wheel, you can then work out the x and z rotation of the car to match those 4 height coords. I believe (but don't quote me on this , this method is used in the jpct car example, as well as the vehicle demo that comes with the jbullet physics engine, and in other car related games. It is pretty simple, efficient, and fast. I think some other solutions involve casting a volume (such as a cylinder) for greater accuracy, but rays were good enough for me.

I hope this helps, I am usually very bad at explaining these kind of things

Ben.

Hi all,

I just recently finished my first game with using jpct 

Any feedback is greatly appreciated.

Click <a href = "http://www.javagameplay.com/offroadrally/rally.html"> here </a> to play.


Thanks in advance.

Quote from: zammbi on September 13, 2008, 05:05:16 AM
I remember trying Proguard on jpct, but failed on all tries.

Ok, thanks for letting me know, at least I know that perhaps it is not something that only I am doing wrong.

It is a shame this doesn't work, when I try to obfuscate jPCT is shrinks down from about 205K to about 72K, but obviously this is useless if it doesn't actually work 

For anyone reading this perhaps in the future, who might be interested, you _can_ obfuscate your own class files with ProGuard, by using something like "-libraryjars C:\dev2\Java\jPCT\jpct.jar", and by not including the jpct.jar in your current working directory. Then copy the jpct.jar file into you newly obfuscated target directory, and jpct (unobfuscated) will run with your obfuscated class files. Maybe someone will find this useful.

Quote from: EgonOlsen on September 13, 2008, 12:35:36 AM
...it's not allowed until the author (that would be me... ) allows you to do so. So...feel free to delete class files that you don't need. No clue about obfuscation...i think i've played around with it in the past, but i really can't remember the results.

Thanks Egon!

I was wondering about the Loader.class, which is 25K, is there a smaller version of this class, or would it be possible to compile a smaller version of this class? My code only uses 3DS files, and I am guessing that I might be able to cut out about 15K, if I didn't need to include code for all the other formats.

Hi all,

I am glad to say that I am near the end of my first project with JPCT 

I am currently compressing resources etc.. and trying to make the download size as small as possible (it's a web applet). I have a couple of questions :

1) Are we allowed (and is it advisable) to delete .class files from jpct.jar that we don't need? I have experimented with this, and have produced a version of jpct.jar that is 141K (original size 205K, using verion 1.1.6). Would using this break any terms of use? My project seems to run well with the trimmed version of jpct.

2) Has anyone had any luck with obfuscating a jpct project? I am using Proguard 4.2 (latest version), and I can create working builds by obfuscating my own project class files (with significant reduction from 181K down to 54K!!!). However, when I try to obfuscate the jpct class files, the project no longer works (class files are no longer found etc...). Has anyone obfuscated JPCT before, is it possible?

Thanks in advance.

Quote from: EgonOlsen on August 26, 2008, 12:10:09 AM

Quote from: dmouse on August 25, 2008, 12:17:06 AM
I am not sure if I was doing something wrong with CollisionListener.collision(), is there a reason why it might get notified multiple times for the same collision event?

That should not happen and i've never ever experienced it albeit i'm using CollisionListeners a lot. Are you sure that the event is 100% the same (i.e. same source, same target, same algorithm)?

I think I realized what the problem was. When the game was re-initialized I was adding CollisionListeners to all the game entities _again_ (this had already happened during the first initialization). Removing this fixed the problem, collisions are only notified once now, and I no longer have to process them in a queue etc..

Thanks for your help.

After more experimentation, it seems that my problems with CollisionListener.collision() were not thread related, but were in fact caused by the collision method sometimes being notified twice with regards to the same collision event. This means that I was sometimes executing response logic twice for the same collision event (once each time it was notified), producing unpredictable results.

I seem to have worked around this by, placing all collision event notifications into a queue, and then removing duplicate entries from the queue, before finally executing responses for the collision events left in the queue. This produces predictable and expected results.

I am not sure if I was doing something wrong with CollisionListener.collision(), is there a reason why it might get notified multiple times for the same collision event?

Thanks in advance.

Hi,

I was wondering if there was perhaps a way to use something like Object3D.checkForCollisionSpherical(SimpleVector translation, float radius)) but to have access to information about which Object3D(s) were hit (if any) as a result of the translation in question.

I have also experimented with CollisionListener.collision(), but since this needs to run in it's own thread, I can't really use it.

Ideally, I would like a method by which I could check if 2 objects are currently overlapping or are about to collide as a result of a translation. I could then use this method to selectively detect collisions between objects at will.

Is there any way of doing this in jPCT?

Any help would be appreciated.

Thanks in advance.

Hi,

I just wanted to say thank you to Egon again for his help with my original question in this thread.

I have decided to blit text and graphics over the the 3d scene, as this method will clearly work for 1.1 applets, 1.2+ applets and hardware accelerated applications, all with the same code. I initially thought this might be slower than g.drawString etc.., but isn't noticiably so, particularly with only a limited amount text being displayed (such as game menus and such).

Thanks again.