QuickDraw?

DoG
Moderator
Posts: 869
Joined: 2003.01
Post: #16
I'd like to point out that C and C++ are not contenders. C is a pure procedural language, while C++ is object-oriented.

Which you use to program is up to your preferences. As far as OO languages go, C++ contends with Java, ObjC, and C#, mostly.

I am not saying which is better, or that any of those is better than another ("get the right tool for the job"), but I think its important to know that C++ is OO and C is not.
Quote this message in a reply
Moderator
Posts: 1,140
Joined: 2005.07
Post: #17
While true that C technically isn't an OO language, it is perfectly possible (and easy) to write OO code in C. If you try to do more complicated OO coding practices, however, it can get quite complicated to pull off, but it certainly is possible.
Quote this message in a reply
Oldtimer
Posts: 834
Joined: 2002.09
Post: #18
Quote:But anyway, note the "image slot" feature. I've been looking at the image loading tutorials over at NeHe, and I don't understand how C and GLUT can work together with these strange new "image streams" and stuff. How do they know it's an image? What is a "stream"? Is it like a "slot"?
Short answer: C has no idea. Here's how it works:

You have a file that contains the pixel data. Let's take a TGA file for instance (simple format, me likey). You open it, and you know only three things:
1) The file is n bytes long.
2) You know what the file contains (i.e. you can read the file into an array)
3) OpenGL wants your images as an array of bytes in a specific format. In a simple case, an array where byte #1 is the first pixel's red component, #2 is the first pixel's green component, #3 is the first pixel's blue component, byte #4 is the second pixel's red component and so on and so on until end of file.

So, you have an array of bytes. OpenGL wants an array of bytes. Simple enough, huh? Not really. OpenGL also needs to know how to use those bytes. By looking at an array, it can't know where one pixel line ends and another one begins. It needs to know the width and height of the image. This info (and a bunch more) is embedded in the TGA file's header - that is, the first 12 bytes of the file.

So, in the TGA case (and this is where the file format specification and/or NeHe tutorials come in handy) the first twelve bytes specify width and height. Extract those, and then just send the rest of the bytes to OpenGL. OpenGL will (by jumping through some hoops - this is simplified) give you back an integer that represents your loaded texture. I guess this is something like Basic's image slots.

So, what you need to wrap your head around with C is that there are no file formats that C knows. You have to tell it everything. Open this file, read this many bytes, and do this with them. Sounds complicated - it really isn't. Smile Hope this helps!
Quote this message in a reply
DoG
Moderator
Posts: 869
Joined: 2003.01
Post: #19
akb825 Wrote:While true that C technically isn't an OO language, it is perfectly possible (and easy) to write OO code in C. If you try to do more complicated OO coding practices, however, it can get quite complicated to pull off, but it certainly is possible.

You can write OO code in Assembly, too, but it's pretty pointless, isn't it? It's all about using the right language to the job at hand. If you want raw speed, go with C, if you want maintainability or clean code, go with an object-oriented language.
Quote this message in a reply
Moderator
Posts: 1,140
Joined: 2005.07
Post: #20
Fenris Wrote:Short answer: C has no idea. Here's how it works:

You have a file that contains the pixel data. Let's take a TGA file for instance (simple format, me likey). You open it, and you know only three things:
1) The file is n bytes long.
2) You know what the file contains (i.e. you can read the file into an array)
3) OpenGL wants your images as an array of bytes in a specific format. In a simple case, an array where byte #1 is the first pixel's red component, #2 is the first pixel's green component, #3 is the first pixel's blue component, byte #4 is the second pixel's red component and so on and so on until end of file.

So, you have an array of bytes. OpenGL wants an array of bytes. Simple enough, huh? Not really. OpenGL also needs to know how to use those bytes. By looking at an array, it can't know where one pixel line ends and another one begins. It needs to know the width and height of the image. This info (and a bunch more) is embedded in the TGA file's header - that is, the first 12 bytes of the file.

So, in the TGA case (and this is where the file format specification and/or NeHe tutorials come in handy) the first twelve bytes specify width and height. Extract those, and then just send the rest of the bytes to OpenGL. OpenGL will (by jumping through some hoops - this is simplified) give you back an integer that represents your loaded texture. I guess this is something like Basic's image slots.

So, what you need to wrap your head around with C is that there are no file formats that C knows. You have to tell it everything. Open this file, read this many bytes, and do this with them. Sounds complicated - it really isn't. Smile Hope this helps!
This is with low level code, though. If you get a library that handles images for you, you can feed it a file name, and it can spit back a structure with all the information you need. (it essentially does what Fenris described, but it's all in the function you call, so you never have to actually see it happen) Though C doesn't know any file types, that doesn't mean you can't find solutions already done in C to use and make your life easier. Smile
Quote this message in a reply
Jones
Unregistered
 
Post: #21
Ah, I see now. It's similar to loading an image with the unix "cat" command, and then using some other script language to fill a cocoa/carbon "image pane" with the data.

Cat reads it as a jumble of numbers, letters and special characters, but the image pane understands.

Anyway, does GLUT have functions for image loading? I've also becoming interested in the ability to combine SDL and GLUT(OpenGL), however the problem is the same:

How can GLUT and SDL talk to each other? How do they access each others windows? I'd like to use the ease of setting up a GLUT window, with the media functions of SDL, unless GLUT has something similar. Does it?

(And this is unrelated: Since when is TNT basic free???)
Quote this message in a reply
Member
Posts: 78
Joined: 2004.06
Post: #22
Quote:(And this is unrelated: Since when is TNT basic free???)

Since they decided under good advice to release it as Open Source. Which was about September of last year Smile

When in doubt ... read the Read Me
10.5.6 | MacBook Pro 2.5x2 | 4 GB RAM | GeForce 8600M GT
Quote this message in a reply
Moderator
Posts: 1,140
Joined: 2005.07
Post: #23
Jones Wrote:Ah, I see now. It's similar to loading an image with the unix "cat" command, and then using some other script language to fill a cocoa/carbon "image pane" with the data.

Cat reads it as a jumble of numbers, letters and special characters, but the image pane understands.

Anyway, does GLUT have functions for image loading? I've also becoming interested in the ability to combine SDL and GLUT(OpenGL), however the problem is the same:

How can GLUT and SDL talk to each other? How do they access each others windows? I'd like to use the ease of setting up a GLUT window, with the media functions of SDL, unless GLUT has something similar. Does it?

(And this is unrelated: Since when is TNT basic free???)
What you see as weird symbols are actually what the text editor interprets it as. It's just a bunch of bits encoded as combinations of ints, floats, etc. The text editor just happens to read in the individual bytes and spits out what ASCII code it turns out to be, which means nothing. In C, if you're doing low level file I/O, you can either open it as a text file and just read and write text like you would with printf or scanf, instead using fprintf or fscanf (or even getc or putc), or you can open it as a binary file to read and write different data types. With fread and fwrite, you can write to disk the bit patterns of ints, floats, whatever datatype is supported in C. (even your own datatypes and structs, but it's often better to just write the individual parts of your structs one at a time rather than the entire thing) What programs do is they know what kind of information is written to disk and in what order, so it goes through and reads the bit patterns and interprets them. Often there's a file header, which is fixed in size, and tells you all you need to know about the sizes of certain parts of the file. Other times, you have chunks of data, where the first value gives you the type (and often the size) of the data that comes next, then repeats for another chunk of data. Often times, though, you can find libraries or code that will do all the hard part for you, and all you have to know is what file name to supply.

As for SDL and GLUT, the media part and window part are separate. It's perfectly fine to set up a window and graphics context with GLUT, and to use SDL to load images and play sounds, since they have nothing in common. When you load an image, you just need to provide the information to OpenGL. So all you do is grab the image data using SDL, and feed it to OpenGL, no problem. Sounds are completely separate from OpenGL and the windowing system, so it doesn't matter at all.
Quote this message in a reply
Jones
Unregistered
 
Post: #24
Ahh, I see now. I don't even need to use SDL to handle drawing stuff, just to load images/models/music etc.

Ok, but exactly how smart is OpenGL? Would I have to "teach" it to read the data sdl gave (and I put in an array (?) )? Or does it already know how to interperet the arrays of images like tga. (As in your example.)
Quote this message in a reply
Moderator
Posts: 3,577
Joined: 2003.06
Post: #25
For most practical purposes OpenGL only understands images as textures which you upload to it via a few different functions. The most central function you should focus on first is glTexImage2D. In fact, I would recommend that if you're going to learn OpenGL you should spend as much time as you need to understand that one function as clearly as possible. Essentially, you pass it a pointer to a buffer (array or malloced area of memory) containing your pixels, and then tell it what format those pixels are in and how you would like OpenGL to store it internally for itself. OpenGL doesn't understand formal graphics formats like TGA, BMP, JPEG, etc.; you have to prepare them for consumption before they can be uploaded to OpenGL in a generic fashion, typically with an external library like LibPNG or Quicktime or SDL or whatever.
Quote this message in a reply
Member
Posts: 78
Joined: 2004.06
Post: #26
Quote:I recently got my hands on a copy of "Mac Game Programming" by Mark Szymczyk for only 10$ at a local book sale.

[offtopic] Haha I got it for 5! Smile It really does seem to still have mostly alot of relevant info though. [/offtopic]

When in doubt ... read the Read Me
10.5.6 | MacBook Pro 2.5x2 | 4 GB RAM | GeForce 8600M GT
Quote this message in a reply
Post Reply 

Possibly Related Threads...
Thread: Author Replies: Views: Last Post
  Quickdraw question xDexx 7 4,109 Oct 11, 2002 07:30 PM
Last Post: Josh