Hey sosa,

I haven't done anything with DirectX, so this might not be good advice. If I understand correctly, the issue is that you need to have varying size vertex buffers used by your RenderItem's, but you don't want to do a DirectX CreateVertexBuffer and DeleteVertexBuffer every frame? Maybe what you could do, is just allocate a huge vertex buffer, and use it like a memory pool. Your RenderItem's ask your pool manager for 50 vertices, and it returns the buffer and a start index. Then you just offset all of your indices by that amount and you're good to go.

Hopefully that helps, or maybe I misunderstood your issue?

James

Originally posted by sosa
I have created a RenderItem class (couldn't think of a better name) that contains the following:

Source Code

1. LPDIRECT3DVERTEXBUFFER9 m_VertexBuffer; // VertexBuffer
2. D3DVERTEXELEMENT9 m_VertexElement; // VertexElement
3. Texture* m_Texture; // texture object
4. float m_x; // x pos
5. float m_y; // y pos
6. float m_width; // width
7. float m_height; // height
8. float m_u; // tex u pos
9. float m_v; // tex v pos

The issue is I have been about to bang my head against the desk all day on is:
I am not sure how to have each class that is Renderable populate a vector of RenderItems so that when I use D3D to create my VertexBuffer I can populate the size correctly and the offste of each textured quad.

If I'm reading this correctly, you're asking about the general methods for filling up a list of objects to be rendered that frame. Either that or you're asking about efficiently creating vertex buffers. I'll answer both, just in case.

Filling a draw list, also known as deferred rendering, is very common. Typically you have a list of objects and those objects have some kind of way to build the struct you show above. In my engine, I have a Renderable component on each object that has the ability to be drawn and a system that has a list of weak pointers to each of those components. Every game loop, I iterate through that list and figure out which ones are visible. For each visible one, I get the render data necessary to run it and add it to the scene.

The Scene object is responsible for maintaining the list of objects being drawn that scene. There's an AddObjectToScene() public function that I call which adds to that list. Since my actual renderer is on another thread, there are other steps I have to go through, but that's the jist of what I do. If you need more information about any of those steps, let me know.

As for the vertex buffer, remind me, you're doing a 2D game, right? If so, don't bother with trying to create a hyper-optimized vertex/index buffer scheme. For a 2D game, rendering geometry will never be your bottleneck. Say you have to render 1000 objects in your world. That's 2000 triangles, which isn't 1/10 of the geometry for a typical video game character. That means that rendering one Sim in The Sims is a LOT more expensive than your entire scene from a geometry perspective. The typical bottleneck for a 2D game is fill-rate. As much as possible, you want to try avoiding unnecessary objects or rendering unnecessary pixels.

Even still, I'm willing to bet that you'll actually spend most of your time waiting for the vertical sync, not calls to DrawPrimitive().

On another note, when you get completely frustrated with something whats a good way to get past it while coding?

There are a number of tricks I've used over the years. One is to talk to other developers about your problem. The other person doesn't even need to speak; I've solved very tricky problems without the other person saying even one word. Just talking helps. An old co-worker of mine worked at a studio that had a stuffed dummy on a chair in a corner of their office. The purpose of this dummy was to provide someone to talk to about tricky problems.

Another thing I do is start drawing out the parts I do know on a white board. By the time I'm done drawing the parts I know, I generally have a reasonable idea for some of the parts I didn't know. At the very least, it helps define the problem.

Try doing something else. If I'm completely stumped, I'll take the opportunity to walk across the street to get something to eat or go chat with a co-worker. Sometimes I'll go to an artsy image dump site and sketch one or two of the photos in my sketchbook. These activities break you out of your programming context and engage the other side of your brain in something creative. After 15 minutes or so, you'll be able to reset a little. Sometimes just working on another task you have to do helps. I try to have a number of different things I can work on, so I just switch gears sometimes.

Finally, taking an hour or so to play one of your favorite games can help remind you why you're even doing this in the first place. When I was crunching on The Sims Medieval, I would take a break around 7:00pm every night after dinner arrived at EA to play a round or two of Left-4-Dead 2 with my friend. That helped fuel me for the next few hours before heading home.

Frustration is big part of software engineering. All I can say is enjoy the challenge and live for that "ah-ha!" moment when you finally get it working. If it makes you feel better, we've all been through it. QA has been on my ass all week about inconsistent utility scores for the AI system. Sometimes, sims just wouldn't acknowledge certain objects when running their utility scoring function. Every time I thought I found the problem, it would come back. I checked in the (hopefully) final fix for it last night. They should be testing it tomorrow so hopefully it doesn't come back as Fix Failed again.

-Rez

Originally posted by rezination
There are a number of tricks I've used over the years. One is to talk to other developers about your problem. The other person doesn't even need to speak; I've solved very tricky problems without the other person saying even one word. Just talking helps. An old co-worker of mine worked at a studio that had a stuffed dummy on a chair in a corner of their office. The purpose of this dummy was to provide someone to talk to about tricky problems.

This is nicely described here: codinghorror.com/blog/2012/03/…duck-problem-solving.html

James