Saturn wrote:EmmanuelD, I read your proposal and have a few comments.
The smallest of these: What's the name in the add-function for? I don't believe vertex/index buffers need to be handled by name in Irrlicht, this should be removed. If an application needs to track those by name, it can easily do the mapping itself.
This was a late addition to the proposal. I mainly wanted to replicate the texture creation interface in order to make things consistent. If I remove the name then the buffer objects will be the only non-queryable resources in the software (as every other object can be fetched from its manager). But this is not a very important point, and in fact I don't see any problem in removing the name.
Saturn wrote:
You don't mention IUnknown, I take it the buffers are derived from it?
Yep. IUnknown is the root of all Irrlicht, there's no reason why the new classes should nto inherit from this class.
Saturn wrote:
On to the beef:
E_VERTEX_TYPE should contain additional members: EVT_VB_FIXED,
EVT_VB_DESCRIPTOR.
I beg to differ. E_VERTEX_TYPE doesn't need yet more members, so that all the alway-the-same switch-statements are amended with yet two more cases. I believe that you should get rid of E_VERTEX_TYPE altogether. And instead of having now three, then five different mesh buffer interfaces, only one is needed and that should be flexible and comfortable enough.
Problem is that we need to differentiate with the current vertex type. I'd also like to get rid of E_VERTEX_TYPE but this can't be done without changing the current Irrlicht interface (let's do that for 2.0 if it is really needed).
Saturn wrote:
The driver returns some IVertexBuffer/IIndexBuffer pointer. The client program doesn't need to care, whether this is really a hardware vertex buffer or not. Thus instead of failing, the function could fallback to a simple memory buffer. Then the drawVertexBuffer function would use the same way of rendering as done now by drawMeshBuffer()
Here, we have different opinions on the subject. If I specify a default ussage then it probably mean that I don't care abouthow the buffer is managed. But if I specify any other usage then it means that I really want this buffer to be managed in a particular way? Silently changing the usage to application memoey simply don't fit the bill IMHO. Moreover, it can fail because the hardware is unable to do something with it. There is no point in creating a vertex buffer object that can't be supported by the driver at all (for example, putting two position vector in the same vertex buffer).
Saturn wrote:
The E_VERTEX_TYPE types can be used to create preconfigured vertex declarations maybe, but else they should be removed.
I'd see what I can do with this in mind.
Saturn wrote:
Also your proposal leaves the interesting part of how the vertex declaration shall look like out completely, and it doesn't tell anything about the interfaces of the newly introduced types. So commenting these is not really possible, eventhough this is an important part. It needs to be easy to use, but still flexible.
It can't be both, unfortunately, although some standard vertex descriptors can be built in Irrlicht to ease their creation.
Basically, the system works like the vertex declarators of DX9: a list of dword describes the vertex streams (yes, there's an 's' here). I'll postpone my implementation in order to write a v0.4 of the draft to explain all these (and to take your comments into account).
Saturn wrote:
How do I write to the buffer and read from it? How do I access a certain element of vertex? How do I determine the size of a vertex, the size of an element? (2D/3D position, 1D/2D/3D texcoords, etc...) Is it allowed and possible to have gaps in between vertices, to maximize the usefulness of the vertex cache?
You typically access the BO data by using lock/unlock. Accessing a particular element of the vertex needs you to know its position. You can either cast the lock() result to a known vertex structure or use a more complex class that will be able to interpret the vertex descriptor and do the job for you. Unfortunately, this class can't be in the irrlicht dll for efficiency reason (if one of the function returns a position vector, the user have no way to know what is the offset to the next position vector, except by doing some nasty pointer math - this should be done by the proxy class, and it can't be done in a virtual function for obvious reasons).
Vertex and element size can be computed from the vertex descriptor itself.
The vertex descriptor can allow gaps, but it is up to the driver to allow them or not. Actually, in my idea, the vertex descriptor can be used to describe a vertex made of one or more vertex streams. It is flexible, but not that easy to handle (although it is not utterly difficult to understand IMHO).
Saturn wrote:
All this is not answered.
I'll try to answer all these questions in the next draft.
Saturn wrote:
All in all, I don't believe a solution that would clutter the irrlicht interface is wanted, what I prefer is an integrating interface change, that smoothly encompasses what now is IMeshBuffer and the new hardware buffers. Ideally without forcing the client program *and* as far as possible irrlicht itself to distinguish between these two.
If I understand this statement correctly, this would break the current irrlicht interface - something I wanted to avoid. I'll still try to see if something can be done with IMeshBuffer.
Thanks for your comments. They are noted, and I'll take them into account.
-- Emmanuel D.