Thanks everyone, all good points about converting surfaces, pre-rendering maps, slowness of python interpreter, etc. The core issue is exposing some of SDL's more lower level, less forgiving API, for platforms/projects that might [theoretically] benefit from it. For the record, all of my surfaces are created with pygame.SRCALPHA or loaded and transformed with Surface.convert_alpha(). Please, no suggestions about not using the alpha channel, as it is important. I am merely stating that I have already taken care of matching pixel formats.
jcupitt, warnings are only useful for teaching, not for performance (still, might be a nice addition to pygame...fire warnings at the developer until they fix it :). Peter, the project that I am working on is here: https://github.com/bitcraft/pyscroll/blob/master/pyscroll/orthographic.py. It is an "adaptive tile refresh" tile map renderer. Matti, your RenderSurface idea is similar to what I am doing... A big surface that can be rendered iteratively with tiles.d For what it is worth, I have begun to crudely patch in support for a lower level access to SDL 1.2's blitting functions, strictly as a proof of concept. No guarantees on correctness, as I have not used C since high school, and never studied the cpython API. I'll keep the list posted. On Mon, Mar 14, 2016 at 9:52 AM, bw <stabbingfin...@gmail.com> wrote: > The request for SDL_LowerBlit makes sense to me if it opens an alternative > avenue to optimize a game's renderer that works better on an under-powered > platform. Some checks done in advance do not have to be recalculated > repeatedly. > > That pygame, by its compiled nature, limits extensibility has been a > tradeoff that sometimes I have not appreciated, though I understand and > agree with why it had to be this way. Not a criticism, but a critique that > I think is apt for this discussion. > > Gumm > > > On 3/13/2016 2:06 PM, Leif Theden wrote: > > Heh, hostility is fun, right? I am not a C programmer, please pay > attention. I have used colorkey, but that is not a straightforward way to > increase speed. Since it involves a check on each pixel, some images may > not benefit (and in fact will lower performance) if there isn't much > transparency. Wheras a 'blit' on matched pixel format surfaces can be a > simple memory copy operation, depending on the platform. > > To illustrate a use case for an "unsafe blit": In tile map drawing, you > will be doing potentially hundreds of blit operations. Since tile > placement is very straightforward, you can be sure there will be no > out-of-bounds blitting. You can enforce pixel formats when the surfaces > are loaded. So, format checks are only needed when surfaces are loaded, > not every time there is a blit operation. (Also, this is just one > potential scenario, please don't elaborate on different way to render a > tile-based map, just stick to the topic: "unsafe/fast blit") > > As is, the 'blit' operation removes several chances for error, especially > for people who don't care to convert surfaces or set clipping regions, but > it does so at a performance cost. > > It could be as simple as making the following function available to > pygame, perhaps in some inconspicuous place, not a part of the surface > class...in order to discourage abuse: > <https://wiki.libsdl.org/SDL_LowerBlit> > https://wiki.libsdl.org/SDL_LowerBlit > > On Sun, Mar 13, 2016 at 3:10 PM, <mspaintmaes...@gmail.com> > mspaintmaes...@gmail.com <mspaintmaes...@gmail.com> wrote: > >> I don't think this is a trolling scheme. Since OP said this would >> "obviously cause graphical errors" if the input was bad, I don't think they >> are going to be surprised and then file a bug. Also, non-C programmers are >> programmers, too :P >> >> Since a hypothetical "fast_blit" (or possibly "unsafe_blit") requires the >> user to make sure all the formats are the same, bounds are checked, etc >> ANYWAY, the overhead of normal blit's rule-enforcement would basically be a >> no-op, ergo normal blit is the same as fast_blit if used with the proper >> inputs. Are you familiar with color_key? If you're using blits with >> per-pixel alpha and you don't need translucency, switching to color-key >> usually gives a noticeable performance boost such that any rendering code >> slowness is dwarfed by non-rendering code. >> >> On Sun, Mar 13, 2016 at 12:18 PM, Martti Kühne < <mysat...@gmail.com> >> mysat...@gmail.com> wrote: >> >>> So you're not a programmer but you want a fast method that potentially >>> delivers surprising results because you don't want to care about the >>> pixel format? >>> >>> I'm starting to suspect an elaborate trolling scheme here. Are you >>> planning to file a bug about the surprising results then, already? >>> >>> cheers! >>> mar77i >>> >> >> > >
