Vertex arrays should work too. At least i had them working on exactly the same machine.

NEW version :
- using Java 1.6 and JOGL 1.1.0
- "FPS counter becoming crazy" bug may disappear
- better "seperation of concerns" in the source code
- artworks displayed in the experimental version
- less use of system memory, more use of video memory for resident textures
- a very small increase of speed

WARNING!
Some recent open source drivers under Linux may cause some problems, gray rectangle flickering on the screen. These drivers don't support alpha components inside the textures. I'm sorry, you will need to use proprietary drivers if your card itself really support 32 bits textures.

Vertex arrays are not an extension, they're always available.

Are you sure you're not getting confused with vertex buffer objects?

PLEASE read the code before saying wrong things! "GL_EXT_vertex_array" is an extension! I know my source code is dirty but I explained above that the answer was inside this class! I have been programming games for eight years, I really make the difference between vertex arrays and VBO. Of course, they are not always available. Come back down to Earth! There are still people who have old chipsets and old graphics cards where nor display lists neither vertex arrays are available. Ok, it is very rare as time goes by but it doesn't mean that it is always available, you are totally wrong!

On the other hand, I will make effort to clean the code and to add much more comments before implementing the cells-and-portals algorithm as I know my code is hardly readable.

Finally, I am really surprised that someone who has been here for a long time is able to tell something so wrong. It is evident that hardware has evolved. Everything has not always been available.  I'm sorry, Orangy Tang, how long have you used OpenGL in your life?

WARNING! The source code on my website has not been updated since the beginning of July. Things have changed...but not inside the class below which show you how I check some extensions.

/*This program is free software; you can redistribute it and/or
  modify it under the terms of the GNU General Public License
  as published by the Free Software Foundation, version 2
  of the License.
  This program is distributed in the hope that it will be useful,
  but WITHOUT ANY WARRANTY; without even the implied warranty of
  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
  GNU General Public License for more details.
  You should have received a copy of the GNU General Public License
  along with this program; if not, write to the Free Software
  Foundation, Inc., 59 Temple Place - Suite 330, Boston,
  MA 02111-1307, USA.
*/
package drawer;

import java.nio.FloatBuffer;
import javax.media.opengl.GL;

class DynamicVertexSetFactory implements IDynamicVertexSetFactory{

    
    private IDynamicVertexSetFactory delegate;
    
    
    DynamicVertexSetFactory(GL gl){
        if(gl.isExtensionAvailable("GL_ARB_vertex_buffer_object")
       && gl.isFunctionAvailable("glBindBufferARB")
       && gl.isFunctionAvailable("glBufferDataARB")
       && gl.isFunctionAvailable("glBufferSubDataARB")
       && gl.isFunctionAvailable("glDeleteBuffersARB")
       && gl.isFunctionAvailable("glGenBuffersARB"))
       delegate=new DynamicVertexBufferObjectFactory(gl);
   else
       if(gl.isExtensionAvailable("GL_EXT_vertex_array")
       && gl.isFunctionAvailable("glColorPointer")
       && gl.isFunctionAvailable("glDrawArrays")
       && gl.isFunctionAvailable("glDrawElements")
       && gl.isFunctionAvailable("glDrawRangeElements")
       && gl.isFunctionAvailable("glIndexPointer")
       && gl.isFunctionAvailable("glNormalPointer")
       && gl.isFunctionAvailable("glTexCoordPointer")
       && gl.isFunctionAvailable("glVertexPointer"))
           delegate=new VertexArrayFactory(gl);
       else           
      delegate=new DynamicDefaultVertexSetFactory(gl);
    }
    
    
    public DynamicVertexSet newVertexSet(float[] array){
        return(delegate.newVertexSet(array));
    }
    
    public DynamicVertexSet newVertexSet(FloatBuffer floatBuffer){
        return(delegate.newVertexSet(floatBuffer));
    }
    
    public DynamicVertexSet newVertexSet(VertexSet vertexSet){
        return(delegate.newVertexSet(vertexSet));
    }
}

Ok, so technically vertex arrays are an extension. But they were introduced with GL1.1 which is usually considered the basic version everyone has. I've never seen a 1.0 driver in the wild, especially since having no installed drivers on windows will give you a default software 1.1 renderer. OpenGL 1.0 is so limited it's practically unusable anyway - it doesn't even support texture objects, and I'll bet you don't check for their presence before using them (I'd check, but I can't see any references to gl textures in your old source code).

Conversely, display lists have been present since 1.0, so your assertion that they might be unavailable is incorrect.

Don't you have anything more interesting to say?

I won't fully support it, I told that at least, I would show a popup if there is something wrong.

Fine, I treat even a separate matter!  That's good!

Don't suppose that I'm confused. At work, no feature has been disabled for OpenGL, I checked it, maybe it is a bug on the driver. Finally, my "optional" check prevents the game from crashing. That is why it is not useless to check it. Display list support is not optional but sometimes, a chipset is announced to be fully compatible with GL 1.1 and that is not true. Sometimes, it is only a problem of driver, sometimes it is really unsupported.

I don't agree with you. I will do my best to correct bugs when it is possible. A part of my code corrects a problem of buffer swap on this kind of chip. I won't remove it. I can't correct every bugs of the environment but I will do what I can.

Good idea! At first, I have to find a way to detect this kind of chipset. Then, I must plan to design a mechanism to catch GLException and to perform an adequate treatment if the vertex arrays are not supported.

Nevertheless, I am not sure that I can detect which graphics card or chipset is being used. If you know how to do it, I am really interested in this.

Finally, on some architectures, I fear that the game might crash even though I try to catch the GLException and to associate an other treatment. With JOGL, I think almost all functions are available. It is not enough, you can't only check if the function is available in a particular machine. For the vertex arrays, it will always answer "true", won't it?

Currently, the game uses another mode of drawing if there is something wrong with vertex arrays, it is just slower. I know that I can't correct every bugs not inside the game but rather in the environment, that is not the aim of my project. Nevertheless, I will do my best to prevent the game from crashing. Don't forget that I plan to use a cells-and-portals algorithm in a few months. Then, the game will be hugely faster than now. 

Finally, as I have still some problems with my driver, I won't be able to modify any visual effect this week and maybe next week. I will use this time to improve the readability and the design of the code. I plan to reach the following aims :
- more comments, at least a complete description of each class, each attribute and each method to make the source code more readable
- respect the MVC design pattern to make easier the creation of the multiplayer online mode
- decompose the project in some components to improve the "reusability" and the "maintenability" of the source code
The following components will be created :
- interfaces : component containing all the interfaces of the project
- main : main component of the project which uses the other component
- sound : component handling the whole sound system (using JOGG + JORBIS)
- tools : component with misc. devices to convert files from Vincent Stahl's format into an OpenGL friendly format and to modify the way to build the textures (priority handling)
- drawer : component used to build, modify, draw and delete set of vertices, textures coordinates and normal coordinates
- md3 : component used to load the MD3 model
- context : component handling the OpenGL (available extensions...) and the sound context

If I succeed in installing my driver, I will go on trying to display all objects in the experimental mode.

I have a lot of things to do 

The component architecture is going to be finished. I had the choice between 2 kinds of component architecture :
- component, link, provided/required interface
- component, port, connector

The first kind is really fine when the provided interface and the required interface are exactly the same. It is very simple and it prevents the redundancy of interfaces (an interface appearing multiple times only with a different name or in a different package). However, the component is not independent, it always depends at least on the component which contains all the interfaces, it complicates the tests on the component and it decreases the reusability of your code as the programmer can't put only your component and connect it directly to another project. I advice to use this kind of architecture only for very simple projects.

The second kind is better fitted when the provided interface and the required interface are different. Then, you use an adapter. It is more complicated and it might force you to duplicate interfaces uselessly. However, the component is fully independent, it can be tested separately and more easily reused as the programmer can take your component and put it in his own project (if it is well documented). I advise to use this kind of architecture for complex projects, open source projects when the maintenability and the reusability are very important.

I chose the second one and it works. The source code will be updated monday. I will try to handle unbreakable objects in the experimental version during this weekend.

Warning! Important information about the future of the game
Money can be a serious obstacle in the development of a project. Nvertheless, my game will always be free (open source and with no charge). I didn't give up the multiplayer online mode, I only need to find a solution to share a dedicated server with some people. If I need money, I will pay it directly if I can afford it, I won't charge the users, I don't plan to create fees or anything like this. I know that my game is still ugly and slow. I won't ask for money even though it would become more interesting. I consider that the video games are works of art, everyone should have an equal access to the art and the culture in a fair world. The only way I know to be sure to give an equal access to my game to everyone is to keep it free of charge. This project is open source because I consider that everyone should have an equal access to the information, whatever the subject (sciences, history ...). Allowing people to access easily to the information is a benefit for the whole society.
I understand that many people here want to live from their games, I respect this choice, they don't do evil, they dream of living from their passion, it's beautiful, I respect their ambition. Many of them would agree with charging the customer, it's their viewpoint, it is the most evident way of getting money. However, I've made a different choice, a complicated choice : I want to avoid charging customers even though the development of my game has a real cost. As I'm not only a dreamer, I have found a solution, a realistic solution to provide a free access to gaming without advertissement or sponsoring. I will announce it on my own website in a few days.




game executable :
Link removed
Link removed

source code :
Link removed

Could you post about it here too? I'm interested in your solution, and others here might be too.

Works OK here - still a bit on the slow side though! (AMD 2800+ JRE 1.6)

Ok. Thanks for this feedback. It doesn't come from my game because the manifest file has been updated, I changed the "Main-Class" attribute some days ago. There must be an other cache somewhere. This cache must contain data about the old manifest file but it tries to use it with the new jar file. As the main class changed between these two versions, there is a contradiction between the old manifest file and the new jar file. Then, Microsoft Vista Ultimate doesn't find the "stahlforce.d3caster" class which was the old main class.
As I want to be able to confirm this without any doubt, I will check my config files anew. Did you use the link? Did you start the game from the command line? I am very sorry for the disturbance and I'm really grateful for your answer as I don't own Vista and my alpha testers are not available currently.
Yes, the slow side is slow, that's why it is called the "slow version" but you couldn't know that I don't work on it anymore. I don't optimize the slow version anymore, it would be a waste of time. I'm currently rewriting a complete model (MVC) and a precise collision system to provide all the features currently available in the slow version in the experimental version this time. Thanks for your help. Which operating system did you use to launch the game? Thanks for the feedback too. Don't forget that it is like 2 games work together at the same time. The next version will be quicker.

Windows 2000 pro

Hi! Thanks for this feedback. I made the same mistake a second time. Now, the main method is in the component called "connection" inside the class called "GameServiceProvider". I've just updated the config files anew. I hope it will work this time and thank you for your patience. When you launched the game, it called the old main method which did not instantiate the connection between the provided services (from "drawer") and the required services (from "main"). Then, the delegate does not reach the class which provides the service. Sorry. I'm tired, I have made more and more mistakes!

On the other hand, I'm testing the vertex shaders and the pixel shaders for my game. I hope it will be useful.