[StratComm]

Originally posted by aldo_14
IMO it's probably most valuable in any situation to have an understanding of the design principles rather than a specific language fluency.

Exactly.  This really is the underlying principle behind learning any programming language anyway.  Especially since the modern languages (C++/Java) have remarkably similar syntax and moving between them is not difficult at all.

Originally posted by aldo_14
Albeit I believe Java graphics performance is signficiantly  improving thanks to DirectX / OpenGL bindings (through several methods IIRC; including direct interface bindings and the Java3d APIs); whether or not it can attain an acceptable performance vis-a-vis C/C++ is a different matter, of course. (The JOGL binding API is unfortunately pretty poorly documented at present, natch, so I'm not sure if direct comparative work has been done)

I would agree that Java is slower, but IMO that would be beside the point - my personal attraction to Java is the portability.  Not so much in terms of moving between different platforms, but in terms of mobile running code.  I think that will be of major use in future, and I'm not sure C++ is as suited - AFAIK all the major mobile agent programs/frameworks use Java (albeit in some cases also a modified VM in order to allow persistant state between transfers).

That's just it, Java as a language was developed specifically with portability in mind, which is why that's the area in which, as a language, it excels hands down.  But that's also a tradeoff as you're compiling to bytecode and you have to run through a translator as opposed to directly on hardware. It's different, and it's the applications, not the language, that makes one more ideal than the other.

[aldo_14]

Originally posted by StratComm

Exactly.  This really is the underlying principle behind learning any programming language anyway.  Especially since the modern languages (C++/Java) have remarkably similar syntax and moving between them is not difficult at all.

That's just it, Java as a language was developed specifically with portability in mind, which is why that's the area in which, as a language, it excels hands down.  But that's also a tradeoff as you're compiling to bytecode and you have to run through a translator as opposed to directly on hardware. It's different, and it's the applications, not the language, that makes one more ideal than the other.

Exactly my point

I just don't like the sweeping generalization of the language as 'less useful', any more than a C++ programmer would like it being done of their specialism.

[CP5670]

I wish they still had C++ classes at my university. They removed the C++ classes altogether last semester and use Java exclusively now, so I'm doing a Java class. I think the college board (the people who run the AP program) switched to Java a few years ago and most of the universities are just following them.

I know some C/C++ but only enough to make small math computation programs (for which Fortran and assembly are overall a bit better), not games or anything like that. Maybe I'll try picking it up on my own later on.

[karajorma]

It's also worth pointing out the inherant security aspect of Java. Buffer under/overruns are a very large and often easily exploitable hole in many poorly written C programs (And they're even found in good ones where they just happened to slip through).

The problem is virtually non-existant in Java due to the fact that a Java array knows exactly how big it is and refuses to let you write beyond it's end.

As Aldo says it's a case of choosing the best language for what you're doing. To say Java isn't as useful as C++ is like saying a boat isn't as useful as a car. If you're trying to sail on an ocean you're not going to get far in the car.

[MicroPsycho]

Originally posted by aldo_14
Doom 3 would be C++ and IIRC OpenGL.  I think the sound & physics code is proprietary (rather than, say, OpenAL and Havok).

AFAIK there's no other language widely used in mainstream (i.e. major or even medium scale titles) coding. However, some other languages are used for scripting purposes.

So OpenGL is another language, or is it code to be used within C++/Java? Would this be similar with DirectX aswell?

If I choose C++, which is very likely, I'll probably try to work on the SCP in class...

[StratComm]

OpenGL (like D3D) is a set of graphics libraries that reference your drivers (or a software implimentation in the OS itself), not a language.

[mikhael]

Choose Python. You can never go wrong with Python. It is simple, logical and beautiful. Its readable. Its interactive and thus discoverable. It's portable and free. It'll teach you basic logical constructs and more advanced concepts (like objects). It is extensible and embeddable. Once you understand it you can apply that knowledge to other languages.

Follow that with C++ (if you grok C++, you will grok C).

[LtNarol]

Allow me to rephrase:

Java is a good learning platform because of its consistency and documentation, its also far easier to learn than C++ or C.

C++ and C are more 'useful' in that they are more geared (at present) to most applications an entry level student creates.  Suppose you get a large project for a semester and decide you want to take it to the next level afterwards.  Java is particularly good for entry level graphics aps, but not so if you're trying to develop your own permutation of whichever data structure.

I'm not saying Java sucks, because I still use it, but there are annoying limits once you get into optimization.

[Kamikaze]

To add to mik's point, languages like python (ruby too) are nice because they can be easily mixed and matched with modules written in C. So if a component needs more performance or lower-level functions, you can write that part in C.

[Descenterace]

Originally posted by aldo_14
The JOGL binding API is unfortunately pretty poorly documented at present, natch, so I'm not sure if direct comparative work has been done

Undocumented? The API is almost call-for-call identical to the C OpenGL API, for which there is adequate documentation! OK, so there are a few gotchas (like buffers having to be in native byte order) but anyone who knows the first thing about calling native code will have no trouble.

Originally posted by mikhael
if you grok C++, you will grok C

Not true. It is possible to write C in C++, but it isn't usually done. C++ uses a more abstract view of the machine, makes heavy use of objects, and avoids pointers.
C is a linear, procedural language at heart. C functions are file-global.
C++ is an object-oriented language. C++ functions are usually object-global.

C is a different paradigm. The language grammar is the same, but programming methods changed a lot between C and C++.

[WMCoolmon]

I'd recommend that you take the opportunity to take classes on C, C++, or Java if you are at all interested in game programming. Python  - since it's technically a scripting language - isn't as widely used. Plus, the other languages are more well-established. So there'll probably be better/more extensive classes on them.

Also, Python is a piece of cake if you know C/++.

From your first post it looks like you're still in High School so I would guess that your choices will be fairly limited.

Overall, if you're faced with a choice between learning C and C++, I would vote C++. It's much more difficult to fully understand, but it is what's used for most games these days, and all of the fundamentals to it are common to C.

[aldo_14]

Originally posted by Descenterace


Undocumented? The API is almost call-for-call identical to the C OpenGL API, for which there is adequate documentation! OK, so there are a few gotchas (like buffers having to be in native byte order) but anyone who knows the first thing about calling native code will have no trouble.

That's the problem; there is no documentation of the differences.  I've been trying to write a little program for a while now, but there is (for example) absolutely **** all information available on how to actually form a ByteBuffer of rasterized pixel data (i.e. the precise ordering pattern for pixels).

As it stands, it'd probably be easier for me to learn C++ and OpenGL (which is what I was doing before, till I started work) than to learn JOGL; which is exactly what I mean.  There is sod all javadoc documentation (virtually all of the commentary for GL methods is 'Interface to C language function:'), and there is little by way of tutorials. That's an access barrier.

[Descenterace]

The data structures are identical to those used in a C program. The solution to your problem is documented. I wrote a 3D engine on JOGL a few months ago; everything required to do that is documented, albeit in C.
The problems I had regarding threading and GLCanvas objects were mainly due to my own lack of experience in dealing with multithreaded apps.

I assume 'rasterised pixel data' means textures in this case. So basically you need to turn an image into an array of pixel colour values, right? Yeah, that is a bit of a sod in Java; no one ever thought it would be necessary to handle an image as anything other than an object... Shortsightedness of the worst kind.

*digs out the HyperDrive OGL abstraction layer*

Pixels are stored in row-major order, and each one is a quadruple of either bytes or floats depending on the texture format you've selected. Remember to set the byte order of any buffer handling non-'byte' values to ByteOrder.nativeOrder() before writing the pixels to it, or you'll end up with some really weird, frustrating bugs.

You can use a PixelGrabber to get pixel data out of a BufferedImage object in TYPE_INT_RGB format, then do some byte-twiddling to fill a byte array. The PixelGrabber will fill an array of ints, one per pixel. Each int consists of the four colour elements in ARGB order (alpha being the most significant byte). If you like, I'll PM you some code to do the conversion.
OpenGL normally takes pixel colour values in RGBA order. Plus, if you're using buffers that store 'float' colour values, you're probably in for a world of pain.

Most of JOGL's problems are less to do with a lack of Java-specific documentation and more to do with a lack of tools for converting objects to raw data.

[MicroPsycho]

Alright, next question, what's a good program to use for writing and compiling C++?

[Kamikaze]

GCC, the GNU C Compiler
Eclipse, a modular multi-language IDE. Supports C++ with a plugin. Written in Java.
DevC++, a free IDE
Vim, an editor that lets you edit madly fast

You can also look at this Wikipedia article for more choices.

[Bobboau]

most people use some form of MSVC, but it costs money, and is windows only, and doesn't follow everything perfictly in some usualy minor details.

[Descenterace]

And it doesn't come with the standard libraries; it comes with the Microsoft standard libraries. That means that you start to rely on functions which the ordinary POSIX-compatible libraries don't provide.

Yes, it happened to me.

I'd recommend getting used to command line development, then moving onto an IDE once you're familar with the construction of Makefiles.

Yay, Vim! My favourite *n[iu]x editor! But I use SciTE for coding, since I know Vim's commands just about well enough to insert/change text and save the file.

[aldo_14]

Originally posted by Descenterace
The data structures are identical to those used in a C program. The solution to your problem is documented. I wrote a 3D engine on JOGL a few months ago; everything required to do that is documented, albeit in C.
The problems I had regarding threading and GLCanvas objects were mainly due to my own lack of experience in dealing with multithreaded apps.

I assume 'rasterised pixel data' means textures in this case. So basically you need to turn an image into an array of pixel colour values, right? Yeah, that is a bit of a sod in Java; no one ever thought it would be necessary to handle an image as anything other than an object... Shortsightedness of the worst kind.

*digs out the HyperDrive OGL abstraction layer*

Pixels are stored in row-major order, and each one is a quadruple of either bytes or floats depending on the texture format you've selected. Remember to set the byte order of any buffer handling non-'byte' values to ByteOrder.nativeOrder() before writing the pixels to it, or you'll end up with some really weird, frustrating bugs.

You can use a PixelGrabber to get pixel data out of a BufferedImage object in TYPE_INT_RGB format, then do some byte-twiddling to fill a byte array. The PixelGrabber will fill an array of ints, one per pixel. Each int consists of the four colour elements in ARGB order (alpha being the most significant byte). If you like, I'll PM you some code to do the conversion.
OpenGL normally takes pixel colour values in RGBA order. Plus, if you're using buffers that store 'float' colour values, you're probably in for a world of pain.

Most of JOGL's problems are less to do with a lack of Java-specific documentation and more to do with a lack of tools for converting objects to raw data.

I think that's what I need.  The problem I had was that, when I finally got the image ready, it was displaying as wholly translucent; .e. it was 'merged' with a the draw colour (I was drawing 2d; but using a textured polygon rather than drawSquare or whetever the method name is).  IIRC it was a PNG image.

Originally posted by Kamikaze
GCC, the GNU C Compiler
Eclipse, a modular multi-language IDE. Supports C++ with a plugin. Written in Java.
DevC++, a free IDE
Vim, an editor that lets you edit madly fast

You can also look at this Wikipedia article for more choices.

I've not tried the C++ plugin, but as a native Java IDE Eclipse is absolutely superb.

[mikhael]

Originally posted by Descenterace
Not true. It is possible to write C in C++, but it isn't usually done. C++ uses a more abstract view of the machine, makes heavy use of objects, and avoids pointers.
C is a linear, procedural language at heart. C functions are file-global.
C++ is an object-oriented language. C++ functions are usually object-global.

C is a different paradigm. The language grammar is the same, but programming methods changed a lot between C and C++.

C++ avoids pointers? Don't tell... well anyone.

When you say "C functions are file-global" and "C++ functions are usually object global", you hurt my brain. Non-class functions (IE functions written outside of classes) are file-global in C++, exactly as in C. C++ is C with slightly tighter typing, language level support (rather than stylistic support) for object orientation.

Better to say, Stroustroup says himself, that C++ is a superset of C.

[Descenterace]

Yeah, C++ can do what C does, so it is a superset, but the point is that it introduces a whole load more things which make the messier C coding constructs unnecessary. I haven't seen much C++ code that uses file-global functions.

C++ introduces references. Unless you're calling old library code, pointers become unnecessary for the everyday. It is nice to have the option of using them when they are required, though.


Aldo, I think there's a rendering setting which ignores alpha entirely and simply draws the texture as a decal. It sounds like you've already got the image loading OK (a task that took me well over a week to make work correctly; btw, if you want a PCX loader, I've got one that works with 24-bit PCX files).
glDisable( GL_BLEND ) should do it, or you can use glBlendFunc to set source factor to GL_ONE and destination to GL_ZERO.
Have a look at glTexEnv too. It can control blend settings, but I think it's only important if you're trying to blend colours.