I'm having a problem manipulating a variable |
LAURENT*
|
Modifying code from the SDL legacy tutorial I have tried to render tiles are new way. This is a link to the tutorial. http://lazyfoo.net/SDL_tutorials/lesson29/index.php
No matter what I've tried and how logical it seems I cannot control where I render my tile to. In order to render I must change the value of my variables. I got the idea to read from a map file and check for conditions to render my level. At the bottom of my post you can view all of my code but I suspect my problem remains exclusively with the set tiles fucntion My problem in my code
ALL OF MY CODE
|
|||||||||||||||
|
LAURENT*
|
I'm having problems with the set_tiles function from the Lazy foo legacy tutorial on SDL 1.0 specifically the tiling tutorials. In the tutorial the creator makes the x axis move over to the right after each tile coordinate has been set. I wanna be able to place tiles in a less patternized way but no matter what I tried on the screen the special tile I made always show at coordinate (0,0).
|
|||||||||||
|
Naith
|
I would like to test out the program by myself and see what's happening and such so do you mind sharing your maps and graphic files?
|
|||||||||||
|
LAURENT*
|
https://www.dropbox.com/s/quzsawrqm78z2yd/resource.zip
This is everything. I slightly modified one of the map files since then but it was very small and only used to testing. |
|||||||||||
|
Naith
|
Thanks.
If I understand your code correctly, you want to render multiple layers of tiles. Correct? Also, I don't understand your map files (except the 'Lazy.map' which is just a normal map file). You have one map file named 'Coords.map' containing zero's (which I guess later will be changed to represent a tile in the tileset) and then you have a map file named 'Zrender.map' which contains some values. I need to hear / see / read your thoughts behind your game, the thoughts behind your code, the way you're handling things in the code and so on. So please enlighten me with some more information regarding what your plan is. And please don't just write that you want to make a game with tiles because that's not gonna help much. And yes, I know that you've already written that you're having problems with the set_tiles function but I need more information before we're starting to change stuff in your code because, to be honest, some things in your code will probably need to get changed in order to make the game behave the way you want. And yes, the set_tiles function will be fixed / changed along with the rest of the code that need's to get fixed / changed. And btw, in my opinion, you should migrate to SDL 2.0. Check this page to read about the new features and also about what needs to be changed in the code to do the migration from SDL 1.2 to SDL 2.0: https://wiki.libsdl.org/MigrationGuide |
|||||||||||
|
LAURENT*
|
I rather just make a new game then immigrate, it not easy and there is a hard learning curve, please cooperate.
My idea was to render the floor first then render the wall tiles with another array. In order for my character to detect the wall tiles the Land pad rectangle must first detect specific floor tiles. Right now I'm having trouble just rendering the wall tiles to any other spot other than the upper left hand corner of the level. My goal is to print the wall tiles on the right location at the moment. I'm not at collision detection yet. |
|||||||||||
|
LAURENT*
|
Zrender was intended to render the tile type and it's coordinate but I decided to save the latter feature to a new map file specifically the map file name coords. Zrender are the wall tiles rendered on the z axis and coords move the tiles to right location.
Try this for testing purposes, In the Zrender map file erase everything and then type the number "12" since their only suppose to be 1 tile render. Within the second for loop of bool set_tiles(Tile *tiles[], Tile *walls[]) Try to modify the value of p before before tiltTypewall reads from the map file //Only one wall tile is suppose to be rendered for testing purposes. Check the code const int TOTAL_TILES_WALL = 1; |
|||||||||||
|
Naith
|
Okey, I have a better understanding now.
Regarding the migration; I will help you whatever version of SDL you're using. It was just my opinion that you should migrate. As long as you're doing it sometime, it's good. I don't want to sound like a smartass now, and forgive me if I do, but since your game will be in 2D (as far as I understand), I don't see a reason to have any z variable(s) and specifying a specific tile to be rendered in a specific z value (since the z axis doesn't exist). Am I missing something here? |
|||||||||||
|
LAURENT*
|
You're right the game is 2D but the view of the game is isometric and I declared a variable named float z to handle the movement of the characters. my idea to handle this special isometric collision detection was to check for the variables y and z at the same time. This is a summary of my logic
If (y < or > a certain value) z can be interacted with. Since the view is isometric similar to a legend of Zelda game just checking for one collision alone sound problematic. I wanted to be able to scale walls and other thing without distorting the view and keeping the graphic like this. http://www.brynmawr.edu/cities/Cities/imgb/071/071d.gif Take a look at the Dot:: move (tile *tiles[], Uint32 deltaticks) function. This is where I use the z variable to implement the gravity on the characters. My plan is to pass both values z and y through parameter to do collision. |
|||||||||||
|
LAURENT*
|
Its just an idea, it showed promise with gravity so I use it on tiles too.
|
|||||||||||
|
LAURENT*
|
BTW can you run it?
|
|||||||||||
|
Naith
|
Now the z variables and such makes more sense. I actually love games which has isometric view (like Zelda). It will be interesting to see the end result of your game!
Yes, I managed to execute the program and I found the reason to why the tile (wall tile) always end up at (0, 0). The error is in the Tile::Show function. Whenever a tile is rendered, the tile is positioned with the help of the floorpad rect / quad. When a wall tile is created, the x and y is not set (instead p and q is set). This means that the x and y is (0, 0) and since the floorpad.x is = x and floorpad.y is = y, the tile ends up at (0, 0) (since the wall tile is positioned with the help of the floorpad rect / quad aswell).
The code below (which is written directly under the above code) doesn't work since 'walltilesheet' is NULL (image surface is not being created at the start of the program).
Solution to the problem: Write this in the Show function:
Or if you want to specify a range of tile types, you can do it like this:
If the tile type ('type') is a red wall tile, us the wallfront rect / quad to position the tile. You should add some more tile types in the if statement if you want more tiles to rely on the wallfront rect / quad. If the tile type ('type') is not a red wall tile, use the floorpad rect / quad to position the tile. I hope you'll understand what causes the error and that you'll understand my solution to it. |
|||||||||||||||||||
|
LAURENT*
|
Whoa. Slick bug fixing. This is just like they say in pixel art "Sometimes other people need to see your work".
I understand what you did. Now I see why when I was debugging the value of p did change but not the coordinates. Thank you for the aid. BTW when you were debugging what did you do to notice this? |
|||||||||||
|
Naith
|
No problem.
I used some breakpoints to check the values of some of the variables at some points in the game loop. I first set out a breakpoint at where the show function of the tile map is first called.
And when I jumped into the show function I put a breakpoint there aswell, checked the value of the x, y, p and q variables and saw that x and y were in fact (0, 0) even though I tryed to change in the map files and such. At the same time I checked the variables in the function, I also realized that the floorpad rect / quad were used by both the floor tiles and the wall tiles when they were to be positioned. So.. yeah. Breakpoints are always good. And like you said, sometimes someone else need to check the code, since that someone can spot errors and problems which the coder of the program has missed. Some off-topic thoughts regarding Lazyfoo To be perfectly honest, I don't like how Lazyfoo does- and solves some things, when it comes to coding. But I do like the tutorials since I have really learned stuff by going through them, when I first learned SDL. They are good when it comes to learn SDL but when the coder has learned the stuff that Lazyfoo learns, the coder should find his / her own code style (which I've did). I do know though that the reason why Lazyfoo solves things in a certain way, is to make the tutorials as simple and logic as possible, but again, the solutions that is made in the tutorials is not always the best solutions (again, in my opinion). I would not, for example, have used a lot of 'const int MyFirstTileType = 0;' , 'const int MySecondTileType = 1;' and so on. Instead I would've created a enum block containing all of my tile types. Example:
By using an enum block, I can set the start value of the first tile type (TILE_RED = 0) and the rest of the tile types that I put into the enum block will automatically be assigned to the next numeric value (TILE_GREEN = 1, TILE_BLUE = 2 and so on). If I set TILE_RED to one (1), TILE_GREEN will be set to two (2) and so on. As the last object in my enum block, I've added a NUM_TILETYPES which will always contain the total number of tile types that I have and it will update itself whenever I add- or remove a tile type from the enum block. That information might come in handy since I might sometimes need to know how much tile types I have without have to go up to the enum block and count all my tile types. Me like enum's. |
|||||||||||||||
|
LAURENT*
|
I actually figured out the tutorials on this site use a lot of bad programming practices that have unfortunately embedded on me. It's for the sake of simplicity but still. I'm currently trying to break these bad habits to become a sharper programmer. Again thanks for the help
Off topic Wanna see some clever? I like to draw up concept before I program. I've draw up the collision detection concept and it's looks really clever. |
|||||||||||
|
Naith
|
No problem.
Yeah, please show. =] |
|||||||||||
|
LAURENT*
|
There are only a few tile type in this game and almost each will require a special collision detection algorithm. Here is the collsion detection for sidewall tile. The purpose of the land pad bare extreme importance. It not only detriment where the character land but also detriment how he get on top of platforms. By running a loop to figure out where the land pad is if it get close enough to a wall I can make the character go along with special rules to get on top of each platform.
Eventually I plan to add alpha blending logic, and a few other details that will make this the first 2D isometric game where you can accurately judge height and make precise jump. |
|||||||||||
|
Naith
|
Nice solution there! Keep up the good work.
|
|||||||||||
|