josch wrote: > On Dec 2, 4:12 pm, "Luke Paireepinart" <[EMAIL PROTECTED]> wrote: > >> Is it too late to add widescreen support? This looks really cool >> (I've never played the game though) but 4x3 on a 16x10 monitor doesn't >> look very attractive :) >> > > well this thread is not supposed to be about what i already can do but > rather about what the engine still severely lacks: performance. > > but one of the current feature is that you can freely resize the > window to EVERY resolution possible - so whatever native resolution > you have it will work fullscreen and still look good. > > today i also just tried out to render all the stuff with rabbyt but > afaik it lacks vertex buffer objects and does all gl calls on EVERY > sprite draw - so with 10k draws i'm back to below 20fps again even > though the calls itself are much faster. maybe the native gl calls > rabbyt does in contrast to slow ctype calls of pyglet will save me > with my issues but then again i'm lost without having vertex lists for > as little gl calls as possible. any ideas? > > > You might consider making the current code more efficient by reducing the number of static values that are recomputed on every update cycle. For example, on every move operation you calculate (in _move):
self.tile_size * self.mapset.width - self.vp_width which as far as I can work out shouldn't be changing necessarily with every movement (I could be wrong - I just glanced at the code). Again, in the update method, called 60 times a sec, you calculate: (self.tile_size-32) ((self.tile_size-32)*3) on every call, which are probably static values in most cases. Also, I don't know how often you update your vertex lists, but the following initialisation code: vertices = [[] for value in self.mapset.groups] tex_coords = [[] for value in self.mapset.groups] count = [0 for value in self.mapset.groups] allocates memory on every call to update_vertex_lists. If this function is called frequently, it would me more efficient and faster to keep those lists in memory (i.e. persistent), and clear their contents when needed and thus avoid the slower option of repetitive memory allocation. It's also not the best way to allocate an empty list: ngroups = len(self.mapset.groups) vertices = [[]] * len(self.mapset.groups) tex_coords = [[]] * len(self.mapset.groups) count = [0] * len(self.mapset.groups) would probably be faster as it avoids accessing the individual values of self.mapset.groups. If the number of groups changes frequently, then it's still probably more efficient to make the lists large enough to handle the maximum likely number of values, but make the allocation once at the start of the program. You might also want to look into Cython or Pyrex to optimise parts of the code that are called often. By being careful about memory allocation/deallocation, I have gotten extremely large speed increases using Pyrex for functions called many times a second. It's possible to write very efficient code in Python, in terms of execution speed, but with code that is looped at high frequency, even the smallest increase in per-cycle computations can lead to much slower performance. If in doubt, search the python mailing list and google - there is quite a bit of info about which operations are more memory efficient or which result in new memory being allocated. It's may be that your performance is suffering more from these kind of issues rather than from the ctypes calls. P. ** --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "pyglet-users" group. To post to this group, send email to pyglet-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pyglet-users?hl=en -~----------~----~----~----~------~----~------~--~---
