FreeGameDev

I’m trying to fix MiniMap angle.

I managed to do the code that rotate the MiniMap but I can’t get the rotation of the camera.

I tried using getCameraViewTarget(), getActiveCameraNode()->getOrientation().getPitch().valueRadians() (in CameraManager) to get the angle but I’m getting something going from 0.5 to 2.5 instead of from 0 to 2π (or -π to π, whatever). Plus it’s not evolving correctly, it’s increasing and then decreasing.

Any idea how I could get this information?

Hi McMic,

getActiveCameraNode()->getOrientation().getPitch().valueRadians() gives you the tilting, not the roll value.

getActiveCameraNode()->getOrientation().getRoll().valueRadians() is what you're looking for.

Hope it will help you.

Best regards,

Thanks!

For some reason I add to remove π/2 from the value to get something working.

It works now, but it’s a bit trembling, maybe it can be fixed with some tweaking (I tried using trunc instead of round it seemed worse).

Please find the patch here: (Could this forum allow uploading of .patch files?) http://mcmic.haxx.es/0001-Fixes-MiniMap ... mera.patch

Hi

The patch looks good!

Unfortunately, to prevent any tremor while moving or rotating, one need to draw on a smaller texture and let OpenGL magnify it when drawing it, for instance, to get some, even basic, anti-aliasing effect.

Mind if I push that patc as is for now?

Sure, push it, it’s way better than previous state.

But indeed, rotating a rendered texture seems like a good idea. But than means rendering more than what we intend to show to be sure we get the whole square area we want after rotation. This is a bit complicated so it’ll have to wait.

At least we can use the minimap. Is click on MiniMap implemented? If so, my patch might have break it, I did not check that.

Hi,

Sure, push it, it’s way better than previous state.

I've read Paul's ok to merge back, so I'll do it asap.

But indeed, rotating a rendered texture seems like a good idea. But than means rendering more than what we intend to show to be sure we get the whole square area we want after rotation. This is a bit complicated so it’ll have to wait.

Maybe, yes. Note that we currently put pixel squares on a buffer copied on a texture. It's just that as for now, the texture is rendered 1:1 on screen.

By playing with mGrainSize and the texture rendering size, we might achieve something decent enough. May I add this to the TODO-list?

At least we can use the minimap. Is click on MiniMap implemented? If so, my patch might have break it, I did not check that.

Yes, it is implemented, but it seemed broken to me (I mean before your patch). I guess this will have to be added to the TODO-list as well?

Regards,

Sorry to say that , but try just riding away wtih camera from the center.
There you can see how much mini-map click drives away from expected behavior .
EDIT : What is more my click&go implementation afair was proper.

Are you sure? I can swear the minimap click was broken already before McMic's patch.

With this patch player colors are used for claimed tiles: http://mcmic.haxx.es/0001-Uses-players- ... imap.patch

This one fixes the click on minimap behaviour.

http://mcmic.haxx.es/0002-Fixes-click-on-minimap.patch

Small but nice fixes

Cool work, MCMic.

Just beware of one thing. Declaring the variables first and then using them is c-ish. It doesn't mean it's bad, but only it's not necessary anymore on c++11, and was abandoned practice because it usually led to unused variables mistakes and such when the code later evolves. Only my two cents though, I've tested the patches and I did pushed them as is.

Thanks for fixing the minimap!!

At first I was declaring them at use but it triggered a compilation error because of the switch.
See http://stackoverflow.com/questions/9239 ... -statement

So it seems it can be avoided using curly brackets.

Indeed.