Something I'm getting frustrated with...

Member
Posts: 116
Joined: 2005.02
Post: #1
I can't find out how to map key functions in C++...I've looked everywhere...I know how to do it in SDL but don't want to use SDL because it requires the user to have SDL installed even for the stupidest little apps...I tried getkeys(); but it turns up wrong...any suggestions? Anything I've overlooked? Sorry if this is really stupid but, this is the only fundamental I can't find Annoyed

Last login: Sat Aug 6 09:15:05 on console
Welcome to Darwin!
Matt-Chelens-Computer:~ matthew$
Quote this message in a reply
Sage
Posts: 1,482
Joined: 2002.09
Post: #2
You know that you can bundle the SDL framework in your application bundle right? If you still don't want to use SDL, you are going to have to take your pick of Cocoa or Carbon events, or CoreFoundation runloops.

The standard C++ libraries aren't really meant to handle low level system events like this.
Quote this message in a reply
Member
Posts: 116
Joined: 2005.02
Post: #3
Ok, I didn't know that...it's been frustrating me trying to find this...I guess the only way to do this is SDL...Cocoa is more for Obj-C and Java and Carbon I haven't learned...beides, Obj-C confuses the crap out of me... I don't get why it has to be

@implementation
- (void) this_command (whatever)
{
//insert code here
}
@end

when you can do:

#include <this_file.h>

int main () {
//insert code here
return 0;
}

Last login: Sat Aug 6 09:15:05 on console
Welcome to Darwin!
Matt-Chelens-Computer:~ matthew$
Quote this message in a reply
Moderator
Posts: 1,140
Joined: 2005.07
Post: #4
The reason why it's set up like that is for 2 reasons. First of all, it's Object Oriented. It may not make sense for small programs where you have no need for such functionality, but it really comes in handy for larger projects. The second reason is because Cocoa is meant to be event-based. It enters the event loop, so basically you have main.m that initiates the event loop, it loads the main NIB file (usually contains a window), then waits for user input.

To learn how to do things without SDL, you're going to need to learn Carbon, Cocoa, or both. I recommend learning both, than combining the two. That way you can switch off between ease of use and low-level functionality depending on your needs for a specific part. In order to learn about either, though, you'll first need to learn about object-oriented programming.
Quote this message in a reply
Moderator
Posts: 3,577
Joined: 2003.06
Post: #5
akb825 Wrote:To learn how to do things without SDL, you're going to need to learn Carbon, Cocoa, or both... In order to learn about either, though, you'll first need to learn about object-oriented programming.
Not for Carbon, which isn't object-oriented, and has a C public API. Not that I'm recommending Carbon.

I know this has been beaten to death all over the forums, but Blorx2, have you considered trying out GLUT?
Quote this message in a reply
Member
Posts: 208
Joined: 2005.04
Post: #6
Blorx2 Wrote:beides, Obj-C confuses the crap out of me...

Pick up a copy of Cocoa Programming for Mac OS X by Aaron Hillegass. I GUARANTEE you'll understand Cocoa / objective-C after reading this book. It's seriously one of the best books I've ever bought. Objective-C is now, without a doubt, my favourite language.
Quote this message in a reply
Moderator
Posts: 1,140
Joined: 2005.07
Post: #7
AnotherJake Wrote:Not for Carbon, which isn't object-oriented, and has a C public API. Not that I'm recommending Carbon.

I know this has been beaten to death all over the forums, but Blorx2, have you considered trying out GLUT?
Just because it's in C doesn't mean it's not OO. CFDictionaryRef, CFArrayRef, etc. are all objects. Sure, they are really structures, but since there are functions specifically for them, they are treated just like objects in an OO language. (the only difference is you have the syntax someFunction(this, parameters) instead of this->someFunction(parameters) (or [this someFunction: parameters] if you prefer Wink))
Quote this message in a reply
Moderator
Posts: 3,577
Joined: 2003.06
Post: #8
The public presentation of the Carbon API is not object-oriented. To say that "you'll first need to learn about" OOP to program Carbon is simply incorrect.
Quote this message in a reply
Member
Posts: 116
Joined: 2005.02
Post: #9
I don't mean to start another fight, but right now I favor C++...

Also, AnotherJake, I'm not getting into GLUT and OpenGL until I think I've got a fairly good grip on SDL...

Last login: Sat Aug 6 09:15:05 on console
Welcome to Darwin!
Matt-Chelens-Computer:~ matthew$
Quote this message in a reply
Moderator
Posts: 3,577
Joined: 2003.06
Post: #10
You'll never need to use GLUT if you can use SDL. The GLUT suggestion was merely made because it doesn't need to be installed on other computers and it has its own keyboard functions.

Also, I seriously doubt there would be a fight over you favoring C++. My statement about not needing to learn OOP to use Carbon was not meant to be taken as an endorsement for C or against C++, I was merely clearing up the facts. You can use whatever language suits your fancy. Wink
Quote this message in a reply
Sage
Posts: 1,066
Joined: 2004.07
Post: #11
I suggest you learn to bundle SDL into the app (as previously stated) and then use SDL's key mapping functions. Once you get the bundling part down, just write everything in plain C++ (no Cocoa or Carbon) and the code will be easily portable to other systems. Once you get SDL down, take a peek at OpenGL (which can be used easily with SDL), which is also cross-platform.

I keep suggesting SDL/OpenGL because I've used them, they're not too difficult to get decent or better at. As an added plus, there's not much to change when porting your code over to Windows or Linux (if that's the goal).

Let me know if you ever need any help with SDL or OpenGL. Perhaps I could send you some of my more recent code for my heightfield engine (which I'm still trying to work on when I get some time).
Quote this message in a reply
Member
Posts: 116
Joined: 2005.02
Post: #12
Ok, since I've had no luck deciphering the way to modify an SDL app from the beginning Xcode project, I just put the SDL framework in a C++ tool project and I've gotten this far

#include <iostream>
#include <SDL/SDL.h>

int main (int argc, char * const argv[]) {
// insert code here...
std::cout << "Welcome to PracticeRPG, press the Up arrow key to start\n";
return 0;
}

and it gives me this:

ZeroLink: unknown symbol '_main'

PracticeRPG has exited due to signal 6 (SIGABRT).

Did I make a mistake in not just using the SDL application?

Last login: Sat Aug 6 09:15:05 on console
Welcome to Darwin!
Matt-Chelens-Computer:~ matthew$
Quote this message in a reply
Sage
Posts: 1,482
Joined: 2002.09
Post: #13
Ah, you also need to grab the SDL_main.m and SDL_main.h files out of the default template. SDL redefines "main" so that it can start using it's own code before it gets to your main function.

You also need to be opening a SDL window before you'll be able to catch keyboard events. The joystick events are the only 'special' events that don't require window focus to catch them.
Quote this message in a reply
Sage
Posts: 1,066
Joined: 2004.07
Post: #14
If you'd like, I can email you the code from my heightmap SDL project. Unlike the FPS code, this one will actually work Smile. You can browse through it and see how I have it set up to work. Pretty fun code. The only stuff you'd really need to concern yourself with would be init.cpp, main.h, and main.cpp.

And yes, starting with the SDL application (or in my case the SDL OpenGL Application) is the best way to go in my opinion. But you do at least need the SDL_main files.

Just let me know if you want my project files.
Quote this message in a reply
Post Reply