Jump to content
  • Advertisement

ifstatement

Member
  • Content Count

    7
  • Joined

  • Last visited

Community Reputation

0 Neutral

About ifstatement

  • Rank
    Newbie

Personal Information

  • Interests
    Programming

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. ifstatement

    Did the SNES have pixel perfect movement

    I think it’s slow because each frame I loops through each tile in the camera area to redraw them on screen again. I need to make a huge surface drawn tile by tile before the game loop and convert the camera area from that surface in a texture and then draw that each frame. Then I can have smooth pixel movement between tiles and use the grid array to determine collision.
  2. ifstatement

    Did the SNES have pixel perfect movement

    So I've modified my code to make the character and camera transition smoothly, pixel by pixel, between tiles. That works but movement is now very slow. So I'm forced to make movement move by more than one pixel at a time but that goes back to the same thing as before where I was moving one tile at a time.
  3. ifstatement

    Did the SNES have pixel perfect movement

    Yeah that's why in my alternate algorithm for pixel-perfect movement I ended up implementing movement by more than one pixel at a time. But also allowed for one pixel at a time. The amount of pixels would increase the longer the player would keep pressing the directional button.
  4. ifstatement

    Did the SNES have pixel perfect movement

    Thank you! I've programmed something along these lines but I can't seem to get the collision right (more details in my previous comments). I've decided to stick to purely grid-based movement and collision detection. There are too many calculations involved in pixel perfect collision, that will take up the cpu more than if I was doing simple grid-based. At least my solution has too many compared to simple grid-based. A tile on my grid is 4x4 so whenever the player, an object or the camera moves it's by 4 pixels at a time. I think some snes action rpgs like alcahest and terranigma use the same method, and those play and look just fine. Plus I have to reserve cpu power for a whole bunch of other gameplay things I want to implement. Also it makes detecting hits/attacks a lot faster and less cpu intensive.
  5. ifstatement

    Did the SNES have pixel perfect movement

    Yes, so I have also programmed an algorithm that would achieve pixel perfect movement. I use the tile map array to detect collision. The character you control has coordinates for that tile map and I check the next tile if it is marked as walkable or not. I use another tile map array with the same dimensions and that one holds boolean values. True means it's blocked, so not walkable, and False means it's walkable. I then use another set of variables for the same character that tracks it's offset in pixels from the tile map coordinates. The offset ranges from 0 to 15 because each tile is 16x16. When the character's offset are <0 or >15 the character's variables for the tile map are incremented by 1. I also have a variable for incrementing the offset variables by more than 1 (1 is a bit slow and would be comparable to walking in a game) so that the character can move faster, which is like running or sprinting I guess. The camera or view area (how many tiles are displayed on screen) has it's own coordinates for which tiles should be displayed (start x, y and end x, y: which makes the view area). The display on screen of those are also offset by another set of variables for the camera and those variables follow the same rules as the character's offset variables. The issue I'm having is I cannot seem to take into account the offset variables and tile map variables correctly so that the collision is detected properly between the character and a hard object on screen. My algorithm uses the tile map array to detect if the tile next to the character in the direction they are walking is walkable or not, if it's not, it will get the pixel coordinates of that tile and the pixel coordinates of the character and then check each pixel the character and the tile are comprised of until they overlap (I plan to also check the actual pixel value of the surface matching the textures of the character and object and consider a pixel only if it's different than the colorkey (255,0,255), that way I can have pixel perfect collision) at which point a collision would have occurred and the character's offset variables are not incremented. That works partially when I run and play the game. The character stops when it encounters the object but when the character is aligned in a certain way with the object it walks through it because, I assume, the tile map coordinates and the object are not aligned in a way that detects as collision. At the moment the grid-based movement I have programmed works perfectly but pixel perfect looks smoother, lol. Sorry if I'm bad at explaining this, I did not study how to make a game nor programming, but I have been playing games and programming for 22 years. So I can figure out a lot of things to make a game I would enjoy playing, and hopefully others too. I would appreciate if anyone would know of a way to achieve pixel perfect movement or can point me towards a website. Also I'm using SDL2 and Free Pascal for my game. Too late to switch to another programming language, I have 19198 lines of code: character and npc menus and interactions, world/level creation, combat and so on. Been working on this for over a year.
  6. ifstatement

    Did the SNES have pixel perfect movement

    Yeah that's the sense I get when watching it on youtube. I've also played it.
  7. For example in Zelda or Castlevania on the SNES, did the character move one pixel at a time or several pixels? I've programmed a tile-based graphics game. Each tile is 4x4 pixels and moving the camera or character moves everything by 1 tile, so 4 pixels at a time. I do this so I can have collision detection that is not cpu heavy by checking the tiles next to the character, whether they are walkable or not. The characters and other objects, and background, etc. are made up of multiple tiles. Did the SNES do the same or did it separate the grid-based layout of levels from the actual movement of the camera and character. So the level would be displayed according to a grid but then the movement of objects and characters, and the camera would be one pixel at a time? I've watched videos on youtube and it seems like the movement on the SNES is grid based and not pixel based.
  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!