Sorry your browser is not supported!

In DBP there is a command (statistic(5)), the example description is "Number of DrawPrimitive Calls"

This is a significant value for managing performance, basically, any bone, mesh limb or object class as 1 DrawPrimitive, an extra camera would double, a third would treble etc. dx9 has a limit of 5k *I think* but DBP always struggled beyond 1k whether for basic plains or complex primitives, no textures, shaders or other media or code going on other than user controls. This was the case for years no matter how many newer graphics cards or CPU's I bought.

So, the big question, does AppGameKit have an equivalent command or will I have to manage this myself?

You're in luck there because AppGameKit only has one camera
Benchmarking commands
You can search for commands here as well

I don't know why these aren't in bench marking but here they are anyway
Also GetShadowPolygonsDrawn()

Thanks, sadly I have already explored those and are very useful but as best I can tell there is nothing there. I was surprised really as I had saw the managed sprite draw call command but nothing for 3d! I guess I will have to come up with a basic management system at some point, thanks anyway.

DirectX 9 is Single Threaded on a Single Core... so while CPU Performance has improved over the years., if you look at Single Core Performance; it hasn't really increased much.
You're looking at ~2x Performance over the past 12 years., while the decade before that you're looking at almost 8x Performance Increase.

Now a Draw Primitive is essentially the number of Draw Calls required to handle State Changes in a given Primitive Object., and DX9 isn't exactly efficient with this.
Generally speaking on a "Modern Processor" you should be able to handle ~1.2 Million Draw Calls / Second or 20,000 Draw Calls / Frame.

This is where newer DirectX become better., as
DirectX 9 : 20,000 Draw Calls / Frame
DirectX 10 : 9,600 Draw Calls / Frame
DirectX 11 : 6,500 Draw Calls / Frame

I won't include DirectX 12 as it actually handles them differently., as it drops State Changes that don't change; so what you instead get is an increase in Draw Calls Possible per Frame at the same Performance.
Still the above is why you end up limited to ~1,000 Draw Primitives; as this comes down to the Draw Calls per Primitive., which for DX9 is ~12-20 depending on Primitive Complexity.

OpenGL and Vulkan work a bit differently here.
See., while DirectX the Draw Calls are Command Lists generated based upon what DirectX thinks it needs... with the Khronos APIs, it's when you're DIRECTLY telling it to do it.
This actually makes it difficult to measure from the API perspective as you could be doing just a single Draw Call or making multiple state Changes that increase the number of Calls Executed... and OpenGL / Vulkan doesn't know what is and isn't.

The key difference between the two is Vulkan, like DX12 will basically do a binary check to see if a given State has changed and if it isn't., simply not do another Call Execution for that Element; the idea again being to increase the potential Draw Calls made per Frame (while the actual excuted calls remains relatively the same).

Simply rule of thumb here is make fewer changes, fewer polygons and fewer objects... better performance.
What you could do is a silent benchmark for a given system to find it's limitations., then just keep track of what's going on in-flight but keep in mind that AppGameKit Script (BASIC) has terrible performance as you increase the number of memory accesses.
I have a thread somewhere that delves into it, and Dark BASIC Professional can often go from being similar performance to 100x faster; and has much greater limitations.

The only real way around that is to switch to "Tier 2" (aka C++ w/AGK SDK).

Raven, hi,
thanks for that, I more or less follow. I am not so sure I want to learn c++ lol, that's why I'm using basic, it is just a hobby and under normal circumstances I would be working full time in a dead end labour market position! Besides I only have vsexpress2008 atm and no real internet. 500mb pcm which is used mostly for job search/email. I am on x64 and vs2008 is only the [quote=]x86 version from an iso on an OLD hdd installed way way back. I know I would need to learn the language first but I got curious and went through the whole rigmarole of the plugin guide to discover I can only produce the 32 bit dll so can't even test it...well it works if I copy/rename the 64bit dll from example folder over/stick it next to it, but its highly likely it just requires a file named windows.dll in same location(it fails without). That and doing the DBP example plugin guide is as far as my experience goes, no real internet to DL the largish install, and I am guessing it will require a lot of internet use to get answers. So Tier 2 is out the window and for as long as COVID is a problem, then so is employment which means no return to unlimited internet.
Yeah, the memblock memory access to change heights for a memblock mesh terrain along with just face normals is way slower than I expected, updating the objects mesh cost but a fraction of the time! This was done separately to ensure it was the memblock access and not the update of the objects mesh...and then I spotted the memory leak caused by deleting a static physics body! So yeah in terms of low end hardware defo keep those numbers way down. Ummm aren't those draw call limits you wrote the wrong way round??

blink0k I forgot to say - if you render same camera in same frame more than once it is the same cost in terms of polycount, therfore same as having two objects, twice the draw call

I wonder if you could use a shader to count that?

I haven't the foggiest to be perfectly honest - my shader knowledge in DBP was limited to minor alterations to code without fully understanding a lot of things even though I had DarkShader. I have the shader pack DLC for AppGameKit, so that coupled with obtaining source files from within will help immensely in speeding up my understanding(hopefully lol). At this stage I should simply maintain my own list of dc's ie basic functions like adding to/subtracting from a variable each time load, delete, show/hide as well as determining numbers of meshes/limb/bones each time. Ideally I want to keep a record of draw calls in screen/off screen as well...but the info on object in-screen is a little concerning when it details results are an estimate. there where similar issues in DBP with the results of the same command but iirc I discovered it was down to the objects bounding box wasn't rotating with the object, so I simply used a separate box object repeatedly, scaling it accordingly to cover the area of the target object and testing that instead. Wasn't a perfect solution but it worked so I will at some point test it in AGK.

Draw calls are more of a guide but I have found it very useful in DBP...there where times when knowing how many dc's helped me hunt out issues without having to strip code down to specific test beds which as anyone might expect can be costly in time.

Once again thanks for the help, awesome forum as always