Hello,
below I outline a way to add extra functionality such as more blending
modes, rotation etc. I also show a way to allow user plugin blitters.
-
Adding extra functionality to the current api.
-
Plugin blitters.
-
On rotation.
-
Using SDL_gfx.
-
Adding extra functionality to the current api.
By adding a bunch of extra flags to the blit/surfaces you can add extra
functionality fairly easily to the current api.
extra_info {
/* eg. BLEND_ADD, BLEND_MULT, FLIP, ROTATE, ROTOZOOM etc. */
unsigned int info_type;
/* info_data will contain what is needed for the type */
void * info_data;
}
Add an extra information field which can have types for the different flags
used. So for flip flags it can store how it wants to flip. For rotate it
can store the angle and axis to rotate on, for rotozoom it can store the
angle+scale.
Below is a way I’ve been thinking of using for the new pygame.
eg.
extra_info = [[BLEND_ADD]]
Surface.blit(source, dest, area, extra_info)
extra_info = [[FLIP, axis]]
Surface.blit(source, dest, area, FLIP, extra_info)
both flip, and add together.
extra_info = [[BLEND_ADD], [FLIP, axis]]
Surface.blit(source, dest, area, extra_info)
That works fine for the current SDL api, and can be used fairly easily with
opengl and other apis.
The idea is to allow adding extra blitters, and properties. Is there a way
which this could be added now with out affecting the ABI, and API?
- Plugin blitters.
Allowing for plugin blitters would be cool. eg. I could add a specialised
blitter which does not draw the color orange, or a blitter which uses opengl
to draw with a shader, or a blitter which checks the temperature first
before colorising the image blue or red. Or whatever wacky things people
want to do with their game.
People already have written lots of different specialised blitters, as well
as generally usable blitters. So it would be good if there was an easy and
consistant way for people to use them, and to share them. If it was the
same way as SDLs blitters are set up that would be the best, so that then
the user only needs to know one api.
You could have a register blitter function… (*1)
NO_ORANGE = SDL_BLIT_EXTRA_USER + 1
register_blitter(NO_ORANGE, draw_no_orange_blitter_function)
Then call it in the normal way.
extra_info = [[NO_ORANGE]]
Surface.blit(source, dest, area, extra_info)
The plugin blitters could be for opengl, direct3d, software, a shading
language… whatever. The blitter just needs to figure out if it can work
ok.
Each blitter function would be responsible for getting the information it
requires out of the extra_info structure. So BLEND_ADD, and NO_ORANGE might
not need any extra data. However a ROTATE, and ROTOZOOM would need extra
information.
(*1) note that the registering IDs part should probably be similar to
however the new user event api is. So that plugin blitters can be reused
between applications/libraries and for consistency.
- On rotation.
One other thing… rotation in software is highly possible, and there is
code for it already done. The SDL_gfx rotozoom stuff has been used by some
games which run acceptably.
So I think that rotation should be included in the base api, since rotation
does run fast enough for some uses. Also you can cache the rotated images
which can give you even more speed. Note that the SDL_gfx code is only C
for it’s scaling stuff… an mmx/sse version should be able to speed it up
even more.
- Using SDL_gfx
I think SDL_gfx has a lot of functionality already for a lot of what is
being proposed. Perhaps the api might need changing, and some bugs fixed.
However a lot of the functionality is already there.
I think the way I have described can be added to the current SDL api, and
also be used by a SDL 1.3+/2.0 future api. The code is already there to do
it with SDL_gfx, and it would require minor changes. Allowing plugin
blitters would allow more people to use, and contribute their specialised
blitters.
There are most definitely improvements that could be made to the proposal,
especially about the ID numbers for the plugin blitters so it could be
consistant with the new event api. I think this way can be added without
breaking backwards API, and ABI… but I’m not sure.
Cheers,