T2D 1.1 alpha first impression...

#1

Quote:5) [BUG] Now the insane effect in the layers (borders in tiles) has appeared...

Have you read the new PDF about ImageMaps? There's a new field to avoid this effect. I think it's called "filterPad" or something, I don't have it now in front of me.

#2 There is no more fx... it should be - bool td2Physics ::

#3

Quote:1) VC6 project is broken. But I could use the VC7 project with VS 2003

Yes; VC6 wasn't updated in the alpha although it only requires ensuring all the files are in there; it will then build.

Quote:The opengl2d3d doesn't have the fixs spotted in the forums. Are they not longer necessary?

OpenGL2D3D is technically not part of T2D but is part of TGE therefore changes to this will be applied via the TGE v1.4 merge. Any changes I make to this get overwritten when we merge unfortunately. This part of the engine is not mine to change but I'll go search for that fix and see if it did indeed make it into v1.4 (and what it does). I was originally making changes to this library but those got took out because of the merge situation. This thread for the OpenGL "fix"?

Quote:Gravity now must to be very little. 25000 -> 200

Yes because forces were not being correctly used in v1.0.2. They are now within reasonable numeric values as well.

Quote:Now my player sometimes gets stuck in the ground (the effect is worse if the gravity is little)

Could you provide a little more info on your players settings and perhaps the "ground" object (tiles?) ? What collision-detection mode? What collision-response mode? Stuff like that.

Do not patch v1.1 with v1.0.2 code, it won't work in most circumstances and certainly can't be supported.

Quote:Now the insane effect in the layers (borders in tiles) has appeared...

Have you spent a little time reading the documentation rather than just trying to port? As Manuel points out, the T2D Image-Map documentation details this and will help resolve these issues. In the alpha, "padding" is off by default.

If you could provide some more info on how your player is getting stuck, I'd appreciate it. Try to keep this code-level to minimal though. ;)

- Melv.

#4 Hi Melv!

5) LOL. This my fault, I was in a hurry and skipped all the explanation about

filterPad = true;

I just looked for "imageName" and "imageMode"... grrrrr
Now my tiles are perfect... (Nice docs by the way specially the particle docs, really appreciated)

Now with the "serious bug" ;)

4) This code works in 1.0.2 after the patch I mentioned... (without it my player slowed down
walking backwards...)

// material of player and tiles
datablock t2dCollisionMaterialDatablock (standardMaterial)
{
	friction = 0.0;
	restitution = 0.0;
	relaxation = 0.5;
	density = 0.5;
	forceScale = 1;
	damping = 0.0;
};
datablock t2dCollisionMaterialDatablock (immovableMaterial)
{
	friction = 0.0;
	restitution = 0.0;
	relaxation = 0.5;
	density = 0.01;
	forceScale = 0;
	damping = 0.0;
};

// how is created...
function chaActor::create (%this, %posX, %posY, %width, %height, %gravity)
{
	%this.gpx = new t2dAnimatedSprite ()	{....};
	if (%gravity > 0)
	{
		%this.gpx.setConstantForce (0 SPC %gravity, 1); //<--- Here (%gravity == 200)
	}
	%this.gpx.setMaxAngularVelocity (0);
}

// how moves...
function chpInca::orderWalkRight (%this)
{
	// invertir imagen del player
	%this.gpx.seeToLeft = false;
	%this.gpx.setFlip (false, false);
	%this.gpx.setLinearVelocityX (%this.velWalk); // <-- velWalk == 40
	%this.gpx.playAnimation (aniInca_Walk);
	%this.gpx.state = $JT_ST_WALK_RIGHT;
}
function chpInca::orderJump (%this)
{
	%this.gpx.setLinearVelocityY (-%this.velJump); //<-- velJump == 100
	%this.gpx.playAnimation (aniInca_Jump);
	%this.gpx.state = $JT_ST_JUMP;
}

// groups and layers
$gn_playerGroup				= 1;
$gn_playerFireGroup			= 2;
$gn_enemyGroup				= 3;
$gn_enemyFireGroup			= 4;
$gn_platformGroup			= 5;
$gn_platformPassableGroup	= 6;

$gn_playerLayer				= 10;
$gn_playerFireLayer			= 9;
$gn_enemyLayer				= 15;
$gn_enemyFireLayer			= 14;
$gn_platformLayer			= 27;
$gn_platformPassableLayer	= 28;

$go_playerGroups = BIT($gn_playerGroup) | BIT($gn_playerFireGroup);
$go_enemyGroups = BIT($gn_enemyGroup) | BIT($gn_enemyFireGroup);
$go_playerLayers = BIT($gn_playerLayer) | BIT($gn_playerFireLayer);
$go_enemyLayers = BIT($gn_enemyLayer) | BIT($gn_enemyFireLayer);
$go_platformGroups = BIT($gn_platformGroup) | BIT($gn_platformPassableGroup);
$go_platformLayers = BIT($gn_platformLayer) | BIT($gn_platformPassableLayer);

// map creation...
function map001::Create ()
{
	%map = new ScriptObject ( :clsMap001) { };
	%map.tileMap = new t2dTileMap () { scenegraph = t2dSceneGraph; };
	%map.tileMap.loadTileMap ("~/client/maps/lvl001.map");
	%map.lyrGround = %map.tileMap.getTileLayer (3);
	%map.lyrGround.setCollisionMaterial (immovableMaterial);
	%map.lyrGround.setLayer ($gn_platformLayer);
	%map.lyrGround.setGroup ($gn_platformGroup);
	%map.lyrGround.setCollisionActive (false, true);
}

// player collision...
function SetPlayerCollision (%gpxActor)
{
	%gpxActor.setGroup ($gn_playerGroup);   // <-- gpxActor is a t2dAnimatedSprite
	%gpxActor.setLayer ($gn_playerLayer);
	%gpxActor.setCollisionActive (true, true);
	%gpxActor.setCollisionPhysics (true, false);
	%gpxActor.setCollisionMaterial (standardMaterial);
	%gpxActor.setCollisionMasks ($go_enemyGroups | $go_platformGroups,
							 $go_enemyLayers | $go_platformLayers);
	%gpxActor.setCollisionCallback (true);
}

I can't spot a error in the above code, just the common platform code...
My guess is something inside the physics engine or some parameter I didn't set correctly.
Hope you could help me

6) [FIXED?] In the 1.0.2 release the velocities depended seriously of the frame rate
I've not tested rigorously but "eyeballing" this seems fixed now. More of this after a more
consciously test...

#5 Melv, me again... sorry I tryed to keep the code minimal before, but I dunno :)
I hope you could reproduce the error now...

About how this stuck happens... well sometimes when the player lands after jumping
he can not move again to the left or right, so my guess is setLinearVelocityX() is failing.
or the engine collision is failing... this happens with my automated enemies too,
so is not a fail in the control state machine of the player, after a while trying to move
he can move again, this happens randomly but frequently.

#6 @Adam: I'd have a look through the collision reference doco before you jump in and try to make alot of code work. First thing to notice is that the collision-detection code has changed considerably. You now select what type of collision-response you want and the default now isn't Rigid-body as that's typically for more specialised purposes; the default is now CLAMP. In this mode, lots of the items in collision-material are not used as they obviously relate to rigid-body only.

You can also use a simple circle collision primitive if that helps.

%obj.setCollisionDetection()
%obj.setCollisionResponse()

I'm not sure why your character gets stuck at all. It sounds like its stuck in an overlap situtation that it never resolved somehow. I setup a simple platformer test a while ago whilst testing all the collision-detection and there were no problems that weren't resolved, hmm. Are you doing any movement in the collision callback?

Just as a note; have a look at "%obj.setCollisionAgainst()" and "bits( "0 4 5 6" )" as they make setting up collisions a little easier.

This'd be alot easier to understand with the new collision detection documentation that didn't make it into the alpha unfortunately. In the meantime, this weekend I'll dig out the copy of the platformer test code to see if something subtle has crept in to foobar something.

Try reducing the gravity to something miniscule; does this stop the problem? Try using a circle either sub/superscribed as well.

- Melv.

#7 @Adam: How easy would it be (and would you mind) packaging up just the files required for me to duplicate the problem? Could either host it or send it (if it's not too monsterously big) to me?

I'd probably be able to track the problem quicker if you did this.

- Melv.

#8 Ok Melv. I'm going to send you a email to your private email.
Please check it. In the meantime I'm going to READ the new
documentation... :)

#9 Cool. Hopefully I can find where the problem is. Just to be clear, I won't get chance to look at it this evening but I will be looking at it over the weekend. Need to rest now.

- Melv.

#10 Rest Melv you deserved it! :)

#11 Melv thank you for your advice.
My platformer is ok now...

4) [FIXED]
Here the explanation: As you said physics now reacts different,
this was my error. I needed to add only:

%gpxActor.setCollisionResponse (CLAMP);
	%gpxActor.setCollisionMaxIterations (2);

to my physics setup and all was OK. LOL.

[EDIT] actually only: setCollisionMaxIterations (2) is required
because CLAMP is by default.

#12 I'm also having some issues getting physics to work desirably. Specifically, one of my objects seems stuck, if I really slam it it, it moves a little, but it will never rotate, it just shifts a little bit. (this is on my port attempt)

ANyway, @Melv, you say there is a physics doco that didn't make it into the alpha? Is that for download somewhere? Thanks!

#13 @Phil: I'm working on finishing this documentation now; it didn't make it into the alpha because it simply wasn't finished. It should clear up alot of issues. I've also discovered a potential problem from another thread that I'm investigating now that may be the cause of objects getting stuck.

It's more than likely something minor that has crept in because this problem is easily reproduced, even on a platformer test app I wrote that worked about 6-7 weeks ago.

This is the thread that I'm working against that could be the same problem you're experiencing.

- Melv.