Portable code and IOS

KnolanKnolan
edited August 2012 in Help request
Hi there, I am writing some code right now and I am testing it on both linux 32 bits and windows 64 bits. To avoid portability problems I am using types declared at orx (such as orxU32), but I am using some C functions too (mostly malloc and free).

Can anyone tell if this can create problems in the future, considering I want to compile it for IOS and android later?

Comments

  • iarwainiarwain
    edited August 2012
    There shouldn't be any real compatibility problem for iOS, at least, but I'd still recommend using orx's API for most of your needs (orxMemory and orxBank modules for memory, orxFile module for file access, etc.).
  • KnolanKnolan
    edited August 2012
    Thanks, I will use them from now on and if I face a compatibility problem I will replace the former ones.
  • iarwainiarwain
    edited August 2012
    I don't see any problem either way.
    Out of curiosity, for which kind of use do you use dynamic allocation in your game? Just asking as there might be some obscure orx features that could help depending on the case. :)
  • KnolanKnolan
    edited August 2012
    First, I draw scenarios and load the monsters in the map dinamically by the config file (I intent to have one file per game level).
    So I create monsters and the grid as pointers.

    Second I need I need a two copies of the scenario walkable areas to run the pathfinding for the monsters.
  • iarwainiarwain
    edited August 2012
    Ah I see, I forgot you were not using Scroll! :)

    Also, do you really need a copy for pathfinding? Isn't there any way to use the original one? Again, I'm just curious. :)
  • KnolanKnolan
    edited August 2012
    I am using an extremely simple modified shortest path algorithm (floyd warshal) it is a dynamic programming algorithm, so it needs to save information in memory (in this case, the same size of the base grid).

    I may chage the algorithm to djikstra or A* in the future, but the grids are so small and simple that I don't really think it will be a problem.
  • iarwainiarwain
    edited August 2012
    Ah I see, thanks for the details. I've never used Floyd-Warshall to be honest, I've been sticking with A* for the last 12 years.

    Actually the orxAnimSet module computes a shortest path matrix (+handling of priorities) in a very similar manner for the animation graph but with a more compact memory representation (cf orxAnimSet_ComputeLinkTable). This code is over 8 years old so I'd probably write things a bit differently now. ;)
  • KnolanKnolan
    edited August 2012
    I use floyd warshal due to its simple implementation since a college programming marathon. It was so simple that I could implement it very fast (we could only take printed material to the competetion).

    I really don't believe the higher cost (O(x³)) will be a problem, since the movement rules make the problem simplified:
    - Monsters can overlap, so I don't need to recalculate the path every frame.
    - I only recalculate the path if the player moves out of a cell (which takes more than a second at normal movespeed).
    - Monsters will only try to attack the player if it is within a certain range and the monster can see the player (aka there is no wall in the line between the monster and the player). This restriction allows me to search a smaller area.
Sign In or Register to comment.