Hi, I'm currently working on an abstraction layer between Direct3D9 and OpenGL 2.1.

Basically there is a virtual class (the rendering interface) that can be implemented with D3D9 or GL21 class. The problem that I have is that I don't know how to store and send the vertices. D3D9 provides FVF where every vertices contains position, texture uv and color in a DWORD value. OpenGL handles the single vertices' elements in different locations of memory (an array for position, an array for texture uv and an array for color in vec4 float format). Basically I want an independent way to create vertices, the application should store them in a portion of memory, then send them all at once to the render interface, but how? I know that OpenGL can handle the vertices in D3D compatibility mode (with glVertexAttribPointer, managing stride and pointer value) that seems to be slower than the native way, but how to manage for example the colors? D3D9 accepts a single 32-bit value in integer format, OpenGL manages it in a more dynamic (but heavy) way, storing each color's channel in a 32-bit floating point value. In this case I can handle the 32-bit integer value inside the vertex shader and then convert it in a vec4 right? But all these operations seems to be too heavy. In the future I want that this abstraction layer is good enough to implement other rendering engines like Direct3D11, OpenGL ES 2.0 and others. So my main question is: there is a nice way to abstract these two rendering API without to change the rest of the code that uses the rendering interface?

How are you creating your vertices anyway? I would create an API independand vertex layout that fits your needs, and have the actual rendering implementation translate this into the correct vertex layout for each API. I don't know if this is the optimal way, but at least it will cause the least problems since the actual GPU vertices are quaranted to fit the current APIs needs. Creating could take a bit longer, but that all depends on how intelligent you implement the translation of your generic vertex format to the API specific. Pseudocode might go like this.

modelFile = LoadFile("Model.myext");

GenericVertexFmt vertices[modelFile.numVertices];

for(each vertex in model)
{
vertices = vertex; //optimal if your file format is API independant, too
}

renderClass.createVertexObject(vertices); //creates a vertex object for the current implemented API

Thats at least how I'd do that, again there might be a better approach, I havn't done this myself but it appears to be a good possibility.

I'd recommend not supporting fixed-function pipeline at all, and instead requiring pixel and vertex shaders.
In D3D9, this means that you'd be using vertex declarations instead of FVFs.
Both D3D and GL allow you to store arrays of individual attributes or strided structures of attributes. The optimal memory layout depends on the GPU.
I've not heard of 'D3D compatability mode' in GL...
Both APIs let you have 4-byte vertex attributes (e.g. For colors).

Yes, I found the vertex declaration more flexible than FVF. How D3D supports individual attributes? And how I can say if the GPU prefeer packed or individual vertices attributes? Seems that OpenGL manages better in a way, Direct3D9 in another way. I found the D3D9 compatibility mode here.

This can be a solution obviously, but can be overweight as works in cases of a lot of vertices. Currently I'm creating a lot of vertices at runtime that handles sprites with XYZ coords, UV coords, colors and a value that points to the palette index (the value is processed by the fragment shader).

This can be a solution obviously, but can be overweight as works in cases of a lot of vertices. Currently I'm creating a lot of vertices at runtime that handles sprites with XYZ coords, UV coords, colors and a value that points to the palette index (the value is processed by the fragment shader).

If I understood Hodgman correctly, there is no big difference in the actual layout of the vertices for both APIs. Using your own format would just assure you can plug in any API you want, while you might need to create a format struct that is aligned to certain bytes (just assuming, not really my stuff here, sorry) it would be a simple memcpy (or similar) operation, which shouldn't be too costy, as far as I can say. Granted that you already don't do things much different then writing your vertices in an array and copying that into the vertex buffer, unless there really is a huge difference in how both APIs expect their vertices, it could cost virtually nothing.