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
Badge?
Donât you think something more like tattooing his name on my forehead would be appropriate already at this point ?!?
⌠Iâll have to think of something for @Hanski and the other resident Einstein.
This looks really impressive!
Sounds like a decent first person horror game
Einstein, not Frankenstein!
Defining FIXMATH_NO_ROUNDING improved performance from 30 to over 40 fps 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âŚ
@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.)
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.
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.
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: