quote:Original post by cyansoftquote:Original post by _DarkWIng_
Shader doesn''t have to do anything how the GC data is submited to GPU.
If so, they why did Yann have a fill_cache method for his shader system? Jamessharpe also mentions the shader being used to fill VRAM.
If the data in the GC''s is always in the format required for rendering from the shaders i.e. you don''t need to transform it, then you can get away with using VertexArray pointers straight into the GC data. I know that DarkWing uses VBO directly as the internal format for the GC, which is fine if you don''t need API independence, but if you do then you need an additional translation layer somewhere, whether it be by use of a polymorphic GeometryChunk or an extra level of indirection via a software buffer(Yann''s method). The extra level of indirection can also become useful if you are trying to adapt the system for streaming over a network.
Here''s an example of one of my fill_shader_cache functions:
void SimpleGouraud::FillShaderCache(ShaderPass &pass){ struct Vertex { float position[3]; unsigned char colour[4]; }; //get a VRAM slot VRAMSlot * slot = tools.GetVRAMSlot(sizeof(Vertex)*pass.geometry->GetNumVerts()); pass.SetVRAM(slot); //copy vertex and colour data from data stream via effect class Effect * e = tools.GetEffect(pass.effectID); unsigned short vertexOffset = e->VOffsetTable[OT_VERTEX]; unsigned short diffuseOffset = e->VOffsetTable[OT_DIFFUSE]; unsigned short stride = e->stride; const unsigned char * src = pass.geometry->GetVertexStream(); int verts = pass.geometry->GetNumVerts(); Vertex * dest = (Vertex *)slot->Lock(); for(int i = 0; i < verts; ++i) { memcpy(&dest->position, src + vertexOffset, sizeof(float)*3); memcpy(&dest->colour, src + diffuseOffset, sizeof(unsigned char) * 4); dest += 1; src += stride; } slot->Unlock();}