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: 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.

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.

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.

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.

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.

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