Messages

1

Support / Re: Button Event Lag?

« on: May 27, 2013, 08:39:49 pm »

 

2

Support / Re: Button Event Lag?

« on: May 27, 2013, 07:54:13 pm »

Ah, cool. Is there any downside to making it execute that way?

3

Support / Re: Button Event Lag?

« on: May 27, 2013, 05:12:16 am »

Thanks, I'll try that. This just sent me on a long adventure of learning about coRoutines and yield.

So, is there no way to run the scaling in parallel, or what if I just call the event first?

4

Support / Button Event Lag?

« on: May 26, 2013, 10:12:15 pm »

I seem to be experiencing some lag with the tk2d button event delegate.

I've tried using this event vs. just detecting straight input in my main game loop, and the game loop reacts immediately, whereas the button event presents a very short delay. Unfortunately, this delay is still enough to throw things off, as I'm detecting a collision at the time of the button event.

Any suggestions? I have been using the buttonDown event, but this seems to present as much lag as buttonPressed.

Thanks for any help.

5

Support / Static Sprite Batcher and Colliders?

« on: September 04, 2012, 05:36:16 am »

I've got a setup with a character controller on a moving sprite and a number of motionless sprites with box colliders. All of the collisions work perfectly.

However, when I place the stationary sprites into a static sprite batcher and commit, the colliders disappear. I do have the sprite's collider marked as  unset in its collection. This is because I'm doing custom scalings box collider settings for each instantiation of the sprite.

Any suggestions?

6

Support / Re: Draw order with moving sprites

« on: September 03, 2012, 07:58:55 pm »

I suppose I was concerned that this could have unintentional physics implications. I suppose I can just give every sprite colliders that are large in the z direction to compensate.

This also adds in some coding overhead, where I'll need add correlated z movement to every sprite.

I guess I was just hoping there was a simple way to make the buffer draw based on the y axis instead.

7

Support / Draw order with moving sprites

« on: September 03, 2012, 07:34:11 am »

Hi,

I am new to TK2D and am making a game with moving character sprites where the bottom of the screen should be perceived as nearer than the top of the screen.

Therefore, if the trunk of a tree is at y = 5, a character at y = 3 should pass in front of it, and a character at y = 7 should pass behind it.

I could move sprites around on the z axis as they move up and down in y, which would then employ the depth buffer to draw in the proper order. This could have other potentially undesirable effects, though. So, is there a better way to make it work?

Thanks for the help!

8

Support / Re: Full Screen and TK2D Camera

« on: August 31, 2012, 10:45:12 pm »

Ah, this is great! I hadn't actually tried adding an override yet. That's what I get for trying to think it all through before acting! Thanks.

9

Support / Re: Full Screen and TK2D Camera

« on: August 31, 2012, 07:08:10 am »

I see.

So, if I want to provide a fullscreen option, I need to anticipate and provide overrides for all potential resolutions?

10

Support / Re: Full Screen and TK2D Camera

« on: August 30, 2012, 06:19:16 pm »

Ok. So, let's say I have a 700x700 sprite background image that's anchored at the bottom left. This is a 1:1 aspect ratio.

If I send this to fullscreen on a 16:10 1680x1050 display, what do you expect to happen?

A) The image is stretched to fill the screen - distorting its appearance
B) The image stays in its native resolution, hugging the bottom left, leaving open space to the top and right
C) The image is scaled up as much as possible within the screen bounds without cropping, keeping its native aspect ratio but leaving open space to the right.

I guess on some level I'm trying to figure out exactly what you mean by pixel perfect:) Thanks!

11

Support / Re: Full Screen and TK2D Camera

« on: August 30, 2012, 01:09:38 am »

I'm not having an issue yet per se... just trying to figure out what target resolution to use as my default.

So, what happens if the aspect ratio of the resolution I've been working with doesn't match the user's fullscreen AR?

12

Support / Full Screen and TK2D Camera

« on: August 29, 2012, 10:09:43 pm »

Hi,

I'm trying to wrap my head around the interaction between the TK2D Camera and fullscreen setting (i.e. in the webplayer or by unchecking the "windowed" checkbox in a standalone app).

Is it possible to provide a resolution override that will kick in when the user selects fullscreen so that the image isn't improperly scaled?

Thanks for any help with this!