Login Action Required

The NinevehGL Forum uses a new concept of "socialized forum" or as we like to say "Tweet Forum".

Here is the deal:
  1. No new registration is required. Just sign in with your Twitter account and authorize the NinevehGL Forum.
  2. Once you’re in, you'll be able to "Follow a Thread", that means every time that thread receive a new post or update you'll receive a mention on your twitter.
  3. Besides, you can enable "Auto Share", then every new post and/or thread you make will be tweeted on your timeline. (By default, auto-share is enabled only for your threads)

Forum Rules:

1. We understand human comunication can become "hot" sometimes. So some insults and bad words ARE allowed. Just don't push too much being an asshole all the time.

2. SPAMMERS are not allowed. There are penalties for this kind of user and they can be banned forever.

3. You can report other users, if you judge necessary. An user reported many times by many people can also be banned forever. However you can also receive penalties for report deliberately for no apparent reason.

If there is a similar thread title, make sure the other one doesn't already have the answer you're looking for.

This forum uses the BBCode (Bulletin Board Code), here are some instructions:

Bold: [b]text[/b]
Italic: [i]text[/i]
Underline: [u]text[/u]

Code: [code]text[/code]

[ul] [*]item [/ul]
[ol] [*]item [/ol]



Embed (videos, code, 3D):

Welcome to the NinevehGL's world!
NinevehGL is a 3D engine forged with pure Obj-C.
Welcome to the
Hello, Guest.

Your current vote:

You can change your vote many times. But it's still one single vote.

ARC practices?
Vote this thread:


Posts: 8


Sat, Oct 12 2013


Iam posting this with all due respect. NinevehGL is very impressive from what I have seen so far. Can I ask why your example projects use @public and @private methods even though it is generally frowned upon considering Objective-C's foundation of data encapsulation?

In terms of ARC, why are we not using @property and @synthesize?

For example:

#import <UIKit/UIKit.h>

@interface ViewController : UIViewController <NGLViewDelegate>

@property (nonatomic, strong) NGLMesh *meshview;
@property (nonatomic, strong) NGLCamera *cameraview;


and for the .m

#import "ViewController.h"

@implementation ViewController

@synthesize meshview;
@synthesize cameraview;

- (void) drawView
meshview.rotateY = 2.0f;
meshview.rotateX -= 0.5f;

[cameraview drawCamera];

- (void) viewDidLoad


[super viewDidLoad];

NSDictionary *settings = [NSDictionary dictionaryWithObjectsAndKeys:
kNGLMeshOriginalYes, kNGLMeshKeyOriginal,
kNGLMeshCentralizeYes, kNGLMeshKeyCentralize,
@"0.5", kNGLMeshKeyNormalize,

meshview = [[NGLMesh alloc] initWithFile:@"lower.dae" settings:settings delegate:nil];

cameraview = [[NGLCamera alloc] initWithMeshes: meshview, nil];
[cameraview autoAdjustAspectRatio:YES animated:YES];

// Starts the debug monitor.
[[NGLDebug debugMonitor] startWithView:(NGLView *)self.view];

- (BOOL) shouldAutorotateToInterfaceOrientation:(UIInterfaceOrientation)toInterfaceOrientation
return YES;

- (void) dealloc
[meshview release];
[cameraview release];
[super dealloc];


Lastly, can I ask why there are so many pragma marks?
0% like this - 0/0


Posts: 571


Sat, Oct 12 2013

In response to: @blackened5

Hello friend,

No problem in asking, we're here exactly for this.

Seems your questions goes all around general programming, C standards and Obj-C best practices, nothing on NinevehGL, but it's OK, it's good to talk about it.

By your questions, I suppose you're not programming iOS and Xcode since the very beginning.
So, here are some points that could solve your questions:

1 - First off, ARC is just a marketing strategy of Apple, not a good solution for expert developers. It's just a ways to minimize the learning curve of Obj-C and bring more developers from platforms that doesn't work directly with memory, like any ServerSide language, C# and Java.

2 - ARC it self or any other "@" directive is just a compiler instruction for Xcode. That means, @property and @syntesize is just a simple shortcut to really declaring the related stuff, like declaring the private variable with following the name pattern _myVariableName (inverse camel case with _ as prefix) and using KVC to declare the methods (- (DataType) foo; and - (void) setFoo:(DataType)value).

3 - Of course we use @syntesize and @property a lot, because it's a shortcut, but it was not always like that. In the early days of Xcode these are not valid compiler instructions, it just change from one compiler's version to another. Similarly @"myString" is just a compiler instruction for initializing an autoreleased instance of NSString with a pure C string "myString". So, in the end, using or not @syntesize will result exactly in the same compiled code. The point is, if you really know about this and what the compiler are doing you can have much more power by adjusting your code to exactly what you need.

4 - Finally about macros, as you notice, all our .h and .m files have a powerful pattern and organization, separating exactly the kind of methods, function, properties and everything we use. In time, you'll learn to use more Xcode shortcuts and see how it's easy to navigate between defined macros. So, with a single shortcut you can go to construction methods, to override public methods, and if you want to edit a private method, BUM, another shortcut and you go right there.

So, everything we put in NinevehGL is result of more than 13 years of experience programing, getting troubles, managing small and large teams of developers, testing and learning with the time. We still have too much to develop, new things to discover and many adjusts to make. However, everything we code, every single line, has a reason to be like that, has a pattern that we learned to be more efficient that others, even the names and the order we give to the variables has a reason to be.

Usually we found our selves just changing the orders of the variables just because it becomes cleaner and more according to our Best Practices.

Hope this helps.

PS: Just to exemplify, notice that in your example you has declared @synthesize meshview; without setting nor indicating an internal name for it (@synthesize meshview = _meshView). Just by this simple thing, in dealloc you put [meshview release], at this point, the compiler must do extra work to understand that you're talking about the internal variable meshview and not the method meshview. Once you use _ as prefix, it becomes much more clear what you want to do. Working with large dev teams, code must have so many patterns to make sure that any developer can easily understand what the other have wrote.
0% like this - 0/0


Posts: 8


Sat, Oct 12 2013

In response to: @blackened5

Okay... I get it now. At least I can understand what you guys are thinking. It impressive enough that you developed your own iOS graphics framework, so I am definitely NOT criticizing.

When I was learning iOS and Objective-C, they were very strict about @synthesize and @property.

That brings up another question. Should we be using ARC with NinevehGL?
0% like this - 0/0


Posts: 571


Sat, Oct 12 2013

In response to: @blackened5

Hello buddy,

I totally understand your question, you have the right to know about what are you using.

About the property and synthesize, it's truth that for your daily work it helps a lot, much more faster than writing down all the methods for KVC. But as I said, it's just a shortcut, the compiler will convert then all into methods before compiling the final code.

About the ARC and NinevehGL, nothing to worry about.
NinevehGL is given as a pre-compiled code, so when compiling your APP the Xcode will just skip all the NinevehGL stuff. And what about the public headers (.h) files, you might ask.

Well, we make sure for using Macros that our public header files will have no conflicts with ARC or non-ARC Apps.

In fact, we use a nice Macro trick to make sure the code can be compiled with or without ARC using the exactly same code, without change even one single line of code.
0% like this - 0/0

NinevehGL is a 3D engine built right on top of OpenGL ES and it uses all the programmable pipeline power, making it easy for you to create great application with shaders.

Share on

Follow NinevehGL
Fastest way to contact us:

Copyright © 2011 db-in. All rights reserved.