Sorry your browser is not supported!

Hi all,

recently I've been working on making a HUD for my game. One of the HUD's elements is a minimap, which I create using the following process:

- At the start of the game, I create a bitmap (1) that holds the whole map
- Every move, a portion of the bitmap is grabbed, using 'GET IMAGE'
- This image is textured on the plane that is displayed in the main bitmap (0)

I've got my code working, but I'm noticing two things:

1. Every time I grab a new portion of the minimap, I need to delete the previous image I used to texture the plane. If I don't do this, the new texture gets distorted a bit. This is a bit inefficient. Is there a simple way to just overwrite the previous texture data the plane holds?

2. The 'GET IMAGE'-command is quite slow. Is there a fast alternative to it? I've read about making memblocks from bitmaps and then making images from these, but I can't figure out how to create a memblock from a specific portion of a bitmap, instead of the whole bitmap.

Thanks for looking at my post!

I think you're right that get image is a bit too slow for a realtime map. I think the easiest solution would be to texture a flat plane with your large map image. You can then scale up the texture so that it's effectively zoomed in to the detail you want. Then you can scroll the minimap around with the scroll texture command. This would also allow you to zoom in and out easily by just scaling the texture again.

this is what I use and it is fast

update_bar() can be used for anything you want the hud to do

@Fallout: thank you for this suggestion. I think it is a very interesting and efficient approach and will certainly experiment with it! However, I eventually hope to make my map dynamic, by adding a radar and LOS-functionality. Am I mistaken in the assumption that your suggested method is more suited to a static minimap?

@Daniel: thank you for posting that code! I'll try to weave it into a test when I get home from work tonight. Just a quick question though, as I am viewing this on my phone: the function "update_bar" isn't displayed, right?

I think this is a bad design, and I want to help.

1. Don't Use 3D Objects For The Hud
3D objects can't be reliably positioned on screen. Sure it looks good on your computer, but the moment the screen resolution, field of view, or aspect ratio change, the object is in another position.
Remember you aren't the only user of your program.
Square screen's and the varieties of wide screens see these objects in different positions.
I understand you can lock objects to camera or whatever. It won't help and it's not worth it.


2. Get Image Is Too Slow
This is a great command, but it shouldn't be used in real time. It's going to kill your performance.


3. Use Sprites Instead
Specifically hide the sprites and only ever use Paste Sprite to make the sprite appear so you have complete control.

Your secret weapon is this command SET SPRITE TEXTURE COORD.
With this command you can use a large image (the whole map) and make the sprite only display a portion of it. No need for awful screen grabs.


4. Don't Update The Mini-map Every Frame.
Just think, if you update every 2 frames, you halved the workload. And so on...


Real-Time Aeriel View Minimaps
Also, if you have to absolutely make the mini-map be some sort of overhead real-time video shot of the area (which is probably a bad idea). Consider using Set Camera To Image, and make use of Camera Masks. You can then add additional sprites over the pasted camera image (like navigation indicators). With camera masks you can control how often the view is updated. Again, this much detail is probably a bad idea.

I agree with Fallout's suggestion.



Surely you could just use sprites for the dynamic parts (enemies, etc) ?

Mage is right in that the SET SPRITE TEXTURE COORD command will essentially do the same thing. I use that same command for a dynamic bitmap font. A sprite is essentially 4 vertices defining a square, and you can move the points around manually to capture any area on the image you want.

I don't agree that you can't position a 3D object on the screen correctly though. You can calculate screen width/height in world units and reposition accordingly. It's only a few more steps than positioning a 2D sprite. I think under the covers though, a sprite and a 3D plane are exactly the same thing, so there's not much difference. It's easier to use a sprite. On the flip side, I find 3D plane gives a smoother texture than a scaled/resized sprite. Probably due to mip mapping or texture filtering that isn't set for sprites.

Benjamin is right that you can just draw dynamic content over the top of the map with sprites. That'd work for both methods. Also, with both methods you could actually render a camera to an image and display it as the minimap, so the minimap could be an actual render of the world. So many possibilities!

3D object for HUD is best: you can rotate it, add a shader, etc. Position issue? Who needs absolute screen position when you can have relative screen position based on % and screen width\height!

How to make minimap? Easy as eating a cupcake.

1. Make... a memblock.
2. Go here http://forum.thegamecreators.com/?m=forum_view&t=172059&b=6
3. Paste your image, draw dots or other nice things.
4. Update HUD from memblock.

(please mods, could you tell me when my pre-mod will end?)

You can do this with my Advanced2D plugin. Simply load your map as an image, and use the clipping functionality so it only draws a rectangular part of the image. Scrolling the map is as simple as drawing the image at a different position.

Ah, so many responses! Thank you kindly all for your contributions!

@Mage: while I understand your point of view regadering 2d vs. 3d HUD's, I've got one functioning that automatically scales along with the player's resolution. I like the timer-basic update suggestion! That one will definitely help FPS-wise

@Benjamin (and Fallout & Mage's third suggestion): indeed, I plan to use sprites for the dynamic content. I've been fiddling around with the AdvancedSprites-plugin which is most excellent.

@MrHandy and Diggsey: those are both very helpfull suggestions. It looks like I'll have quite a lot of experimenting to do in the coming days. I'll let you know what works best! (My coding abilities might not do justice to the full potential of the suggested methods, but we'll see!)

Dont listen to this advice,not that its bad advice,but all you need to do is size it to you screen width and height,Not only that you can texture it then SET OBJECT TRANSPARENCY.

What I do is I dont change the screen,there is no need to if you know what you are doing.


update_bar just updates the size of the hud or the size of the object you want as your health or ammo.

Ok I see a couple people taking to the idea that you should use 3D Objects for the HUD. And zero backers for 2D which I'm pretty sure are all being silent at this point.

3D Object Pros:
You can modify U/V data instead of using Get Image.
You can rotate the 3D hud easily.
You can make the hud circular easily.
You can add shaders to the object.
Can be affected by render passes and effects.

3D Object Cons:
Different screen sizes And shapes see it in different places.
Screws up when Field Of View changes or is set at an extreme value.
Can interfere with render passes and effects.
2D overlay elements require more work to position accurately.
Can't easily add 3D overlays like map markers.
People usually can't make the map completely 3D and resort to mixing 2D and 3D.

2D Sprite Pros:
You can set Texture Co-ords instead of using Get Image.
Easy to position and scale.
You can rotate the hud easily.
Easy to accommodate different screen sizes and shapes.
Doesn't interfere with shaders and rendering.
Doesn't require building or loading a 3D object.
Not affected by camera field of view.

2D Sprite Cons:
Hard to make round.
Hard to animate.
No fancy Shader Effects.

"Don't Use 3D Objects For The Hud"





I think we can agree, given enough math you can pretty much reposition anything.

1. Consider the required work needed to make it work for all screens. This doesn't mean 3D is wrong, this is just a factor to consider.

2. Mixing 2D and 3D Elements. Any sprites overlaying the 3D plane will be difficult to position accurately and consistently. Especially If the FOV is changing due to in game effect or variations in gamers screen shapes. And heaven forbid trying to reposition or move the hud. This doesn't mean its impossible.

3. Screen Aspect Ratio and Perspective also stretch things.


Doing this well with 3D objects is a pain. I would only recommend doing it if its completely necessary.


Also I get the impression that some people aren't looking at this from the perspective of how things are going to look on more than one computer. A couple people mentioned how easy it was to correct the objects position based on some sort screen orientation (and no one mentioned that the 3D object also scales and deforms too) but it would be interesting to see how this is done.

Nothing is impossible here, but I just can't justify the workload needed to accommodate all the potential problems if this was to be used in an actual real game. The benefits are nice (shaders). No doubt it's been done and done well, in addition to badly.

Picture of Boats Docked - Ultra Wide Field of View


This is a bit extreme but imagine what would happen. A 2D mini-map would not be affected by this. A 3D or a 3D+2D minimap would be ruined.

@Mage


Different screen sizes And shapes see it in different places.
--- RELATIVE POSITIONS FTW! relative to screen!
Screws up when Field Of View changes or is set at an extreme value.
--- You can make a simple shader to set vertices position within screenspace. Or just internally using vertex lock but that's not cool. Also in post below dude said about set object fov()
Can interfere with render passes and effects.
--- Lie. Hide object.
2D overlay elements require more work to position accurately.
--- Why do you want to combine 2D hud and 3D hud? Pointless.
Can't easily add 3D overlays like map markers.
--- Lie. Paint everything you need it IN MEMBLOCK. Plus shader overlay effects.
People usually can't make the map completely 3D and resort to mixing 2D and 3D.
--- Talkin'bout yourself?
2D Sprite Pros:
You can set Texture Co-ords instead of using Get Image.
--- Memblock
Easy to position and scale.
--- Scale is distorted and ugly.
You can rotate the hud easily.
--- Rotation is distorted and ugly.
Easy to accommodate different screen sizes and shapes.
--- Lie. You must stretch your hud if 5:4 changes to 16:9
Doesn't interfere with shaders and rendering.
--- So what? 3d hud too!
Doesn't require building or loading a 3D object.
--- "make object plain" is too compicated :/
Not affected by camera field of view.
--- But affected with stretching and rotating ugly artifacts.



I'll say this: rotating and scaling artifacts are ugly as piece of monkey cheese.


That is impossible - DBP camera can't do more than 180.

edit: making my answers a lil bit clearer

Not to be pedantic, but those cons for 3D seems easy to overcome to me ...

Different screen sizes And shapes see it in different places.

If you want to position a minimap on the right and keep it the same size for all resolutions, for a sprite you need to scale the sprite to take into account the screen resolution and then offset it to the left of the screen width(). With a 3D object, it won't need to be resized, and you just offset it from the right in the same way (screen x with (if using lock to screen).

Screws up when Field Of View changes or is set at an extreme value.

Set object fov() will overcome that.

Can interfere with render passes and effects.

Not sure how?

2D overlay elements require more work to position accurately.

Yes, but very marginal. Object screen x/y commands give you the screen coord of your objects, then you just postion proportionally. However, it'd probably be best to use planes for objects though, and then you'd use the object coords.

Can't easily add 3D overlays like map markers.

Just another 3D plane positioned proportionally. You still have to use computed values if you're dealing with dynamically positioned/resized sprites based on an unknown screen resolution.

People usually can't make the map completely 3D and resort to mixing 2D and 3D.

Those people need to learn how easy it is then!

I often use 2D sprites for the HUD etc. The main reason for this is if I have a HUD element that won't easily conform to the power of 2 dimension required for textures, I don't want it to be stretched. Otherwise, 3D all the way for me.

I learnt something today.

TheComet

Me too! That was so simple, so I didn't noticed...

Man this sucks... and Mr. Handy what was that...


Well you guys make some interesting points and I can certainly see value in using a 3D HUD.

A few points:

1. 3D, I'm not saying never do it. I'm saying you should probably do it in 2D.

2. Program Complexity. I tried to give the guy an easier solution. Saying things like well just rewrite the shader, or it's not much more work, aren't exactly helpful. I made a conscious attempt to try to avoid that kind of advice.

3. Something being possible is not the same as it being efficient or easy or quick.

4. I'm just trying to give good advice that promotes success and not failure.


Damn, ok some rebuttals:



I agree. My thought on this is that with 2D you can choose to ignore scaling. You can let the player scale the hud as a setting, some games do this. I don't like this solution however, and I think your concern is warranted. I view this problem as being at least better to deal with than 3D Hud FOV/Perspective/Aspect Ratio scaling/positioning which I perceive as harder to deal with (but not impossible). Using "world units" is more difficult and annoying then merely using pixels.




I was not aware of this command. The example code in the help docs doesn't run since it cant find it's media. I get the impression that it will negate FOV skewing, which would be nice. Thanks for sharing that.



This is a blessing and a curse. For example if you are using an HDR shader, the HUD can end up being visible to the shader when it lights and blurs stuff. Or some other full screen effect. This isn't the only example, and sometimes this can be good. It can be problematic but it's not an impossible situation. You might find you need to hide the hud between render passes. If the odd chance the shader needed to be rewritten do this then it's not a realistic option for most people although technically possible. Adding another pass to draw the Hud can have negative a performance impact. Just some of the stuff i was worried about.




I wrote my comment thinking exactly this. My thought is that reliably dealing with a FOV that is actively expanding/contracting (effect like gradual zooming of a sniper scope) with any random screen aspect ratio, would make it messy to deal with. Again not impossible, just a total pain in the butt. Your comment above seems to improve this some.



I agree. Honestly I believe I was over simplifying things here. When you paste a map onto the screen its simple math to find the center and add whatever offset X/Y you need to paste a marker. If it's all rotated then it'll be a pain. But with 3D you have all that plus you need to figure out a separate X and Y scale for the offset of the marker from the center (or whatever) of the map plane. It's great you can find the center of a 3D plane on screen, if something needs to be placed on the edge, how do you find the X/Y of the edge? It's certainly possible, just more work, but I'm considering overall difficulty and complexity here. That's the priority I gave my advice above.



I'm just thinking about difficulty here. I'm trying to help in a way that will make things easier. Yes people do (right or wrong) mix 2D and 3D elements. I think I go a bit far with my statement saying people usually do this, but its also not good to dismiss this in a completely unhelpful way. Adding 2D Text is much easier than texturing it on a plane, especially if's dynamic.


Exactly, just felt it was the more difficult option.



This is an interesting idea, but unrealistic for many people due to difficulty. set object fov() seems very helpful however.



Why are you calling me a liar? This is true. You can't use Hide Object where a single SYNC is being used and only some cameras need it hidden. You possibly could, ignoring issue of difficulty, rewrite said shader to accommodate this. But even without cherry picking a scenario, the statement is in fact true. It's not meant to be an impossible problem. And I think you aren't being very polite to someone who is just trying to lend a hand. I'd like an apology please.


Perhaps you need to add some text that isn't pre-arranged, like a players name, or a message. Sure there's a way to get that onto a textured plane, but it's a pain in the butt compared to simply using text commands.



You have called me a liar again. Why are you dumping on people trying to help? Memblocks/Shaders are an interesting idea, but using a Memblock isn't generally regarded as easy and it's slow. Shader overlay effects require knowledge of using shaders at best and ability to write shaders at worst. I'm considering difficulty and not just possibility, with the advice I was giving. I was thinking like Fallout was above about using relative co-ords to position planes. Although shader effects could probably look nice.




Are you trying to insult me? Why?



Slow.



Valid points. Depending on what you are doing the effects of these may not be acceptable. That's okay.




This is the third time you called me a liar. You don't need to stretch the hud if you properly match the Aspect Ratio to the Resolution. You might scale the hud uniformly to prevent it from being too big or small depending on resolution.




You have to take extra steps to handle the 3D hud. It's not an impossible situation. You could cherry pick some awful situations. This is only listed as negative aspect.



My original statement stands. But you make some valid points.




Perfectly valid opinion. If bad artifacts are appearing then a 3D Hud might be the better option.




I think you missed the point of this statement with your response. The intention was to display a more extreme example of Field of View and to some extent other skewing effects I mentioned. There is no expectation that that scene could literally be rendered in DBPRO.




mrHandy your entire post comes off as being a bit condescending and insulting. I hope this was not your intention, especially since you mention becoming a Mod in one of your posts.


So I hope when you all see what I wrote here and above it's from a perspective of favoring less difficulty and less complexity. If your result looks really bad, you should chose another method.

This post started with the OP using GET IMAGE. And I was like oh use sprite texture co-ords to scroll the map. That was my original reason for saying don't go 3D. Then a couple people came and said nope no 2D. I thought ok you can scroll the map using UV Data. However I thought about the problems that would develop using either 3D or 2D or both. A big issue centers around running the program on more than one computer. It's just better to promote the easier solution, and mention any harder or fancier one. Despite the many interesting ideas and valid points, I don't see much of anyone talking about or paying attention to complexity or difficulty.

I didn't think I was talking to the shader writing crowd so to speak. I don't mean that in any derogatory way. I just prioritized the easier solution.

Using a 2D or 3D Hud isn't wrong by any means.

If putting this sort of thought into the kinds of suggestions I am giving is unwelcome then I probably shouldn't be posting here. Especially when I get a rebuttal on the exceedingly low level of mrHandy.

No i did not. I have three words in my english vocabulary: "untruth, falsehood, lie". You can choose what you like.

How could you say about fullscreen "effects and passes" without extra cameras?

So you say changing aspect in 3D game is a no-no as it will ruin your HUD? Interesting. I have 5:4 and 16:9 monitors, and I don't like black bars on 16:9.

Well, i apologize for "Talkin'bout yourself?". It was a bit harsh, yep.

P.S. But I sure do 2D HUD if there is not any animated details!

On subject:

I want to add for discussion this screenshot (see attach). How to make minimap like that? Any ideas?

Make a second city, and texture it with greys, and outlines. Camera. and plain the second city with relative positions, then transparency, and fade it. If you use 2 bit textures they are faster than 8 bit textures.

mage:


Indeed, and I have a very high opinion of your posts and the points you make! Looking at the thread, I hope this discussion won't degenerate into a 'theological' debate about which method is best: 2D or 3D. It is clear that both have their merits in certain situations. My programming-skills aren't very sophisticated yet, so I am glad with all the different solutions offered... they allow me to look at a problem from several perspectives and a chance to contemplate and learn!

That being said: I haven't been able to experiment much during the last days (I'm about to get married, and the preparations are irritatingly demanding ). I've looked at the Advanced2D plugin and hope to delve into using memblocks after getting it to work. Regarding that, I was wondering if the following theory would work correctly:

Oh, I forgot about height scale trick! Thanks.

@Zerotown
I think memblocks (and refreshing image from them) are faster than switching bitmaps. I have a map 100x100 that is much redrawing and refreshing minimap image every cycle, and it's pretty fast.

Thanks, That makes me feel a lot better. And your hud looks really good.

In that shot, it mentions that "all lines are vectors" you would need some sort of 2D Plugin, or you'd need to build the map out of polygons. Instead of square shapes we've been talking about you could use more complex shaped objects and have them be pure white or whatever. Again, instead of drawing with a texture, draw with polygons. There'd be an issue with scrolling the map, and pasting it all onto a texture scrolling 3D plane (by using a camera set to texture image) could cause the edges to blur. You might be able to get around pasting it all onto a 3D plane, by using a shader to calculate the alpha levels of each pixel of the map objects. Anything outside of a certain boundary could taper or be immediately transparent. If you did this with regular 2D Sprite Commands, it wouldn't be vector and edges could pixelate when scaled. Oh you could use the built-in draw commands with some difficulty but it would end up being super slow anyway.




lol thanks. I have high opinion of a lot of people around here. I don't think the thread will go theological. Everyone's got good reasons for their choice and there's no right or wrong answer. And then it can also depend on the scenario too.




No you're still better off either scrolling using Sprite Texture Co-ords or 3D Plane U/V Data. The reason is you don't have to recopy the image. It's something like 50,000 times faster. Its better to change 3 or 4 numbers than to keep copying tens of thousands of pixels.




Congrats. Hope you two end up happy together.

The whole point of using Advanced2D is that you don't have to copy the image.

@Zerotown
You're almost right, but you don't need to switch to another bitmap in the loop, you can just draw it straight to the screen:

preparation:
- Draw the entire map in bitmap 1
- Make an image of the map
- Delete the entire map from bitmap 1
- Switch to bitmap 0

during game execution:
- Set a clipping mode (a2SetClip)
- draw the map at specified x,y coordinates (a2DrawImage)

Wow,this turned out to be a small war on 3d objects,lol,sorry if I started a war with the code I posted.

I didn't mean to leave out Advanced2D, Advanced2D is a good idea because it's got a better capabilities. I was just responding to his use of copying bitmaps, just as you mentioned to him also.

@Mage
I think using 3D polys to build map is quite simple, but... i think that minimap with lots of markers needs a huge optimisation works, as game could run out of FPS because of draw calls. My goal is to make minimap that will work well even on netbooks. So I am in deep research now.

For that Minimap you posted I think the best option is to make the vector shapes out of polygons. The biggest question is how to make it scroll, whilst cropping the edges of the map. If you use a second camera and overlay it's view of the minimap as a textured plane in the players HUD it will hard crop the edges of the map when displayed. You can possibly use a shader to fade the edges or put a simple overlay on the second camera that fades it's edges to black and have the HUD 3D plane be ghosted.

The screenshot says it's vectored so 2D would be a cheat. 2D is easier (and not as nice) since you can simply have the map be a pasted portion of an image. You don't even need a second camera (which is a huge speed increase). For the markers, you can just X-Y paste rotated images. The FOV indicators would probably overhang the map, making implementing them difficult. The 3D method would simply camera crop them automatically. I would probably cheap out and hide them when they overhang, rather then use the same camera trick mentioned with the 3D camera (for performance). Obvious issues would be depending on how things were handled with different resolutions, there could be pixelation particularly if the minimap is made low-resolution and scaled up. Some games ignore resolution scaling, and just worry about positioning. You might be able to get away with this, and avoid pixelation entirely. I don't think draw calls would be an issue at all, like humorously non-existant, unless you attempted some sort of 2D vector method with a plugin, instead of 2D sprites.

Making the Map 3D and drawing it directly to the screen without the use of a second camera is probably a bad idea. Cropping the map to a specific screen area would be fairly difficult, unless some sort of customized shader was used. It would allow you to avoid taking the big FPS hit that a second camera would create.

-imho

I think I should go for second camera as lesser evil.