R0J0hound's Forum Posts

• • R0J0hound
  • 
  • • Joined 15 Jun, 2009
    • 
    • 91 topics • 7,658 posts
  • 1

  • 21 Sep, 2014
  • Quote

  By platforms do you mean android and ios? My guess there is a tag in the manifest that says if it's a game, app or anything else. That said I'm unfamiliar with the export process, and weather or not you can access it or if the process is fully automated.

• • R0J0hound
  • 
  • • Joined 15 Jun, 2009
    • 
    • 91 topics • 7,658 posts
  • 1

  • 21 Sep, 2014
  • Quote

  I agree with Katala's idea of having a top view layout in the back.

  For pathfinding and other motion in iso the simple thing is to do it in top view and then position some isometric objects from the top view positions to isometric positions.

  The math is simple:

  IsoX = x-y

  IsoY = 320+(x+y)/2

  Example:

  https://dl.dropboxusercontent.com/u/542 ... nding.capx

  I left the top view stuff visible but in practice you would make it completely invisible. The advantage of doing it that way is all behaviors can now work as an isometric motion.

  The animation aspect is basically the same as changing animations in 8-direction.

  viewtopic.php?f=147&t=90880&p=713920&hilit=animation#p713920

  To me z-sorting is the hardest aspect of isometric. In the capx I sorted by Y which doesn't sort right in some cases.

• • R0J0hound
  • 
  • • Joined 15 Jun, 2009
    • 
    • 91 topics • 7,658 posts
  • 1

  • 20 Sep, 2014
  • Quote

  Yes, that would work.

• • R0J0hound
  • 
  • • Joined 15 Jun, 2009
    • 
    • 91 topics • 7,658 posts
  • 1

  • 20 Sep, 2014
  • Quote

  Glad they helped. I found the topics using the forum search with "comma number".

• • R0J0hound
  • 
  • • Joined 15 Jun, 2009
    • 
    • 91 topics • 7,658 posts
  • 1

  • 20 Sep, 2014
  • Quote

  eli0s

  Maybe I've become accustomed to it.

  I did a bare basic js test of motion and even then it's not buttery smooth.

  http://jsfiddle.net/us1v4sq4/1/

  Also added a graph of the frame time to inspect it further

  http://jsfiddle.net/us1v4sq4/2/

  For me there are some little spikes in the frame time, but it doesn't really correlate to the motion.

  Not sure what can be done to improve it. The issue may lie in the web browser itself.

• Try Construct 3

  Develop games in your browser. Powerful, performant & highly capable.

  Try Now Construct 3 users don't see these ads
• • R0J0hound
  • 
  • • Joined 15 Jun, 2009
    • 
    • 91 topics • 7,658 posts
  • 1

  • 20 Sep, 2014
  • Quote

  Other stuff running in the background have much less of an effect than Garbage collection. Garbage collection is automatic and in javascript you can't control when it happens as far as I know. Ashley has done a lot to keep the amount of garbage made by the engine to a bare minimum according to his blog posts.

  I don't really notice the lag, but then again my pc is dog slow with html5 as it is.

• • R0J0hound
  • 
  • • Joined 15 Jun, 2009
    • 
    • 91 topics • 7,658 posts
  • 2

  • 20 Sep, 2014
  • Quote

  Another interesting idea would be to use

  http://en.wikipedia.org/wiki/Dijkstra%27s_algorithm

  The idea is to use an array to store the direction to move for every spot to get to the target with the shortest distance. It's just as easy to have more than one target so it's good for many objects that need to find a path to the same set of targets.

  So after the array is calculated objects can move to the closest target by just referencing the direction of the square it's currently on.

  https://dl.dropboxusercontent.com/u/542 ... eSpot.capx

  In the example I made the objects accelerate toward the direction instead of just setting the direction. The result was nice rounded turning.

  It caused a stall if I calculated the array all at once, so I adjusted it to only calculate a bit at a time.

• • R0J0hound
  • 
  • • Joined 15 Jun, 2009
    • 
    • 91 topics • 7,658 posts
  • 1

  • 19 Sep, 2014
  • Quote

  JavaScript's garbage collection (GC) is one cause of stuttering. It's gotten better over time because web browsers are implementing ways so the GC causes shorter stalls. Some are better at this than others.

  Another reason is stuff running in the background, the underlining os can be as much of a culprit as other programs. The nes had a lot less variance since only the current game was running.

• • R0J0hound
  • 
  • • Joined 15 Jun, 2009
    • 
    • 91 topics • 7,658 posts
  • 1

  • 19 Sep, 2014
  • Quote

  How is 0-100 limiting? Just convert a 0-255 value to 0-100 with value/255*100.

• • R0J0hound
  • 
  • • Joined 15 Jun, 2009
    • 
    • 91 topics • 7,658 posts
  • 1

  • 19 Sep, 2014
  • Quote

  There's an example here:

• • R0J0hound
  • 
  • • Joined 15 Jun, 2009
    • 
    • 91 topics • 7,658 posts
  • 1

  • 19 Sep, 2014
  • Quote

  Here are some topics with examples:

• • R0J0hound
  • 
  • • Joined 15 Jun, 2009
    • 
    • 91 topics • 7,658 posts
  • 1

  • 18 Sep, 2014
  • Quote

  If you have a center location and a radius you can do this:

  Sprite set X to centerX + radius*cos(angle(centerX,centerY,mouse.x,mouse.y))

  Sprite set Y to centerY + radius*sin(angle(centerX,centerY,mouse.x,mouse.y))

• • R0J0hound
  • 
  • • Joined 15 Jun, 2009
    • 
    • 91 topics • 7,658 posts
  • 1

  • 18 Sep, 2014
  • Quote

  —

  If you have a center (centerX, centerY) and scale factor you could do it like this:

  x = (object.x - centerX)*scale + centerX

  y = (object.y - centery)*scale + centerY

  width = self.width*scale

  height= self.height*scale

• • R0J0hound
  • 
  • • Joined 15 Jun, 2009
    • 
    • 91 topics • 7,658 posts
  • 1

  • 17 Sep, 2014
  • Quote

  Sure,

  It appears to swing because the sprite's origin point may not be in the exact center of the cog. You can adjust it in the image editor. Or it also may look like it's swinging because of the cog's shading.

• • R0J0hound
  • 
  • • Joined 15 Jun, 2009
    • 
    • 91 topics • 7,658 posts
  • 1

  • 17 Sep, 2014
  • Quote

  Swinging?... Oh I see it. The sprite's hotspot may need a little adjusting.