Now is the time to learn Obj-C!

[Gan]

I do. I shall. I will.

Give me 30 min.


-Gan

[WarHampster]

Heh.

Also:

Obj-C works similarly. You can create classes and such.

Lol.

Obj-C is a lower level programming language. It's a tiny step above C. C is right above machine code. I think machine code is the base. RB is kinda slow and clunky. It's like a programming language on a programming language. It layers it's runtime over different languages which allows portability but decreases performance significantly.
Programmers who program in RB aren't any lesser. They just aren't making programs as high performance as natively made programs. Such as C#, C, and Obj-C programmers.

Machine code -> Native assembly -> C level -> BASIC level -> SC / GM level

Machine code -> Native assembly -> Virtual machine -> C#/ Java Level

Basically.

[Telstar5]

RB compiles binaries. So does Xcode. They're both native to the system already.

Personally I think you just take whatever Apple does as better than anything else.

I mean, if Apple decided that Xcode was rubbish and replaced it with RealBasic, you'd be calling Xcode a pos like you are RealBasic :\\

[Gan]

Are you sure RB compiles binaries? Or does it already have precompiled binaries that is filled with it's libraries and that it inserts resources?
I believe RB takes already compiled binaries and fills it. Which creates another layer and lesser performance.

I like Xcode because it works for me. It's stable, simplistic interface, to me easy, and even free. I know that Obj-C due to it's low level has incredible performance that RB can't stack up against.

Here's an article that also helps sum it up:
http://forums.realsoftware.com/viewtopic.php?f=10&t=7075

Rb is nice with it's cross-platform and easy learning curve. Obj-C is nice with it's functionality and performance.

Neither are bad, it's all a matter of choice and what you need.


-Gan

[Gan]

I do. I shall. I will.

Give me 30 min.

Sorry I took longer than 30 minutes but...

Scratch Game Making Obj-C Tutorial Part 1
Scratch Game Making Obj-C Tutorial Part 2
Source


-Gan
P.S. Here are the methods to fill the NSView:

Code: [Select]

-(void)awakeFromNib { 
       
} 
- (void) timerTick: (NSTimer *) gameTimer { 
       
      [self setNeedsDisplay:YES]; 
} 
 
- (void)mouseDragged:(NSEvent*)theEvent{ 
      //CGPoint aMousePoint = CGPointMake([self convertPoint:[theEvent locationInWindow] fromView:nil].x, [self convertPoint:[theEvent locationInWindow] fromView:nil].y); 
       
      [self setNeedsDisplay:YES]; 
} 
- (void)mouseUp:(NSEvent*)theEvent{ 
      //CGPoint aMousePoint = CGPointMake([self convertPoint:[theEvent locationInWindow] fromView:nil].x, [self convertPoint:[theEvent locationInWindow] fromView:nil].y); 
       
      [self setNeedsDisplay:YES]; 
} 
 
- (void)keyDown:(NSEvent*)theEvent{ 
      unichar aKey = [[theEvent charactersIgnoringModifiers] characterAtIndex:0]; 
      if (aKey == NSUpArrowFunctionKey) { 
             
      } 
      if (aKey == NSDownArrowFunctionKey) { 
             
      } 
      if (aKey == NSLeftArrowFunctionKey) { 
             
      } 
      if (aKey == NSRightArrowFunctionKey) { 
             
      } 
} 
- (void)keyUp:(NSEvent*)theEvent{ 
      unichar aKey = [[theEvent charactersIgnoringModifiers] characterAtIndex:0]; 
      if (aKey == NSUpArrowFunctionKey) { 
             
      } 
      if (aKey == NSDownArrowFunctionKey) { 
             
      } 
      if (aKey == NSLeftArrowFunctionKey) { 
             
      } 
      if (aKey == NSRightArrowFunctionKey) { 
             
      } 
} 
 
- (BOOL)isFlipped{ 
    return YES; 
} 
- (BOOL)acceptsFirstResponder { 
      return YES; 
} 
 
- (void)drawRect:(NSRect)dirtyRect { 
    // Drawing code here. 
       
} 
 
-(void) dealloc { 
       
      [super dealloc]; 
}

[Telstar5]

What? RB programs run, they're carbon so they're backward compatible with everything since OS 9, they're fast, they're easy to make, they can be as powerful or resource-wasting as you like so what does it matter?

I give up.

Xcode is the next best thing since sliced bread and I'm going to swear an oath to Apple under a picture of the Queen.

[Gan]

What? RB programs run, they're carbon so they're backward compatible with everything since OS 9, they're fast, they're easy to make, they can be as powerful or resource-wasting as you like so what does it matter?

You're confused Tel. RB programs are just like normal programs. Though they're built using old carbon or still buggy cocoa libraries. Besides that RB sets a layer on top of the program. That layer allows RB to be in essence its own language. Though the layer also causes a decrease in performance. Anything made in Rb won't be as fast as Obj-C just for that reason.

Xcode is the next best thing since sliced bread and I'm going to swear an oath to Apple under a picture of the Queen.

Xcode isn't the next best thing since sliced bread but it is useful. It gets the job done and even though it requires a large learning curve the results are fantastic.


-Gan

[Telstar5]

That layer deals with the GUI and letting it interact with the OS.

Just because Carbon is old doesn't make it worse than Cocoa. Carbon is far superior in its flexibility and Apple are stupid deprecating it.

[GMG Mike]

REALbasic compiles real machine code. The code references a framework (runtime) which handles all of the built-in RB classes such as Window, Socket, etc.

The latest versions have beta Cocoa support. If you compile a Carbon app and a Cocoa app, they both compile the exact machine code - only the framework is different.

[Gan]

That layer deals with the GUI and letting it interact with the OS.

Just because Carbon is old doesn't make it worse than Cocoa. Carbon is far superior in its flexibility and Apple are stupid deprecating it.

The layer still causes a slowdown.
Want to know something? Compare a game made in Sc to a game made in RB. If they are the same game RB will run faster. Why? Sc adds an extra runtime layer. Same between RB and Obj-C.

As far as I know Apple went for Cocoa to make it not only easier on the programmers to program but to have a more efficient framework for developing applications.

@Mike
Quick question. Realbasic uses an actual compiler to compile the code or is the app already compiled and it just inserts resources? If it uses an actual compiler how does it compile for pc on a mac?


-Gan

[WarHampster]

This is a stupid argument. Different tools are best for different jobs. I would never think of writing a networking application in C++, I'd use something simpler like Java (Telstar would use RB) that hides the gory details. At the same time, no one would want to write something like a modern 3d graphics engine in RB. You need low-level access to the GPU to write optimized 3d and RB doesn't have that functionality.

Neither is better, they're just different and have different purposes.

Likewise, if you go on Tigsource (a major indie-gaming forum), there are plenty of developers that use only Gamemaker (not Al's ). They get along just fine with the C/C++ people; both groups realize that the tools are meant to do different things.

BTW Xcode is an IDE. Has nothing to do with a specific language.

EDIT - I assumed that RB was interpreted, I'm actually interested in how that works now.

[Gan]

Well said.

EDIT - I assumed that RB was interpreted, I'm actually interested in how that works now.

I've always thought it was interpreted as well.


-Gan

[Telstar5]

Gandolf is the one suggesting that Mike ports SilverCreator to Objective C. He clearly doesn't want to, and you make a list of all the reasons as to why RealBasic sucks - mainly the gist of the argument is it's not an official Apple product OMG heathen get it out of my face etc and therefore is worth less than Obj C. At least that's what I gather from reading between the lines.

[WarHampster]

Gan's message with Apple propaganda removed: things get slower with every level of code above assembly, so SC would be faster if it was written in obj-c.

Personally I think that SC is doing just fine, while I'd like to see some extra functionality (especially being able to interrupt paint events, as we've discussed), it is more than fast enough for the types of games it is intended for.

[Gan]

Speed is nice but Sc is already pretty good.

My proposal was for Sc to get on the Mac App Store. Would be a huge popularity boost.

Though the Mac App Store regulations state:

2.1

Apps that crash will be rejected
2.2

Apps that exhibit bugs will be rejected
2.3

Apps that do not perform as advertised by the developer will be rejected
2.4

Apps that include undocumented or hidden features inconsistent with the description of the app will be rejected
2.5

Apps that use non-public APIs will be rejected
2.6

Apps that are “beta”, “demo”, “trial”, or “test” versions will be rejected
2.7

Apps that duplicate apps already in the App Store may be rejected, particularly if there are many of them
2.8

Apps that are not very useful or do not provide any lasting entertainment value may be rejected
2.9

Apps that are primarily marketing materials or advertisements will be rejected
2.10

Apps that are intended to provide trick or fake functionality that are not clearly marked as such will be rejected
2.11

Apps that encourage excessive consumption of alcohol or illegal substances, or encourage minors to consume alcohol or smoke cigarettes, will be rejected
2.12

Apps that provide incorrect diagnostic or other inaccurate device data will be rejected
2.13

Developers “spamming” the App Store with many versions of similar apps will be removed from the Mac Developer Program
2.14

Apps must be packaged and submitted using Apple’s packaging technologies included in Xcode – no third party installers allowed
2.15

Apps must be self-contained, single application installation bundles, and cannot install code or resources in shared locations
2.16

Apps that download or install additional code or resources to add functionality or change their primary purpose will be rejected
2.17

Apps that download other standalone apps will be rejected
2.18

Apps that install kexts will be rejected
2.19

Apps that require license keys or implement their own copy protection will be rejected
2.20

Apps that present a license screen at launch will be rejected
2.21

Apps may not use update mechanisms outside of the App Store
2.22

Apps must contain all language support in a single app bundle (single binary multiple language)
2.23

Apps that spawn processes that continue to run after a user has quit the app without user consent will be rejected
2.24

Apps that use deprecated or optionally installed technologies (e.g., Java, Rosetta) will be rejected
2.25

Apps that do not run on the currently shipping OS will be rejected
2.26

Apps that are set to auto-launch or to have other code automatically run at startup or login without user consent will be rejected
2.27

Apps that request escalation to root privileges or use setuid attributes will be rejected
2.28

Apps that add their icons to the Dock or leave short cuts on the user desktop will be rejected
2.29

Apps that do not use the appropriate Mac OS X APIs for modifying user data stored by other apps (e.g bookmarks, Address Book or Calendar entries) will be rejected
2.30

Apps that do not comply with the Mac OS X File System documentation will be rejected

3. Metadata (name, descriptions, ratings, rankings, etc)

3.1

Apps with metadata that mentions the name of any other computer platform will be rejected
3.2

Apps with placeholder text will be rejected
3.3

Apps with descriptions not relevant to the application content and functionality will be rejected
3.4

App names in iTunes Connect and as displayed on Mac OS X should be the same, so as not to cause confusion
3.5

All app icons should be similar, so as to not to cause confusion
3.6

Apps with app icons and screenshots that do not adhere to the 4+ age rating will be rejected
3.7

Apps with Category and Genre selections that are not appropriate for the app content will be rejected
3.8

Developers are responsible for assigning appropriate ratings to their apps. Inappropriate ratings may be changed by Apple
3.9

Developers are responsible for assigning appropriate keywords for their apps. Inappropriate keywords may be changed/deleted by Apple.
3.0

Developers who attempt to manipulate or cheat the user reviews or chart ranking in the App Store with fake or paid reviews, or any other inappropriate methods will be removed from the Mac Developer Program

Check out 2.14 and 2.5.
Mike definitely showed interest in a popular Sc. Though Sc would have to be bundled by Xcode in Obj-C. So I'm willing to help out.


-Gan
P.S. No more complaining about these rules and the Mac App Store. There's nothing we can do about it and complaining gets in the way of making progress.
P.S.S.

reading between the lines.

Sometimes that actual meaning is in the text.
P.S.S.S.....

Sorry I took longer than 30 minutes but...

Scratch Game Making Obj-C Tutorial Part 1
Scratch Game Making Obj-C Tutorial Part 2
Source


-Gan

Video's back up. In 2 parts.