Sorry your browser is not supported!

I've just added a minimap to my 3D game, but I am using 2D drawing primitive each cycle to place the map over the top of the 3D scene.

This is killing performance as I need to draw this every cycle even if the minimap is static.

Is there a better way? I've noticed people talk about using a sprite for this by changing the sprite priority order, but I can't see how to create a 'blank' sprite to draw on, and can't see how you would change the contents of the sprite.

Any advice would be appreciated.

I remember once making a 3d space game, my whole 3d space field was I think 10000 wide by 10000 high. On the top left of the screen I had a sprite that that was 100 x 100 and that was the background for my minimap. Then I would paste little sprite dots on top of it that would represent the 3d ships in my 10000 x 10000 3d world. I did this by deviding their position by 100. It worked great, but I dont know if it will help you...it might give some direction. I think it went something like this:


so in my game loop I would put e.g. runmap(12) - this would make sprite 12 represent object 12 on a minimap using image number 7. I never developed this to be more better with the ID finding. But im sure you get the idea

the int(dbObjectPositionX(obj)+0.5)/100; converts the 3d float value to a 2d int value and then I devide it by 100 to make it corrispond with my 100 x 100 minimap block. you could change this suit your 3d world/2d minimap ratio.

it worked for what I was doing.

Thanks for the suggestion RancidRat. I will try adding lots of little sprites to see if this is any faster.

Hey RancidRat - I added the SPRITE logic for all the elements of the MINIMAP and its working great - with no apparent hit on CPU.

I even used the dbSetSpriteAlpha to fade the map 50% and it looks 100% better than it did when it was being drawn solid with the 2D primitives.

Great to hear it is working DGDK works really fast with sprites.

Also... you could experiment with a small memblock (image format)

DWORD 0 = Width Offset 0 - Width of radar image
DWORD 1 = Height Offset 4 - Height of rardar image
DWORD 2 = Depth Offset 8 - Depth usually value of 32(bits)
... Array of DWORDS - (stack of DWORDS for each ROW # of columns wide)

Then you literally set the RGBA directly into there "pixel location" and make image from memblock.

This does all your drawing in a memblock - with only the one heavy call - it might be faster then drawing dots as well.

Sprite solution sounds decent also.

--Jason

Thanks for the tip on memblock Jason - I might give that a try. The sprite solution is quite fast though, but it won't hurt to see if I can squeeze a little more performance out of this.

A copy of the demo with the sprite radar is here:
http://www.craftylogic.com/upload/Downloads/DroneHunterRelase2.zip

If anyone has the time, I wouldn't mind some feedback on the FPS you all get and approx. CPU utilisation from the program.

Instructions:

<Arrows> Move
<CONTROL><Arrows> Steer drone
<ALT><Arrows> Rotate 'DroneCam'
<SPACE> Launch/Explode Drone
<F1> Regenerate level / respawn Enemy

Thanks!

That's pretty cool. 60 FPS. I deleted it, though, and realized I didn't look at the CPU usage. Probably not much at all, though.

60 FPS, with only 5% of one of my CPUs. Since this is a 1.6 GHz dual core, that's only 5% utilization of an 800 MHz CPU. Very efficient code!

Either that, or Intel really knows what they're doing.

Thanks for the feedback everyone.

I have 3 computers to test on here, but they are all P4-3Ghz or higher, so it's hard to know how well I'm going with performance.

I get a consistent 60 FPS on all 3 of my computers - but here is the CPU utilisation for each of them:

Machine 1 - Desktop-P4-3Ghz-1Gb / ATI-X300-128Mb = 0-3% CPU usage
Machine 2 - Desktop-P4-3Ghz-1Gb / Intel integrated graphics-128Mb(shared) = 10-25% CPU usage
Machine 3 - Laptop-Core2Duo-3Ghz-2Gb / ATI-Mobility-X1600-512Mb = 0-2%

One thing I did notice is that the machine 2 (integrated graphics) dropped to 20 FPS when the textures were 512x512. Dropping them down to 128x128 put the FPS back to 60.

I am just starting out at games programming, but already I've seen that keeping performance under control is a big part of things.

I wonder if there is a rule that games developers use for polygon counts and texture memory utilisation. At least now I know why so many games (99% of them) allow you to pick the texture detail level, lighting effects, particle effects etc.

Pheonix73 - You're learning important things. Hard rule of thumb for poly and Textures? I don't have one. Developing on a "slower" PC is a good thing for writing tighter code in general - and you're right about optimizations like textures and poly having dramatic impact.

Basically - Once your gfx data in the video card exceeds the video cards RAM - problems with speed and sometimes display (appearance) result.

This gets deep bro - (and using DarkGDK its kinda far removed but read this anyway) and depends how the "gfx system" that your using ties into the video hardware - for example - direct x has three main modes for "individual" gfx things (mesh and textures) One in VRAM period (fastest) - One In a system area that happens to have az "fast wired connection to the vram) (Slow) and a special mode where dx keeps it in regular system ram - and tries to manage it for you (slowest).

In short - when the VRAM is full - direct stuff - well - no wiggle room - the other 2 methods - basically try to swap out "unused ram" and swap in the stuff its trying to render - and the lest "room" in the vram to allow this sort of "smart management" during a render - the SLOWER it gets.

To Summerize - those setting you mention - and why they are in games - is simply that - fill the VRAM - SLOW game - overburden the GPU with to many shaders and special effects - Slower Game - Giving users options? Allows them to find their own sweet spot.

One Could Calculate their gfx and textures and stuff and see if the vram is getting stuffed - but sometimes this is just to much work - and its easier to make a reasonabley light weight "gfx" base - (lower poly models - no effects - then the user can "turn up" like we were just discussing to get them that balance.

Ok - NEw TOPIC! GFX card work - from another point of view.

Objects in GDK that are not on screen - are still "rendered" even though you don't see them. This is a dumbed down explanation of what's going on - but if an object isn't on the screen - then if you can "Exclude" that object - then you eliminate some work for the video card during the render (dbSetObjectExcludeOn(ID) is more performance advantageous the simply dbObjectHide or whatever. Note - exclude doesn't work on instanced objects ... and if you exclude the "main" objects other instances are based on - they disaappear also!)

So - how do you know if an object is on the "screen"? How about dbObjectInScreen()??? Nope - that work VERY lame! Very flawed - don't waste your time. What you need is something called frustrum culling - this is where you basically get the "coords" of the view area - and test objects if they are in it - and if they are not - exclude em - if they are - un-exclude them, and your frame rates increase!

Caveat - if you are trying to check 500+ objects in the frustrum code - then the work involved testing the frustrum "in or out" thing - well - you lose the gfx speed gain in cpu processing time! So - there are various "means" to try and deal with this - and you should do some searching on things like: Frustrum culling, occlusion culling (can't be done correctly in DarkGDK), backface culling (not exactly related but youshould know if you don't already ...what it is..)

Lost in thought ported some DBPro code from a OpenGL app for frustrum culling - and it even works on "limbed" objects (static ones that don't move around - like buildings made of various "chunks" or limbs for example...)

I ported this to GDK - and I have code for this sort of thing in this lib: http://code.google.com/p/darkgdkoop/

good luck man! You're learning and doing the right kind of testing and benchmarking etc - performance stuff - all important things to consider before you spend monthes getting the game right then it crawls and your like ...WHAAA????

Keep up the good work!
--Jason

Thanks for the advice and encouragement Jason.

I've been programming since I was very young (Commodore 64 etc ), and do it every day for a living, but know relatively little about 3D games programming.

Every time I read one of your posts I realise how much I have to learn! As the saying goes - you don't know what you don't know. You are helping me to find out what I don't know which is very useful indeed.

Strangely I only started programming all those years back so that I could write computer games - isn't it funny how we get side-tracked in life?

For all the lines of code I've written professionally, the last thing I programmed that resembled a game was a little RPG thing on my lowly 80286 back in 1989 when I was in school! 20 years is a long time between drinks but I hope that I can finally get back on track.

I must say that DarkGDK is making this task very easy for me. It has lots of simple commands to help ease me into the whole 3D thing without too much scary maths or tedious setup so I can see results quickly. It's also got a great, lively community.

I also particularly like the option of jumping into DirectX calls directly or straight into C++ libraries if something isn't in the GDK.

I am surprised at just how easily I was able to knock up the DroneHunter game. It looks a lot better than I thought it would for my first 3D game.

You're welcome - funny you and I are more alike than I would have thought - I started very as well - wrote games as a kid - 2d - dabbled with a 3d engine once when I was 20 or so - but professionally coding since 20 on - and only dabbled a bit with TGC DBPro maybe in 2004? Then again last year I think... So - its been a crash course The amount one needs to make a game isn't that bad - but the curious - like yourself - are bound to run into more and more stuff "they should know" ... sometimes its quite daunting... sometimes I have to walk away from it - because there is SO MUCH to do to make higher end - or even "really decent" games - that it can be mind blowing.

I'm glad I was able to steer you a bit toward the don't knows - and I'm sure you'll do just fine!

So - Drone Hunter? Where can I check it out? (Can I check it out?) LOL

--Jason

the link to the game is in one of my posts above. If you are interested i can email you the source.

So it is - I checked it out - Sweet! Off to a great START! As in Nice!

@Phoenix73 - Nice what you have made. I have 60 FPS. Just one adjustment for the minimap. Move offset of the "player" to the middle and not the nose.

I like what you have made (the camera) with the "missile"

Thanks for your input Neils. I will adjust the offset of the map pointers. Currently i am using the top left of the sprite where i should be using the centre to position it properly. Is this what you are refering to when you say 'nose' ?

You should use the center of the object. I think the "nose" is in the top left corner. So you need to move it more to right bottom corner