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:
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_LowerBlitHeh, 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.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.
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")
On Sun, Mar 13, 2016 at 3:10 PM, mspaintmaestro@xxxxxxxxx <mspaintmaestro@xxxxxxxxx> 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 :PSince 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 <mysatyre@xxxxxxxxx> 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