Four-way Gravitational Engine Issues (Atari 2600)












1














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.)










share|improve this question




















  • 2




    Posting a link to your whole project is generally frowned upon. If you need debugging help, post the relevant code in the question. If it is too big, narrow it down. If you can't narrow it down, the question might not be suitable for this site. Also try Retrocomputing.
    – fuz
    Nov 22 at 18:56
















1














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.)










share|improve this question




















  • 2




    Posting a link to your whole project is generally frowned upon. If you need debugging help, post the relevant code in the question. If it is too big, narrow it down. If you can't narrow it down, the question might not be suitable for this site. Also try Retrocomputing.
    – fuz
    Nov 22 at 18:56














1












1








1







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.)










share|improve this question















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.)







assembly 6502






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Nov 22 at 20:19









Dean coakley

6691319




6691319










asked Nov 22 at 18:23









Angel Sachse

112




112








  • 2




    Posting a link to your whole project is generally frowned upon. If you need debugging help, post the relevant code in the question. If it is too big, narrow it down. If you can't narrow it down, the question might not be suitable for this site. Also try Retrocomputing.
    – fuz
    Nov 22 at 18:56














  • 2




    Posting a link to your whole project is generally frowned upon. If you need debugging help, post the relevant code in the question. If it is too big, narrow it down. If you can't narrow it down, the question might not be suitable for this site. Also try Retrocomputing.
    – fuz
    Nov 22 at 18:56








2




2




Posting a link to your whole project is generally frowned upon. If you need debugging help, post the relevant code in the question. If it is too big, narrow it down. If you can't narrow it down, the question might not be suitable for this site. Also try Retrocomputing.
– fuz
Nov 22 at 18:56




Posting a link to your whole project is generally frowned upon. If you need debugging help, post the relevant code in the question. If it is too big, narrow it down. If you can't narrow it down, the question might not be suitable for this site. Also try Retrocomputing.
– fuz
Nov 22 at 18:56

















active

oldest

votes











Your Answer






StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");

StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});

function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});


}
});














draft saved

draft discarded


















StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53436422%2ffour-way-gravitational-engine-issues-atari-2600%23new-answer', 'question_page');
}
);

Post as a guest















Required, but never shown






























active

oldest

votes













active

oldest

votes









active

oldest

votes






active

oldest

votes
















draft saved

draft discarded




















































Thanks for contributing an answer to Stack Overflow!


  • Please be sure to answer the question. Provide details and share your research!

But avoid



  • Asking for help, clarification, or responding to other answers.

  • Making statements based on opinion; back them up with references or personal experience.


To learn more, see our tips on writing great answers.





Some of your past answers have not been well-received, and you're in danger of being blocked from answering.


Please pay close attention to the following guidance:


  • Please be sure to answer the question. Provide details and share your research!

But avoid



  • Asking for help, clarification, or responding to other answers.

  • Making statements based on opinion; back them up with references or personal experience.


To learn more, see our tips on writing great answers.




draft saved


draft discarded














StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53436422%2ffour-way-gravitational-engine-issues-atari-2600%23new-answer', 'question_page');
}
);

Post as a guest















Required, but never shown





















































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown

































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown







Popular posts from this blog

Berounka

Sphinx de Gizeh

Different font size/position of beamer's navigation symbols template's content depending on regular/plain...