In the last couple months I've been working on a project using "Fake Gravity Platformer Test with Shooting" (from here: http://atariage.com/forums/topic/179473-fake-gravity-platformer-test/) as a template.
The goal of my project is to create a Platformer with four-way gravity.
This is how the Code is supposed to work: First, it is decided which Code should be executed depending on the current gravity, then every direction of Collision is represented by a Subroutine.
Each of those Subroutines follow the same scheme: The Code tests if one pixel collides with the block and then tests for another one in the same row/column (depending on which direction and which gravity)
This is supposed to create a glichless "Hitbox" for the player character.
This sadly doesn't work for a reason unknown to me (The player can jump through walls or glitch his "head" halfway into a block supposed to be solid)
I've tried many methods to fix this issue:
Make the Player Coords normal values instead of float, hoping it would help, but it didn't
Tried different PlayerCoords-to-Block-Value conversions like division, modulo and bitwise
Change Order of Subroutines
I'm clueless and I've completely run out of ideas.
Does anyone know what the Problem could be?
I attached the current state of my project:
https://pastebin.com/NbD4Huvi
a
(P. S. Visual Batari Basic v1.0 Build 568 used to work, I don't know if anyone uses this language anymore or I'm the only one, I already posted this on the Atari 2600's Programming Forum for Newbies, but haven't recieved an answer in two weeks.)
I got a similar issue, atari has a very limited power of processing, specially using bank switching.
In my case the problem was with joystick movements that position the sprite beyond the limits of playfield blocks and batari collision function seems process with a delay =P
So I found this workaround that cancel movement considering the offset of player width and height.
Let's see the trick: