Part 3: Cleanup and Fixes
I’ve done a lot of things since the last post, so I apologize in advance if this post jumps around in topics, but I’ll try to keep it as organized as I can.
To pick up from where we left off from Part 2, I started drawing a tile map and I attempted to get some simple collision detection - getting the containing tile from any point on the grid. That wasn’t quite working, and I believe this was because the math done in the GetTileAtPosition() call. This code has changed completely since then and it’s now working, which I’ll get to a bit later.
The first new thing I got started on was cleaning up some files. I moved some code around, created new files and organized it all a bit better. I won’t go over this in detail, but I will mention that I struggle with this sometimes. Getting the “this includes this other file, then that includes that so it can access this” logic through my head can be tricky sometimes.
The next big thing I did was change my Render->Pixels to be void * instead of a u32 *. I did this so we can cast it to multiple different values without issue, and since void * is the same size as a u32 *, we shouldn’t have too much problems. I also changed my v2 structure to use real32 instead of u32. This was so math can be done on v2’s a lot easier. One other thing I did was change our Color values (was u32) to 3 different real32 values, an R G and B. This is so we can read the colors a bit better and eventually do some math on these as well. After these changes (and a couple others..), we got this:
Wow, most of my rendering is broken now! Not that I should be surprised, I’ve changed quite a bit. Let’s try to figure out what’s happening here.
First of all, we see that there are just dots everywhere.. However, the render square still appears to be working. The lines appear to be repeating, but if you look closely (the diagonal lines going down) the points of a single line are still there, they are just spaced incorrectly. When changing the values even slightly, the line looked more or less like a line as these were spaced farther or closer together. So my equation for rendering a line is wrong. I believe that the y positions were always correct, but the x positions were not.
I also noticed that my grid’s positions are all wrong as well, which is odd. I would think that because my render square is still fine, that the grid positions would be too.
Now I have to apologize again, because since I was making so many changes, it wasn’t exactly clear what fixed the issues, but I do remember it was a combination of a couple of things. Number 1, I was passing the wrong color values in for my new real32 R, G and B - I was passing values 0 - 255 instead of 0 - 1.
So after fixing a couple simple errors, I got to fixing the grid first. I changed it around a little bit so that I’m initializing the map structure once, and rendering it each call afterwards.
And we’ve got our grid back. Now to figure out the line, I was confused how it was working before but it wasn’t now, when really the only thing we changed there was from integer to float. After some research, I discovered Bresenham’s Line Algorithm. After implementing this, I got my lines working again! Doing it this way was much cleaner, and it handles all types of lines with no problem.
Now at this point, my circles were still wrong - likely also because of the switch from integer to float; and guess what, this guy Bresenham is helping us out again with a circle drawing algorithm. This one goes by the ‘Octants’ of a circle. If you can guess from the term Octant, there are 8 octants to a circle, and each is calculated a bit differently. After implementing this, we have our circles back!
I’d also like to mention our pseudo collision detection is working now too; here is what that function currently looks like.
From here, we are looking pretty good! All of our rendering has been fixed with proper algorithms, we have the pseudo collision detection working and we have our tile map (mostly) figured out. Can you spot the problem with the tile map?
From an earlier screenshot, it looks like we are missing two points on the top left, and almost an entire column on the right. Next time I’ll try to figure this out. On my todo list is mapping our rendering to the tile map and to get an entity system going.
EDIT: The issue with the tile map was the ‘<=’, it needed to be ‘<’ to be used as the index (in both the initialize and the rendermap call). I noticed that there was also a tile point being drawn at the origin 0,0 (bottom left), and it was drawing that point from an invalid index!
(Also, the unknown debugger issue I was having at the end of Day 2 was somehow fixed during all of my refactoring)
Just as an aside, I’d like to talk about my first plan to implement player movement. I’m not sure if it’s a good idea or not.. Actually, I don’t think it’s a good idea, but it was my first thought and I want to go over it anyway.
Remember our player in Asteroids is just a triangle in the center of the screen, and the only player movement that happens is a rotation. So my initial thought was to have an array of positions that I calculate and initialize on startup, and based on the users input, I cycle through this array and redraw the player at that position. Doing it this way, I’m not sure how I would have a “smoothness” to it, meaning acceleration and deceleration. I would also be locked into the number of positions I calculate ahead of time.
I may just try this out and see how it goes. I know it’s not the best solution, but it may be the easiest.
Thanks for reading and I’ll see you next time!