I'd like to have a water effect on a background layer in my app. The effect doesn't need to react to touch or anything - it just needs to wave an image a little bit.
CCWaves3D seem ok, but leave have nasty black artifacts around the edges when I run it. Similarly CCShaky3D. CCLiquid brings my app down from 20fps to 5fps..
Is there any other effect I might want to try out? Or perhaps I'm using the current effects in a wrong way?
id shaky = [CCShaky3D actionWithRange:4 shakeZ:NO grid:ccg(15,10) duration:4];
id liquid = [CCLiquid actionWithSize:ccg(15,10) duration:1];
id wave = [CCWaves3D actionWithWaves:18 amplitude:80 grid:ccg(15,10) duration:10];
Bonus question - where can I find any good documentation for cocos2d effects? I found default cocos2d docs utterly useless & wasted a couple of hours trying to google before asking this question :/
I have noticed performance issues when building/running in debug mode. Have you tried to build/run in release mode? Also, are you experiencing this on the device and not just on the simulator?
Unfortunately, I have not found alternate documentation specifically for cocos2d effects. Here are a few links to posts and sites I have gathered for many different resources including tutorials, tools for making tile map games, using zwoptex for making sprite sheets, using vertex helper for making a verticies plist file for box2d/chipmunk collision detection instead of just rectangles, and sites for images & sounds:
Cocos2d Resources
Need 2D iPhone graphics designed
http://www.learn-cocos2d.com/knowledge-base/tutorial-professional-cocos2d-xcode-project-template/
I have found Ray's Tutorials especially helpful along with viewing the test applications included with cocos2d.
Happy coding!
Related
I am relatively new to sprite kit and have been attempting to create my first basic game. All physics and other basics seem ok, but for some reason whenever I build and run the screen dimensions are off (looks like default is 1024×768)?
Pretty sure I'm missing something fundamental here but it doesn't seem immediately obvious on how to adapt the screen to any size iPhone screen (this is my ultimate goal).
My question is whether this is actually just a setting issue or is it necessary to implement code?
Thanks in advance and have a great day!:)
To answer the first part, you can easily change the size of your scene.
If you take the default GameScene, click out of the scene and look at the Attributes Inspector. You will see the default size of 1024,768. Personally if landscape I tend to work with an iPhone 5 design resolution of 568,320.
Regarding multiple devices, SpriteKit works pretty well out the box. You should look at the documentation regarding scaleMode, take a look in the GameViewController.swift. .AspectFit worked really well, nearly pefect across all devices apart from a little letterboxing on iPad. However, for the amount of effort put in, more than good enough.
On a side note, I've found the following iPhone Resolution Guide resource useful in the past.
I need to implement on-screen drawing feature within one of my apps. I would imagine it would be an on-screen transparent overlay. I'm looking to be able to trace the finger path and leave a line, select colors and have erase/undo feature.
I did some research of what's currently on the app store, and a lot of those apps look similar and use similar brushes.
Something tells me that they look too much alike for this to be a coincidence. Does apple provide any built-in finger painting canvas, or are there some widely-known open source projects for on-screen drawing?
Thank you!
I ran into the same thing while looking for examples when I got started with drawing, so I released my efforts as a sample project called SimpleDrawing. I tried to keep things basic while supporting most/all of the standard drawing tools and operations.
There is the GLPaint project, which you can get here.
Other than that, you could use CoreGraphics & -touchesBegan:withEvent: if you wanted.
First of all thanks for taking the time to read through and attempt to help with the problem I'm having. First question posted here and after reading through the startup agreement I'll try and be descriptive as possible =)
I'm currently working on a Game for the Iphone as my final year university project. This game is one I hope to continue working on and expanding after I leave and use as a springboard for my CV into the industry. I've got a good few months left, so plenty of time to take things slowly and carefully plan it out.
I have a background in Java and OpenGL in C++ so I understand some of the basic fundamentals. I'm not that experienced in Objective C yet, need to start somewhere =), so I apologise for any obvious mistakes I'm making. The current state of code is i've got multiple items rendering to a single OpenGL ES view based on the OpenGL ES 1.1 model. I feel since the project is primarily 2D I shouldn't need to go to the higher version. I would post up the code I have but it's full of prototyping and misc code and is incredibly messy. In fact I wouldn't mind restarting the code as a multi view template then moving over the blocks of code as I get them working.
I've done research through many different mediums as to the ideal way to create a multi view application with each view being OpenGL-ES based. I've seen many tutorials on using the UI-kit view with an OpenGL view, but I've decided the best way for my project to ensure full dynamic and customisation I'd be happier using openGL for all the views.
TL;DR:
The question I'm trying to ask is if theres a good tutorial or template anywhere I'm missing that will allow me to start up a new multi view project that will allow me to switch between multiple views (Menus etc)?
You can't go far wrong with cocos2d if you're making a 2D app but want it to be openGL accelerated.
I'm trying to create a relatively simple game with 2D graphics which has somewhat complicated animations. I tried to develop the game with the basic Core Graphics and Core Animation libraries but the animation performance of the game objects is not satisfactory (i.e. jerky/delayed).
So, I am now looking into Cocos2D which looked very promising until I checked into the high resolution support for the iPhone 4. This doesn't seem to work very well at all, but then again, i've just started to look into it.
The one thing the documentation seems to say about the issue it so simply use the CCDirector to set the scale factor, which can be done like so:
if( [[UIScreen mainScreen] respondsToSelector:#selector(scale)]) {
[[CCDirector sharedDirector] setContentScaleFactor: [[UIScreen mainScreen] scale] ];
}
However, this doesn't give the behavior I expect. It simply doubles the amount of pixels to work with, meaning I have to take the 'double pixels factor' into account in all my code.
In the Core Graphics/Animation libraries the coordinate space we work with doesn't change. Behind the curtains it simply doubles everything to fill the iPhone 4 high res screen and uses the #2x images where available. This actually works very well and the game logic need not take the device's resolution into account. Cocos2D seems to have implemented this pretty badly, making me not want to go onboard the Cocos2D train.
I found some other topics on the subject but there were no real answers that didn't involve workarounds. Is this being fixed? Am I doing it wrong or is Cocos2D simply not high res ready? Are there any alternatives to Cocos2D which can give me what I need?
Sorry for the shameless self-promotion but I guess it can help you out. I've written two small blog posts on high res in cocos2d recently and put them up on our website.
The first one goes into detail as to how to get cocos2d up and running including a proposed fix for how to implement the auto-loading behaviour of regular vs high-res images.
Additionally, there is a second post trying to go into some details on the difference between points and pixels. UIKit is entirely based on points which is why you do not have to re-work all your coordinates. In contrast to UIKit, cocos2d works based on pixels and is therefore resolution-dependent. You can provide cocos2d with the means to work with points rather than pixels through some rather simple conversions. I've implemented those as categories for CCDirector and CCNode to make them easy to work with. Obviously, the methods in these categories are not the only ones one should "pointify". Specifying sizes on CCLabel or any positions on CCMoveBy, for example, are pixel-based and thus would have to be reworked also ...
Have a look at the blog at: http://apptech.next-munich.com/ (I would've directly linked to the articles but as a new user I can only post a single link in an answer).
Hope this helps and gets you started!
I'm in the process of figuring out a pretty simple solution to this. My progress is posted here: http://www.cocos2d-iphone.org/forum/topic/8511#post-50361
Basically you scale your the texture source rects in CCSprite, but nothing else, that way you get to use your same 320x480 coordinate system(aka a points system), but you get high res graphics.
You should combine my technique with this with point #2 from Benjamin's blog here, so you don't get memory problems: http://apptech.next-munich.com/2010/07/high-res-using-cocos2d-on-ios-4.html
Cocos2D uses the UIImage methods imageWithContentsOfFile: and initWithContentsOfFile: which, despite what the documentation says, don't correctly return the #2x versions of images when on the iPhone 4.
This is a known bug and apparently Apple are working on it.
However, some people believe this is correct behaviour as it is passing a path to a specific file, rather than a name of a file and letting the system decide which one to use. In that case, I have proposed that the documentation be updated to reflect this fact if it is true. We'll see how Apple respond.
What are some suggested "paths" for getting better at drawing in code in Cocoa? I think at this point, that's my biggest weakness. Is drawing in code something general, or Cocoa-specific?
Thanks!
- Jason
The best way is probably practice. Try drawing some simple things at first: a calendar (basically a grid), a custom button, or a digital clock.
Its also worth noting that a lot of 'custom' controls are made from images, so not that much of the drawing is done in code -- the only thing the code does is stitch those images together.
You might want to look at Opacity, a drawing app for OS X (I'm not affiliated with these folks, just discovered the app a few days ago). What sets Opacity apart from other drawing apps is that it can create Quartz code directly from your drawings. Naturally, the generated code is not perfect but in the few days I've been trying this app I've found it to be quite helpful in understanding how to use Quartz more effectively.
Drawing in code is need for creating custom controls no matter what UI toolkit you pick. Drawing in code certainly has its advantage, for example the application/framework that you are building is really lightweight come production time, cause there will be lot let resources(images/fonts/etc) to worry about.
Also if a problem arises changing drawing in code is a lot easier than to redo code and images together.
If you are doing Cocoa drawing start by looking at source code of BGHudAppKit and reading Cocoa Drawing Guide by Apple.
I'm in the same boat as you; I'd like to learn more about drawing code.
It's a big document, but the Quartz 2D programming guide on the developer website seems like a good place to start from. They introduce Graphics Contexts and Paths and include plenty of images.
There's also a book referenced in that document, Programming With Quartz: 2D and PDF Graphics in Mac OS X which looks good. The APIs for iPhone and OSX are almost identical, so there's no problem using a Mac OSX book.
So I'd suggest start with the Apple documentation (you don't need to read past the section on CGLayer drawing), try some sample code and figure out how it's working. Then move on to either that book or find more sample code on the web. Good luck!