Both a suggestion to Parallax, and a problem.

Comments

• Mike Green Posts: 23,101

  2007-06-15 16:12 edited 2007-06-15 16:12

  Yes, and it's hard to determine what the minimum stack requirement may be since that depends on the local variables declared and the complexity of expressions and on the dynamic pattern of method calls (who calls whom and when). There are some optimizing compilers that can do a worst case flow analysis of a program and give you this kind of information, but it's not really that useful since, on a memory limited processor like the Propeller, so many other factors come into play (like the size of your code and the global storage used, let alone the actual call patterns).
  
  In any event, it's way beyond the capability of the Propeller Tool's compiler to determine any kind of useful information on stack usage.
  
  You can set up a spare cog with a routine that will initialize the stack area to some unique pattern and watch how it is overwritten and even display an indicator of the worst case stack usage so far on some kind of attached display.
• potatohead Posts: 10,255

  2007-06-15 16:24 edited 2007-06-15 16:24

  I have found that doing some worst case planning, or coding in for specific cases, based on timing, number of elements in process, etc.. ; breaking tasks into discrete chunks, that are known, are all helpful where determining your stack size is concerned.
  
  In the context of a video game, known numbers of moving objects, size of assets, display buffer size, draw video on fly needs working ram, color lookup tables, and in game object data structures can all be known things. One very simple example is moving things. Let's say moving everything, every frame consumes too much RAM. One then can decide to only move some things, with the use case for that RAM consumption known.
  
  Stuffing assets into the EEPROM is a great idea too.
  
  You then work with known buffer sizes, and timing, all of which consume known stack sizes.
  
  In the game context, there really should be few unknown memory consumption issues.
  
  I recently spent some time authoring a game on the 2600. That thing has 128 bytes of RAM period. (OK, it can be expanded via the cart, but I was not going there for my game.) In the end, to make it all work nicely, two things happened.
  
  I literally used every bit of RAM. (to the literal binary bit)
  
  I knew the RAM consumption for every last use case on the machine, and that included stack required for subroutine call and return. (I ended up with only two levels at any one time. Call three and it crashes sooner or later!)
  
  It is a good idea to lay out your in-memory structures, pack data into bytes well, and have these be fixed to define the limits in your game.
• CJ Posts: 470

  2007-06-20 17:12 edited 2007-06-20 17:12

  sounds like you are using the standard graphics object, the one that takes up 24K for the display buffers
  
  ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
  Parallax Forums - If you're ready to learn, we're ready to help.