Torque and cocoa
by Mark Kromis · in General Discussion · 09/10/2005 (1:24 pm) · 4 replies
I downloaded the newest version from cvs, and found that you had a cocoa files, but it looks like it more of just CoreFoundation etc.., either way keep up the good work.
I updated later from cvs and it seems that the files are missing. Are you planning to put the CoreFoundation/Cocoa stuff back in? Is it a wip? Are you going to completely drop Carbon?(please?)
As looking through the code I found some strange code. In the cocoa file you had
Can you tell me what this is? Can I comment this out? This is trowing an error.
This almost seems to be a diff file header.
Keep up the great work.
I updated later from cvs and it seems that the files are missing. Are you planning to put the CoreFoundation/Cocoa stuff back in? Is it a wip? Are you going to completely drop Carbon?(please?)
As looking through the code I found some strange code. In the cocoa file you had
#include "PlatformMacCarb/platformMacCarb.h"but should be
#include "PlatformMacCocoa/platformMacCocoa.h"
Can you tell me what this is? Can I comment this out? This is trowing an error.
This almost seems to be a diff file header.
<<<<<<< resManager.h ======= >>>>>>> 2.4
Keep up the great work.
#2
1) about this stuff...
That stuff came in when you updated with CVS. It tried to auto-merge in the new stuff to your existing codebase. But things did not go perfectly, it found a place it couldn't figure out how to merge: a 'conflict'. The stuff betweeen the "<<<<<" and "=====" is your old code. The stuff between the "=====" and ">>>>" is the new code. You'll have to read through it, and edit the file to merge them by hand. It's a pain, but it happens all the time in software dev, and it gets easier with practice.
2) We don't have Cocoa files. We're not using Cocoa. Here's why:
- Carbon is a C interface to the OS, Cocoa is an Objective-C interface. This means that in some cases, Carbon is faster.
- Carbon was backwards compible to OS9. Back when the mac platform was initially written, that was seen as important. It's not important anymore, and OS9 support has been gone for a long time. But the old code remains.
- Some parts of the platform code *must* be written with Carbon. The unicode font rendering and text input springs to mind ( probably because I've been working on it for a few weeks ). We have to use the ATUSI interface, which is part of Carbon and dates back to OS9, to get the fine control and metrics we need to proerly render unicode text.
- Torque's event handling is naughty. Very naughty. All polling. That can't change without re-engineering the way that Torque itself, outside of the platform layer, deals with events. Naughty polling event handling is ok in some cases, such as realtime apps, which are by their nature designed to use all the resources they can, in order to give you the best gameplay experience ( i.e. framerate ). Cocoa doesnt like naughty event handling; Carbon lets you get away with more.
So, yeah. There are a lot of reasons why we don't use Cocoa.
That doesnt mean we wont use Cocoa in future... It's just not the best choice at the moment.
09/12/2005 (3:04 pm)
OK, answers to your 2 questions:1) about this stuff...
Quote:<<<<<<< resManager.h
=======
>>>>>>> 2.4
That stuff came in when you updated with CVS. It tried to auto-merge in the new stuff to your existing codebase. But things did not go perfectly, it found a place it couldn't figure out how to merge: a 'conflict'. The stuff betweeen the "<<<<<" and "=====" is your old code. The stuff between the "=====" and ">>>>" is the new code. You'll have to read through it, and edit the file to merge them by hand. It's a pain, but it happens all the time in software dev, and it gets easier with practice.
2) We don't have Cocoa files. We're not using Cocoa. Here's why:
- Carbon is a C interface to the OS, Cocoa is an Objective-C interface. This means that in some cases, Carbon is faster.
- Carbon was backwards compible to OS9. Back when the mac platform was initially written, that was seen as important. It's not important anymore, and OS9 support has been gone for a long time. But the old code remains.
- Some parts of the platform code *must* be written with Carbon. The unicode font rendering and text input springs to mind ( probably because I've been working on it for a few weeks ). We have to use the ATUSI interface, which is part of Carbon and dates back to OS9, to get the fine control and metrics we need to proerly render unicode text.
- Torque's event handling is naughty. Very naughty. All polling. That can't change without re-engineering the way that Torque itself, outside of the platform layer, deals with events. Naughty polling event handling is ok in some cases, such as realtime apps, which are by their nature designed to use all the resources they can, in order to give you the best gameplay experience ( i.e. framerate ). Cocoa doesnt like naughty event handling; Carbon lets you get away with more.
So, yeah. There are a lot of reasons why we don't use Cocoa.
That doesnt mean we wont use Cocoa in future... It's just not the best choice at the moment.
#3
1. About the CVS update. The files came directly from a new cvs pull. So I wasn't alerted to any conflicts at the time, because no files were downloaded yet. I normally use xCode which has built in manager.
2. About the Cocoa files, I agree that Carbon can be faster then Cocoa, but are you considering CoreFoundation as Carbon? I'm pretty sure that they are not considered to be same. Have you looked into using Quartz for text rendering, or is that a big change?
3. I very briefly looked into the event handling, I think I need to study that more. What is the general opinion about using HID and/or Force Feedback? Would that help with the event handling or hinder it? Are you going to re-add joystick support back in? It appears commented out at the moment.
Thanks for your patience.
09/12/2005 (10:58 pm)
@Paul1. About the CVS update. The files came directly from a new cvs pull. So I wasn't alerted to any conflicts at the time, because no files were downloaded yet. I normally use xCode which has built in manager.
2. About the Cocoa files, I agree that Carbon can be faster then Cocoa, but are you considering CoreFoundation as Carbon? I'm pretty sure that they are not considered to be same. Have you looked into using Quartz for text rendering, or is that a big change?
3. I very briefly looked into the event handling, I think I need to study that more. What is the general opinion about using HID and/or Force Feedback? Would that help with the event handling or hinder it? Are you going to re-add joystick support back in? It appears commented out at the moment.
Thanks for your patience.
#4
1) I'll look into that file asap.
2) CoreFoundation isn't really either Carbon or Cocoa, but a seperate thing which is available to both. ATSUI already uses Quartz. Torque draws text as a series of quads, 1 per character, using a texture map containing the drawn character's glyph. Check out dglDrawTextN(), it's a pretty easy read.
3) Implementing support for more advanced input devices is unrelated to event handling. Yes, they generate events which must be handled, but using them doesn't change the basic handling philosophy I was talking about. I'm looking at adding support for joysticks, gamepads and the like in 1.4 . I have been sent a code dump from Kurtis Seebaldt, that has some promising stuff in it. I want to get this into 1.4, but I have a few other things on the list first.
/ Paul
09/13/2005 (12:26 am)
@Mark:1) I'll look into that file asap.
2) CoreFoundation isn't really either Carbon or Cocoa, but a seperate thing which is available to both. ATSUI already uses Quartz. Torque draws text as a series of quads, 1 per character, using a texture map containing the drawn character's glyph. Check out dglDrawTextN(), it's a pretty easy read.
3) Implementing support for more advanced input devices is unrelated to event handling. Yes, they generate events which must be handled, but using them doesn't change the basic handling philosophy I was talking about. I'm looking at adding support for joysticks, gamepads and the like in 1.4 . I have been sent a code dump from Kurtis Seebaldt, that has some promising stuff in it. I want to get this into 1.4, but I have a few other things on the list first.
/ Paul
Torque Owner Jake Oster
"Can you tell me what this is?"
That would be CVS version comments.
"Can I comment this out?"
Yes! You're going to want to check out the source in that area to make sure it's kosher before trying to do another build though.
Good luck!