Hey all, I'm developing a rhythm game for the iPhone at the moment, just wondered if anyone had any thoughts on the best pieces to use for reaction time.
I have all the coding worked out, and I've narrowed it down to about 2 ways:
1: Using instances of UIButton that bypass the UIControlEvent or whatever, in order to use touchesBegan and touchesEnded. I've found this to be a bit faster in the past.
2: Using UIViews with custom functions to change the state of the buttons. They would also use touches began.
The rhythm pads (eight of them) need to be able to play a sound with minimal lag, and provide some sort of feedback, i.e. changing the image of the button.
My question: Is it better to Use UIViews and make my own buttons, or actual UIButtons that have been subclassed to use touchesBegan etc?
For anyone that finds this while searching, using touchesBegan, ended, and moved is WAY faster. In terms of a rhythm game or application requiring fast input, this is the way to go.
Related
I already have my app finished but i want to polish it with some nice animations. Nothing to crazy, I just need to loop through some sprites to make it look like a plant is growing. For obvious reasons, I don't want to try and work this into a cocos2d framework. I found a couple animation classed on the web, but the animation look crappy and unnatural. Any ideas as to how I can best achieve this?
UIImageView animations would be the easiest. http://mobile.tutsplus.com/tutorials/iphone/uiimageview-animation/
I am trying to program an iPhone app where the user can handwrite. I am using touchesmoved to track the user's finger, but I get between 30 and 50 updates a second. For quick finger movements, this is often no enough to get smooth letters: small letters like i often just get the touches began and then the touches ended points, with no points in between.
I was wondering if I could get better time (and space) resolution by using an NSTimer to query the touch object for its locationInView without waiting for it to call touchesmoved. Anyone knows if this might work?
Thanks.
I'll advise against NSTimer - its better to use CADisplayLink approach. For example, try to use my tiny lib https://github.com/nt9/NTLoop
I just wanted to know how you could implement a bookcase, like in iBooks, into your iPhone app.
I presume you would need to use a UIScrollView, but then I read somewhere that you need to use a UITableView. Which is it?!
You'd use code that others have already written, such as AQGridView.
I'm not sure if there's a better way, but you could create multiple small views or images (these would represent each book) then add these small views/images to the subview of a larger view in a linear format (leaving a space between each element). Then just set the background of your larger view as an image of a bookcase. Sorry I don't know of a better way.
And for the above solution I would use a UIScrollView.
You can implement it anyway you like, but it seems to me that a UITableView would be the easiest (which will scroll anyway). All of the magic will happen in your UITableViewDataSource, which is where you will decide what books are placed on what row.
Once you have decided which books to display you will have create a custom tableview cell that draws the appropriate objects.
To be honest, while not too difficult of a task, it will take a lot of effort to get looking right. If you are not comfortable with custom drawing then be prepared to spend time learning about the various image/graphic APIs.
I've been trying to get this right for weeks now, and though I've learned a lot through my misfires, at this point, I just need a solution. The issue is with unpacking the seemingly overlapping graphics and UI APIs included in Cocoa, many of which produce similar effects, but feature unique limitations that I've often discovered only after investing many hours into an implementation.
I'm new to Cocoa, but not to programming, and I'm trying to create a Mac app with a very customized UI – think Capo, Garageband, or Billings. One view in my window will display an ordered list of subviews, each of which does a lot of custom drawing, and each must support a "selected" state and drag-reordering. The subviews do not need to support being dragged outside of their superview.
Ideally, a drag will give animated feedback as it happens, pushing neighboring sibling views to make space, e.g. toolbar icons or the Safari bookmarks bar. The trouble is, I can't seem to land on the right pack of technologies to get this right. I've done the subviews as NSView subclasses in an NSCollectionView and also as CALayers in a custom CollectionView-like NSView, and neither seems to offer the perfect solution. That said, the first option seems the better of the two for its superior handling of mouse events.
I've not yet tried doing this as a TableView, and I don't want to go down that path without some indication I'm on the right track. Extensive Googling has shown only that there aren't any up-to-date resources on CoreAnimation-enabled reordering or dragging. As such a standard feature of the OS X UI, I feel like this should be easier!
Any help from anyone on what the right tools are for this job would be greatly appreciated. TIA.
I used to use and love RBSplitView, however I failed at reimplementing it programmatically as a certain version of xcode does not support IB plugins anymore.
Therefore I went back to using NSSplitView. NSSplitView is fine for what I need, the thing is that the autoSave of NSSplitView is broken. So I decided to implement it myself.
The thing I am doing at the moment is resizing 1 of the subviews of the NSSplitView.
What is the proper way of resizing an NSSplitView? - setPositionOfDivider:itIndex: should be the way to go ( haven't tried it ), however I do not know how to get the current position of the divider.
-- thanks in advance
In my experience, NSSplitView hates you and wishes you harm. RBSplitView is so much better, it is worth IMO the headache of programatic layout (and I've been so burned with the ShortcutRecorder IB plugins that I will never go back to IB plugins).
That said....
The only way that I know of to determine the current position of the divider is to look at the subviews, find the divider's view, take it's frame, and work out its position keeping in mind the dividerThickness. It is insane that you have to write that code, but the code isn't that incredibly difficult, and you can put it in a category.
Or go back to RBSplitView while you still can, if your needs are ever going to be complicated.
I'm using Swift here but the same method should exist in Objective C:
mySplitter.setPosition(123, ofDividerAtIndex: 0)