I search for a possibility to migrate my PC OpenGL application and an iPhone App into one XCode project (for convenience). So if I make chances to these source files I want to apply this for both plattforms and want to be able to compile for both plattforms from one project. How could I accomplish this?
Is there a way to do so in XCode 4 or 3.25? Any help would be highly appreciated
edit: Okay, I went so far - All in all, it seems to work with XCode 4.
My only problems are these openGL/Glut functions, that aren't working on iPhone:
glPushAttrib( GL_DEPTH_BUFFER_BIT | GL_LIGHTING_BIT );
glPopAttrib();
glutGet(GLUT_ELAPSED_TIME);
glutSwapBuffers();
Any ideas how to fix these issues?
PushAttrib/PopAttrib you'll need to replace yourself with code which manually tracks those states, or you could rewrite your code in such a way that anything which relies on those states, sets them itself.
glutGet(GLUT_ELAPSED_TIME) could be replaced by mach_absolute_time (not particularly easy, but the right thing to use) or [NSDate timeIntervalSinceReferenceDate] (easy, but potentially problematic since it's not guaranteed to be monotonically increasing, or to increase at 1.0 per second)
glutSwapBuffers will be replaced by -presentRenderbuffer: on your EAGLContext (but it sounds like you're already doing this; if you weren't, you wouldn't be able to see anything).
You could use dgles to wrap your desktop OpenGL implementation and provide a OpenGL ES 1.x interface.
I found this documentation online in regards to the OpenGL ES 1.0 specification
There are several reasons why one type or another of internal state needs to be queried by an ap- plication.The application may need to dynamically discover implementation limits (pixel component sizes, texture dimensions, etc.), or the application might be part of a layered library and it may need to save and restore any state that it disturbs as part of its rendering.PushAttrib andPopAttrib can be used to perform this but they are expensive to implement and use and therefore not supported.Gen- erally speaking state queries are discouraged as they are often detrimental to performance.Rather than trying to partition different types of dynamic state that can be queried, tops of matrix stacks for example, no dynamic state queries are supported and applications must shadow state changes rather than querying the pipeline.This makes things difficult for layered libraries, but there hasn’t been enough justification to retain dynamic state queries or attribute pushing and popping.
That and this other link here seems to indicate that you'll need to keep track of those bits yourself. No help for you there.
glut just calls the system code, yeah? (wglSwapBuffers, glxSwapBuffers)
Try this here eglSwapBuffers and maybe this book out
Sorry I don't have a more concrete answer for you.
very annoyed by this lack seemingly simple functionality of pushing attribs, but you can use glGetto get the state of something before you set the param , like this which worked for me:
Boolean tmpB;
int tmpSrc,tmpDst;
glGetBooleanv(GL_BLEND,&tmpB);
glGetIntegerv(GL_BLEND_SRC_ALPHA,&tmpSrc);
glGetIntegerv(GL_BLEND_DST_ALPHA,&tmpDst);
glEnable(GL_BLEND);
glBlendFunc(GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA);
//draw rectangle
CGSize winSize=[[CCDirector sharedDirector] winSize];
CGPoint vertices[] = { ccp(0,0), ccp(winSize.width,0), ccp(winSize.width,20), ccp(0,20) };
glColor4ub(255, 0, 255, 55);
ccFillPoly( vertices, 4, YES);
if(!tmpB)
glDisable(GL_BLEND);
glBlendFunc(tmpSrc, tmpDst);
Related
The title pretty much says it. What I really want is a layer mode that takes the alpha channel of the one below it and in all other respects behaves the same. The general question seems worth asking.
I'm skimming the docs, and it seems like layer modes are a fixed enum, but I wan't to be sure there isn't something I'm overlooking. I'll also take any alternative suggestions.
Thanks.
No - it is not possible to add new layer modes but for including your own modes inside GIMP source code.
However, layers are a bit more generic now, since they can be written as a GEGL operation - I'd have to check the source, but all that is needed is probably to write the proper GEGL operation (which is easy to derive from the other layer modes), and add the new operation to the enums. The big drawback of this approach as compared to plug-ins is that you can't share the layer mode with other GIMP users, and even worse: the XCF files you create with your custom mode will only be "readable" in your modified copy of GIMP.
An workaround is to write a plug-in that creates a new layer from two underlying layers, combining them as you like. You'd have to invoke it manually each time you updated each layer. You'd have to use Python-fu, instead of script-fu,a s the later does not give one access to pixel values.
For the simple case you describe, though, it seems like a sequence of "alpha-to-selection",
"selection-to-channel", "copy", "add-layer-mask", "paste" can do what you want without a need to copy pixels around in a high level language.
After not programming for a long, long time (20+ years) I'm trying to get back into it. My first real attempt is a Scrabble/Words With Friends solver/cheater (pick your definition). I've built a pretty good engine, but it's solves the problems through brute force instead of efficiency or elegance. After much research, it's pretty clear that the best answer to this problem is a DAWG or CDWAG. I've found a few C implementations our there and have been able to leverage them (search times have gone from 1.5s to .005s for the same data sets).
However, I'm trying to figure out how to do this in pure Objective-C. At that, I'm also trying to make it ARC compliant. And efficient enough for an iPhone. I've looked quite a bit and found several data structure libraries (i.e. CHDataStructures ) out there, but they are mostly C/Objective-C hybrids or they are not ARC compliant. They rely very heavily on structs and embed objects inside of the structs. ARC doesn't really care for that.
So - my question is (sorry and I understand if this was tl;dr and if it seems totally a newb question - just can't get my head around this object stuff yet) how do you program classical data structures (trees, etc) from scratch in Objective-C? I don't want to rely on a NS[Mutable]{Array,Set,etc}. Does anyone have a simple/basic implementation of a tree or anything like that that I can crib from while I go create my DAWG?
Why shoot yourself in the foot before you even started walking?
You say you're
trying to figure out how do this in pure Objective-C
yet you
don't want to rely on a NS[Mutable]{Array,Set,etc}
Also, do you want to use ARC, or do you not want to use ARC? If you stick with Objective-C then go with ARC, if you don't want to use the Foundation collections, then you're probably better off without ARC.
My suggestion: do use NS[Mutable]{Array,Set,etc} and get your basic algorithm working with ARC. That should be your first and only goal, everything else is premature optimization. Especially if your goal is to "get back into programming" rather than writing the fastest possible Scrabble analyzer & solver. If you later find out you need to optimize, you have some working code that you can analyze for bottlenecks, and if need be, you can then still replace the Foundation collections.
As for the other libraries not being ARC compatible: you can pretty easily make them compatible if you follow some rules set by ARC. Whether that's worthwhile depends a lot on the size of the 3rd party codebase.
In particular, casting from void* to id and vice versa requires a bridged cast, so you would write:
void* pointer = (__bridge void*)myObjCObject;
Similarly, if you flag all pointers in C structs as __unsafe_unretained you should be able to use the C code as is. Even better yet: if the C code can be built as a static library, you can build it with ARC turned off and only need to fix some header files.
As the iPad app I am making has been growing its size, it is hard for me to keep track of UI design values. Here, I am talking about values such as a table's width, background colors, and a title's font.
I would like to organize all UI design-related values and objects more efficiently.
How do you organize these?
Do you #define values in a header file?
Do you declare them as global variables or not?
Do you put your values one static class?
Or do you think not-organizing these values is rather better?
I would like to hear your advice.
Thank you :)
Yes it depends, therefore just some rules of thumb...
Do you #define values in a header file?
...in cases where I might want to change this locally only, eg for constants, colors, alignments, button images, ... the main reason why I do this however is the documentation it allows by giving the local defines a long explaining name
Do you declare them as global variables or not?
...an all my apps I have a MainDataManager Class, that holds all the variables I need globally - for the UI part often I have my own globally used object. This is extremely useful, simplifies the code, and probably one of the most important things I learned early on. might also see here Using Variable of AppDelegate as a Global Variable - question regarding release/retain
Do you put your values one static class?
...static classes exist kind of conceptually. Static variables are quite useful when you want to give a method some kind of memory of its own. However, none plays an important role in my UI.
In general, I like to use IB to layout the screens but set all the button names, labels, texts in the code. Why? Because when I have to localize the app maintaining multiple XIB files (for each language there will be one isolated XIB file to maintain) becomes a real burden even if there is only one single change in the layout.
All the global constant settings are always kept in GloblDefinitions.h while at the same time I have in my .pch file this entry #import "GlobalDefinitions.h"
So the combintation of a delegate variable provided globally + GlobalDefinitions.h for constants is my solution.
Its a good question. When combining use of interface builder with hand-coded UI tweaks and/or custom components you also have the problem of duplicated values between IB and code.
In some situations, for readability and for easy adjustment by a third party its easier if values are just hard coded in-place - so in trival cases (e.g. cases where the value is not repeated anywhere else or is unlikely to change) this might be a valid option.
In general, if the constants are specific to the layout of a particular UI component then it seems to make sense to #define them in the header file for the UI component that uses them - I think putting them all in one global file breaks the decoupling that you'd like to have between user interface components, and also for readability it can be easier for another dev to find them in the header file.
On the other hand if there are values that are used consistently across multiple UI components within the one application, then these can be defined in a global include file. Similarly if there are 'base' values that are used to derive other lengths etc. that are used commonly across multiple UI components these also can be stored in a global include.
Also whereever possible make use of the layout manager margin flexibility settings and width/height flexibility settings to minimise the need to hard code values. And when relevant, derive values from a base value or a system value (e.g. screen width).
At the end of the day if the value is there in code in front of you sometimes that much easier to figure out and tweak than changing a #define off in some other file - on the other hand - if the same value is repeated in multiple places and a #define is not used, then it can be very confusing for another coder to come in and change one of these repeated values only and try to understand and sift through the resultant side effects and which other places the value should be changed.
Well Ryan that depends upon you..
You can either use pre processor directives..
declaring in .pch file.
or you can either make an object class taking all the constants....
Hope that will help you..
Thanks
This is what I have learnt from few of my previous projects.
1] Naming conventions - use appropriate and standardized prefix. ex tblRecordLis, viewControlPanel etc.
2] Keep Constants together - keeping all constants at one place reduces the pain of searching entire project to find/fix/replace constants and their values.
3] Grouping relevant Classes together according to utility and their functionality.
4] UI constants like size, offsets , frame values (Which you need to hard code) can be kept in constants
a few which I used are
#define MenuPopoverFrame CGSizeMake(278, 550);
#define LandscapeContentSize #"{{0,0},{719,734}}"
#define PortraitContentSize #"{{2,0},{765,980}}"
5] Using IB as much as possible as it gives us more flexibility.
6] PROPER commenting and documentation proves to be a life saver when dealing with debugging.
I find it easy to declare keys as constants as using them at multiple places also increases the chances of error if used as such. eq key named #"method" can be better declared as
#define kMethodKey #"method"
This very simple thing saves my time while debugging when the project size grows larger.
** Taking hints from Apple's samples also gives you a great help in keeping your code standardized.
I'm getting up to speed with the new APIs introduced in OS 3.0, especially the cool new improvements to Core Animation (mostly on CALayer etc...). Now I'm trying to figure out how to use CAGradientLayer. It looks simple at first, but the NSArray it requires for the colors property must contain CGColorRef (according to the header file). I've tried casting to (id), but then the NSArray seems to contain NSCFType objects, which doesn't sound good.
Anybody figured how to use it or could point to some good code samples?
Thanks
Even though the NSCFType objects in the array "don't sound good", you are supposed to use CGColorRefs directly in the array. The same principle applies here as for the animation question I asked a while back. The examples I've seen for using this class all employ arrays of CGColorRefs.
can anyone please tell me what are the equivalent functions for glArrayElement()& glTexGeni() in openGL ES..
There is no equivalents for these two functions.
OpenGL|ES is a stripped down and leaner version of OpenGL, so some stuff has been left out.
glArrayElement is not required as the whole glBegin / glEnd rendering mode has been removed from GL|ES. glArrayElement does not make sense without the glBegin/glEnd anymore. Since you'll have to rewrite the rendering code to use glDrawArrays/glDrawElements you will not miss it.
glTexGen has been removed as well. If you use a later version of GL|ES, you can emulate all the functionality using vertex shaders. If you're stuck with early GL|ES (1.0 or 1.1) you have to emulate it in software (e.g. calculate the texture coordinates on your own and pass them to gl via glTexCoordPointer).