Page 1 of 3 123 LastLast
Results 1 to 10 of 21

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

  1. #1

    Another question YAY! (Sprite Engines Collision).

    As per my last question about collisions, I'm using a simple method of tracking the X, Y of my main sprite before movement, so that if a collision occurs, I can put the main sprite back.

    Basically the setup (or the view of it), would resemble something like a basic rpg or bomberman game (actually, for testing I'm using a gameboy bomberman sprite).

    When he walks into my 16x16 blocks, I would like the top half of his body to be able to walk through them, from either direction (and of course have that top half of his body drawn over a block when he runs up into one).

    Anyone know how I might go about that?, Right now I'm basically thinking of checking the position of both sprites when they collide and if it happens to be one of those, just let him pass, otherwise let the collision go through like normal.

    I was however hoping there might be a less intensive method lol.

    Oh and also, just quickly, do I use a sprites Z value to determine whether it's drawn overtop, level with or underneath something (and what determines over and under).

    Any help is greatly appreciated .

  2. #2

    Another question YAY! (Sprite Engines Collision).

    hello Chesso,
    the best way to do what you want is to code your own tile engine. That
    gives you more flexibility on "special effects".

    Anyway, in two words you have to do 2 steps of drawing, or even only
    one, it depends on level of detail you need...

    First draw terrain to fill your tiled map (grass, water...) then, from top
    to bottom draw the wall-items-obstacles things. You just have to check
    where the player tile position is, and when drawing that tile, draw the
    player sprite too. That is valid also for enemies and so on so, just check
    for every tile if there's an active sprite over it and then draw it.
    If you want to add a nicer fx to that, when drawing walls in front of the
    player, draw that tile with alpha and it becomes transparent

    I did a thing like that some time before but i had problems with delphix,
    because of slow down, maybe undelphix solves the problem.

    Another solution is to look at tilestudio that does the job for you, even
    export the tiles, the map and the delphix classes to use in your game!
    Here's the link: http://tilestudio.sourceforge.net/


    I hope it's clear enough, i'm not happy with my english lately... :?
    <center>
    <br />Federico &quot;FNX&quot; Nisoli
    <br />Lead Programmer - FNX Games
    <br />http://www.fnxgames.com
    <br /><img src="http://www.fnxgames.com/imgs/banners/fnxban.gif">
    <br /></center>

  3. #3

    Another question YAY! (Sprite Engines Collision).

    Hi

    I've googled for some bomberman screenies to understand exactly what you mean.

    So you don't want a top-down view... you want the camera to look at a 45 degree angle to the playground.

    You'll have to modify the bounding box for each moving sprite. The bounding box should be the bottom half of each moving sprite (the feet of each sprite).

    You can modify the bounding box by overriding the GedBoundsRect method for a TSprite descendant.

    An example:
    [pascal]
    type

    TMyPlayerSprite = class(TSprite)
    private
    ....
    protected
    function GetBoundsRect: TRect; override;
    public
    ....
    end;

    {implementation}

    function TMyPlayerSprite.GetBoundsRect: TRect;
    begin
    Result := Bounds(Trunc(WorldX), Trunc(WorldY)-(Height div 2), Width, Height div 2);
    end;
    [/pascal]

    You should always draw the background and the walls first before drawing the active charactes.
    Just use the TSprite.Z variabele.

    Hope this helps...

    Good luck
    Coders rule nr 1: Face ur bugz.. dont cage them with code, kill'em with ur cursor.

  4. #4

    Another question YAY! (Sprite Engines Collision).

    Could you explain the GetBoundsRect function? Like what is going on with it, WorldX and WorldY what do they represent (it's late here I'm half asleep lol).

    Oh yeah and does using the Z mean that a Z value of 2 will draw over a Z value of 1? or vice versa.

    Iv'e come across (although I can't remember) things that have used either one of those.

    EDIT:

    Oh and another thing (don't think I asked about this before), is there any function for method of doing transparent text?

    Iv'e seen the exampels that use DXPowerDraw with there own font sort of thing, which I might end up doing at a later stage for the sake of having my own fancy little font (if anyone knows where there is more info on using that component i'd appreciate that too, like is there specific dimensions or ordering of where everything goes).

  5. #5

    Another question YAY! (Sprite Engines Collision).

    Okay.. let me explain :

    A TSprite object has its own X and Y variabeles.
    It also has a list of sub-sprites. This allows you to make a sprite-hierarchy. if you add a sub-sprite to a sprite, the subsprite's position (X,Y) is relative to the parent-sprite's position.
    So if you move the parent-sprite, all it's childeren are also moved. The World X and Y are the actual world-coordinates of the sprite.
    So if you use subsprites, the WorldX can be computed by adding the subsprite's X and the parent's X.
    If you use a 'deeper' hierarchy with childeren who have childeren and grandchilderen etc the WorldX is the sum of the Sprite's X and it's parent's X, grandparent's X, etc.

    The GetBoundsRect function is a function which returns the bounding rectangle for a sprite. Each sprite has it's own bounding rectangle.
    The bounding rectangle depends on the sprite's position in the world, that's why we use World X and Y to define it in the function.
    When checking collision, the sprite engine checks for bounding-rectangle-overlaps (but i think you already knew that ).

    The code i gave you will make sure that only the bottom half of the sprite is covered by the bounding rectangle. I assume that the width and the height of the sprite are equal to the width and the height of the picture associated with the sprite. You must set these values explicitly when you create the sprite, if i'm not mistakin.

    Humm... The z-drawing-order.. :think:

    You could find this out yourself.. but i took some secs to analize the DelphiX source for you.
    I assume that DelphiX first draws the sprites with a low Z value and then those with a high Z value.
    But you should give this a try... plz, tell me the results :razz:

    About the font..
    I always used DXDraw.Surface.canvas.TextOut.
    Use the DXDraw.Surface.Canvas.Font record to manipulate it's fontface, size, color etc..
    This will suffice for basic text's.

    Good luck... hope this was enough info.
    Coders rule nr 1: Face ur bugz.. dont cage them with code, kill'em with ur cursor.

  6. #6

    Another question YAY! (Sprite Engines Collision).

    Hello, yes everything fairly clear aside from the font.

    I know how to use Canvas.Font for basic text but there doesn't seem to be any method in that to make it transparent.

    I want to display some stat information on the screen in the game and the window size is a mere 350x350, so I figured if I made the text transparent to a degree, it would be easier to see what's underneath and seem less cluterly and at the same time providing usefull information (like lives, or fps etc).

    EDIT:

    NOTE: I tried the code for changing the bounding box of the sprite, and no matter what I do, Divide, Plus, Minus, Times anything, it always bases it off the bottom not the top.

    I'm trying to ignore or cut, basically the top half of the sprite as far as collisions are concerned and nothing I do stops it from doing the opposite lol.

    Does anyone have any advice on creating there own font for use with DXPowerFont?

    I tried to create the invidual letters on photoshop, with all the nice effects and stuff, but that really screws up, because no matter what I use for the background or just transparent, alot of each letter ends up going based on that colour, rather than the colour chosen for the text.

    So if I make up a letter in PS with a pink background to put in my font bitmap, any sort of blur or shadowing ends up a pinky/black and when it's transparent and output to the screen and it looks like there is pink all around the letter .

  7. #7

    Another question YAY! (Sprite Engines Collision).

    it always bases it off the bottom not the top.
    Uhh... what do you mean. :eh: can you show to me (somehow) how the bounding box is created when you use my function.

    I'll probably need some code before i can solve the sprite bounding box problem. The creation and draw code would be usefull as well.

    plz notice that I might be unable to solve this problem, I haven't used DelphiX for a long time. :?

    A workaround for the font problem...

    For each text or label in the game, you could create a TDirectDrawSurface.
    Fill the surface with a color (e.g black) and set this color as the surface's transparent color.
    Then use TextOut to draw a text.
    And draw the surface using TDirectDrawSurface.Draw on the main DXDraw.Surface.

    It's slightly harder to code, but when succesfull this technique allows you to perform many operations and effects on you text. You can rotate, scale and wave the text using the various drawing functions. Be carefull though.. these DelphiX drawing functions are totally software-based and are rather slow. UnDelphiX has hardware accelerated graphics, so you better use that if you want cool FX.

    Good luck
    Coders rule nr 1: Face ur bugz.. dont cage them with code, kill'em with ur cursor.

  8. #8

    Another question YAY! (Sprite Engines Collision).

    What I mean, is that the bottom half of the sprite is allowed to pass through objects.

    I'm looking to have the top half of the sprite to pass through objects (creating the effect of the sprites feet being literally infront of any object in any direction and the top half of him being drawn over top and not colliding).

    Let's say the sprite is walking up into a block, it's meant to look as if the top half of the sprites body is towering over the block, due to the angle.

    But all you really have to do is to look at any 2D RPG's or even Bomberman itself (not sure about bomberman but I would assume) looks.

  9. #9

    Another question YAY! (Sprite Engines Collision).

    Personally, I would ditch the DeplhiX collision detection completely for this type of game. Or at least for anything other than bad guys and bullets (if applicable)

    As your game works on a fixed grid and there's no chance of a wall being in an odd place, I'd use a grid system using an array of booleans.
    This array would be populated with the walls of the map. True for blocked.
    Then work out if you're colliding with a block or if you can move into the free space next to you using a very simple calculation.

    I implemented a system like this for a platformer in VB once. it worked quite well.

    Just take the corner pixel co-ordinates and divide them by the number of pixels each cell takes up get the gridx and gridy for that corner and check if that grid is taken with a block, if so, don't move there. Do this before you apply your position changes in DoMove.

    This type of collision detection is Uber fast. No pixel tests to do at all. and you'll be able to add whatever offsets you want to the X or Y axis so you'll appear to walk behind blocks for a little way then stop.

    gridx := x / gridsizex;
    gridy := y / gridsizey;

    If you do this for each corner of the sprite, it'll work. If you only do this for the centre of the sprite, you'll be able to walk halfway into every object in all directions.

    If I was doing a game like this, this is how I'd do it.

  10. #10

    Another question YAY! (Sprite Engines Collision).

    Well it is a fixed size that can be split up into 32x32 blocks, the main character, other animations, any enemies and the movement don't work in this fashion lol.

    Speed isn't really too much of a problem as each level is considerably small and nothing too complex going on.

    I'll probably have to re-consider this in later games where I'll need more flexibilty for sure.

Page 1 of 3 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
  •