Page 2 of 3 FirstFirst 123 LastLast
Results 11 to 20 of 21

Thread: Another question YAY! (Sprite Engines Collision).

  1. #11

    Another question YAY! (Sprite Engines Collision).

    I don't understand...

    the main character, other animations, any enemies and the movement don't work in this fashion
    How do they move?

    Do they have free movement within the 32x32 cell? either way, the way I suggested will work.

    Your array for your map, say for example it's 10x10 - the fact that your sprites are all 32x32 is not important at this stage.

    [pascal]
    -0123456789
    0XXXXXXXXXX
    1X X
    2X X XX X X
    3X XX X
    4X X XX X X
    5X XX X
    6X X XX X X
    7X X XX X X
    8X X
    9XXXXXXXXXX[/pascal]

    say your sprite starts with a left-top of 32x32 a right-top of 63x32, a left-bottom of 32x63 and a right-bottom of 63x63

    this would equate to all four points being in the grid cell 1x1
    now if you wanted to move diagonally to the right by a couple of pixels,
    34x34 65x34

    34x65 65x65

    the bottom-right pixels when translated to the grid are in 2x2 which is obstructed.. so he can't move that way.


    Does this explain what I'm on about? or did you understand before and I don't understand the problem?

  2. #12

    Another question YAY! (Sprite Engines Collision).

    Maybe I just don't understand this whole tiling thing, Iv'e tried it before but could never get my head around it for some reason.

    How would I know which square he's on and which he's moving too, to check?

    He wouldn't be moving from one square to another in each move like a chess piece, that would look a bit iff.

  3. #13

    Another question YAY! (Sprite Engines Collision).



    for example with any game resolution you can do:

    EDIT ( ops: i invert row with column):

    X position div 10 = column
    Y div 10 = row

    this for a 10x10 table.

    but x and y usually is related to the upper left corner of your sprite, you have to adjust this part as Jasonf wrote.

    this doesn't mean you have too move like chess!
    Will: "Before you learn how to cook a fish you must first learn how to catch a fish." coolest

  4. #14

    Another question YAY! (Sprite Engines Collision).

    I understand your concern about the jumpy movement, but it's not like that at all, certainly nothing like Chess or Checkers.

    You'll still have pixel smooth movement. And you'll still draw your tiles as sprites in the usual way. The only thing is, in the background you've got an array telling you where the obstacles are.

    what you could do is use an array as the definition of your maps.
    Each type of tile has a number with a Zero as the ground (or anynumber, you may want different types of tiles as ground tiles. You could say if the tile type <5 then it's ground, otherwise, it's wall.

    You know which tile he's on by checking the center of your sprite against the grid by dividing your X & Y positions by 32

    You know which tile he's going to move to by writing a function like this.
    (I'm at work and don't have access to Delphi, so I can't check if they syntax is 100% )

    [pascal]
    Procedure DoMove( blah blah )
    begin

    // About to move.. check each of the corners.

    if ( checkNextSquareIsGround( X+moveAmountX, Y+moveAmountY) ) and
    ( checkNextSquareIsGround( X+width+moveAmountX, Y+moveAmountY) ) and
    ( checkNextSquareIsGround( X+moveAmountX, Y+moveAmountY+height) ) and
    ( checkNextSquareIsGround( X+width+moveAmountX, Y+moveAmountY+height) ) then
    begin
    X := X + moveAmountX;
    Y := Y + moveAmountY;
    end;

    end;

    function checkNextSquareIsGround( X,Y:integer ) : boolean
    var
    gridX,gridY : integer;
    tileNumber : integer;
    begin

    // Get Grid location for pixel location.
    gridX := x div 32; // 32 pixels per square.
    gridY := y div 32;

    if (gridx>=0) and (gridx<=10) and (gridy>=0) and (gridy<=10) then
    begin

    tileNumber := grid[gridx,gridy];

    if tileNumber <5 then
    begin
    result := true;
    end
    else
    begin
    result := false;
    end;
    end
    else
    begin
    result := false;
    end;

    end;[/pascal]

    hopefully, this should give you an idea.

    Then at the start of each level, when you want to create your wall sprites, go through the grid.
    Place tiles at gridx*32, gridy*32 and set the image to the relevant image to the number in the grid array.

    does this make sense?
    [/pascal]

  5. #15

    Another question YAY! (Sprite Engines Collision).

    But using the uhh sprite engine, if I ended up using this method at some point is still allright?

    Mainly because it handles the animations for me pretty well .

  6. #16

    Another question YAY! (Sprite Engines Collision).

    yeah, you'd still be using the sprite engine.

    You would just not worry about collisions with wall sprites.. you'd let the grid code handle that.

    I trust you have a few different types of sprites.

    TPlayerSprite
    TWallSprite
    TBaddieSprite

    You can tell which is which when the collision code is called. Just make sure pixel test is off on the wall sprites. Just do Nothing if you hit a wall.

    Does this make sense?

  7. #17

    Another question YAY! (Sprite Engines Collision).

    True, but I don't think that stops the sprite engine from checking collisions, and then doing more additional checks (outside of the DoCollision event) would just be asking for a performance hit wouldn't .

    If I could get my head around the code above for changing the bounding box I might be able to get the desired effect.

    I modified it to what, well if I were to set the bounding box myself would work, but it doesn't seem to take it the way I would lol.

  8. #18

    Another question YAY! (Sprite Engines Collision).

    Wow this is confusing as hell.

    Using chronozphere earlier method with the GetBoundsRect function, I added a call to draw either Rectangle, Flood Fill and FrameRect with input that matched what was put into Bounds();

    And guess what happens......

    It draws the LEFT and TOP a little away from the screens *Literal* LEFT and TOP (not the sprites) even if I use X, Y instead of WorldX and WorldY, and the RIGHT and BOTTOM drag themselves to follow a little away from the top left hand corner of the sprite.

    Wth is that lol, I can't test why I'm getting it wrong if it goes whack like this lmao.

  9. #19

    Another question YAY! (Sprite Engines Collision).

    The fastest way is to use a 'dummy' block instead of real block. like wall,tile..etc.
    The dummy block is samll,unvisible and you need adjust its position(for collision)
    Your sprite is only collide with the 'dummy' block.The wall,tile... is just for 'show'.
    So your sprite can walk through them(top half of his body) and have collision effect.

  10. #20

    Another question YAY! (Sprite Engines Collision).

    I think I know just what you mean, but I'd think that it does add just a little more to it then it could if I worked this bounding box problem.

    I mean if I can manage (with code from earlier in this thread) to make it basically stop checking the bottom half, there must be a way to do the opposite or atleast I hope so lol.

Page 2 of 3 FirstFirst 123 LastLast

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •