Making tiles do something.

[wiiqwertyuiop]

Ok, how would I go about making a tile DO something? Like how would I make, for example, one tile hurt the player, another increase a RAM address, etc. I have a idea on how to do it, but I'm not sure if it's the best approach. Any help would be appreciated!

[Burzy]

Perhaps I'm being a moron right now until my meds kick in, but you might want to be more specific.  I have no clue at all what game your talking about, what system, etc.  Someone will come in here and say this way more snottily than me, so hopefully this helps a bit before they do

[wiiqwertyuiop]

Well i think I found out what to do, but it still might be helpful if I header what others say.


And I am talking about the SNES and I want to know how to make tiles, do things. Like the munchers (they are blocks) in SMW, how do they interact with Mario?

[elbobelo]

The tiles don't interact with Mario at all (I don't know the game so I am assuming).  In every game I've hacked, the enemies and player all have coordinates and attributes.  The muncher might be sprite #30 for example and sprite 30 might pull attributes like width, height, horizontal offset, and vertical offset programmed somewhere else in the game.   Mario might be sprite #0 and will pull his attributes.  These attributes combined with their coordinates on-screen are thrown into an algorithm which calculates if there is a collision.  And depending on some other attribute if this collision is "true" then it will "do something", whether it be increase a counter or hurt Mario.

Tiles are drawn onto the screen in a completely different algorithm and don't have any properties of their own.  All the properties and attributes will be referring to the sprite number not a tile.

[Nightcrawler]

First, your terminology is likely to impede being able to get any help because people are going to have a hard time understanding what you're saying. I'll try to help you out.

Tiles are just a a small singular square graphic of a particular dimension. They don't really do anything by themselves.  However, ultimately everything you see on the screen is built from tiles. Put them together and they can make a background image or static objects. For action objects, you're going to need something more.

Let's move up the scale. Next, there are sprites. Sprites on the SNES are basically defined graphical objects with some available attributes to allow them to do some basic things on the screen. Attributes include things like coordinates, palette indexes, how many tiles make it up, and flipping. Sprites are typically the player, enemies, power-ups, etc. Action items. Sprites can only do what the attributes defined by the system allow, which is minimal. Let's move up again.

Now we move into the game code space. This is where you are no longer limited in what you can do. The game will have all sorts of code defining the details of game objects including your player and enemies that are represented by sprite objects on screen. So, it is there in the game's code that you will find lines of code that manipulate the sprites into on screen actions such as animation and also off-screen actions such as damage.

I cannot even begin to explain game code to you. To start, you will need to learn about assembly language, debuggers, and how to interact with the hardware via registers to set the tiles and sprite objects we've talked about. We have various documents on this site on SNES hardware and available debuggers. We have some assembly guides, but you can Google for even more board information on the subject.

What you want to do is not a trivial task and make take you weeks or months to learn necessary material if you're starting with no knowledge. Know that you are more likely to get answers to your questions if they are more specific than the general question you asked here.

[wiiqwertyuiop]

The tiles don't interact with Mario at all (I don't know the game so I am assuming).  In every game I've hacked, the enemies and player all have coordinates and attributes.  The muncher might be sprite #30 for example and sprite 30 might pull attributes like width, height, horizontal offset, and vertical offset programmed somewhere else in the game.   Mario might be sprite #0 and will pull his attributes.  These attributes combined with their coordinates on-screen are thrown into an algorithm which calculates if there is a collision.  And depending on some other attribute if this collision is "true" then it will "do something", whether it be increase a counter or hurt Mario.

Tiles are drawn onto the screen in a completely different algorithm and don't have any properties of their own.  All the properties and attributes will be referring to the sprite number not a tile.

The muncher is not a sprite though. It is a block, i'm 100% sure of it.

And I am already aware of the things already mentioned, but that would make no sense it every tile/block in the game was a sprite, you wouldn't be able to have that many on screen.

[elbobelo]

The muncher is not a sprite though. It is a block, i'm 100% sure of it.

And I am already aware of the things already mentioned, but that would make no sense it every tile/block in the game was a sprite, you wouldn't be able to have that many on screen.

Oh so you are talking about Mario interacting with background tiles.  It's probably the same section of game that determines what kind of block Mario is standing on.  Different things happen when Mario is on Ice, Lava, Conveyer Belt, Floor, and Munchers.  Mario probably reads from a large part of RAM that is constantly updating level data.

[wiiqwertyuiop]

I'm not really sure, I know there is something in the game called map6 pages, I think they might handle tile interaction.Well my method seems to be working now anyway, so yeah.