Main Menu
Menu

Show posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Show posts Menu

Messages - Kernle 32DLL

#1
Support / Re: Collisions
May 06, 2011, 06:28:34 PM
There we go again. With a proper level, my method seems way to slow. Framrates drop to 20fps on my galaxy -> Not good :/
So I'm back to square one again. I'm finally so far to say "screw this all, lets get that ellipsoid rolling".

So far I had no success in getting it to work. As said, I want to check if a given object (now defined as an ellipsoid) collides with the world. I measured out, that a ellipsoid with the radius values 76,22,15 (X,Y,Z respectively) would be the optimal choice. But how do I get the collision check running? My code so far looks like this:

if(!mPlayerObject.checkForCollisionEllipsoid(SimpleVector.ORIGIN, sEllipsoid, 1).equals(sEllipsoid))
endGame();


While sEllipsoid is a SimpleVector with x,y,z set to the values above, and SimpleVector.ORIGIN is used to tell that I want to check the collision at the current position (0,0,0 in objectspace), without any moving at all. The if clause always returns true, so what did I do wrong? :/ Oh, by the way, The collision modes are set as

mPlayerObject.setCollisionMode(Object3D.COLLISION_CHECK_SELF);
mWorldObject.setCollisionMode(Object3D.COLLISION_CHECK_OTHERS);


Any ideas? Oh, and may there be a better choice for collision detection, since I only want to check IF a collision is happening at the current position? E.g. I dont need that "moving in direction xxx" stuff, just a simple collision true/false check :/

So long,
Kernle
#2
Support / Re: Version updates!
April 26, 2011, 01:19:37 AM
That just made my day :) Thanks!
#3
Well, the allocation tracker gives me the creation of a two SimpleVectors (line 2717 and 2719 in Object3D.java) and one Object3D[] (line 2720 in Object3D.java) per calcMinDistance call. Makes quite a lot of allocations, if used a lot.

Oh, and I dont use an octree atm.
#4
Support / Re: Collisions
April 24, 2011, 05:42:19 PM
Well, that didn't work out as I planed :-/

I developed the following approach, but using this drops my fps to near 30-40 on a Galaxy S, this means unplayable on slower devices:

I use a simplefied, 2D version of my mesh, and take the bounding vertex lines. Interpreting this lines a vectors, I use them via calcMinDistance using my world Mesh. So basically, I'm moving that "shape" around, and check if this shape collides with my map.



The code looks like this:
(mCollisionShapeX and mCollisionShapeY are arrays containing the X/Y Points for my "collisionshape", see picture)

final public static SimpleVector sCollisionOrg = new SimpleVector();
final public static SimpleVector sCollisionDir = new SimpleVector();

public void checkCollisions()
{
for (int i = 0; i < mCollisionShapeX.length; i++)
{
int i2 = (i+1) % mCollisionShapeX.length;

sCollisionOrg.set(mPlayerPos.x + mCollisionShapeX[i], mPlayerPos.y - mCollisionShapeY[i], 0);
sCollisionDir.set(mPlayerPos.x + mCollisionShapeX[i2], mPlayerPos.y - mCollisionShapeY[i2], 0);

sCollisionDir.sub(sCollisionOrg);

// Normalizing without creating a new vector
float length = sCollisionDir.length();
sCollisionDir.x /= length;
sCollisionDir.y /= length;

float distance = mWorldObject.calcMinDistance(sCollisionOrg, sCollisionDir);

if (distance != Object3D.COLLISION_NONE && distance <= length)
{
resetPlayerPosition();
break;
}
}
}


As already said, this slows down the game quite impressively. So, either calcMinDistance is coded very sloppy, or just not suited for this kind of use. Anyway, this leaves me with no choice but to start from scratch. I know the answer is there somewhere, there is just something missing I don't get.

I think my approach with ray detection via the vectors mentioned above is not so bad, but I don't get it connected with jPCT-AE :/

Help?

So long,
Kernle

PS: Oh, speaking of it, there are two things that could be improved within jPCT-AE: Make a function to normalize vectors without creating a new one, and looking into the calcMinDistance variant that takes a maximum distance value. Either I didn't get the point, or it just does not work. Thats why I did a manual check with <= distance (see code).
#5
Nevermind, it's world space of course (silly me...) However, using calcMinDistance is not a good idea atm, as it allocated a lot of objects (Object3D[] and SimpleVectors).

So long,
Kernle
#6
Support / Question about Object3D.calcMinDistance
April 24, 2011, 02:24:33 AM
Hi there,

Just a quick question. Has the org vector in Object3D.calcMinDistance to be world of local space? I dont have any suited environment to test this out right now.

Oh, and just out of curiosity... What stands the AABB for in the Object3D.XXXIntersectsAABB functions for?

So long,
Kernle
#7
Support / Re: Collisions
April 22, 2011, 01:53:20 PM
The issues are the areas marked red. There are areas which would be handled as collided, but there was no actual collision, and areas where geometry would not be tested for collision. Two spheres would create the same problem.

However, you gave me a good hint with ray/polygon collisions. I think I'll try that, and report back. Thanks =)

So long,
Kernle
#8
Support / Re: Collisions
April 22, 2011, 01:14:17 PM
Quote from: EgonOlsen on April 21, 2011, 09:51:15 PM
What's the exact problem with it?

That an ellipsoid is not a submarine :D No seriously, the problem is that using an ellipsoid (or a sphere, same matter) is not percise enough to make for a collision tester for a submarine. I could of course kind of rebuild the sub with ellipsoids for collision testing, but that would be an enormous performance waste.

I attached a picture for further explaination.

So long,
Kernle

[attachment deleted by admin]
#9
Projects / Re: Projects anyone?
April 21, 2011, 05:59:06 PM
I'm currently working on a massive advanced port of one of my cooler pc games, originally titled "SoS-Submarine". The original game was created in the frame of a contest, related to water-games. And yeah, I won.. Barely ;-)

Anyway, the game itself was fine, but the coding was messy, and the overall game experience had a lot more potential. So, for my first private android game project to be released, I am now recreating this game the way it was meant to be, for Android :)



The games purpose is to guide a submarine trough a underwater tunnel system. It might involve using weapons e.g. torpedoes later, but this is not stone-set yet. For the first release there are planned 5 levels, with 3 submarines to choose (2 unlock able). A brief achievement system is planed as well, but may be dropped if found unnecessary (or by lack of creative achievements).

The current status is that the controls are fully implemented (turning via turning the phone, and regulating speed and diving via the bars shown in the screenshot), and a basic UI is in place, too. Brief lighting is implemented as well, but may see improvement during the ongoing development. As for the levels, I'm currently using a WIP-Updated-Version of one of the original levels. It's mainly an atmospheric test, e.g. for placing objects in front of the player, etc. (and yes i know that the pillars are flat in the screenshot, didn't had time to make full 3d-modells yet).

The next big thing I'm currently nagging on is the implementation of collision detection.

For anyone interested testing, there you go: click (1,14mb) - Android 1.6

Edit 23.04.2011:
- New apk
- Changed package- and appname
- Swaped icon for custom one (placeholder)
- Fixed UI for smaller devices
- Removed percentage view (will be reintegrated later again, tough)
- Code cleanup

Edit 24.04.2011:
- Added basic collision detection (slow tough)
- Optimized 9-patch graphics

Edit 25.04.2011:
- Added start countdown
- Added gameover screen (placeholder)
- Fixed back- & homebutton behavior

Edit 05.05.2011:
- Fixed level culling
- Adjusted color tinting
- New gameover screen
- Cleaned UI layout
- Fixed display shutting down during gameplay (forgot keepScreenOn call)

Known issues:
- Bars are not multi-touch compatible yet

Test Results so far:
- Samsung Galaxy S with 2.2.1
Works fine, bars and gameover screen minor lag sometimes (may be android 2.2 related)
- Nexus S
Works fine (?)
- HTC Wildfire
Unplayable (4fps)

So long,
Kernle
#10
Support / Re: Collisions
April 21, 2011, 05:01:21 PM
Mh, not really a friend of bullet. Also, it seems a bit overkill for some simple intersection tests. Isn't there some other lightweight method for collision detection? I don't need any real physics stuff, since I only want to detect if the player has collided with the wall, to reset him onto the right track :/

Well, any suggestions?

So long,
Kernle
#11
Support / Collisions
April 21, 2011, 02:00:28 AM
Hi there,

Short question, how to check for collisions in jPCT-AE? I only found Sphere/Ellipsoid to Polygon checking. Is there any chance of Polygon to Polygon checking, e.g. simple mesh intersecting routines, or in worst case, a simple Box to Polygon method? Didn't find any, and Sphere/Ellipsoid to Polygon checking could get a bit tricky with my game approach.

So long,
Kernle
#12
I use a Galaxy S for development, and it works quite well. But you should not ask "what is the best device on the market", because you want to target as many devices as possible. Its more important to decide for which plattform you want to develop. Looking at this chart, the choice should be obvious: http://developer.android.com/resources/dashboard/platform-versions.html Keep in mind that jPCT-AE is even 1.6 compatible ;-) Sorry for getting a bit side tracked ;-)

Oh, and yes.. EgonOlsen is right, Samsungs update policy is not existing. E.G. the 2.3 Update for the Galaxy S is already a month overdue (Not that I care, there is a leaked 2.3.3 version :P).

So long,
Kernle
#13
Hi,

Yet another problem I need to get solved: How to work with Lights in jPCT-AE? Judging from the docs, it seems there are only "point" lights, e.g. a light pointing into all directions. Any chance to create a spot light, that lights only a certain direction?

Another thing that I need to learn how to use is the function setDiscardDistance for a Light object. I thought that it would set the max. distance where the light could shine, but when regardless to which value I set it, this "distance" seems incredible small, so it seems like there is nearly no illumination at all :/ As a side note, the doc mentiones a value in the Config calls, which does not exist (Config.discardDistance).

Any toughts?

So long,
Kernle
#14
Support / Re: Strange rotation behavior?
April 01, 2011, 11:03:08 PM
Yep, that did the trick. Thanks again
#15
Support / Re: Is jPCT-AE the right engine for me?
April 01, 2011, 11:02:37 PM
Sorry, as I said, no offense intended. Concerning the JavaDoc, I have to correct my statement. I was not refering to object cloning to be memory wasteful (the javadoc even mentiones that they use shared data), but more general things. HOWEVER, I'm not able to find those functions I'm actually refering to right now.... Shame on me! Anyhow, as soon as I find them again, I will ask you about them ;-)

For now, I'm pretty satisfied with the engine. There are some things that are uncomon for me, but so far I was able to solve every mystery I came across (with your help btw) :-)

So long,
Kernle