Skip navigation
Welcome, Guest! Please Login or Join

Loading...

Ask all programming questions here!

Sep 14 at 10:18:29 PM
brilliancenp (0)
avatar
(Nick Pruitt) < Tourian Tourist >
Posts: 24 - Joined: 08/15/2017
Kansas
Profile
Thanks for the opinions guys. For my learning I went with gravity but that may change. I have my character doing what I want for now. The next thing I want to learn is character interaction with obstacles. In my demo I am using to learn the type is a platformer but I guess it doesn't really matter. I am trying to learn how to make the player land on platforms and be impeded by obstacles. Im going to start with random platforms that the character can jump to. My first thought is that we put some sprites on the screen to create the platforms. Now when this is finished how do I check to see if the player is standing on them? I mean my first thought would be when the player is moving down, to chek to see if the players Y value is greater than or equal to the 'platforms'. I currently do this in my demo but the y value is uniform forming an invisible floor that the player could move along while I tested everything else. With many sprites at different heights it seems like that would be a lot of tests each frame. Is there an easier way? Like a general sprite collision routine and then figure out what it is interacting with (enemy, wall, floor etc.)

Sep 15 at 8:13:47 AM
SoleGooseProductions (120)
avatar
(Beau ) < Ridley Wrangler >
Posts: 2738 - Joined: 04/22/2013
Indiana
Profile
You could set up a routine to check the player sprite against every other sprite, or a certain range of them, and then go to a routine that determines what has been contacted, and what to do about it. That is kind of what I did with Spook-o'-tron since it is all sprite based, in an earlier build (in the end they all became the same points-wise and in terms of contact).

The issue is that it eats up a lot of CPU due to all of the checks, and you can only have 64 sprites total. The other problem with sprite-based platforms is the 8 sprites per scan line limit. Since backgrounds and sprites work different enough, if you want to expand your idea down the road it might be a good idea to start looking into doing platforms with backgrounds sooner than later (that would also allow your gravity engine to carry over), otherwise you could end up doing the work twice, and in two different ways (very little of my sprite based collision code seems to carry over to background use). MRN has a great tutorial on this, his Week 7 lesson (probably need to begin at week 5 for it to make sense; I skipped his ones deling with sprites when I started out). That is set up for treating all BG tiles the same, but with a small modification you can give the background tiles a "type" like structure and then pass through some one way, destroy others, fall through some, etc. His way also ties all of that to the metatile data so you do not have to have separate tables for any of that info. What you see on screen is what you get.

-------------------------
"The light that burns twice as bright burns half as long..." ~ Blade Runner

SoleGooseProductions.com



Edited: 09/15/2017 at 08:26 AM by SoleGooseProductions

Sep 15 at 9:34:02 AM
brilliancenp (0)
avatar
(Nick Pruitt) < Tourian Tourist >
Posts: 24 - Joined: 08/15/2017
Kansas
Profile
Originally posted by: SoleGooseProductions

...MRN has a great tutorial on this, his Week 7 lesson (probably need to begin at week 5 for it to make sense; I skipped his ones deling with sprites when I started out)...

Awesome.  I will check that out.  That helps alot and thats exactly why I asked lol.  Much appreciated.  Its early so maybe this is a stupid question, what is MRN?
 

Sep 15 at 10:33:57 AM
Gauauu (0)
avatar
(Nathan Tolbert) < Cherub >
Posts: 10 - Joined: 08/09/2017
Illinois
Profile
Originally posted by: brilliancenp
Its early so maybe this is a stupid question, what is MRN?

A forum user named "Mario's Right Nut" -- he has this tutorial.

 
Originally posted by: SoleGooseProductions
You could set up a routine to check the player sprite against every other sprite, or a certain range of them
The other thing I would recommend is, as much as possible, do your collision logic based on your logical game actors and not based on sprites or tiles themselves. (ie have a logical bounding box for your main character, and do collision tests based on that bounding box, and not based on the sprites that make up the character. ) This gives you more flexibility if you change how the character is represented in terms of sprites. Similarly with backgrounds -- check against whatever level of background element/metatile your game would find appropriate (ie often 16x16 pixel blocks like Mario), and don't actually check against each individual hardware-level tile.

On that guide to platformers page I linked to previously, there's a section about collisions with platforms that's worth reading.

-------------------------
My games: http://bitethechili.com


Edited: 09/15/2017 at 10:34 AM by Gauauu

Sep 15 at 11:00:54 AM
SoleGooseProductions (120)
avatar
(Beau ) < Ridley Wrangler >
Posts: 2738 - Joined: 04/22/2013
Indiana
Profile
Originally posted by: Gauauu
 
Originally posted by: SoleGooseProductions
You could set up a routine to check the player sprite against every other sprite, or a certain range of them
The other thing I would recommend is, as much as possible, do your collision logic based on your logical game actors and not based on sprites or tiles themselves. (ie have a logical bounding box for your main character, and do collision tests based on that bounding box, and not based on the sprites that make up the character. ) This gives you more flexibility if you change how the character is represented in terms of sprites...

This was a very valuable lesson that I leanred during Spook-o'-tron. Bunnyboy kept saying, years ago, not to directly check against sprite things, but rather to create variables for them. I chalked it up to a waste of variables in Pong and went my own way. Why have an EnemyStatus variable, or 32 of them for that matter, when a "dead" enemy could just have a Y value of 01 for instance. Out of sight, out of mind. Well, let's just say that it led to a world of problems and that I ended up having to redo all of the sprite handling code at some point  . Off-screen enemy collision code started interferring with off-screen projectile and civilian code and I suddenly realized that variables would have solved everything.

MRN's background collision system checks against metatiles. It seems to work rather well, at least for 16x16 worlds.


-------------------------
"The light that burns twice as bright burns half as long..." ~ Blade Runner

SoleGooseProductions.com


Sep 15 at 5:32:19 PM
MODERATOR
KHAN Games (88)
avatar
(Kevin Hanley) < Master Higgins >
Posts: 7760 - Joined: 06/21/2007
Florida
Profile
Originally posted by: SoleGooseProductions

...stuff
 

Beau and his abbreviations...
 

Oct 13 at 10:58:07 AM
brilliancenp (0)
avatar
(Nick Pruitt) < Tourian Tourist >
Posts: 24 - Joined: 08/15/2017
Kansas
Profile
Originally posted by: Gauauu
 
Originally posted by: brilliancenp
Its early so maybe this is a stupid question, what is MRN?

A forum user named "Mario's Right Nut" -- he has this tutorial.

 
Originally posted by: SoleGooseProductions
You could set up a routine to check the player sprite against every other sprite, or a certain range of them
The other thing I would recommend is, as much as possible, do your collision logic based on your logical game actors and not based on sprites or tiles themselves. (ie have a logical bounding box for your main character, and do collision tests based on that bounding box, and not based on the sprites that make up the character. ) This gives you more flexibility if you change how the character is represented in terms of sprites. Similarly with backgrounds -- check against whatever level of background element/metatile your game would find appropriate (ie often 16x16 pixel blocks like Mario), and don't actually check against each individual hardware-level tile.

On that guide to platformers page I linked to previously, there's a section about collisions with platforms that's worth reading.
Well it has taken about a month but I finally have my code working in line with MRN's tutorials.  I cant believe how much easier my code is to read and go through.  Much appreciated to everyone for the help.  I have made my way up to bounding boxes which is going to take some time.  The concept seems easy enough but putting it into action and actually understanding what it is doing is taking some time.  I am really trying to understand everything rather than just copy and paste and hope it works lol.  Debugging is getting easier for me as well.  I am so used to being able to step through the code with all my other development stuff. Had to think back to how I used to do things before that.  So by using the hex editor and some debug hex variables I am getting the hang of it.  Thanks again!

 

Oct 14 at 9:39:31 PM
SoleGooseProductions (120)
avatar
(Beau ) < Ridley Wrangler >
Posts: 2738 - Joined: 04/22/2013
Indiana
Profile
Awesome to hear man. I don't know if you realize quite how fast you're moving in comparison to some of us  .

-------------------------
"The light that burns twice as bright burns half as long..." ~ Blade Runner

SoleGooseProductions.com


Oct 16 at 12:27:19 PM
Mega Mario Man (58)
avatar
(Tim ) < Kraid Killer >
Posts: 2251 - Joined: 02/13/2014
Nebraska
Profile
I live and die by the Hex Editor. I even catch bugs that I don't know about by watching the Hex Editor.

I'm glad to hear that it is all working out!

-------------------------
Current Project
Isometric Survival Horror

Older Projects
Tailgate Party, Power Pad Demo, Happy Hour

Links
Store, Facebook, Twitter

Oct 19 at 9:37:39 AM
brilliancenp (0)
avatar
(Nick Pruitt) < Tourian Tourist >
Posts: 24 - Joined: 08/15/2017
Kansas
Profile
I am not THAT accomplished with the hex editor lol.  But I can atleast check variables from it and see where maybe a bug is appearing by looking for changes or non changes where they should be.