Embedded Files
3/21/2023
Welcome back to the Integration Hell development blog.
Loading Game Files - For now with how simple the game engine is, loading files was trivial to make work. Now that I have saving/loading files, it is time to start rendering the game.
Pictures - The first step to getting gameplay is to put a picture onto the screen, as all textures in the game are going to be pictures. My first successful attempt of getting a picture on screen is below.
That happy little fella represents the player for now, so I need to scale it down and have it replace the red rectangle that exists on the window. After a little more research, I got the picture to move as the player in the window.
Getting tiles to render on the screen was trickier that I thought it would be. What made it difficult was making the process work for any screen resolution. For now I am testing the game with an 800x600 pixel window, but I want to have the option to change the resolution later without having to rewrite the algorithm. Pictured below is a screen full of tiles getting rendered. (The tile information located is not from sectors yet)
Scrolling the tiles was also a relatively simple task. The way I implemented it involves fixing the tiles on screen to a specific section to the screen. When the player moves, the tiles shift in the direction of the movement (The player sprite itself does not move). If the tile moves more than one tile length away from its spot, then the tile snaps back to its default position in the grid of tiles. To the player, the tiles seem to move on and off screen when they actually just teleport back to their assigned spot.
While that works, this still does not render tiles from the game's memory. Finding a robust way of rendering tiles to the screen was more difficult than nearly every other thing I have made for this game so far. Again, I wanted this to work for any resolution rather than just the 800 x 600 testing resolution. My current implementation does not work for all resolutions, but should work upto 4K resolutions. All of this has to do with how many sectors are on the screen at once. The game takes the sector the player is in and the eight sectors around that one. Then each tile visible on the screen figures out how far away it is and then renders the tile data from that sector. This works but rendering the tiles as a whole is not finished.
There are two problems left to solve that I haven't implemented solutions for yet.
Every frame, the game evaluates what texture needs to be rendered for the tile. Then it updates the texture that the tile needs to use. However, the current way that this is done is super wasteful. Every time it changes texture, it unloads the current one and loads a new one in. When applied to every tile on screen, it lags the game which is a problem since there is lag without the engine actually doing anything.
The fact that the tiles on screen are not the same tiles in the game causes rendering issues currently. The existing tiles in a sector 'follow' the player. This is only a rendering bug and does not reflect the actual tiles or player position.
Text on the screen was another challenge of this week. The current library I'm using to render the game (SDL2) does not include any text processing in the library. I had to find another library (SDL2_tff) to render text to the screen. This will be important later when I begin creating menus for the player to use but I'm including it in this blog since I did that this week.
That's all for this week, thanks for reading and I'll see you next week.
The Checklist:
Tasks:
✔️ Put an image on the window
✔️ Put text on the screen
✔️ Load world data from disk
✔️ Create simple assets to use for the game
𐄂 Render a tile from memory
𐄂 Render a sector from memory
𐄂 Render the game world
𐄂 Create more assets to use
𐄂 Create better file organization for the game
𐄂 Create a menu system
𐄂 Give the game an icon
Google Sites
Report abuse