FlxG.camera.zoom problems

[Anthony Green]

Hello I'm new to Haxe/HaxeFlixel. I'm having a strange issue with FlxG.camera.zoom. I'm trying to define a range in which a user can zoom in/out. 

    private function zoomControls():Void {

        var test:Float = FlxG.camera.zoom;

        var change:Float = 0.0;

        if (FlxG.mouse.wheel > 0.0) {

            change += 0.2;

        } else if (FlxG.mouse.wheel < 0.0) {

            change -= 0.2;

        }

        if (test > 1.2 && test < 3.0) {

            FlxG.camera.zoom += change;

        } else if (test < 1.2) {

            if (change > 0.0) {

                FlxG.camera.zoom += change;

            }

        } else if (test < 3.2) {

            if (change < 0.0) {

                FlxG.camera.zoom += change;

            }

        }

        trace(test);

    }

This works fine but as far as I'm concerned shouldn't. I set the initial zoom to 2.0 and I want the range to be 1.0 - 3.0. This does exactly only if I set the zoom to something in between [1.2 , 3.0]. But when I zoom out eventually it should hit 1.2 and never go below that but it does go to 1.0, which is what I want but that shouldn't happen. Not so similarly, if I get to 3.0 it doesn't go past 3.0. 

When I first set this up I was doing it slightly different and depending on the platform, Flash, I would get some weird floats that weren't exact. So I set the numbers to more exact values but that doesn't seem to matter as far as Flash is concerned which will still come up with not exact floating points sometimes. I can't tell on the other platforms because no matter how I print it, trace/cpp.Lib, it is printing the right value but will evaluate to false if I print it as a bool vs the value that it's saying it is. 

This was tested on 64 bit Ubuntu/Windows/OSX/Flash. I'm using Haxe 3.1.0-rc.4 and HaxeFlixel 3.2.2. Even if I set a return before the test if statements, and before that just adjust the zoom based off of change, it doesn't work. I've been testing this for about 2 hours which is way more time than I think I should be spending on something as trivial as this so I decided to post here.

Anyway, what exactly is going on behind the scenes here that are making these statements act strangely? I'm almost positive it has to do with the way floating points work but how can I get the behavior I expect? 

[Andrei Regiani]

I'm not sure what's wrong, but I re-wrote the logic in a different way, tell me if it works for you: (worked fine here)

private function zoomControls():Void

{

// Config

var zoomMax = 3.0;

var zoomMin = 1.0;

var change = 0.2;

// Zoom In

if (FlxG.mouse.wheel > 0.0 && FlxG.camera.zoom < zoomMax)

{

FlxG.camera.zoom += change;

}

// Zoom Out

else if (FlxG.mouse.wheel < 0.0 && FlxG.camera.zoom > zoomMin)

{

FlxG.camera.zoom -= change;

}

}

[Andrei Regiani]

Two things:

* Be sure to use AA:

FlxG.camera.antialiasing = true;

* With your current zoom settings (max: 3.0, min: 1.0), when you zoom in you loose image quality, to instead you could use zoomMax to 1.0 and zoomMin to -2.0 (and default = -1.0). To maintain the same image propositions, you'd just need to re-export assets bigger.

[Anthony Green]

Hey sweet. I typed up a long response thanking you, etc, etc but it got deleted. 

Also, something is wrong with floating points. I posted a screenshot showing the problem I'm experiencing but as I said someone here deleted it. I'm using 64 bit Windows/OSX/Ubuntu and Flash in Chrome on Windows/OSX. Why are my floating point values incorrect. In Flash when they get sent to trace they get printed out as 3.0000000000001 and 1.000000000001 or something similar, on OSX/Windows/Ubuntu they get rounded to the nearest value on standard out and in trace but during the comparison they're the values stated previous. 

Am I the only one have issues with floating point values? 

[Gama11]

Hey, I have no idea why your post got deleted, sorry about that. Google groups is a bit weird when it comes to spam detection.. Also, I can't seem to find a way to recover the post. :/

I'm seeing those floating point issues too. You could try Math.fround() to try and "correct" that. Is this actually causing a problem for you though?

[Anthony Green]

Yes and no. I'm still getting accustomed to the engine but as Andrei pointed out the logic is very simple but I ended up spending a lot of time rewriting and debugging to find out that it had nothing to do with that. At one point in the update loop I was just doing FlxG.camera.zoom = 1.0 if (FlxG.camera.zoom == 1.0) and it would always evaluate to false. I'm not doing scientific computing here but I expect floats to be a little more precise. 

Since I'm new I don't even know where to look for this kind of bug since I'm not entirely sure how this all comes together. Is it OpenFL or HaxeFlixel or is it somewhere else? 

[Anthony Green]

So, I guess I've been lucky or something because I've never run into this when coding in C++/ObjC. I just spent the last several hours reading about floating point representation and doing experiments using doubles in C++ which is what these Float values are being converted to, at least that's what it looks like the C++ code isn't the most friendly thing to read, and I'm running into the exact same thing! It's always nice to learn something new. 

Now, I guess a different question, I'll look it up myself but if someone happens to see this and knows the answer, is there a way to set the precision on floating point values from within Haxe? 

Sorry for the confusion about all this. I've only been coding for a couple years.