OMG This thread is so old, I forgot what my post had said. lol I had written up that guide for people who I had been discussing things with at the time, so yeah there are a lot of loose ends in it.
First off, the code was written for use with a Classic Castlevania clone, based on the code used in Castlevania III.
#1 : He uses the variable "solid_count" in the second code snippet. But its previously undefined and I dont know where how hes actually identifying a tile as being solid during the first loop.
The
solid_count is how many TYPES of solids you'll have in the room. In most of the tutorials around the Game Maker community, people typically settle on 1 type of solid, so a tile is either solid or it's not solid. In Castlevania III, there were 8 types of solids because various tiles could affect how the player moved: Mud, Conveyor right, Conveyor left, Crumbling ledge, Ceiling Spike, Solid, and Floor Spike (same properties as a ceiling spike, but whatever). If you stood on a mud tile, you'd sink down. If you stood on a conveyor tile, you'd move left or right. If you stood on a crumbling ledge tile, it would gradually fall apart the longer you stood on it. If you touched a spike, you'd die.
#2: He says :
Code:
The array solid_map in this example holds all the definitions. In this case, tile sheets would need to be arranged so that all tiles of the same type are together and located in the bottom-right section of the tile sheet.
I don't have the tile sheet for CV3 and cant find it, so I dont know how many tiles this "bottom right section" is that hes talking about. Is it up to us to define, and if so, how?
The
solid_map is an array specifying which tiles belong to each solid category. The way Castlevania had its tiles set up is all the decorative, non-solid tiles would be first, then tiles would be placed in the tile set in the same order as the types listed above - mud tiles first, then conveyor tiles, then crumbling ledge tiles (which was just the normal solid tile repeated), then the ceiling spike tile, then normal solid tiles, then a floor spike tile (which was actually somewhere else in the game's code, so it was always the last one). The solid_map would house the IDs of the last tile in each type of solidplus 1.
The way solid_map was used is you'd compare each tile's ID to each value in solid_map. If a tile had an ID less than the lowest entry in solid_map, the tile would be that type. As an example, let's say our solid_map was defined as [48,48,48,48,72,74,74,128]. If you had a tile with ID 32, then the tile would be type 0 (decorative) because it's not greater than solid_map[0]. If the tile had an ID of 52, then we check all the entries of solid_map until we find one that is higher than the tile ID. In this case, solid_map[4] is higher than the tile ID, so the tile is type 4 (crumbling ledge).
#3: Is the third code section on the page just the first 2 sections simplified?
The third code, if it's the one I'm thinking of, compresses the tile map. Instead of having each tile take up one variable, you can fit multiple tiles into one variable. In this case, it fits 2 tiles into one variable.
#4: The last section, the map read; since I dont understand where/how a flag for solid was set, i dont understand how this works. Would this piece go into a step event of a moving object?
The read code goes inside a script (hence the
return calls in it). It would get the player's x and y coordinates, compress them to match the same layout as the tile map, then return (like a normal Game Maker function) the tile's type (0, 1, 2, 3, 4, 5, 6, or 7) so the game could then decide what to do with an instance walking on that tile.