TRUE DECIMAL-PIXEL COLLISION AND PROCESSING IN NIKRAToday I wanted to talk about the decimal-pixel engine that's just been implemented for NIKRA.
Please don't get this confused to sub-pixel movement; which involves moving in whole pixels, saving the extra, then when that adds to a whole pixel, add that too.
What this does is a little different, and breaks this trend. So let me explain this as well as I can:
When you draw sprites to a View Port, if the Port of the screen is larger than the real amount of pixels in the game, it will compensate the extra pixels. This can be seen when you're trying to scale a game to fit the screen and you get
'stretched pixels', which in my opinion SUCK. Stretched pixels tick me off a lot, possibly due to my uncontrollable perfectionism (hence me only just finishing the palette).
So with that in mind, the 'extra' resolution of pixels also allows the engine to draw sprites if their coordinates are non-integer (or decimal-coordinations).
If your View Size is small enough (NIKRA is 320 by 180 ~ 1080p/6), and your View Port is big enough (fullscreen 1080p), the you can draw your sprites at a decimal position!
THIS BREAKS THE BARRIOR OF ONLY HAVING A MAX SPEED OF 1 OR 2(but in it's TRUE form, not just saving the extra pixels and drawing them later. Everything is calculated to the quarter most pixel - it basically checks for object 0.25px near it in the most mathematically way possible)
Here's the simple 'repeat()' code I used for the collision checking:
It's pretty self-explanatory.
And to get the 'bsol' Boolean we need to calculate if there's something beneath it in a very precise way!
As follows:
TA DA!
It's hard to see this effect at a 30fps speed (only because of the gif! the game runs at 60fps), and at it's true speed, it's as smooth as butter!
Hopefully this helps some people!
Until next time,
-Seth
EDIT:
By the way, before anyone points it out, there are far more efficient ways for setting the x and y without a repeat() function. One way (which I'm not sure if it's a whole lot more efficient), is to check the whole length of the velocity speed then if there's nothing there; jump that distance. If there is, check half of the velocity speed's distance, and so on! I just don't know if that'd be worth while...?
