Slashdot Mirror
Computer Graphics With Java
Michael Grady writes "Computer graphics has become an
indispensable part of mainstream computing and the undergraduate
course in computer graphics programming is often one of the most
popular courses in the curriculum. In the early days, such courses dealt with low level
implementation details and algorithms such as converting lines to
pixels, filling rectangles, view clipping and anti-aliasing. When OpenGL arrived on the scene, it was welcomed as an efficient and
powerful, procedure-oriented library that kept many of the low level
details out of sight. The sort of projects that could be tackled in
an introductory course became much more impressive. That was back in the 90's. Is
there a way to build a course covering the basic computer graphics
concepts and techniques which takes advantage of object orientation
and higher levels of abstraction? I believe the authors of Computer
Graphics using Java have found a way." Read below for Michael's review
Computer Graphics Using Java 2D and 3D
author
Hong Zhang and Y. Daniel Liang
pages
462
publisher
Pearson Prentice Hall
rating
8
reviewer
Michael Grady
ISBN
0-13-035118-0
summary
Introduction to computer graphics concepts and techniques using Java 2D and 3D
Their strategy is to teach by example using the comprehensive, high level interfaces provided by Java 2D and Java 3D. Their examples are often well chosen and fun. The programming exercises are entertaining and appropriate.
About one third of the book is devoted to 2D graphics and covers the usual topics: coordinate systems, modeling, constructive area geometry, color models, affine transformations, compositing, splines, clipping, fonts, raster images, animation and image processing. As anyone who has worked in this area knows, Java 2D provides a beautifully designed set of classes for high quality 2D graphics and imaging. This part of the book could also serve as an excellent introduction for any programmer who wants to begin exploring its functionality.
Where the book really shines is in the examples. My favorite 2D examples include:An interactive demo of the RGB Color model which also illustrates constructive area geometry. An efficient rendering of the Mandelbrot set as a raster image. An elegant analog clock that shows how to use the Timer class in animation. An interactive demo of the common 2D affine transformations.
Surprisingly, none of the code uses anti-aliasing, even though Java 2D does a great job smoothing rough edges. In computer graphics circles, this is a faux pas — a violation of accepted, although unwritten, social rules, and points must be deducted for this omission. But if you add the required one line of code, most of the examples look pretty good.
The last two thirds of the book are devoted to 3D graphics programming, which reflects a common emphasis in the course at the undergraduate level. Coverage includes scene graphs, the rendering pipeline, 3D modeling, affine and projective transformations, illumination and reflection models, texture mapping, adaptive rendering, animation and interactivity, as well as object oriented graphics concepts such as behavior dynamics.
Java 3D provides a high level, object oriented framework for 3D graphics programming, with about 360 classes. For those who are used to programming with OpenGL, the Java 3D mindset may require a bit of indoctrination. It's based on the concept of a scene graph, and makes a lot of sense from an object oriented programming viewpoint.
Basically, a scene graph is a data structure for organizing the objects of a scene. We mean objects in the object oriented sense. Java 3D objects may be responsible for geometric, transformation, illumination, shading or behavioral data. The nodes of the scene graph represent objects and the edges represent a necessary connection. For example, a transformation node may be connected to a node representing a cube. The corresponding transformation object defines how the cube should be rotated, scaled, etc. In traversing the graph from its root, the Java 3D rendering engine finds all the information required to render the scene. It's a cool way to do computer graphics at a higher level of abstraction than programming directly with OpenGL.
Once again, many of the examples are excellent for an introductory text. My favorite 3D examples include: The classic spinning dodecahedron. This example shows that setting up the scene geometry is pleasantly intuitive in Java 3D. The ease of computing the normal vectors of all plane surfaces using the NormalGenerator class is a good illustration of the power of object oriented programming. Transformations, lighting and material properties are handled by dedicated classes. An interactive illustration of the common 3D affine transformations showing the effect of modifying transformation matrices. The mirror image of rotating 3D text that demonstrates the effect of composing transformations. How to generate a torus mesh. The canonical Utah Teapot.
Once again,the code does not use anti-aliasing, even where it is badly needed.
One of the benefits of using the Java platform is the extensive support for networking, multithreading, multimedia, database access and web services. For the most part, none of these benefits are exploited in the text. But that is probably the subject for a second course in computer graphics using Java.
All in all, it's clear that the authors are excellent teachers. This shows in their effective use of the teaching-by-example style. As stated in the preface, the authors intended their book for students and computer professionals who want to learn basic computer graphics concepts and techniques and who want to get started in programming with the Java 2D and 3D APIs. I believe they have succeeded in this goal, and if you are in this group of readers, I can confidently recommend their book.
You can purchase Computer Graphics Using Java 2D and 3D from amazon.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
Their strategy is to teach by example using the comprehensive, high level interfaces provided by Java 2D and Java 3D. Their examples are often well chosen and fun. The programming exercises are entertaining and appropriate.
About one third of the book is devoted to 2D graphics and covers the usual topics: coordinate systems, modeling, constructive area geometry, color models, affine transformations, compositing, splines, clipping, fonts, raster images, animation and image processing. As anyone who has worked in this area knows, Java 2D provides a beautifully designed set of classes for high quality 2D graphics and imaging. This part of the book could also serve as an excellent introduction for any programmer who wants to begin exploring its functionality.
Where the book really shines is in the examples. My favorite 2D examples include:An interactive demo of the RGB Color model which also illustrates constructive area geometry. An efficient rendering of the Mandelbrot set as a raster image. An elegant analog clock that shows how to use the Timer class in animation. An interactive demo of the common 2D affine transformations.
Surprisingly, none of the code uses anti-aliasing, even though Java 2D does a great job smoothing rough edges. In computer graphics circles, this is a faux pas — a violation of accepted, although unwritten, social rules, and points must be deducted for this omission. But if you add the required one line of code, most of the examples look pretty good.
The last two thirds of the book are devoted to 3D graphics programming, which reflects a common emphasis in the course at the undergraduate level. Coverage includes scene graphs, the rendering pipeline, 3D modeling, affine and projective transformations, illumination and reflection models, texture mapping, adaptive rendering, animation and interactivity, as well as object oriented graphics concepts such as behavior dynamics.
Java 3D provides a high level, object oriented framework for 3D graphics programming, with about 360 classes. For those who are used to programming with OpenGL, the Java 3D mindset may require a bit of indoctrination. It's based on the concept of a scene graph, and makes a lot of sense from an object oriented programming viewpoint.
Basically, a scene graph is a data structure for organizing the objects of a scene. We mean objects in the object oriented sense. Java 3D objects may be responsible for geometric, transformation, illumination, shading or behavioral data. The nodes of the scene graph represent objects and the edges represent a necessary connection. For example, a transformation node may be connected to a node representing a cube. The corresponding transformation object defines how the cube should be rotated, scaled, etc. In traversing the graph from its root, the Java 3D rendering engine finds all the information required to render the scene. It's a cool way to do computer graphics at a higher level of abstraction than programming directly with OpenGL.
Once again, many of the examples are excellent for an introductory text. My favorite 3D examples include: The classic spinning dodecahedron. This example shows that setting up the scene geometry is pleasantly intuitive in Java 3D. The ease of computing the normal vectors of all plane surfaces using the NormalGenerator class is a good illustration of the power of object oriented programming. Transformations, lighting and material properties are handled by dedicated classes. An interactive illustration of the common 3D affine transformations showing the effect of modifying transformation matrices. The mirror image of rotating 3D text that demonstrates the effect of composing transformations. How to generate a torus mesh. The canonical Utah Teapot.
Once again,the code does not use anti-aliasing, even where it is badly needed.
One of the benefits of using the Java platform is the extensive support for networking, multithreading, multimedia, database access and web services. For the most part, none of these benefits are exploited in the text. But that is probably the subject for a second course in computer graphics using Java.
All in all, it's clear that the authors are excellent teachers. This shows in their effective use of the teaching-by-example style. As stated in the preface, the authors intended their book for students and computer professionals who want to learn basic computer graphics concepts and techniques and who want to get started in programming with the Java 2D and 3D APIs. I believe they have succeeded in this goal, and if you are in this group of readers, I can confidently recommend their book.
You can purchase Computer Graphics Using Java 2D and 3D from amazon.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
You don't need antialiasing if you are rendering with an interval engine like this one:
http://sunfishstudio.com/
stuff |
I've always been under the Impression that Java can't use hardware rendering, wouldn't that restrict usage for more intense applications?
You mad
Is there a way to build a course covering the basic computer graphics concepts and techniques which takes advantage of object orientation and higher levels of abstraction? I believe the authors of Computer Graphics using Java have found a way."
Why must you ask rhetorical questions of me???
Even those who arrange and design shrubberies are under considerable economic stress at this period in history.
First of all, I've used Liang's introductory Java book in classes I've TAed, he is quite good.
As for Java graphics programming itself, it's definitely a mixed bag, but in general more good than bad. Back in my undergraduate days I took two courses for Java graphics and Java game programming. If you're already familiar with the language, it's a great tool for learning the basics and mid-level game-oriented 2D and 3D programming. Java has a lot of great tools for all kinds of design, and the speed-issues are not a concern with JIT and APIs that take advantage of hardware acceleration. And Java's easy network programming lets you build some interesting projects.
That said, people seriously thinking about futures in game development should be learning DirectX and C++ as soon as possible. OpenGL is great, and if you're doing cross-platform work it's obviously the right choice. But DirectX is the standard now; even Carmack hasn't been too hard on it lately. It's managed to make great strides while the OpenGL committee squabbled.
Unfortunately, teaching computer graphics in Java3D locks the aspiring developer into the Java platform. At least with OpenGL, you're not locked into any particular programming platform and have more choices in that regard. That makes learning OpenGL easier as well, since you don't have to already be a Java developer to pick up OpenGL and can instead learn it in your favorite language. And, at this stage in the game, there are plenty of Object-Oriented APIs based on OpenGL available.
Life would be easier if I had the source code.
Java is about the last language id use for anything involving graphics.
I'm no Java hater, I think it owns when it comes to developing maintainable applications and deployment across multiple platforms, but lets be realistic, it's slow.
One could argue that it still has merit in an academic sense, for teaching the basics of graphics programming, but even that is kind of flawed. You probably want to avoid OOP in general when it comes to the actual graphics component of an application, as it adds overhead. Not only is Java itself slow, but the way in which it approaches graphics is probably the worst way to approach it in any language performance wise.
JAVA really is a brilliant achievement. It comes with nearly everything built in, and what is not included is easy to make. The simplicity of Graphics in JAVA is unsurpassed in any real language, and has huge capabilities. Even using OpenGL with JAVA is possible. This work is exactly what is needed to get more people using JAVA and revolutionary in the way of graphics. I still remember trying to draw a house with Assembly and C++ using only native libraries. JAVA makes life a lot easier, and graphics possible for all.
There is an enormous amount of work done in the Java 3d api, unfortunately hardly anyone uses it - I counted only a handful of games made - most not really commercial quality. It's ironic that the mobile 3d version has had a lot more success, considering how limited mobile phones are.
M. Guzdial's "Introduction to Computing and Programming with Java: A Multimedia Approach" was used in an introductory Java course that I took during Intersession this year. It doesn't focus on creating graphics, or 3D objects (which I imagine would be pretty daunting for a lot of people), but rather bases its lessons around modifying already extant images and sound files, systematically teaching the student how various aspects of OOP work, and giving them an obvious 'real world' use for programming.
Historically, scene graph APIs haven't been too useful. There are successful drawing APIs, like OpenGL, and game engines, but the in-between middleware hasn't been that useful. SGI Inventor, later Open Inventor, was the classic in that space, and it's not used much any more.
Java 3D is abandonware. Sun wrote it, badly, and it's now a "community source project", meaning Sun doesn't support it any more. I used it in its early days and wasn't impressed. The Java3D collision detection system was both badly designed and badly implemented. The general consensus was "give us an OpenGL binding and get this turkey out of the way".
If you are programming portable code you want any non-Windows users to be able to run casually, Java is a better choice. The web consists of more than just Windows users, y'know.
(you knew it was coming) we had to deflect the electron beams ourselves using little magnets we had dug out of the ground with our bare fingernails.
ccalam - acoustic versions of new songs.
As far I know, Java uses 32 bit values internally as a minimum, so even if they got around adding a unsigned byte, it would technically be a 32 bit value in disguise. But I got to admit, the lack of unsigned byte is a huge annoyance when you program in java. :/
Do you even understand how signed values work? Signed and unsigned are the exact same thing, save for two major exceptions:
1. Sign-preserving operations. The only one I can think of off the top of my head is a signed right shift. (>>) Use a bitwise shift instead. (>>>)
2. When the result of computations are printed out. An unsigned value is printed as a larger positive number while a signed value is given a negative sign and inverted if the first bit is a 1, before being printed out.
Java has a very sophisticated graphics library. (see: java.awt.image.BufferedImage) It uses 32-bit ARGB values. Somehow, the sign doesn't seem to cause a problem.
Javascript + Nintendo DSi = DSiCade
silly problem but I had written a small java app to create thumbnails from images for the wife's photo website. the resizing made the thumbs look poor compared to Apple's ImageEvents. had to google an applescript to accomplish the thing. hopefully the image quality has gotten better. all I was doing was taking a 400x400 or so jpg and reducing it by 50%. nothing else. and they turned out either blurry or lost sharpness, etc. ImageEvents does the job alot better.
when I taught AP Comp Sci we did some graphics projects and yes, the 2D stuff is really cool. but I don't know whether java is ready for higher end stuff or even decent quality yet. hope it is, that'd be really nice.
My problem? I was perfectly gruntled, until some numbnuts came by and dissed me.
As a somewhat-successful professional software engineer, it has been my experience that this sort of programming is not as common as many students and/or civilians think. The majority of programming code is done on the business level... i.e. I need a report that will tell me how fribble relates to frabble, or we need a system that will track all of the incoming support requests on our jimble jamble product.
As a student I really thought I would get the opportunity to write games, but after seeing the development process at a software publisher specializing in gaming, I realized that the programmers spend more time dealing with things like physics and optimization and leave a lot up to graphics artists.
My university computer science graphics course was still pretty low level. We use OpenGL for 2D drawing primitives, but the assignments were: line drawing with anti-aliasing, 3D rendering, camera movement, adding light sources, and finally ray tracing. As I said before, we only got to use 2D drawing routines to project 3D data onto a 2D surface. Many people in the class complained because they thought the course would be using OpenGL 3D. Hell, most of the undergrads referred to OpenGL like it was a single library, not realizing that OpenGL is just an API that many companies reimplement to utilize specific hardware. Painfully obvious by questions like, "Well, how does OpenGL do it?"
Except that, without unsigned values, Java won't let you, for example, say:
byte a = 0xFF;
-- I prefer the term "karma escort."
You have to do an explicit cast:
byte a = (byte)0xff;
That's a bit annoying, but hardly a giant pain in the ass.
byte a = (byte)0xFF;
This program will print out the correct result of -1: If you want to upconvert it to an int, don't cast it. Casting is a sign extended operation. Instead, you can OR the value. e.g.:
byte rgb = 0xFF0000;
byte a = (byte)0xFF;
rgb |= a;
Java makes you work a bit more at it, but it's nothing major. In most circumstances you *should* be using bitwise operations anyway. There are very few situations where you need to add an unsigned byte to a signed integer. (Most of them caused by a false sense of optimization or memory economy.) In those cases you use a (0xFF & a) operation to cast the byte without sign extending it.
Javascript + Nintendo DSi = DSiCade
You'd be wrong. First, clock ticks are cheap. An insanely fast computer can be bought for as little as $200-$300. You probably pay developer that for just over one day's work. If you can shave a week's worth of development time off of a project with 10 devs, then you can probably afford to double the hardware requirements. If you've got 10,000 employees waiting on this app, what do you think is more important: having your code run 10% faster, or having it available now? Installing an extra server can make up that speed difference, but nothing can recoup the lost productivity of those 10,000 people.
Second, java is fast. The JIT is going to compile the code to native as soon as it starts running a lot. Maybe within the first few seconds of operation. A large-scale program is going to be running for a long time, and those brief moments lost to compiling at start-up aren't going to amount to much.
A JIT compiled language can actually run faster than a natively compiled one. Why? For two reasons: compiled code is compiled for the lowest common denominator, and the JIT has more information available to it than a static compiler. The JIT can be smarter than a static compiler. It can see that some final variable has been set to a certain value or the isNetworkAvailable() function is always going to return the same value, and can optimize out all of the loops and branches around those statements, or just re-arrange them so that the preferred branch is always taken in speculation. It can see that it is running on a machine that has a certain SIMD instruction available, and can compile using that instruction.
I recently upgraded to a 64 bit machine. I installed a 64 bit JVM, and all of my code ran as 64 bit. It Just Worked. No rewrite. No recompile. The JVM just compiled my java as 64 bit code as it ran. I got >2gb of heap space, and it is presumably using some those new native 64 bit instructions.
I'd love to see someone port an open source Java class libary or VM's graphics library to render the graphics on the Cell microprocessor's SPE math processors, especially in PS3/Ubuntu.
Is there an open source Java OpenGL implementation? That would be a great package to see running on the Cell.
--
make install -not war
- infer from context/documentation that *some* signed values are actually unsigned values in disguise
- for such values, use bit shift instead of arithmetic shift
- for such values, manually translate them if they are printed incorrectly on the console or in a debugger
Not only that, you're not even right. You miss the following problems:That would be the specific library, not Java. Java has multidimensional arrays, though they are actually arrays within arrays. (ad infinitum)
That is generally the fastest way to access image data. I don't know about you, but I've been using the formula (y * width + x) since before Java was even invented. (Actually, it was usually a high-performance variation that derived from the formula, but it was the same basic concept.) The formula is, and please take this with the utmost respect, an absolute requirement for anyone doing intricate graphics work.
FWIW, most programmers today never have to dive down to such a level. C/C++, Java, C#, Language of Choice(TM) all have libraries that abstract away low-level graphics operations. So unless you are writing a graphics library, you shouldn't need to deal with such things any longer.
Of course, in your case you were doing low-level graphics operations. If I were to hazard a guess, you were using the AWT Toolkit to load a JPG image, which you then extracted the pixel information from using a MemoryImageConsumer. (IIRC) Primitive stuff, intended for Applets. The BufferedImage and ImageIO libraries are much more useful these days.
Javascript + Nintendo DSi = DSiCade
Oops, got my twos complement wrong in the example -- it's been a while. But the point is still valid.
Integers are for wimps.
Real graphics is done with floats.
There are places where the networks are not touching,and there are places where they are-Boeing's Lori Gunter
Everything Java does has to be done in C first. Until operating systems are written in Java, that's always going to be the case. OpenGL has been available in C for over 15 years, and by the time it was implemented in Java it wasn't a novelty anymore. Maybe there's some benefit to Java memory management in scene graphs, but all that functionality had to be written in C first before Java would run it.
Why does everyone here seem to assume I have to be making Doom 3? First, why does a graphics project have to be new? Why can't I add some graphics to my existing Java app? Porting the whole thing to Ruby then doesn't make much sense. Java is a modern, high-level language, and it is much more well known that Ruby. If you went through school more before one or two years ago (and probably up to now) chances are if you were taught one of Ruby and Java it was almost certainly Java.
Java isn't perfect, by why does every discussion even tangentially related to Java become a "Ruby r00lz!!!" discussion? I can think of many great reasons why someone might use Java. Libraries, familiarity, existing app, embedding (does Ruby have an equivelent of the applet that a large number of computers can run from a web page?).
Take it as a "If you must use Java, here is how it does graphics" if you want. The book is about graphics in Java. It's not called "How To Do Computer Graphics", "Making Wicked Fast Games", or "The Best Graphics Library Ever". It's about JAVA.
<hippy-voice>Why the hate, man? Just let it be........</hippy-voice>
Comment forecast: Bits of genius surrounded by a sea of mediocrity.
No it's not.
;)
why not use Short.reverseBytes(short) for your 2s-complement skills?
Website Hosting
Your first three points are still valid (basically the one point that you have to manually keep track of which byte variables are really unsigned). However, your attempt to add more points is pathetic. For instance, "short a = (short)65535;" works just like "byte c = (byte)255;". Furthermore, Java actually *does* have an unsigned 16-bit type. It is called "char". As in "char a = 65535; int b = a;".
mod parent funny.
Website Hosting
That's funny...it seems the folks at runescape (www.runescape.com) have had plenty of success with their JAVA 3D game. They seem like a pretty big boy to me.
Runescape: "There are currently 208580 people playing!"
But how much of the billiance of Java due to the fact that it's Java and not the way a consortium defined the API layers? The Java APIs work because they were designed by consortiums spending many years in meetings around the world to define specs. The internet enabled more collaboration with the Java specs than any language before it, but these API's have to be implemented in C.
Well, yeah. If the documentation says, "This method expects a bit-packed value in ARGB format" you had better pass it a value in ARGB format. That's true whether you're working in Java or C/C++. I pity the fool who doesn't read his documentation.
Killer isn't it? Adding that extra > sign.
I don't know about you, but I like to see my bit-packed values in Hexadecimal. It's a heck of a lot easier to read than decimal. And what'dya'know? Java just happens to have a library for printing unsigned hexadecimal values.
Um, okaaaay. Would you like to explain to the class which overflow-detection scheme you can use in C/C++ that you can't use in Java? Remember, you've got the same bits in that 32-bit value. So unless you've got assembly hooks back to the processor to give you a heads up, I don't see how you could have a test in C that won't work in Java.
First off, you're a very bad boy for using the decimal value 65535 when your real intent is obviously to fill all 16 bits with 1's. You should be using 0xFFFF for clarity instead. Secondly, the compiler thinks you're a bad boy for assigning an integer value to a short. You should have done this:
short x = (short)65535;
(Actually, you should have done "short x = (short)0xFFFF", but one point at a time.)
Thirdly, why are you doing such a thing? Java extends all bytes and shorts to integers for operations. This is a feature that gets around problems caused by newbs screwing up byte alignment with pointless attempts at saving memory. Your processor is a 32-bit computational machine. It's poor form (and poor performance) to make it pretend to be a 16-bit machine.
Oh noes! Casting rules!
As in, the rules you read when you learn how to program the language. Unsurprisingly, casts are signed. So if you don't want to cast a number (which you should never, ever, ever be doing with a bit-packed number anyway) you should be doing bitwise casts on them:
x = (0xFFFF & y);
See above for further ranting about why you are using a short for working storage rather than an integer.
Javascript + Nintendo DSi = DSiCade
As far I know,...
From what I just read, that's shorter than the distance to your coffee grinder.
I swear to God...I swear to God! That is NOT how you treat your human!
Perhaps Processing is "Java-like" because it's written in Java? Maybe you should ask the Processing dev team why they chose Java to produce their graphics? I admit that it looks like it simplifies experimentation, but it's a bad example to use to claim that Java does graphics poorly.
That's pre 7-11 thinking....
3. Division. The shortest implementation of unsigned division using signed types I could knock together in a few minutes is
What do you mean?
Microsoft invented the internet. Everyone knows that.
It's simpler to use longs, but good point. However, I do question the criticality of division in this case. In the decade I've been doing graphics in Java I've never found this to be a problem. Most of your working values are smaller than an integer, and you don't do math on bit-packed values. The values where sign matters (e.g. coordinates) *should* actually support negative values. I did up a couple of 2D rendering engines in Java 1.1 and 1.3 back when Java Applet gaming was still hot. It just wasn't an issue.
;-)
The truth is that the signed/unsigned whining by the AC is exactly that: whining. Computer Graphics *is* a mathematically intense field, but the rendering part of it is all just bitmapped data. And as any programmer worth his salt knows, there are plenty of ways to skin bitmapped data.
Javascript + Nintendo DSi = DSiCade
I've taught introductory computer graphics courses at both Stanford and the University of California, Santa-Cruz, and by far the most important change that needs to be made to the "traditional" curriculum is the introduction of the programmable pipeline. Far more so than the chosen language or API, teaching shaders forces students to understand the mathematics that lies at the heart of the graphics pipeline while simultaneously endowing them with the tools they need to create Really Cool Projects®. The prevailing mentality seems to be that asking students to handle lighting and transformations directly in an introductory setting is too difficult, but my experience has been that this is not at all the case.
For those that are interested, I have SIGCSE paper on the subject available here.
... although I sometimes have a hard time convincing IT consultants of this -- What? You want your data in a GRAPH? Are you SERIOUS? -- Good, annotated, interactive plots can be enormously helpful to make sense of numeric data, which is what a lot of business programming is about, regardless of whether you are an investment banker or a pharmaceutical researcher.
If such features are absent from some business software, it is not because users would not find them useful; it is because many business programmers lack the skills to create them.
It is true that Java lacks a convenient plotting library in its standard, but it has a decent set of basic tools in the J2SDK, so it isn't that difficult to write a simple one. Making it interactive is a bit trickier, of course. Simple plotting libraries are of course available for download, although the few I have studied were a bit too simple.
Using script languages for such purposes sounds risky to me. Some ten years ago, when I heard that the team I was planning to visit had only Macs, I did hastily write a data conversion / plotting tool in Tcl/Tk to take with me, so that I could still access and use my data --- I didn't fancy porting a FORTRAN/C++ application from Unix to Mac OS on the spot! It worked, but it was terribly slow on anything over a thousand data points or so.
Java was much better, and it allowed me to share my data with co-workers over the internet in the form of interactive graphs; in the late 90s that was quite a novelty for us... And an object-oriented language is enormously beneficial for such purposes, in my humble opinion, because that is the right way to assemble a data graph -- as a set of data objects, annotation objects, and interactive anchors.
I still regret that MS moved away from the concept of the original MS Graph, which basically treated data sets as objects to be rendered, to the array-based model of Excel, which I find much less practical, and is riddled with inconveniences and a few significant bugs. Call me eccentric.
To add to the list of problems: Comparisons work differently for signed and unsigned types.
"A JIT compiled language can actually run faster than a natively compiled one."
But in practice, it never does.
Like this: http://product.thinkfree.com/ ??
None of that is required to work with OpenGL in Java, of course.
A computer graphics course using any API (be it OpenGL, DirectX, or what-have-you) is like a data structures course that focuses solely on the STL (or your favorite language's equivalent); it has its place at a higher level but it is not a replacement for down-and-dirty, low-level study and implementation.
Many universities these days are turning out "programmers" rather than "computer scientists" -- they can get stuff done, provided the tools are available to them, but God help you if you ever ask one to create that tool themselves. Pointers scare the hell out of them, they can't read declarations with more than 1 level of indirection, even simple concepts like recursion are beyond them (I once had an interviewer tell me that most people took 15 minutes to solve the recursion interview question which took me all of 60 seconds to solve and explain, and then they were wishy-washy when he challenged their solution, even if it was correct -- they had no confidence in their solution.)
Its a sad day when a CS student goes through "Computer Graphics I" and may have never studied (and implemented) the variety of line-drawing algorithms to experience first-hand their respective code complexity and performance, or who have never experienced the joy of drawing an ellipse using a purely-incremental algorithm using second-order derivatives.
Its an even sadder day when a CS student goes through "Data Structures" and may have never implemented a self-balancing binary tree, KD-trees, red-black trees, pooled memory allocators or skip-lists.
APIs come and go, but fundamentals are forever. I pity the poor programmer who "knows Direct3D" only to have it replaced by DirectRayTracer years down the line.
Not all is lost, as there still are many great CS schools that haven't forgotten about the fundamentals, but I think there are many who have unfortunately lost their way.
The developers of Runescape and Blizzard have slightly different levels of resourcing. Is it possible, do you think, that that might JUST MAYBE have a little bit to do with the difference in the comparison?
In addition, Runescape is WAY older than WOW.
I recently completed my MS in CS, will post additional materials if anyone is interested. I used genetic algorithms to alter the look of JOGL generated visuals in my thesis "Aesthetic Emergence in Synesthetic Sculptures". Here are two batches, each with a few variations:
http://youtube.com/watch?v=F1xvnI96gFA
http://youtube.com/watch?v=XPylKUSEuuc
The wires 'weave' according to evolved vector fields - the finished product will use the vector fields in addition to 3D geometry from a Point Grey stereoscopic camera to sculpt the musicians in my band, with the animation modulated by MIDI events and other items.
Music for coding. Genetic algorithm driven visuals. http://www
Bit-packed, huh? You must really like bitwise operations. A sane language would let you express it as a struct with four members. But keep working around Java's quirks; it's no skin off my back.
Killer isn't it? Adding that extra > sign.
The amount of work has absolutely nothing to do with it. It's not much work to walk around the mines in a mine field.
Um, okaaaay. Would you like to explain to the class which overflow-detection scheme you can use in C/C++ that you can't use in Java? This doesn't work for Java, because the faux-unsigned byte you would be storing in c will wrap around in "normal" circumstances. You will have to do two checks instead of one in this case. Again, not a huge amount of work, but a minefield.
First off, you're a very bad boy for using the decimal value 65535 when your real intent is obviously to fill all 16 bits with 1's.
On the contrary, my intent was to mimic a situation like this:
struct ARGB
{
char a, r, g, b;
}color = {255, 255, 255, 255};
I really did mean 65535.
As in, the rules you read when you learn how to program the language. Unsurprisingly, casts are signed. So if you don't want to cast a number (which you should never, ever, ever be doing with a bit-packed number anyway) you should be doing bitwise casts on them:
Oh right. You're bit-packing again to deal with shortcomings of your language. As you were.
Well, there may be a lot of people out there who like Java, but I'm not one of them. Java is the Cobol of the 21st century, it's OK for bureaucratic applications, when you need attributes like "traceability" and "auditability", but come on, graphics?
Get serious, folks! Java is about the last language one would use for computer graphics. It lacks the raw speed of C, it lacks the quick and dirty coding pace of Python. If I worked for Mastercard or Citigroup I would use Java, of course, but not for graphics!
I agree. Whether a corporation invented the language should be the deciding factor in whether it's used for OpenGL. That's why I would never use C or C++ for calling OpenGL, but Perl would be a perfectly good choice.
That's not fair. To say that Java can only go as far as Runescape, while other languages such as C++ are clearly better (WoW, EQ2) is just plain dumb. You're comparing a game thats played in a BROWSER to a game thats played in FULL SCREEN. The game played in the browser (Runescape) is hampered by the browser itself. Performance becomes an issue. That, and Runescape is really old, so comparing a new game with it is stupid. That would be like me comparing a brand new Porche to a beat down '82 pickup.
Runescape cannot utilize full system resources like it's full screen C++ counterparts can. It has nothing to do with Runescape being made in Java. Remember, runescape is NOT the pinnacle of Java graphics.
No, PS3 Cell SPEs each have 256KB of local store, plus they each can DMA from each other, and from main memory another 256MB (or possibly nearly 512MB).
The PS3 in game mode uses both the SPEs and the RSX, and has the same amount of memory, but has excellent graphics.
--
make install -not war
I agree. Whether a corporation invented the language should be the deciding factor in whether it's used for OpenGL. That's why I would never use C or C++ for calling OpenGL, but Perl would be a perfectly good choice.
Say that again? C and C++ are standards-based languages with no official working implementation. That's definitely not "corporate-made", in the sense of Java (or C# for that matter).
Because object orientation is a natural fit for 3D graphics, and because I won't willingly do anything in a language so primitive that it lacks automatic memory management.
...which is based on Java.
Because it's 10-100x slower than Java?
I use Ruby most weeks, but not for 3D graphics.
I'm not a big fan of Java, but it has OO, performance to rival C (no, really), it runs on every platform I care about, and it's commonplace enough that I can be confident it'll still be around in 10 years.
GCHQ Quantum Insert installed. If only our tongues were made of glass, how much more careful we would be when we speak
Comment removed based on user account deletion
C# is available on other platforms such as Linux through the Mono project, for example this article titled C# and .NET Without Microsoft. Also since the introduction of Silverlight Microsoft can allow other OS' to run a subset of .NET code -- maybe even coded in C# -- through a browser plug-in.
You've fallen into the trap of thinking C# = Windows which is not true. Do some reading of these links and you'll be amazed what C# really is.
Also as an EMCA specification it's not likely to be tied to a platform any more than any other international standard.
Why every time someone speaks of portable code they refer to Java?
Isn't python just as portable?
The idea behind java is to prevent you from trying to do things like save memory by making items that are not fully portable. In C/C++ the size of short and int and ever char are not defined and the spec does not require integers to be represented by 2's compliment. For those reasons you should be using well defined sizes that are portable and not chars if you want to save the extra few bytes.
r y/pa-ctypes3/index.html
Source: http://www-128.ibm.com/developerworks/power/libra
I especially like the line: "Among the more interesting are 60-bit systems (CDC Cyber) which are only addressable by full words; on such a system, char is 60 bits."
If you want to be lazy and not have a full class, then in java you can just create a byte array to represent ARGB, "byte[] argb = new byte[4];" since it doesn't waste much space (I think it takes 8 bytes, 4 for the data, and 4 for the length, but that depends on the implementation).
Or, you can wrap an int (that is defined as exactly 32 bits in Java) in a class and keep all the bitwise operations that you fear hidden as implementation details and nice helper functions can be used, such as "byte getA(); void setA(byte A);" That way people don't have to worry about the inner implementation. You could even have constructors that build the ARGB object from Strings, ints, byte arrays, and other ways.
My kids actually play Runescape and doing their tech support is not much fun. Game seems to have tolerably acceptable graphics although nothing to shout about. But what a memory hog and CPU burner (literally! leave it on the "exit game y/n" flaming torch screen for a while and watch the temperature go through the roof.)
"Don't belong. Never join. Think for yourself. Peace." V.Stone, Microsoft Corporation
Try Computer Engineering - it's a bit of Electrical Engineering mixed with Computer Science with that C and assembly flavor. Minty!
It's not the execution speed that makes me stay away from Java -- it's that I like C so much more. Doesn't help that I despise the absurdly long function names (IOCCC parody)
"I've spent my whole life figuring out crazy ways to do things. It'll work." -- Montgomery Scott, "Relics"
I still have doubts that the Macintosh, for example, will receive C# support. It may be an EMCA specification, but it's development is still controlled by Microsoft, and Microsoft has a habit of poorly supporting their products on any platform other than their own. Java already has a proven track record and receives support on all platforms, including cell phones. I'm sure C# is a wonderful language, but I'm not sure it'll ever be able to claim all that.
FTA:
"In the early days, such courses dealt with low level implementation details and algorithms such as converting lines to pixels, filling rectangles, view clipping and anti-aliasing"
Well sorry , but that IS (amongst other things) what computer graphics is about. If you want to learn how to write a graphics program in Java, sure, get this book, but if you want to learn how computers do graphics you NEED to learn this low level stuff as well as going down even further to the hardware level. Any serious computer science course will teach this low level detail, only toy colleges would teach you one line library calls and pretend they're actually teaching you computer graphics.
Its a bit like someone professing to teach about filesystems then not going any deeper than fopen()!
And I have an HP calculator that can't run Java neither.
....
Java is an adulterated piece of crapola, I am telling you
IANAL but write like a drunk one.
EVE online was not written in C/C++ - it was done using stackless Python.
Yikes, forget one word and you change the whole context.
The above should say "not only written", instead of "not written".
[Grumbles about editing desires]
Runescape is run by a small group while blizzard is a rather large one with deep pockets and an army of developers and graphics designers. Obviously bliz games will have nicer graphics and whatever. But the point is, a java-based game can still not only survive, but thrive. 200,000 concurrent players means probablly well over a million active players. That's nothing to poo-poo on. I call that success.
If you're going to make unfair comparisons, at least get your competition right:
http://www.wurmonline.com/
Javascript + Nintendo DSi = DSiCade
Comparing Java to Flash won't win you any friends. Especially since you're assuming that Java == Applets. Why don't you go play some Java games instead?
o rt=5&order=1&screen=0&max=25 -- (Make sure you try Miners, Xero, and fuzetsu. Those are my favorites. Amazing that they fit in a mere 4K, isn't it?)
http://www.puppygames.net/
http://www.wurmonline.com/
http://www.javaunlimited.net/games/db.php?min=0&s
Javascript + Nintendo DSi = DSiCade
Yes I did. Sorry, another one of my brain farts.
Javascript + Nintendo DSi = DSiCade
Sure C and C++ are corporate-made. They were both created by AT&T / Bell Labs. They have gone on to later be turned into standardized languages, but Java has open standard as well.
Also, does Java have an official implementation? As far as I know, it has the JLS and a number of JCP standards. And Sun does offer a compiler and a JVM, but I am aware of nothing that makes that the official implementation.
C++ handles this pretty well by letting you express it as image(i, j). The translation to image.data[j*x + i] inlines easily, and you can templatize your image class to turn bounds checking on and off on individual instances at compile time. Some people would prefer to express it as image[i,j] which C++ doesn't allow, but surely image(i,j) (which I prefer anyway) is an acceptable compromise.