Jump to content

  • Log In with Google      Sign In   
  • Create Account

Banner advertising on our site currently available from just $5!

1. Learn about the promo. 2. Sign up for GDNet+. 3. Set up your advert!


Member Since 11 Mar 2000
Offline Last Active Yesterday, 06:09 PM

Posts I've Made

In Topic: Design: Managers VS Single Entities

04 May 2015 - 12:59 PM

When we talk about addRenderable, would a renderable have the data for the VBO / IBO. Where this data will actually be put into the buffer. Where the render system has a giant VBO / IBO that grows / shrinks when renderables are added. Or would it be that each renderable has its own individual VBO / IBO (the actual GPU buffers) that is used by the render system?


For sprite-based rendering, you shouldn't need to worry about vertex data at all. The render system can trivially generate vertex data for sprites because they're just unit quads centered at the origin, and since the render system is also managing texture resources, it would need to "own" the UV data for the vertices anyway. All the renderable would need to specify is translation, rotation, scale, and image resource of the sprite. Multiple renderables that reference the same image resource can reuse the same vertices. A clever render system could atlas multiple sprites into the same texture resource, so that the only state that needs to change between rendering individual sprites is the transform.

In Topic: Design: Managers VS Single Entities

29 April 2015 - 02:06 PM

Ok, so we really are talking about something like my original psudo code (second post by me).


Not quite, since methods like DrawSprite and DrawParticles (if I'm referring to the correct post) imply that calling code tells the renderer what to render, and when to render it, based on the order and presence of draw commands. Rendering is guided by procedures, which is at the core of an immediate-mode API.


In a retained-mode API, calling code only manipulates a model, i.e. data, and the render system handles what should be rendered and when. You're not calling into the render system every frame telling it to render something. It already knows about your sprite because you added it to a list (via addRenderable), and it will stay there until you remove it (removeRenderable). The correct render order of the sprites, both among themselves and versus other renderables like particles, can be entirely data-driven. Provided that you give the render system enough information to perform the sorting (Z-order, transparency, etc.), it should solve any of the issues you have.

In Topic: Design: Managers VS Single Entities

28 April 2015 - 11:48 AM

What Josh is describing is a retained-mode API, where the graphics library (RenderSystem) maintains its own internal model of the scene. The application adds and removes "renderables" from that scene, however beyond that the graphics library handles how and when everything is drawn. What you have right now is an immediate-mode API, where the application maintains the model and issues drawing commands to the graphics library.


In the retained-mode API, the application builds the scene using the aforementioned renderable primitives, but that's it. The graphics library does the rest. There are no batchers issuing draw commands to the API. If you want to add and remove a sprite to and from the scene, it would look something like this:

// when the game object represented by the sprite is created
Sprite* sprite = new Sprite("Foo.png", Vector2(100, 100));
// ...
// when the game object represented by the sprite is destroyed

That's it. As far as batching is concerned, that can and should be automatically detected by the renderer. If all your sprites use the same vertex format, same shader, etc., the renderer will know and can combine those vertices into the same VBO and collapse the draw calls. Same thing with particle systems, or 3D meshes, or anything else that can be rendered in your scene.


This leads to the last point, which is is that the graphics library should own and manage the low-level graphics resources like vertex buffers. The application should only deal in abstractions, and let the graphics library determine what physical resources are required, and how to manage those resources.

In Topic: Picking a random value from array with priority

09 March 2015 - 01:38 PM

Out of curiosity, what is it you're trying to model? Sometimes the domain can influence the best approach to dealing with probability densities.

In Topic: null a vector of pointers in a parameter?

02 March 2015 - 12:29 PM

Do you absolutely need a null-able parameter? Or could it be an empty container? How would the behavior of the function differ?