| 80
|
|
- >
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.
|
Bradley Harms |
13 years ago
|
 |
|
| 79
|
|
|
Bradley Harms |
13 years ago
|
|
|
| 78
|
|
|
Bradley Harms |
13 years ago
|
|
|
| 77
|
|
- >
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.
|
Bradley Harms |
13 years ago
|
|
|
| 76
|
|
|
Bradley Harms |
13 years ago
|
|
|
| 75
|
|
|
Bradley Harms |
13 years ago
|
|
|
| 74
|
|
|
Bradley Harms |
13 years ago
|
|
|
| 73
|
|
|
Bradley Harms |
13 years ago
|
|
|
| 72
|
|
|
Bradley Harms |
13 years ago
|
|
|
| 71
|
|
|
Bradley Harms |
13 years ago
|
|
|
| 70
|
|
I've made some headway on the speed issue. The slowdown was caused by the way
the tilemaps's draw method was written: One of the things the draw method did
was to determine the region of cells in the tilemap's array that corresponded
to the pixel area passed to the draw method. (This area is referred to as the
"grid area".) Each of the cells contained in the tilemap's "dirty cells" set
was tested to see if it was contained in the grid area using the
`Rect.collidepoint` method, and if so, the corresponding part of the tilemap's
internal surface was updated and the cell was removed from the dirty cells set.
However, the dirty cells set contains values corresponding to every single cell
in the entire tilemap, not just the ones in the grid area determined in the draw
method. This meant that the draw method was comparing every single cell in the
dirty cell set to the grid area for every single draw, but only the ones in the
grid area actually got refreshed and thus removed from the dirty cell set.
Naturally, this left the majority of the cell positions in the set, creating a
lot of extra work for the loop unecessarily.
The strange thing is that as far as I know, this is the way the draw method has
worked for a very long time, yet it was not until revision 66 that it actually
started causing noticable problems. I'm not sure what to make of this.
In any case, the problem has been solved fairly well by replacing the loop in
the draw method with a pair of loops that together check for dirty cells only in
the part of the tilemap that is actually being drawn rather than all over the
tilemap. It is now easy to acheive framerates as high as 78 FPS, a great
advantage over the previous 30 FPS. (This measurement was taken on a 64-bit
Athlon 2 X4 quad core CPU at 800 MHz per core.)
|
Bradley Harms |
13 years ago
|
|
|
| 69
|
|
|
Bradley Harms |
13 years ago
|
|
|
| 68
|
|
|
Bradley Harms |
13 years ago
|
|
|
| 67
|
|
#Beginning to re-implement the changes to entities that were made in rev. 60.
---
- BUG - Currently, tilemaps do not appear to be getting drawn.
- BUG - The framerate has dropped to half of its usual speed.
- >
Rect is now boolean false if either width or height is 0. (Previously it was
only false if BOTH width AND height were 0.) This is more consistent with the
Pygame rect and meets some of the assumptions that were being made by other
parts of the library, which should hopefully fix some bugs here and there.
- >
Functionality for the Actor class has been broken up into several mixin
classes. Classes that previously inherited Actor now inherit only the mixins
that implement functionality that the classes actually need.
- >
New mixin class `entity.actor.SimpleGeometryMixin`, which provides basic
geometry and collision detection that is common to many types of entities.
This includes the `rect`, `pos`, and `size` attributes, the
`collide_outside_*` methods, and a new attribute called `oldrect`.
- >
New mixin class `entity.actor.AnimatedMixin`. This is actually the
`apglib.image.AnimatedSprite` class modified to be used as an entity mixin,
which is sort of how it was being used already. Now, however, it no longer
inherits from `pygame.sprite.Sprite`, and some non-essential parts have been
removed.
- >
New mixin class `entity.actor.SpriteWrapperMixin`, which allows an
entity to be used in Pygame sprite groups without other sprite behavior
getting in the way.
- >
The method `visible_collide_rect` that was present in several entities has
been renamed to `get_visible_rect`, and its behavior has been changed such
that it now returns the area of the entity that is visible (or None or a
"null rect" if nothing is visible) instead of returning just a boolean.
- >
The set of entity interfaces that were defined in `apglib.entity` have
been redone. Some new one have been added. Their names should hopefully
explain their purpose well enough; if not, check their documentation:
IMinimalEntity, ISolidEntity, IVisibleEntity, ICameraSource, IWorld
- >
The long-standing `hidden` flag that was present for entities has been
replaced with the more intuitive `visible` flag. Its meaning is the exact
opposite of the `hidden` flag: When `visible` is set, the entity is drawn by
its containing world. When it is clear, the entity is not drawn by its
containing world.
- >
Found a problem in the World class's point collision detection that was
causing the list returned to be filled partially with collders and
partially with (collider, innerpoint) pairs. This was revealing itself in
the form of odd behavior in the "OK" and "Cancel" buttons of the sandbox,
wherein one of the buttons being clicked would cause the other one to
change to its clicked (WST_ACTIVE) state as well.
|
Bradley Harms |
13 years ago
|
|
|
| 66
|
|
|
Bradley Harms |
13 years ago
|
|
|
| 65
|
|
|
Bradley Harms |
13 years ago
|
|
|
| 64
|
|
|
Bradley Harms |
13 years ago
|
|
|
| 63
|
|
|
Bradley Harms |
13 years ago
|
|
|
| 62
|
|
|
Bradley Harms |
13 years ago
|
|
|
| 61
|
|
|
Bradley Harms |
13 years ago
|
|
|
collapse all