lp:activeprocess

Related source package recipes

No recipes using this branch. (?)

Create packaging recipe

Related snap packages

Related bugs

Related blueprints

80. By Bradley Harms on 2011-01-16

- >
  The FPS readout has been replaced with a new feature in the engine module.
  (see below)
- >
  New flag `engine.show_fps`, when enabled, will cause an FPS "bar" to be
  drawn in the lower-left corner of the screen. The length of this bar depends
  on the current engine speed. When the fps exactly equal to the target speed,
  the bar will be fully white. When fps is less than the target speed, a
  portion of the right of the bar equal to the difference between the target
  speed and the actual fps will be red to show the severity of the lag. When the
  actual speed is above the target speed, a portion of the left of the bar
  equal to the difference between the actual speed and the target speed will be
  drawn at the left.
- >
  New flag `engine.allow_fpstoggle` that, when enabled, allows the FPS bar to
  be toggled on and off by pressing the F12 key.
- >
  The various `engine.allow_*` flags and `engine.show_fps` have been changed to
  be enabled by default only when in debug mode. When in production mode, they
  default to False.
- >
  `TextBox` now has a `char_max` attribute that indicates the maximum number of
  characters allowed. AFAIK, the class adequately prevent the number of
  characters in the box from ever going over this limit. By default, the limit
  is -1, which means "no limit."
- `TextBox` no longer resizes automatically to fit its contents.

79. By Bradley Harms on 2011-01-16

- Replaced all occurrences of "has_focus" with "focused"
- A few minor changes from rev 66 regarding the gui system were re-added.
- >
  `WidgetMixin` was given a simple `get_visible_rect` method based on simple
  rect geometry. (NOTE: This method may be superceded later.)
- >
  Enough tweaks were made in the `gui.core`, `gui.control`, and `gui.frame`
  modules to allow the sandbox to function again.
- `easygui` was removed.

78. By Bradley Harms on 2011-01-10

- >
  Another slight optimization based on closures; by placing the occurrences of
  `self.__class__` inside the Rect definition with references to `from_rect`,
  `from_xywh`, etc. it is possible to effectively enclose the classmethods
  within the other methods. (See apglib/geometry/rect.py:456). This appears to
  have raised the fps slightly (~1 fps)

77. By Bradley Harms on 2011-01-10

- >
  A manual frameskip mechanism was put in place into the engine. It can be
  activated by passing `frameskip = X` to the engine initializer, where X is
  the number of frames to skip. (0 = don't skip any frames, 1 = skip every
  2nd frame, 2 = draw every 3rd frame, 3 = skip every 4th, etc.)
  The mechanism seems to be somewhat effective, but the frameskip must be
  set relatively high (like 5 or 6) to get the game logic to approach the
  target framerate, and even then, it can never really quite reach it. And there
  is currently no way to determine the ideal frameskip mechanism automatically;
  it must be set manually.
- >
  Frameskip can be altered at runtime by pressing the F9 and F10 keys.
  Documentation has been added for this to the engine.
- >
  The function `engine.get_fps()` has been replaced with a new variable
  `engine.fps`, which functions in the same way.
- >
  I'm going to give up on the speed issues for now and focus on getting the
  world editor working again. Should users encounter severe speed problems, I
  will direct them to the frameskip mechanism as a temporary solution.

76. By Bradley Harms on 2011-01-10

- >
  Minor changes to `apglib.image` to improve consistency, speed, and to
  remove useless code.
- >
  Most occurences of Rect(...) and FRect(...) have been replaced with calls to
  the appropriate alternate rect constructors. This seems to have improved
  by a small amount (possibly +0.5 to +1.5 fps).

75. By Bradley Harms on 2011-01-09

- >
  I wasn't able to deduce the isolate the cause of the slowdown that appeared
  due to changes in revision 72 (ie. making cameras into entities, moving
  screen filtering functions into the cameras, updating the engine to work with
  the new system) but decided to just re-add them all anyway. I will just
  attempt to optimize the code and search for slowdown as I can.
- >
  In an attempt to speed things up, I tried creating separate rect constructors
  for each of the different ways of creating a rect (from a pair, from a quad,
  from a pair of pairs, etc.).
- >
  The optimizations for access to the `pos` and `size` rect attributes was
  removed to make things easier. (All attributes should behave the same as
  before, but now the access speeds are all slightly different.)
- >
  A few of the calls to the default rect constructors have been replaced with
  calls to the new, optimized constructors. (Little improvement has resulted,
  but I will keep puting more in.)

74. By Bradley Harms on 2011-01-08

- >
  Reverted to 71; will continue by re-implementing changes made in 72 and the
  few remaining changes from 60

73. By Bradley Harms on 2011-01-08

- >
  Reverted to 71; will continue by re-implementing changes made in 72 and the
  few remaining changes from 60

72. By Bradley Harms on 2011-01-08

- >
  My bad; the last revision actually did not contain the changes stated.
  This one does.
- >
  There has been another sudden inexplicable drop in speed, though not quite as
  bad as last time. Profiling data is again illusive, but I have a feeling the
  problem is somehow related to the fact that Cameras are again a type of
  entity.

71. By Bradley Harms on 2011-01-08

Re-application of rev.60 changes for `entity.camera`, `engine`, and `res`