Scroller in 3D

Taking multiplications out of the inner loop really made the difference. Now I have mode7 like transformations working at 30 fps in the 110x88x16 color mode :slight_smile:

11 Likes

@jonne, can we give @hanski another wizard badge for this?

3 Likes

Badge?

Don’t you think something more like tattooing his name on my forehead would be appropriate already at this point ?!? :wink:

… I’ll have to think of something for @Hanski and the other resident Einstein.

4 Likes

This looks really impressive!

1 Like

Sounds like a decent first person horror game :slight_smile:

3 Likes

:slight_smile: Einstein, not Frankenstein!

2 Likes

Defining FIXMATH_NO_ROUNDING improved performance from 30 to over 40 fps :slight_smile: I did not notice any visual glitches which was very suprising! I will keep it now like this and see if it causes visual problems at some point…

2 Likes

@Hanski how do you include FixMath in your project?

#include "fixmath.h" //??
#include "fix16.h" //??
#include "FixMath.h" //??

It should just be #include <fixmath.h>.
But given that it’s in POKITTO_LIBS there might be something else you have to do to have it included,
like adding it to the library search path.

I included fix16.h, but then had to comment out including fixmath.hpp in that file. Have to figure out is there a better way. You also have to add the FixMath folder to your search path.

Thanks @Pharap and @Hanski
The search path is what I was missing… “Project Build Options” --> “Search Directory”

P.S.
Maybe dumb question, but is it Q16.16 right? Does it overload common operations + - / * ? I seems to remember it was not allowed? But I get no error from first test.

I think operations are overloaded in .hpp. I use explicite fix16_mul()-calls.

They are. I hadn’t spotted them before.
Perhaps because I was looking for free functions and not member functions.


@HomineLudens, some things to be aware of:

By implementing the operators as member functions instead of free functions, it means that this is valid:

Fix16 a = 5.0;
Fix16 b = a * 0.5;
```
But this is not:
````cpp
Fix16 a = 5.0;
// Error:
Fix16 b = 0.5 * a;
```
(See [this SO question](https://stackoverflow.com/questions/4622330/operator-overloading-member-function-vs-non-member-function) for more info.)

And `fix16.hpp` is going to generate a huge number of warnings (at least 70) because of the unnecessary `const`s on the return values.

(Also having `sin`, `cost` etc as member functions instead of free functions is a very weird choice.)
1 Like

Thanks for the tips, I was facing strange problems using overloaded “/” operator.
It’s seems like the division from 2 fix16 return a float.

having:

fix16_t speedX;

2 options:

speedX=fix16_div(speedX,fix16_from_float(1.2));
or
speedX=fix16_from_float(speedX/fix16_from_float(1.2));

That is really strange. The first option should work, but is much faster if converted to multiplication. Also you could store the result of fix16_from_float() to a const variable, so it is not evaluated every time.

I move to div for debugging purpose. Moving back to multiplication.
Same for storing variable. I’m still tuning some gameplay but thanks for point it out.

1 Like

It’s highly likely that what’s happening is that the returned result is in fact a Fix16 but it’s being implicitly converted to float because of the conversion operators:

C++11 acknowledged and rectified this issue by adding the explict keyword that disables implicit conversions but allows conversions in an explicit context (i.e. via static_cast).


If you post the exact expression that’s causing the issue I could have a look at it to see if I can think of why it would be trying to implicitly convert to float.

I expect you’re trying to do something like:

Fix16 a = 5.0;
auto b = a / 2.0;

In which case, rather than calling a.operator/(2.0), it will call static_cast<double>(a) / 2.0.

The solution would be:

Fix16 a = 5.0;
auto b = a / Fix16(2.0);

(This issue is precisely why I made the conversion operators explicit in my FixedPoints library.)

If you have access to C++11 there are some other solutions that don’t require modifying the library, so let me know if you’d like more information about those solutions.

3 Likes

It seems like I was using

fix16_t myVar;

instead of

Fix16 myVar;

This not combined well with operator overloading

What kind of issue did you get? Are you using Fix16 or fix16_t as type?

From what I gather @Hanski isn’t using the C++ bits at all, he’s relying entirely on the C parts: