DX Vertex Cache Code

[dima]

http://www.mvps.org/directx/indexes/ - this site is very helpful, you can find vertex cache code under DX8, here is a direct link: http://www.mvps.org/directx/articles/vcache.htm

I have used this from way before, and it is the only way to optimize drawing alot of dynamic data with 3D acceleration, this is what pretty much every 2D game engine out there is missing except haaf's HGE, which has gone open source now btw. I am working on getting this into BMax officialy (by making requests on their forums).

I would also like to know why the thread asking about vertex cache before/below this one got pointed to GameDev.net and got locked. Please explain.

[ggambett]

I would also like to know why the thread asking about vertex cache before/below this one got pointed to GameDev.net and got locked. Please explain.
What part of You will probably find what you're looking for elsewhere, for example in the GameDev forums (http://www.gamedev.net (http://www.gamedev.net/)) or the multitude of tutorials you can find online. isn't self explanatory?

BTW, when a thread is locked the idea is that it should remain locked. If you disagree contact the moderators privately, but opening a thread with the same name as the one that was closed goes against the idea of moderation.

[dima]

I am not sure if 'moderation' is what is being applied to current scenario. A perfectly legitimate question in the 'Technical' forum. Why not just point everyone to google? Or at least let someone else try maybe helping.

[Savant]

If you disagree contact the moderators privately
Words mean things.

[ggambett]

From the FAQ :
1. Do not post requests for tutorials, how to use API/DirectX/OpenGL or any other package, help with your code or how to code it Besides, have you taken a look at this user's history? His few posts have been to ask how to do a vertex cache (FAQ says don't), how to make a scenegraph (FAQ says don't), how to encrypt game images (FAQ says don't), what data structure to use to represent terrain, and so on. So it's clear that a) his needs would be much better addressed at a more tech-oriented site such as GameDev (remember that IndieGamer is geared towards people whose problem isn't how to make games but how to design and market them more effectively), b) he doesn't bother to use the search or even to browse the forums (see "where do I sell my games"), c) he doesn't bother to read the FAQ.

I don't have a problem with the occasional tech question by people who contribute a lot to many other aspects of the site, but this isn't the case. Note that despite all of this all I did was pointing him to the correct place and close the thread to avoid further noise. Unfortunately you did exactly what I was trying to avoid.

[dima]

I didn't mean to be rude, but also, these type of questions can be very useful to people here who haven't even thought of searching for this. I know that many do not consider this type of stuff when making franetic games which require tons of dynamic geometry. Then after learning, things become much easier. I apologize if I violated this boards regulations.

[Aldacron]

I don't have a problem with the occasional tech question by people who contribute a lot to many other aspects of the site, but this isn't the case. Note that despite all of this all I did was pointing him to the correct place and close the thread to avoid further noise. Unfortunately you did exactly what I was trying to avoid.

Then, realistically, what is the meaning of the word 'technical' in this particular forum's title? It's an unfortunate thing, but my experience is that the vast majority of users on any forum do not read the FAQ - especially 'noobs' who need to the most. Even when giving them prominent notices in bold letters. Most people do read the forum description, however. And this forum description begins:

Discuss game development and technical topics, including programming...

If I were just surfing on in, not knowing much, I'd think this is the perfect forum to ask how to encrypt an image or how to build a scenegraph - both of which are technical, programming topics related to game development. And considering how many other items are listed in the description, it seems this forum is for a broad category of topics.

Maybe that FAQ line you quoted should be moved from the FAQ and added to the forum description. Really, FAQs are largely useless.

[mmakrzem]

Thank you very much dima for your help. I will take a look at the links you provided.

ggambett, locking a thread and not giving me an explanation is just confusing. How was I to know that a Technical thread is not for Technical questions? I would have appreciated if you directed me to the FAQ seeing as I didn't read them.

[ggambett]

ggambett, locking a thread and not giving me an explanation is just confusing.
But I did explain :(

I would have appreciated if you directed me to the FAQ seeing as I didn't read them.
The idea of having the FAQ as a sticky thread is that you should read it before posting, it's a matter of courtesy towards the rest of the forum members (read the rules before doing something!). It's like the artist portfolio forum, where 1 or 2 threads are deleted every day because they don't fit the format specified in the FAQ. Sure, a moderator could go editing every non-compliant thread, but it's just more work for the mods, people can be lazy and write whatever they want knowing that a mod will fix it anyway. Same for threads in the wrong forum. What incentive is there for people to put a minimum of effort (reading the FAQ, thinking for 5 seconds if the forum they chose is the right one) if they can do whatever they want and have a mod fix it?

[MrGoldfish]

There's hardly anything revolutionary about a vertex cache. It's just a case of grouping together all polygons that use the same texture (or another parameter) and rendering them all at the same time. Thus taking workload off of the GPU by reducing the number of state/texture changes.

This method typically doesn't work with 2D because there is no z-buffer to sort your images. They must all be rendered in the order they come in. This makes it inherently hard to batch together render calls. There are ways of batching this data though, you just have to try and get it optimised as best you can.

[dima]

Technically, the biggest benefits from batching is not just the reduced texture/state changes, but the amount of Draw calls. Each call to DrawPrimitive stalls the bus until it is recieved on the other end. Then new data can be sent. This in itself is a huge bottleneck, thus batching dynamic geometry or using static buffers is implemented, to reduce the number of Draw calls to the hardware. The more data you send with each call, the better you are utilizing your bandwidth. Sending single quads to the graphics cards one by one, even if they are using same textures/blend modes, will result in hitting this bottleneck. So batching geometry is very essential to maximizing throughput. This of course goes hand in hand with organising everything by texture/state. Also, about the z-buffer, with 3D APIs you have full access to it, even for 2D games, so there is no need to actually sort your quads/tris, just let the z-buffer take care of that. In any case, batching geometry is the only way to maximize dynamic data throughput, without it you cannot have thousands of moving things at FULL framerates. (like particles)