Jump to content
  • Advertisement
Jan Haas

Is the interface of my api agnostic rendering layer well designed?

Recommended Posts

Hey guys, 
I hope this is an appropriate question.
Well, I tried to design a little part of my rendering layer. bgfx oriented.
Question: Is this good design? And what changes would you suggest?

vboID CreateDynamicVertexBuffer(VertexBatch, Duration);
vboID CreateStaticVertexBuffer(VertexBatch, Duration);
void  UpdateVertexBuffer(vboID);
void  DeleteVertexBuffer(vboID);

- My interface works with IDs that are structs for type safety . An ID maps to something the corresponding method(s) can interpret. It doesn't necessarily map to OpenGL handles etc. A create* method yields a valid ID. If the creation fails an exception is thrown.

- VertexBatch is responsible for capturing the vertex data. It provides convenient OpenGL Intermediate Mode syntax. It has no virtual methods because it needs to be fast.
- Duration is an enum that lets you specify how long the data will remain on the GPU memory. The reason is that I can batch static level geometry together in one big Vertex Buffer and just return the offset into this buffer. Other types of memory can be handled differently, but I don't know how... Question: How do you normally handle this scenario and what is with data that frequently changes? 
- Dynamic Vertex Buffer cannot be updated, StaticVertexBuffer can.
- If a vboID is deleted I may or may not destroy the underlying resource. Depends on the type of memory (frequently changing etc.)

If this question somehow doesn't belong here, it's okay ;)
Thank you 

Edited by Jan Haas

Share this post

Link to post
Share on other sites

The best way to tell if multi-platform code works on the systems is to get it working on the systems.  That will tell you what is missing or what is cumbersome.

The Big Design Up Front pattern can help guide your engineering efforts, but the implementation details will change when you get into the actual work on the systems. There will be 'found work', there will be unknowns that you need to solve once you get to the details of making it work.

Once all the critical functionality is present, add utility functions to simplify the common patterns.  Usually there will be advanced patterns that will require the hardware-specific functions, so be prepared with accessors to expose them when needed.

Share this post

Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!