What are DirectX and OpenGL (part 2)

Continued from this post.

So here is where I answer some of the big questions:

What is the difference between DirectX and OpenGL? The answer to this one is: everything. OpenGL was designed ages ago (pre 1990), while DirectX 1 was build (1994) specifically to draw game developers from DOS onto the new Windows 95 platform. DirectX is (to all intensive purposes) a Windows / Mircrosoft only solution, while OpenGL runs on most desktop operating systems that exist (including a variety of embedded platforms). While DirectX provides strong support for many features outside of 2D and 3D Graphics, OpenGL relies on external systems to provide that functionality (potential systems include: SDL, OpenAL, GLUT (OpenGL Utility Toolkit), or even DirectX).

What does DirectX Compatible mean? When a graphics card is DirectX 9 Compatible, it means that it supports the DirectX 9 specification and can run software built to run on top of DirectX 9. Due to it’s history, each version of DirectX breaks compatibility with the previous version. As a devloper, I see this as a nightmare for Microsoft and the developers that work with DirectX. Mainly for a developer: if you are qualified in DirectX 10, you need to learn how to drive DirectX 11.

Why is there only OpenGL 1 and 2? Considering that OpenGL is the older of the two, these numbers make OpenGL seem way out of date. The simple answer to this question is: Extensions. Where DirectX revises the entire platform with each release to incorporate new features, OpenGL has a system called Extensions. This allowed graphics card vendors to add new functionality without changing OpenGL itself. Those applications and games that needed the Extension can look ask the OpenGL system for the Extension, if it doesn’t exist: the game can work around not having the Extension, or explain to the user that their graphics card cannot support it. Major Extensions in recent years include:

• Multitexturing
• Normal Mapping
• Shaders

Why is there no such thing as an “OpenGL compatible” graphics card? Again the answer is Extensions. Because the core OpenGL specification is so simple, almost any graphics card that is capable of any 3D graphics is OpenGL compatible. For that reason, no-one bothers with the idea of “OpenGL Compatible”.

What are DirectX and OpenGL?

Most people have no clue as to what DirectX or OpenGL actually is. Most people know DirectX as “the thing I need to run my games”. I felt it was time to write an explanation that clears up exactly what DirectX and OpenGL are. Below is a simple “stack” diagram to show how the layers between your Graphics Card (NVidia; ATI; Via; Intel; S3; etc.), and your Games fit together:

Going from the bottom layer (your hardware), to the top layer (your Games): the first layer is the “Hardware Abstraction Layer”. This layer is provided by the Operating System (Windows, Linux or Mac OS), and allows Device Drivers to “talk” to the hardware by sending and receiving data and commands. It’s a bit like your web browser sending and receiving data to a web site on the internet.

However, each graphics chipset has a different protocol (think of it like a language) that it understands. Thats where the Device Driver layer comes in. The Operating System defines a set of standard language and set of commands that the Device Driver must provide to the Operating System. The Device Driver is responsible for translating those “Operating System Commands” into a the protocol that the actual Graphics Card can understand. A bit like a human translating between two languages.

However, generally a Graphics Device Driver for an Operating System generally has a very minimal set of commands for basic 2D operation (things like “draw this picture over here”; “draw a line here”; etc.), because there are still many graphics cards in the world that don’t support the complex operations expected by an advanced 3D Game. To compensate for that, DirectX and OpenGL provide an extended set of commands for doing complex 3D operations (like “draw a polygon”; “move the camera like this”; etc.). Why make the Graphics Hardware do this? Having Hardware perform an operation is almost always faster than having software do it, thus the term “3D Hardware Acceleration”. DirectX and OpenGL give software (like Games, a level editor, or a 3D modeling package) access to the more advanced features a Graphics Card may provide. You might think of them as an “Advanced Device Driver”.

But

• What is the difference between OpenGL and DirectX?
• What does “DirectX 7/8/9/10 Compatible mean”?
• Why is there only “OpenGL 1 and 2”?
• Why is there no such thing as an “OpenGL Compatibly” Graphics Card?

Well, I’ll be answering those questions in my next post.

How do you drink coffee?

I love coffee, I used to hate it, but now I simply can;t live without it. Like so many people in my line of work, I’m a caffeine addict. If I don’t have a cup of coffee or two in the morning, I get a splitting headache (tend to happen on Sunday when I forget to make myself a cup in the morning).

So how coffee do you drink?

• Not at all?
• Every now and then?
• Lots of it?
• Total addict?
• Give me an IV dammit! 😛

And how do you drink it?

• With milk and sugar?
• With just milk?
• Black?
• Strong and Black?
• Through a needle in my arm!

Yes this looks like a poll, but I prefer comments.

Native looking Netbeans on Linux

It’s all very fine and well those Windows people having a nice native Look & Feel under Netbeans, but what about us lowly Linux types? Well as many already know, Sun implemented a GTK Look & Feel around the 1.5 release, but the Metal Look & Feel is still the default on a Linux system, even at 1.6. The new GTK Look & Feel actually uses GTK widgets underneath, so will emulate the GTK Look & Feel very closely (although I’ve come across a few minor issues with scrollbars).

So how do you invoke Netbeans with the GTK Look & Feel? It’s documented in the Netbeans documentation:

Instead of simply invoking the /bin/netbeans executable, invoke:

/opt/netbeans/bin/netbeans -laf com.sun.java.swing.plaf.gtk.GTKLookAndFeel

Substitue /opt/netbeans for wherever you installed Netbeans to.

Hint: You can open your “/opt/netbeans/etc/netbeans.conf” file, and add the “-laf com.sun.java.swing.plaf.gtk.GTKLookAndFeel” to the end of the “netbeans_default_options” variable.

This is all very fine and well for GNOME people, but what about the KDE users out there? The answer comes in the form of the QT Engine for GTK. It makes GTK applications use QT for their rendering (installed by default in SUSE).

Finally, heres a screen shot of Netbeans running with the Serenity Look & Feel (under KDE). I know it doesn’t look great, but it illustrates the idea anyway 😉 Click the image for the full view.

EoD SQL 0.9-beta Released

Due to a lot of work having come my way recently, I’ve decided to do another EoD SQL Beta release instead of going directly to 1.0. Several known bugs have been fixed in this release, and generally things are working much better than they used to. Here are some of the highlights of this release:

• Queries are now pre-validated instead of lazy-validated
• More detailed error messages
• Query Strings are sanity checked during validation
• @SelectPrimitive works as expected and can now handle Collections of primitives
• JDBC 4 Query Strings (“?1, ?2” instead of “?{1} ?{2}”) work again
• java.sql.Date, Time, and Timestamp are now known primitive types

There is still a bit of cleanup work to do, but this release should be a lot easier to work with, and a lot more stable.

Enjoy 😉

Making Swing feel like Web 2.0

The more people use Web 2.0 application, the more they enjoy the lovely (mostly blue / purple) look-and-feels. The problem is that while you have lovely CSS and loads of images to make a web page look nice, desktop applications look just the same as they always did. So I’ve collected a few tips and tricks to make you Swing applications look really really good.

1. Look and Feels
   1. JGoodies Plastic – my personal choice
      
   2. Javootoo Look & Feel – a listing of Swing look-and-feels
2. The Popup class!
   1. Familiarize yourself with the javax.swing.Popup class
   2. Use it instead of normal modal JDialogs
      1. Don’t overuse it, think carefully about what you put in it
      2. You can’t drag a Popup or minimize it
   3. Can be used instead of ProgressMonitor’s etc.
3. Borders
   1. Use Compound and Empty borders to pad your content
   2. Use the LineBorder class to create rounded corners
4. Animating Card Layout
   1. This looks massively cool for toolboxes and the like
5. Almost every Swing component supports HTML 3.2 as text content
   1. <html>Hello <b>World</b></html> can be put in a JLabel, JButton, JCheckBox, etc. etc. etc.
   2. You don’t need to use a JEditorPane or JTextPane for fancy looking content
6. Stop thinking static / table layout
   1. You can use setVisible just like you use the “display” attribute in CSS
   2. You can add and delete components (you may need to revalidate() the Container though)
   3. Create your own LayoutManagers if all else fails
7. ResourceBundles are your friends!
   1. They can be used to hold complex HTML content as well as simple text
   2. Use the java.text.MessageFormat to format your strings

Work and Coffee have taken me!

I’m working on a new post, but it’s taking a lot more time than usual (as you can tell). Work is also taking it’s toll on the amount of time, combined with the fact that I’m gearing up for the start of a move (and a wedding). So I’m really busy at the moment. I’m also working more on my photography and art (I’ve spent to long just coding), and to top the list off, I’ve also started work on a novel, and a possible graphic novel. So while I work on this next blog post, take a look at my deviant art page.

Hope everything is going well for all my readers out there 🙂

Extending the Filesystem Idea

My idea of a filesystem for objects has extended itself in my mind quite dramatically. I find that a lot of things I store in a database would be really nice to store on the filesystem. But of course in a server environment, using the filesystem is a “bad idea”. There are really good reasons for not using the filesystem in a server application:

• When you’ve got lots of users it’s really easy to run out of file-handles
• Locking becomes a mission that you mostly have to handle yourself
• You may be running in a cluster, and then your admins have to deploy special filesystems
• The filsystem is “slow”
• You loose the content based addressing of a relational-database

That said, in many cases, it makes abundant sense to use a “filesystem” of some sort or the other to store your data. So my idea extends to this:

• A “Filesystem” API that can store any data
• The filesystem is contained in one file (2 if you journal it)
• The filesystem can have a caching layer put on top of it to improve performance
• The API supports:
  • Locks on files (or parts of a file)
  • Symlinks
  • Events
• A Network layer for clustering

If my work allows, I’ll be  developing this API and open-sourcing it.

A File-System for Objects

I’ve been thinking about it for a long time: Why can’t I have a sort of file-system that stores Objects instead of files. Well today I started working on one. I’ll probably be open-sourcing it once I’m happy that it mostly works. Basically the API works a lot like java.util.prefs. Instead of opening files and having to handle reading and writing from them, worrying about how many file handles you’re holding and the like, you simply store objects in directories, and can ask for them back later.

The advantages of the API are:

• You never directly open or close a file
• The entire system operates out of a single “datastore.dat” file (if using the default File-System implementation)
• Objects can be added, changed and removed asynchronously
• The implementation can store the objects anywhere:
  • Filesystem (included)
  • Memory (included)
  • Across a network
  • In a database

The idea is that you can have a simple-to-use long-term store of Objects (and arrays of Objects) in an application.