I've been happily using Sparrow, but due to the immense pain in the ass it is to actually put something onto an iOS device, I've been programming in the simulator up until now. I finally got it onto a device for the first time today, and the touch events were barely responding at all. They respond right away in the simulator, but I can push 10 or 20 times without a response on the actual hardware. Do I just suck at Objective-C? Sorry if I didn't give much information, but I don't really know what to say. Basically I have several objects floating around the screen that are subscribed to SP_EVENT_TYPE_TOUCH and they "die" when you touch them. I didn't think there was any problem because in the simulator it works just as I expect. I would appreciate any help. Thanks!
Touch not working on hardware well
(7 posts) (3 voices)-
It may be that the framerate is too low, causing the touches not to register. You can find out the actual framerate with this code snippet. What result do you get?
If it's too low, then you have to find ways to speed up your game. The simulator is much more forgiving than the actual hardware, so there might be some things you have done in an inefficient or suboptimal way, e.g. using too big textures, not using a texture atlas, memory leads, etc. I'm sure you'll find ways to speed up your game sufficiently.
Posted 10 months ago # -
Slade
MemberMaybe you should try with only subscribing your game class to SP_EVENT_TYPE_TOUCH and check every object in onTouchEvent instead?
[self addEventListener:@selector(onTouchEvent:) atObject:self forType:SP_EVENT_TYPE_TOUCH]; - (void)onTouchEvent:(SPTouchEvent*)event { //Check if a specific object was touched }
I had some problems when I accidentally had two subscriptions instead of one.
Posted 10 months ago # -
Also, I don't know much about how the phone makes the whole finger touch into one single point (I assumed in the beginning that if your finger was on the screen it would register that range of pixels, but I was wrong I think). Obviously I'm not just touching one pixel. One of the objects of the game is to touch very small objects (1 pixel by 1 pixel). Is this asinine? I have started to think it is, and am thinking of catching the touch event at a high level and raising my own custom event to check a radius to see if the touch was within X pixels of the object. It even seems hard for 16 x 16.
Good to know about the frame rate, because I always assumed the simulator would always be worse, but that's not the case. The frame rate obviously suffers once I get above 250 objects on screen moving around. I'll have to note that. When I get to work I'll try the frame rate things you described.
Right now the graphics are at placeholder phase (bare minimum). The game is a white background with a 64x64 pixel "enemy" texture, and a 36x36 gray semi-transparent texture that I use statically. I just use the hell out of them. I store the textures statically and reuse them through SPImages, of course. I am nearly brand new to memory management, but I try to release whenever I init (I've spent years in C#...so I'm spoiled). I'm not new to game programming, so I'm always thinking about ways to shrink textures and make things as efficient as possible, so I suspect memory leaks due to my inexperience. Or, when you say "too big" textures...I am using the 64x64 texture at various sizes (64x64, 32x32, 16x16, 8x8, 1x1), but does this come with a performance hit? Should I make all those sizes beforehand and put them into an atlas?
Posted 10 months ago # -
Ah, OK, that explains it. Yes, each touch is only registered at exactly one pixel, so it will be nearly impossible to hit a single pixel or a very small area. You'll have to test for a bigger area.
OK, if you re-use the textures in lots of images, then you're doing it the right way, each texture will be in memory only once. And those are definitely not too big; you can use up to 1024x1024 on older devices, or 2048x2048 on now ones. (Of course only a few when they're that huge). Scaling down the image makes no difference, that's fine.
BTW, if the 2 textures you are using are rendered alternately (Sparrow draws t1, then t2, then t1, then t2, ....), then you'll win some speed by using a texture atlas, even with only 2 textures, because you'll Sparrow OpenGL all those textures switches.
Other than that, everything sounds reasonable.
Posted 10 months ago # -
Yes, I got it working using the box method I described above. I had a bit of trouble getting it working because touch events wouldn't register with the empty space on my SPSprite, only on objects (like SPImage) inside it. No matter how I prodded, the method wouldn't fire. Finally, I just set it up at the SPStage level. That was a bit of a pain though, because globalX and globalY are set up for the original portrait mode, and not the rotated sprite landscape. I did get it eventually though, and raised my own NSNotification that sends a 32x32 SPRectangle around the point that came with the touch. That is picked up by all of the baddies on screen and they test using intersectsRectangle with their bounds. That worked just as I had hoped, and I am able to squish multiple sprites at once if they are close.
Now I just have to deal with those awful EXC_BAD_ACCESS errors. The worst part is they are intermittent.
Posted 10 months ago # -
There is an alternative solution to pick up the touches: if the areas that have to be touched are all distinct objects, you can override the "hitTest:" method of SPDisplayObject; the demo project contains a sample showing how to do that. That should be easier than your current approach! Sorry for not having mentioned it before, I did not think of that myself before.
Posted 10 months ago #
Reply
You must log in to post.