Files
SDL/src/render/software/SDL_render_sw.c

1191 lines
43 KiB
C
Raw Normal View History

/*
Simple DirectMedia Layer
2023-01-09 09:41:41 -08:00
Copyright (C) 1997-2023 Sam Lantinga <slouken@libsdl.org>
This software is provided 'as-is', without any express or implied
warranty. In no event will the authors be held liable for any damages
arising from the use of this software.
Permission is granted to anyone to use this software for any purpose,
including commercial applications, and to alter it and redistribute it
freely, subject to the following restrictions:
1. The origin of this software must not be misrepresented; you must not
claim that you wrote the original software. If you use this software
in a product, an acknowledgment in the product documentation would be
appreciated but is not required.
2. Altered source versions must be plainly marked as such, and must not be
misrepresented as being the original software.
3. This notice may not be removed or altered from any source distribution.
*/
#include "SDL_internal.h"
Fix uses of undefined macro identifiers (-Wundef) * Fix -Wundef warnings due to use of unguarded SDL_LOADSO_DISABLED * Fix -Wundef warnings due to use of unguarded SDL_VIDEO_DRIVER_WINDOWS * Fix -Wundef warnings due to use of unguarded SDL_VIDEO_DRIVER_ANDROID * Fix -Wundef warnings due to use of unguarded SDL_LOADSO_DUMMY * Fix -Wundef warnings due to use of unguarded SDL_VIDEO_DRIVER_COCOA * Fix -Wundef warnings due to use of unguarded SDL_VIDEO_DRIVER_UIKIT * Fix -Wundef warnings due to use of unguarded SDL_TIMERS_DISABLED * Fix -Wundef warnings due to use of unguarded SDL_EVENTS_DISABLED * Fix -Wundef warnings due to use of unguarded SDL_TIMER_DUMMY * Fix -Wundef warnings due to use of unguarded SDL_VIDEO_DISABLED * Fix -Wundef warnings due to use of unguarded SDL_AUDIO_DISABLED * Fix -Wundef warnings due to use of unguarded SDL_JOYSTICK_DISABLED * Fix -Wundef warnings due to use of unguarded SDL_HAPTIC_DISABLED * Fix -Wundef warnings due to use of unguarded SDL_SENSOR_DISABLED * Fix -Wundef warnings due to use of unguarded __ANDROID__ * Fix -Wundef warnings due to use of unguarded __IOS__ * Fix -Wundef warnings due to use of unguarded EMULATE_CAS * Fix -Wundef warnings due to use of unguarded SDL_ATOMIC_DISABLED * Fix -Wundef warnings due to use of unguarded SDL_THREADS_DISABLED * Fix -Wundef warnings due to use of unguarded SDL_AUDIO_DRIVER_SNDIO * Fix -Wundef warnings due to use of unguarded SDL_AUDIO_DRIVER_NETBSD * Fix -Wundef warnings due to use of unguarded SDL_AUDIO_DRIVER_WASAPI * Fix -Wundef warnings due to use of unguarded SDL_AUDIO_DRIVER_DSOUND * Fix -Wundef warnings due to use of unguarded SDL_AUDIO_DRIVER_HAIKU * Fix -Wundef warnings due to use of unguarded SDL_AUDIO_DRIVER_COREAUDIO * Fix -Wundef warnings due to use of unguarded SDL_AUDIO_DRIVER_AAUDIO * Fix -Wundef warnings due to use of unguarded SDL_AUDIO_DRIVER_OPENSLES * Fix -Wundef warnings due to use of unguarded SDL_AUDIO_DRIVER_ANDROID * Fix -Wundef warnings due to use of unguarded SDL_AUDIO_DRIVER_PS2 * Fix -Wundef warnings due to use of unguarded SDL_AUDIO_DRIVER_PSP * Fix -Wundef warnings due to use of unguarded SDL_AUDIO_DRIVER_VITA * Fix -Wundef warnings due to use of unguarded SDL_AUDIO_DRIVER_N3DS * Fix -Wundef warnings due to use of unguarded SDL_AUDIO_DRIVER_EMSCRIPTEN * Fix -Wundef warnings due to use of unguarded SDL_NEON_INTRINSICS * Fix -Wundef warnings due to use of unguarded SDL_ALTIVEC_BLITTERS * Fix -Wundef warnings due to use of unguarded __VITA__ * Fix -Wundef warnings due to use of unguarded __3DS__ * Fix -Wundef warnings due to use of unguarded SDL_DYNAPI_PROC_NO_VARARGS * Fix -Wundef warnings due to use of unguarded __APPLE__ * Fix -Wundef warnings due to use of unguarded __WINRT__ * Fix -Wundef warnings due to use of unguarded SDL_HIDAPI_DISABLED * Fix -Wundef warnings due to use of unguarded __TVOS__ * Fix -Wundef warnings due to use of unguarded HAVE_DRIVER_BACKEND * Fix -Wundef warnings due to use of unguarded SDL_JOYSTICK_XINPUT * Fix -Wundef warnings due to use of unguarded SDL_JOYSTICK_WGI * Fix -Wundef warnings due to use of unguarded SDL_JOYSTICK_DINPUT * Fix -Wundef warnings due to use of unguarded SDL_JOYSTICK_MFI * Fix -Wundef warnings due to use of unguarded SDL_JOYSTICK_EMSCRIPTEN * Fix -Wundef warnings due to use of unguarded SDL_JOYSTICK_PS2 * Fix -Wundef warnings due to use of unguarded SDL_JOYSTICK_PSP * Fix -Wundef warnings due to use of unguarded SDL_JOYSTICK_VITA * Fix -Wundef warnings due to use of unguarded SDL_JOYSTICK_N3DS * Fix -Wundef warnings due to use of unguarded __MACOS__ * Fix -Wundef warnings due to use of unguarded SDL_VIDEO_RENDER_D3D * Fix -Wundef warnings due to use of unguarded SDL_VIDEO_DRIVER_WINRT * Fix -Wundef warnings due to use of unguarded SDL_VIDEO_DRIVER_RPI * Fix -Wundef warnings due to use of unguarded SDL_VIDEO_VITA_PVR_OGL * Fix -Wundef warnings due to use of unguarded SDL_VIDEO_DRIVER_VIVANTE * Fix -Wundef warnings due to use of unguarded SDL_VIDEO_RENDER_D3D11 * Fix -Wundef warnings due to use of unguarded SDL_VIDEO_RENDER_D3D12 * Fix -Wundef warnings due to use of unguarded SDL_RENDER_DISABLED * Fix -Wundef warnings due to use of unguarded SDL_VIDEO_RENDER_METAL * Fix -Wundef warnings due to use of unguarded SDL_VIDEO_RENDER_PS2 * Fix -Wundef warnings due to use of unguarded SDL_VIDEO_RENDER_PSP * Fix -Wundef warnings due to use of unguarded SDL_VIDEO_RENDER_VITA_GXM * Fix -Wundef warnings due to use of unguarded SDL_ARM_SIMD_BLITTERS * Fix -Wundef warnings due to use of unguarded SDL_ARM_NEON_BLITTERS * Fix -Wundef warnings due to use of unguarded SDL_VIDEO_DRIVER_HAIKU * Fix -Wundef warnings due to use of unguarded SDL_VIDEO_DRIVER_PS2 * Fix -Wundef warnings due to use of unguarded SDL_VIDEO_DRIVER_PSP * Fix -Wundef warnings due to use of unguarded SDL_VIDEO_DRIVER_VITA * Fix -Wundef warnings due to use of unguarded SDL_VIDEO_DRIVER_N3DS * Fix -Wundef warnings due to use of unguarded SDL_VIDEO_DRIVER_KMSDRM * Fix -Wundef warnings due to use of unguarded SDL_VIDEO_DRIVER_RISCOS * Fix -Wundef warnings due to use of unguarded SDL_VIDEO_DRIVER_EMSCRIPTEN * Fix -Wundef warnings due to use of unguarded SDL_VIDEO_DRIVER_NGAGE * Fix -Wundef warnings due to use of unguarded SDL_VIDEO_METAL * Fix -Wundef warnings due to use of unguarded SDL_LSX_INTRINSICS * Fix -Wundef warnings due to use of unguarded HAVE_PTHREAD_NP_H * Fix -Wundef warnings due to use of unguarded __RISCOS__ * Fix -Wundef warnings due to use of unguarded FAKE_RECURSIVE_MUTEX * Fix -Wundef warnings due to use of unguarded USE_POSIX_SPAWN * textureData is only needed when SDL is built with YUV support * Fix -Wundef warnings due to use of unguarded SDL_AUDIO_DRIVER_ALSA * Fix -Wundef warnings due to use of unguarded SDL_SSE3_INTRINSICS * Fix -Wundef warnings due to use of unguarded SDL_SSE4_2_INTRINSICS * Fix -Wundef warnings due to use of unguarded SDL_SSE4_1_INTRINSICS * Fix -Wundef warnings due to use of unguarded SDL_AVX512F_INTRINSICS * Fix -Wundef warnings due to use of unguarded SDL_SSE2_INTRINSICS * Fix -Wundef warnings due to use of unguarded SDL_AVX_INTRINSICS * Fix -Wundef warnings due to use of unguarded SDL_AVX2_INTRINSICS * Fix -Wundef warnings due to use of unguarded SDL_SSE_INTRINSICS * Fix -Wundef warnings due to use of unguarded SDL_MMX_INTRINSICS * Fix -Wundef warnings due to use of unguarded HAVE_CLOCK_GETTIME * Fix -Wundef warnings due to use of unguarded SDL_AUDIO_DRIVER_DISK * Fix -Wundef warnings due to use of unguarded SDL_AUDIO_DRIVER_DUMMY * Fix -Wundef warnings due to use of unguarded SDL_VIDEO_DRIVER_DUMMY * Fix -Wundef warnings due to use of unguarded HAVE_GCC_ATOMICS * Fix -Wundef warnings due to use of unguarded HAVE_GCC_SYNC_LOCK_TEST_AND_SET * Fix -Wundef warnings due to use of unguarded SDL_USE_LIBDBUS * Fix -Wundef warnings due to use of unguarded SDL_AUDIO_DRIVER_JACK * Fix -Wundef warnings due to use of unguarded SDL_JOYSTICK_VIRTUAL * Fix -Wundef warnings due to use of unguarded SDL_JOYSTICK_LINUX * Fix -Wundef warnings due to use of unguarded HAVE_LIBC * Fix -Wundef warnings due to disabling SDL_LIBC * Fix -Wundef warnings due to use of unguarded HAVE_PLATFORM_BACKEND * Fix -Wundef warnings due to use of unguarded DEBUG * Fix -Wundef warnings due to use of unguarded HAVE_LINUX_INPUT_H * Fix -Werror=unused-variable when building with SDL_LIBC=OFF * Fix -Wundef warnings due to use of unguqrded SDL_USE_LIBUDEV * Use SDL alloc functions in libusb/hid.c * Fix -Wundef warnings due to use of unguarded HAVE_LIBUDEV_H * Fix -Wundef warnings due to use of unguarded SDL_VIDEO_VULKAN * Fix -Wundef warnings due to use of unguarded SDL_VIDEO_DRIVER_OFFSCREEN * Fix -Wundef warnings due to use of unguarded SDL_VIDEO_RENDER_OGL * Fix -Wundef warnings due to use of unguarded SDL_VIDEO_OPENGL * Fix -Wundef warnings due to use of unguarded SDL_VIDEO_OPENGL_GLX * Fix -Wundef warnings due to use of unguarded SDL_VIDEO_OPENGL_ES * Fix -Wundef warnings due to use of unguarded SDL_VIDEO_OPENGL_ES2 * Fix -Wundef warnings due to use of unguarded SDL_VIDEO_RENDER_OGL_ES2 * Fix -Wundef warnings due to use of unguarded SDL_AUDIO_DRIVER_OSS * Remove SDL_AUDIO_DRIVER_SUNAUDIO reference since it is never set * Fix -Wundef warnings due to use of unguarded SDL_AUDIO_DRIVER_PIPEWIRE * Fix -Wundef warnings due to use of unguarded SDL_AUDIO_DRIVER_PULSEAUDIO * Fix -Wundef warnings due to use of unguarded SDL_VIDEO_DRIVER_X11_XCURSOR * Fix -Wundef warnings due to use of unguarded SDL_VIDEO_DRIVER_X11_XDBE * Fix -Wundef warnings due to use of unguarded SDL_VIDEO_DRIVER_X11_XFIXES * Fix -Wundef warnings due to use of unguarded SDL_VIDEO_DRIVER_X11_XINPUT2 * Fix -Wundef warnings due to use of unguarded #if SDL_VIDEO_DRIVER_X11_XINPUT2_SUPPORTS_MULTITOUCH * Fix -Wundef warnings due to use of unguarded #if SDL_VIDEO_DRIVER_X11_XRANDR * Fix -Wundef warnings due to use of unguarded #if SDL_VIDEO_DRIVER_X11_XSCRNSAVER * Fix -Wundef warnings due to use of unguarded SDL_VIDEO_DRIVER_X11_XSHAPE * Don't call XShape functions when XShape is diabled * Fix -Wundef warnings due to use of unguarded SDL_VIDEO_DRIVER_WAYLAND * Fix -Wundef warnings due to use of unuarded SDL_VIDEO_DRIVER_X11 * Fix -Wundef warnings due to use of unguarded SDL_VIDEO_DRIVER_RISCOS * Fix -Wundef warnings due to use of unguarded SDL_VIDEO_OPENGL_EGL * Disable array when compiled with SDL_EVENTS=OFF * Fix -Wundef warnings due to use of unguarded SDL_INPUT_LINUXEV * Fix -Wundef warnings due to use of unguarded SDL_THREAD_PTHREAD * Fix -Wundef warnings due to use of unguarded SDL_THREAD_WINDOWS * Fix -Wundef warnings due to use of unguarded SDL_THREAD_PS2 * Fix -Wundef warnings due to use of unguarded SDL_THREAD_PSP * Fix -Wundef warnings due to use of unguarded SDL_THREAD_VITA * Fix -Wundef warnings due to use of unguarded SDL_THREAD_N3DS * Fix -Wundef warnings due to use of unguarded SDL_THREAD_STDCPP * Fix -Wundef warnings due to use of unguarded SDL_THREAD_NGAGE * Fix -Wundef warnings due to use of unguarded __WINDOWS__ * Fix -Wundef warnings due to use of unguarded __WINGDK__ * Fix -Wundef warnings due to use of unguarded __ANDROID__ * Fix -Wundef warnings due to use of unguarded SDL_THREAD_GENERIC_COND_SUFFIX * Fix -Wundef warnings due to use of unguarded SDL_VIDEO_VITA_PIB * Fix -Wundef warnings due to use of unguarded SDL_VIDEO_VITA_PVR * Fix -Wundef warnings due to use of unguarded SDL_FILE_DISABLED * Fix -Wundef warnings due to use of unguarded __XBOXONE__ * Fix -Wundef warnings due to use of unguarded __XBOXSERIES__ * Fix -Wundef warnings due to use of unguarded SDL_VIDEO_OPENGL_WGL * Fix -Wundef warnings due to use of unguarded SDL_AUDIO_DRIVER_QNX * Fix -Wundef warnings due to use of unguarded SDL_AUDIO_DRIVER_DISK * Fix -Wundef warnings due to use of unguarded SDL_VIDEO_DRIVER_QNX * Fix -Wundef warnings due to use of unguarded DEBUG_RAZOR * Fix -Wundef warnings due to use of unguarded WINAPI_FAMILY_PHONE_APP * Fix -Wundef warnings due to use of unguarded SDL_MAC_NO_SANDBOX * Fix -Wundef warnings due to use of unguarded __(IPHONE|APPLETV|MAC)_OS_VERSION_MAX_ALLOWED * Fix C4090 warning ('function': different 'const' qualifiers) * ci: use -isystem for include dirs of pspdev toolchain * cmake: add -Wundef option * Fix remaining -Wundef warnings due to use of unguarded SDL_VIDEO_VULKAN and SDL_VIDEO_METAL * Fix -Wundef warnings due to use of unguarded __MACOS__ * DEBUG_CONVERT is guaranteed to be defined in src/audio/SDL_audiocvt.c * Fix -Wundef warnings due to use of unguarded HAVE_NANOSLEEP * Fix -Wundef warnings due to use of unguarded HAVE_DXGI_H * Fix -Wundef warnings due to use of unguarded HAVE_LINUX_INPUT_H * fix SDL_VIDEO_DRIVER_WAYLAND * fix SDL_VIDEO_DRIVER_X11 * Fix -Wundef warnings due to use of unguarded HAVE_MMDEVICEAPI_H * Fix -Wundef warnings due to use of unguarded HAVE_PTHREAD_SETNAME_NP * Fix -Wundef warnings due to use of unguarded HAVE_PTHREAD_SET_NAME_NP * Fix -Wundef warnings due to use of unguarded HAVE_SETJMP * Fix -Wundef warnings due to use of unguarded HAVE_SIGNAL_H * Fix -Wundef warnings due to use of unguarded HAVE_TPCSHRD_H * Fix -Wundef warnings due to use of unguarded MACOSX_COREAUDIO * Fix -Wundef warnings due to use of unguarded SDL_HAPTIC_DINPUT * Fix -Wundef warnings due to use of unguarded SDL_HAPTIC_IOKIT * Fix -Wundef warnings due to use of unguarded SDL_HAPTIC_XINPUT * Fix -Wundef warnings due to use of unguarded SDL_IPHONE_KEYBOARD * Fix -Wundef warnings due to use of unguarded SDL_JOYSTICK_RAWINPUT * Fix -Wundef warnings due to use of unguarded SDL_POWER_ANDROID * Fix -Wundef warnings due to use of unguarded SDL_POWER_EMSCRIPTEN * Fix -Wundef warnings due to use of unguarded SDL_POWER_HAIKU * Fix -Wundef warnings due to use of unguarded SDL_POWER_LINUX * Fix -Wundef warnings due to use of unguarded SDL_POWER_MACOSX * Fix -Wundef warnings due to use of unguarded SDL_POWER_PSP * Fix -Wundef warnings due to use of unguarded SDL_POWER_UIKIT * Fix -Wundef warnings due to use of unguarded SDL_POWER_VITA * Fix -Wundef warnings due to use of unguarded SDL_POWER_WINDOWS * Fix -Wundef warnings due to use of unguarded SDL_THREAD_PTHREAD_RECURSIVE_MUTEX * Fix -Wundef warnings due to use of unguarded SDL_THREAD_PTHREAD_RECURSIVE_MUTEX_NP * Fix -Wundef warnings due to use of unguarded SDL_VIDEO_DRIVER_VIVANTE_VDK * Fix -Wundef warnings due to use of unguarded SDL_VIDEO_DRIVER_WAYLAND * Fix -Wundef warnings due to use of unguarded SDL_VIDEO_DRIVER_X11_HAS_XKBKEYCODETOKEYSYM * Fix -Wundef warnings due to use of unguarded SDL_VIDEO_DRIVER_X11_SUPPORTS_GENERIC_EVENTS * Fix -Wundef warnings due to use of unguarded SDL_VIDEO_OPENGL_CGL * Fix -Wundef warnings due to use of unguarded SDL_VIDEO_OPENGL_EGL * Fix -Wundef warnings due to use of unguarded __MACOS__ * Fix -Wundef warnings due to use of unguarded __OpenBSD__ * Fix -Wundef warnings due to use of unguarded __FreeBSD__ * Fix -Wundef warnings due to use of unguarded __MWERKS__ * Fix -Wundef warnings due to use of unguarded __WIN32__ * Fix -Wundef warnings due to use of unguarded SDL_IPHONE_LAUNCHSCREEN * Fix -Wundef warnings due to use of unguarded SDL_VIDEO_OPENGL_ES2 * Remove unused HAVE_CONST, HAVE_INLINE and HAVE_VOLATILE * Revert "Use SDL alloc functions in libusb/hid.c" This reverts commit 847c64b00da12ca08bef9e947eb948e378eeaef8. * Handle FAKE_RECURSIVE_MUTEX in similar way as SDL2 * Don't use defined in macro
2023-03-29 21:49:01 +00:00
#if SDL_VIDEO_RENDER_SW && !defined(SDL_RENDER_DISABLED)
#include "../SDL_sysrender.h"
#include "SDL_render_sw_c.h"
#include "SDL_draw.h"
#include "SDL_blendfillrect.h"
#include "SDL_blendline.h"
#include "SDL_blendpoint.h"
#include "SDL_drawline.h"
#include "SDL_drawpoint.h"
#include "SDL_rotate.h"
2021-03-16 15:14:58 +01:00
#include "SDL_triangle.h"
/* SDL surface based renderer implementation */
typedef struct
{
const SDL_Rect *viewport;
const SDL_Rect *cliprect;
SDL_bool surface_cliprect_dirty;
} SW_DrawStateCache;
typedef struct
{
SDL_Surface *surface;
SDL_Surface *window;
} SW_RenderData;
static SDL_Surface *SW_ActivateRenderer(SDL_Renderer *renderer)
{
SW_RenderData *data = (SW_RenderData *)renderer->driverdata;
if (!data->surface) {
data->surface = data->window;
}
if (!data->surface) {
SDL_Surface *surface = SDL_GetWindowSurface(renderer->window);
if (surface) {
data->surface = data->window = surface;
}
}
return data->surface;
}
static void SW_WindowEvent(SDL_Renderer *renderer, const SDL_WindowEvent *event)
{
SW_RenderData *data = (SW_RenderData *)renderer->driverdata;
if (event->type == SDL_EVENT_WINDOW_PIXEL_SIZE_CHANGED) {
data->surface = NULL;
data->window = NULL;
}
}
static int SW_GetOutputSize(SDL_Renderer *renderer, int *w, int *h)
{
SW_RenderData *data = (SW_RenderData *)renderer->driverdata;
if (data->surface) {
if (w) {
*w = data->surface->w;
}
if (h) {
*h = data->surface->h;
}
return 0;
}
if (renderer->window) {
SDL_GetWindowSizeInPixels(renderer->window, w, h);
return 0;
}
return SDL_SetError("Software renderer doesn't have an output surface");
}
static int SW_CreateTexture(SDL_Renderer *renderer, SDL_Texture *texture)
{
SDL_Surface *surface = SDL_CreateSurface(texture->w, texture->h, texture->format);
if (surface == NULL) {
return SDL_SetError("Cannot create surface");
}
texture->driverdata = surface;
SDL_SetSurfaceColorMod(texture->driverdata, texture->color.r, texture->color.g, texture->color.b);
SDL_SetSurfaceAlphaMod(texture->driverdata, texture->color.a);
SDL_SetSurfaceBlendMode(texture->driverdata, texture->blendMode);
Fixed bug 3359 - Software renderer does incorrect blending with SDL_RenderCopyEx Simon Hug The software renderer produces incorrect results when blending textures at an angle with certain blend modes. It seems that there were some edge cases that weren't considered when the SW_RenderCopyEx function was last changed. Or another bug possibly covered up the problem. (More on that in another bug report.) Most of the issues come from the fact that the rotating function sets a black colorkey. This is problematic because black is most likely appearing in the surface and the final blit will ignore these pixels. Unless a colorkey is already set (the software renderer currently never sets one), it's very hard to find a free color. Of course it could scan over the whole image until one is found, but that seems inefficient. The following blend modes have issues when drawn at an angle. NONE: The black pixels get ignored, making them essentially transparent. This breaks the 'dstRGBA = srcRGBA' definition of the NONE blend mode. MOD: Again, the black pixels get ignored. This also breaks the 'dstRGB = dstRGB * srcRGB' definition of the MOD blend mode, where black pixels would make the destination black as well. A white colorkey will work though, with some preparations. BLEND: There are some issues when blending a texture with a translucent RGBA target texture. I - uh - forgot what the problem here exactly is. This patch fixes the issues mentioned above. It mainly changes the code so it tries to do things without the colorkey and removes the automatic format conversion part from the SDLgfx_rotateSurface function. Getting the format right is something the caller has to do now and the required code has been added to the SW_RenderCopyEx function. There's a small change to the SW_CreateTexture function. RLE encoding a surface with an alpha mask can be a lossy process. Depending on how the user uses the RGBA channels, this may be undesired. The change that surfaces with an alpha mask don't get encoded makes the software renderer consistent with the other renderers. The SW_RenderCopyEx function now does these steps: Lock the source surface if necessary. Create a clone of the source by using the pixel buffer directly. Check the format and set a flag if a conversion is necessary. Check if scaling or cropping is necessary and set the flag for that as well. Check if color and alpha modulation has to be done before the rotate. Check if the source is an opaque surface. If not, it creates a mask surface that is necessary for the NONE blend mode. If any of the flags were set, a new surface is created and the source will be converted, scaled, cropped, and modulated. The rest of the function stays somewhat the same. The mask also needs to be rotated of course and then there is the NONE blend mode... It's surprisingly hard to get the pixel from a rotated surface to the destination buffer without affecting the pixel outside the rotated area. I found a way to do this with three blits which is pretty hard on the performance. Perhaps someone has an idea how to do this faster? As mentioned above, the SDLgfx_rotateSurface now only takes 8-bit paletted or 32-bit with alpha mask surfaces. It additionally sets the new surfaces up for the MOD blend mode. I shortly tested the 8-bit path of SDLgfx_rotateSurface and it seemed to work so far. This path is not used by the software renderer anyway.
2016-11-15 01:12:27 -08:00
/* Only RLE encode textures without an alpha channel since the RLE coder
* discards the color values of pixels with an alpha value of zero.
*/
if (texture->access == SDL_TEXTUREACCESS_STATIC && !surface->format->Amask) {
SDL_SetSurfaceRLE(texture->driverdata, 1);
}
if (!texture->driverdata) {
return -1;
}
return 0;
}
static int SW_UpdateTexture(SDL_Renderer *renderer, SDL_Texture *texture,
const SDL_Rect *rect, const void *pixels, int pitch)
{
SDL_Surface *surface = (SDL_Surface *)texture->driverdata;
Uint8 *src, *dst;
int row;
size_t length;
if (SDL_MUSTLOCK(surface)) {
SDL_LockSurface(surface);
}
src = (Uint8 *)pixels;
dst = (Uint8 *)surface->pixels +
rect->y * surface->pitch +
rect->x * surface->format->BytesPerPixel;
2022-12-01 16:07:03 -05:00
length = (size_t)rect->w * surface->format->BytesPerPixel;
for (row = 0; row < rect->h; ++row) {
SDL_memcpy(dst, src, length);
src += pitch;
dst += surface->pitch;
}
if (SDL_MUSTLOCK(surface)) {
SDL_UnlockSurface(surface);
}
return 0;
}
static int SW_LockTexture(SDL_Renderer *renderer, SDL_Texture *texture,
const SDL_Rect *rect, void **pixels, int *pitch)
{
SDL_Surface *surface = (SDL_Surface *)texture->driverdata;
*pixels =
(void *)((Uint8 *)surface->pixels + rect->y * surface->pitch +
rect->x * surface->format->BytesPerPixel);
*pitch = surface->pitch;
return 0;
}
static void SW_UnlockTexture(SDL_Renderer *renderer, SDL_Texture *texture)
{
}
static void SW_SetTextureScaleMode(SDL_Renderer *renderer, SDL_Texture *texture, SDL_ScaleMode scaleMode)
{
}
static int SW_SetRenderTarget(SDL_Renderer *renderer, SDL_Texture *texture)
{
SW_RenderData *data = (SW_RenderData *)renderer->driverdata;
if (texture) {
data->surface = (SDL_Surface *)texture->driverdata;
} else {
data->surface = data->window;
}
return 0;
}
static int SW_QueueSetViewport(SDL_Renderer *renderer, SDL_RenderCommand *cmd)
{
return 0; /* nothing to do in this backend. */
}
static int SW_QueueDrawPoints(SDL_Renderer *renderer, SDL_RenderCommand *cmd, const SDL_FPoint *points, int count)
{
SDL_Point *verts = (SDL_Point *)SDL_AllocateRenderVertices(renderer, count * sizeof(SDL_Point), 0, &cmd->data.draw.first);
2019-03-19 16:52:09 -07:00
int i;
if (verts == NULL) {
return -1;
}
cmd->data.draw.count = count;
for (i = 0; i < count; i++, verts++, points++) {
verts->x = (int)points->x;
verts->y = (int)points->y;
}
return 0;
}
static int SW_QueueFillRects(SDL_Renderer *renderer, SDL_RenderCommand *cmd, const SDL_FRect *rects, int count)
{
SDL_Rect *verts = (SDL_Rect *)SDL_AllocateRenderVertices(renderer, count * sizeof(SDL_Rect), 0, &cmd->data.draw.first);
2019-03-19 16:52:09 -07:00
int i;
if (verts == NULL) {
return -1;
}
cmd->data.draw.count = count;
for (i = 0; i < count; i++, verts++, rects++) {
verts->x = (int)rects->x;
verts->y = (int)rects->y;
verts->w = SDL_max((int)rects->w, 1);
verts->h = SDL_max((int)rects->h, 1);
}
return 0;
}
static int SW_QueueCopy(SDL_Renderer *renderer, SDL_RenderCommand *cmd, SDL_Texture *texture,
const SDL_FRect *srcrect, const SDL_FRect *dstrect)
{
SDL_Rect *verts = (SDL_Rect *)SDL_AllocateRenderVertices(renderer, 2 * sizeof(SDL_Rect), 0, &cmd->data.draw.first);
if (verts == NULL) {
return -1;
}
cmd->data.draw.count = 1;
verts->x = (int)srcrect->x;
verts->y = (int)srcrect->y;
verts->w = (int)srcrect->w;
verts->h = (int)srcrect->h;
verts++;
verts->x = (int)dstrect->x;
verts->y = (int)dstrect->y;
verts->w = (int)dstrect->w;
verts->h = (int)dstrect->h;
return 0;
}
typedef struct CopyExData
{
SDL_Rect srcrect;
SDL_Rect dstrect;
double angle;
SDL_FPoint center;
SDL_RendererFlip flip;
float scale_x;
float scale_y;
} CopyExData;
static int SW_QueueCopyEx(SDL_Renderer *renderer, SDL_RenderCommand *cmd, SDL_Texture *texture,
const SDL_FRect *srcrect, const SDL_FRect *dstrect,
const double angle, const SDL_FPoint *center, const SDL_RendererFlip flip, float scale_x, float scale_y)
{
CopyExData *verts = (CopyExData *)SDL_AllocateRenderVertices(renderer, sizeof(CopyExData), 0, &cmd->data.draw.first);
if (verts == NULL) {
return -1;
}
cmd->data.draw.count = 1;
verts->srcrect.x = (int)srcrect->x;
verts->srcrect.y = (int)srcrect->y;
verts->srcrect.w = (int)srcrect->w;
verts->srcrect.h = (int)srcrect->h;
verts->dstrect.x = (int)dstrect->x;
verts->dstrect.y = (int)dstrect->y;
verts->dstrect.w = (int)dstrect->w;
verts->dstrect.h = (int)dstrect->h;
verts->angle = angle;
SDL_copyp(&verts->center, center);
verts->flip = flip;
verts->scale_x = scale_x;
verts->scale_y = scale_y;
return 0;
}
static int Blit_to_Screen(SDL_Surface *src, SDL_Rect *srcrect, SDL_Surface *surface, SDL_Rect *dstrect,
float scale_x, float scale_y, SDL_ScaleMode scaleMode)
{
int retval;
/* Renderer scaling, if needed */
if (scale_x != 1.0f || scale_y != 1.0f) {
SDL_Rect r;
r.x = (int)((float)dstrect->x * scale_x);
r.y = (int)((float)dstrect->y * scale_y);
r.w = (int)((float)dstrect->w * scale_x);
r.h = (int)((float)dstrect->h * scale_y);
2022-12-27 15:05:51 -08:00
retval = SDL_PrivateBlitSurfaceScaled(src, srcrect, surface, &r, scaleMode);
} else {
retval = SDL_BlitSurface(src, srcrect, surface, dstrect);
}
return retval;
}
static int SW_RenderCopyEx(SDL_Renderer *renderer, SDL_Surface *surface, SDL_Texture *texture,
const SDL_Rect *srcrect, const SDL_Rect *final_rect,
const double angle, const SDL_FPoint *center, const SDL_RendererFlip flip, float scale_x, float scale_y)
{
SDL_Surface *src = (SDL_Surface *)texture->driverdata;
SDL_Rect tmp_rect;
Fixed bug 3359 - Software renderer does incorrect blending with SDL_RenderCopyEx Simon Hug The software renderer produces incorrect results when blending textures at an angle with certain blend modes. It seems that there were some edge cases that weren't considered when the SW_RenderCopyEx function was last changed. Or another bug possibly covered up the problem. (More on that in another bug report.) Most of the issues come from the fact that the rotating function sets a black colorkey. This is problematic because black is most likely appearing in the surface and the final blit will ignore these pixels. Unless a colorkey is already set (the software renderer currently never sets one), it's very hard to find a free color. Of course it could scan over the whole image until one is found, but that seems inefficient. The following blend modes have issues when drawn at an angle. NONE: The black pixels get ignored, making them essentially transparent. This breaks the 'dstRGBA = srcRGBA' definition of the NONE blend mode. MOD: Again, the black pixels get ignored. This also breaks the 'dstRGB = dstRGB * srcRGB' definition of the MOD blend mode, where black pixels would make the destination black as well. A white colorkey will work though, with some preparations. BLEND: There are some issues when blending a texture with a translucent RGBA target texture. I - uh - forgot what the problem here exactly is. This patch fixes the issues mentioned above. It mainly changes the code so it tries to do things without the colorkey and removes the automatic format conversion part from the SDLgfx_rotateSurface function. Getting the format right is something the caller has to do now and the required code has been added to the SW_RenderCopyEx function. There's a small change to the SW_CreateTexture function. RLE encoding a surface with an alpha mask can be a lossy process. Depending on how the user uses the RGBA channels, this may be undesired. The change that surfaces with an alpha mask don't get encoded makes the software renderer consistent with the other renderers. The SW_RenderCopyEx function now does these steps: Lock the source surface if necessary. Create a clone of the source by using the pixel buffer directly. Check the format and set a flag if a conversion is necessary. Check if scaling or cropping is necessary and set the flag for that as well. Check if color and alpha modulation has to be done before the rotate. Check if the source is an opaque surface. If not, it creates a mask surface that is necessary for the NONE blend mode. If any of the flags were set, a new surface is created and the source will be converted, scaled, cropped, and modulated. The rest of the function stays somewhat the same. The mask also needs to be rotated of course and then there is the NONE blend mode... It's surprisingly hard to get the pixel from a rotated surface to the destination buffer without affecting the pixel outside the rotated area. I found a way to do this with three blits which is pretty hard on the performance. Perhaps someone has an idea how to do this faster? As mentioned above, the SDLgfx_rotateSurface now only takes 8-bit paletted or 32-bit with alpha mask surfaces. It additionally sets the new surfaces up for the MOD blend mode. I shortly tested the 8-bit path of SDLgfx_rotateSurface and it seemed to work so far. This path is not used by the software renderer anyway.
2016-11-15 01:12:27 -08:00
SDL_Surface *src_clone, *src_rotated, *src_scaled;
SDL_Surface *mask = NULL, *mask_rotated = NULL;
int retval = 0;
Fixed bug 3359 - Software renderer does incorrect blending with SDL_RenderCopyEx Simon Hug The software renderer produces incorrect results when blending textures at an angle with certain blend modes. It seems that there were some edge cases that weren't considered when the SW_RenderCopyEx function was last changed. Or another bug possibly covered up the problem. (More on that in another bug report.) Most of the issues come from the fact that the rotating function sets a black colorkey. This is problematic because black is most likely appearing in the surface and the final blit will ignore these pixels. Unless a colorkey is already set (the software renderer currently never sets one), it's very hard to find a free color. Of course it could scan over the whole image until one is found, but that seems inefficient. The following blend modes have issues when drawn at an angle. NONE: The black pixels get ignored, making them essentially transparent. This breaks the 'dstRGBA = srcRGBA' definition of the NONE blend mode. MOD: Again, the black pixels get ignored. This also breaks the 'dstRGB = dstRGB * srcRGB' definition of the MOD blend mode, where black pixels would make the destination black as well. A white colorkey will work though, with some preparations. BLEND: There are some issues when blending a texture with a translucent RGBA target texture. I - uh - forgot what the problem here exactly is. This patch fixes the issues mentioned above. It mainly changes the code so it tries to do things without the colorkey and removes the automatic format conversion part from the SDLgfx_rotateSurface function. Getting the format right is something the caller has to do now and the required code has been added to the SW_RenderCopyEx function. There's a small change to the SW_CreateTexture function. RLE encoding a surface with an alpha mask can be a lossy process. Depending on how the user uses the RGBA channels, this may be undesired. The change that surfaces with an alpha mask don't get encoded makes the software renderer consistent with the other renderers. The SW_RenderCopyEx function now does these steps: Lock the source surface if necessary. Create a clone of the source by using the pixel buffer directly. Check the format and set a flag if a conversion is necessary. Check if scaling or cropping is necessary and set the flag for that as well. Check if color and alpha modulation has to be done before the rotate. Check if the source is an opaque surface. If not, it creates a mask surface that is necessary for the NONE blend mode. If any of the flags were set, a new surface is created and the source will be converted, scaled, cropped, and modulated. The rest of the function stays somewhat the same. The mask also needs to be rotated of course and then there is the NONE blend mode... It's surprisingly hard to get the pixel from a rotated surface to the destination buffer without affecting the pixel outside the rotated area. I found a way to do this with three blits which is pretty hard on the performance. Perhaps someone has an idea how to do this faster? As mentioned above, the SDLgfx_rotateSurface now only takes 8-bit paletted or 32-bit with alpha mask surfaces. It additionally sets the new surfaces up for the MOD blend mode. I shortly tested the 8-bit path of SDLgfx_rotateSurface and it seemed to work so far. This path is not used by the software renderer anyway.
2016-11-15 01:12:27 -08:00
SDL_BlendMode blendmode;
Uint8 alphaMod, rMod, gMod, bMod;
int applyModulation = SDL_FALSE;
int blitRequired = SDL_FALSE;
int isOpaque = SDL_FALSE;
if (surface == NULL) {
return -1;
}
tmp_rect.x = 0;
tmp_rect.y = 0;
tmp_rect.w = final_rect->w;
tmp_rect.h = final_rect->h;
Fixed bug 3359 - Software renderer does incorrect blending with SDL_RenderCopyEx Simon Hug The software renderer produces incorrect results when blending textures at an angle with certain blend modes. It seems that there were some edge cases that weren't considered when the SW_RenderCopyEx function was last changed. Or another bug possibly covered up the problem. (More on that in another bug report.) Most of the issues come from the fact that the rotating function sets a black colorkey. This is problematic because black is most likely appearing in the surface and the final blit will ignore these pixels. Unless a colorkey is already set (the software renderer currently never sets one), it's very hard to find a free color. Of course it could scan over the whole image until one is found, but that seems inefficient. The following blend modes have issues when drawn at an angle. NONE: The black pixels get ignored, making them essentially transparent. This breaks the 'dstRGBA = srcRGBA' definition of the NONE blend mode. MOD: Again, the black pixels get ignored. This also breaks the 'dstRGB = dstRGB * srcRGB' definition of the MOD blend mode, where black pixels would make the destination black as well. A white colorkey will work though, with some preparations. BLEND: There are some issues when blending a texture with a translucent RGBA target texture. I - uh - forgot what the problem here exactly is. This patch fixes the issues mentioned above. It mainly changes the code so it tries to do things without the colorkey and removes the automatic format conversion part from the SDLgfx_rotateSurface function. Getting the format right is something the caller has to do now and the required code has been added to the SW_RenderCopyEx function. There's a small change to the SW_CreateTexture function. RLE encoding a surface with an alpha mask can be a lossy process. Depending on how the user uses the RGBA channels, this may be undesired. The change that surfaces with an alpha mask don't get encoded makes the software renderer consistent with the other renderers. The SW_RenderCopyEx function now does these steps: Lock the source surface if necessary. Create a clone of the source by using the pixel buffer directly. Check the format and set a flag if a conversion is necessary. Check if scaling or cropping is necessary and set the flag for that as well. Check if color and alpha modulation has to be done before the rotate. Check if the source is an opaque surface. If not, it creates a mask surface that is necessary for the NONE blend mode. If any of the flags were set, a new surface is created and the source will be converted, scaled, cropped, and modulated. The rest of the function stays somewhat the same. The mask also needs to be rotated of course and then there is the NONE blend mode... It's surprisingly hard to get the pixel from a rotated surface to the destination buffer without affecting the pixel outside the rotated area. I found a way to do this with three blits which is pretty hard on the performance. Perhaps someone has an idea how to do this faster? As mentioned above, the SDLgfx_rotateSurface now only takes 8-bit paletted or 32-bit with alpha mask surfaces. It additionally sets the new surfaces up for the MOD blend mode. I shortly tested the 8-bit path of SDLgfx_rotateSurface and it seemed to work so far. This path is not used by the software renderer anyway.
2016-11-15 01:12:27 -08:00
/* It is possible to encounter an RLE encoded surface here and locking it is
* necessary because this code is going to access the pixel buffer directly.
*/
if (SDL_MUSTLOCK(src)) {
SDL_LockSurface(src);
}
/* Clone the source surface but use its pixel buffer directly.
* The original source surface must be treated as read-only.
*/
src_clone = SDL_CreateSurfaceFrom(src->pixels, src->w, src->h, src->pitch, src->format->format);
Fixed bug 3359 - Software renderer does incorrect blending with SDL_RenderCopyEx Simon Hug The software renderer produces incorrect results when blending textures at an angle with certain blend modes. It seems that there were some edge cases that weren't considered when the SW_RenderCopyEx function was last changed. Or another bug possibly covered up the problem. (More on that in another bug report.) Most of the issues come from the fact that the rotating function sets a black colorkey. This is problematic because black is most likely appearing in the surface and the final blit will ignore these pixels. Unless a colorkey is already set (the software renderer currently never sets one), it's very hard to find a free color. Of course it could scan over the whole image until one is found, but that seems inefficient. The following blend modes have issues when drawn at an angle. NONE: The black pixels get ignored, making them essentially transparent. This breaks the 'dstRGBA = srcRGBA' definition of the NONE blend mode. MOD: Again, the black pixels get ignored. This also breaks the 'dstRGB = dstRGB * srcRGB' definition of the MOD blend mode, where black pixels would make the destination black as well. A white colorkey will work though, with some preparations. BLEND: There are some issues when blending a texture with a translucent RGBA target texture. I - uh - forgot what the problem here exactly is. This patch fixes the issues mentioned above. It mainly changes the code so it tries to do things without the colorkey and removes the automatic format conversion part from the SDLgfx_rotateSurface function. Getting the format right is something the caller has to do now and the required code has been added to the SW_RenderCopyEx function. There's a small change to the SW_CreateTexture function. RLE encoding a surface with an alpha mask can be a lossy process. Depending on how the user uses the RGBA channels, this may be undesired. The change that surfaces with an alpha mask don't get encoded makes the software renderer consistent with the other renderers. The SW_RenderCopyEx function now does these steps: Lock the source surface if necessary. Create a clone of the source by using the pixel buffer directly. Check the format and set a flag if a conversion is necessary. Check if scaling or cropping is necessary and set the flag for that as well. Check if color and alpha modulation has to be done before the rotate. Check if the source is an opaque surface. If not, it creates a mask surface that is necessary for the NONE blend mode. If any of the flags were set, a new surface is created and the source will be converted, scaled, cropped, and modulated. The rest of the function stays somewhat the same. The mask also needs to be rotated of course and then there is the NONE blend mode... It's surprisingly hard to get the pixel from a rotated surface to the destination buffer without affecting the pixel outside the rotated area. I found a way to do this with three blits which is pretty hard on the performance. Perhaps someone has an idea how to do this faster? As mentioned above, the SDLgfx_rotateSurface now only takes 8-bit paletted or 32-bit with alpha mask surfaces. It additionally sets the new surfaces up for the MOD blend mode. I shortly tested the 8-bit path of SDLgfx_rotateSurface and it seemed to work so far. This path is not used by the software renderer anyway.
2016-11-15 01:12:27 -08:00
if (src_clone == NULL) {
if (SDL_MUSTLOCK(src)) {
SDL_UnlockSurface(src);
}
Fixed bug 3359 - Software renderer does incorrect blending with SDL_RenderCopyEx Simon Hug The software renderer produces incorrect results when blending textures at an angle with certain blend modes. It seems that there were some edge cases that weren't considered when the SW_RenderCopyEx function was last changed. Or another bug possibly covered up the problem. (More on that in another bug report.) Most of the issues come from the fact that the rotating function sets a black colorkey. This is problematic because black is most likely appearing in the surface and the final blit will ignore these pixels. Unless a colorkey is already set (the software renderer currently never sets one), it's very hard to find a free color. Of course it could scan over the whole image until one is found, but that seems inefficient. The following blend modes have issues when drawn at an angle. NONE: The black pixels get ignored, making them essentially transparent. This breaks the 'dstRGBA = srcRGBA' definition of the NONE blend mode. MOD: Again, the black pixels get ignored. This also breaks the 'dstRGB = dstRGB * srcRGB' definition of the MOD blend mode, where black pixels would make the destination black as well. A white colorkey will work though, with some preparations. BLEND: There are some issues when blending a texture with a translucent RGBA target texture. I - uh - forgot what the problem here exactly is. This patch fixes the issues mentioned above. It mainly changes the code so it tries to do things without the colorkey and removes the automatic format conversion part from the SDLgfx_rotateSurface function. Getting the format right is something the caller has to do now and the required code has been added to the SW_RenderCopyEx function. There's a small change to the SW_CreateTexture function. RLE encoding a surface with an alpha mask can be a lossy process. Depending on how the user uses the RGBA channels, this may be undesired. The change that surfaces with an alpha mask don't get encoded makes the software renderer consistent with the other renderers. The SW_RenderCopyEx function now does these steps: Lock the source surface if necessary. Create a clone of the source by using the pixel buffer directly. Check the format and set a flag if a conversion is necessary. Check if scaling or cropping is necessary and set the flag for that as well. Check if color and alpha modulation has to be done before the rotate. Check if the source is an opaque surface. If not, it creates a mask surface that is necessary for the NONE blend mode. If any of the flags were set, a new surface is created and the source will be converted, scaled, cropped, and modulated. The rest of the function stays somewhat the same. The mask also needs to be rotated of course and then there is the NONE blend mode... It's surprisingly hard to get the pixel from a rotated surface to the destination buffer without affecting the pixel outside the rotated area. I found a way to do this with three blits which is pretty hard on the performance. Perhaps someone has an idea how to do this faster? As mentioned above, the SDLgfx_rotateSurface now only takes 8-bit paletted or 32-bit with alpha mask surfaces. It additionally sets the new surfaces up for the MOD blend mode. I shortly tested the 8-bit path of SDLgfx_rotateSurface and it seemed to work so far. This path is not used by the software renderer anyway.
2016-11-15 01:12:27 -08:00
return -1;
}
SDL_GetSurfaceBlendMode(src, &blendmode);
SDL_GetSurfaceAlphaMod(src, &alphaMod);
SDL_GetSurfaceColorMod(src, &rMod, &gMod, &bMod);
/* SDLgfx_rotateSurface only accepts 32-bit surfaces with a 8888 layout. Everything else has to be converted. */
if (src->format->BitsPerPixel != 32 || SDL_PIXELLAYOUT(src->format->format) != SDL_PACKEDLAYOUT_8888 || !src->format->Amask) {
blitRequired = SDL_TRUE;
}
/* If scaling and cropping is necessary, it has to be taken care of before the rotation. */
if (!(srcrect->w == final_rect->w && srcrect->h == final_rect->h && srcrect->x == 0 && srcrect->y == 0)) {
Fixed bug 3359 - Software renderer does incorrect blending with SDL_RenderCopyEx Simon Hug The software renderer produces incorrect results when blending textures at an angle with certain blend modes. It seems that there were some edge cases that weren't considered when the SW_RenderCopyEx function was last changed. Or another bug possibly covered up the problem. (More on that in another bug report.) Most of the issues come from the fact that the rotating function sets a black colorkey. This is problematic because black is most likely appearing in the surface and the final blit will ignore these pixels. Unless a colorkey is already set (the software renderer currently never sets one), it's very hard to find a free color. Of course it could scan over the whole image until one is found, but that seems inefficient. The following blend modes have issues when drawn at an angle. NONE: The black pixels get ignored, making them essentially transparent. This breaks the 'dstRGBA = srcRGBA' definition of the NONE blend mode. MOD: Again, the black pixels get ignored. This also breaks the 'dstRGB = dstRGB * srcRGB' definition of the MOD blend mode, where black pixels would make the destination black as well. A white colorkey will work though, with some preparations. BLEND: There are some issues when blending a texture with a translucent RGBA target texture. I - uh - forgot what the problem here exactly is. This patch fixes the issues mentioned above. It mainly changes the code so it tries to do things without the colorkey and removes the automatic format conversion part from the SDLgfx_rotateSurface function. Getting the format right is something the caller has to do now and the required code has been added to the SW_RenderCopyEx function. There's a small change to the SW_CreateTexture function. RLE encoding a surface with an alpha mask can be a lossy process. Depending on how the user uses the RGBA channels, this may be undesired. The change that surfaces with an alpha mask don't get encoded makes the software renderer consistent with the other renderers. The SW_RenderCopyEx function now does these steps: Lock the source surface if necessary. Create a clone of the source by using the pixel buffer directly. Check the format and set a flag if a conversion is necessary. Check if scaling or cropping is necessary and set the flag for that as well. Check if color and alpha modulation has to be done before the rotate. Check if the source is an opaque surface. If not, it creates a mask surface that is necessary for the NONE blend mode. If any of the flags were set, a new surface is created and the source will be converted, scaled, cropped, and modulated. The rest of the function stays somewhat the same. The mask also needs to be rotated of course and then there is the NONE blend mode... It's surprisingly hard to get the pixel from a rotated surface to the destination buffer without affecting the pixel outside the rotated area. I found a way to do this with three blits which is pretty hard on the performance. Perhaps someone has an idea how to do this faster? As mentioned above, the SDLgfx_rotateSurface now only takes 8-bit paletted or 32-bit with alpha mask surfaces. It additionally sets the new surfaces up for the MOD blend mode. I shortly tested the 8-bit path of SDLgfx_rotateSurface and it seemed to work so far. This path is not used by the software renderer anyway.
2016-11-15 01:12:27 -08:00
blitRequired = SDL_TRUE;
}
/* srcrect is not selecting the whole src surface, so cropping is needed */
if (!(srcrect->w == src->w && srcrect->h == src->h && srcrect->x == 0 && srcrect->y == 0)) {
blitRequired = SDL_TRUE;
}
/* The color and alpha modulation has to be applied before the rotation when using the NONE, MOD or MUL blend modes. */
if ((blendmode == SDL_BLENDMODE_NONE || blendmode == SDL_BLENDMODE_MOD || blendmode == SDL_BLENDMODE_MUL) && (alphaMod & rMod & gMod & bMod) != 255) {
Fixed bug 3359 - Software renderer does incorrect blending with SDL_RenderCopyEx Simon Hug The software renderer produces incorrect results when blending textures at an angle with certain blend modes. It seems that there were some edge cases that weren't considered when the SW_RenderCopyEx function was last changed. Or another bug possibly covered up the problem. (More on that in another bug report.) Most of the issues come from the fact that the rotating function sets a black colorkey. This is problematic because black is most likely appearing in the surface and the final blit will ignore these pixels. Unless a colorkey is already set (the software renderer currently never sets one), it's very hard to find a free color. Of course it could scan over the whole image until one is found, but that seems inefficient. The following blend modes have issues when drawn at an angle. NONE: The black pixels get ignored, making them essentially transparent. This breaks the 'dstRGBA = srcRGBA' definition of the NONE blend mode. MOD: Again, the black pixels get ignored. This also breaks the 'dstRGB = dstRGB * srcRGB' definition of the MOD blend mode, where black pixels would make the destination black as well. A white colorkey will work though, with some preparations. BLEND: There are some issues when blending a texture with a translucent RGBA target texture. I - uh - forgot what the problem here exactly is. This patch fixes the issues mentioned above. It mainly changes the code so it tries to do things without the colorkey and removes the automatic format conversion part from the SDLgfx_rotateSurface function. Getting the format right is something the caller has to do now and the required code has been added to the SW_RenderCopyEx function. There's a small change to the SW_CreateTexture function. RLE encoding a surface with an alpha mask can be a lossy process. Depending on how the user uses the RGBA channels, this may be undesired. The change that surfaces with an alpha mask don't get encoded makes the software renderer consistent with the other renderers. The SW_RenderCopyEx function now does these steps: Lock the source surface if necessary. Create a clone of the source by using the pixel buffer directly. Check the format and set a flag if a conversion is necessary. Check if scaling or cropping is necessary and set the flag for that as well. Check if color and alpha modulation has to be done before the rotate. Check if the source is an opaque surface. If not, it creates a mask surface that is necessary for the NONE blend mode. If any of the flags were set, a new surface is created and the source will be converted, scaled, cropped, and modulated. The rest of the function stays somewhat the same. The mask also needs to be rotated of course and then there is the NONE blend mode... It's surprisingly hard to get the pixel from a rotated surface to the destination buffer without affecting the pixel outside the rotated area. I found a way to do this with three blits which is pretty hard on the performance. Perhaps someone has an idea how to do this faster? As mentioned above, the SDLgfx_rotateSurface now only takes 8-bit paletted or 32-bit with alpha mask surfaces. It additionally sets the new surfaces up for the MOD blend mode. I shortly tested the 8-bit path of SDLgfx_rotateSurface and it seemed to work so far. This path is not used by the software renderer anyway.
2016-11-15 01:12:27 -08:00
applyModulation = SDL_TRUE;
SDL_SetSurfaceAlphaMod(src_clone, alphaMod);
SDL_SetSurfaceColorMod(src_clone, rMod, gMod, bMod);
}
/* Opaque surfaces are much easier to handle with the NONE blend mode. */
if (blendmode == SDL_BLENDMODE_NONE && !src->format->Amask && alphaMod == 255) {
isOpaque = SDL_TRUE;
}
/* The NONE blend mode requires a mask for non-opaque surfaces. This mask will be used
* to clear the pixels in the destination surface. The other steps are explained below.
*/
if (blendmode == SDL_BLENDMODE_NONE && !isOpaque) {
mask = SDL_CreateSurface(final_rect->w, final_rect->h, SDL_PIXELFORMAT_ARGB8888);
Fixed bug 3359 - Software renderer does incorrect blending with SDL_RenderCopyEx Simon Hug The software renderer produces incorrect results when blending textures at an angle with certain blend modes. It seems that there were some edge cases that weren't considered when the SW_RenderCopyEx function was last changed. Or another bug possibly covered up the problem. (More on that in another bug report.) Most of the issues come from the fact that the rotating function sets a black colorkey. This is problematic because black is most likely appearing in the surface and the final blit will ignore these pixels. Unless a colorkey is already set (the software renderer currently never sets one), it's very hard to find a free color. Of course it could scan over the whole image until one is found, but that seems inefficient. The following blend modes have issues when drawn at an angle. NONE: The black pixels get ignored, making them essentially transparent. This breaks the 'dstRGBA = srcRGBA' definition of the NONE blend mode. MOD: Again, the black pixels get ignored. This also breaks the 'dstRGB = dstRGB * srcRGB' definition of the MOD blend mode, where black pixels would make the destination black as well. A white colorkey will work though, with some preparations. BLEND: There are some issues when blending a texture with a translucent RGBA target texture. I - uh - forgot what the problem here exactly is. This patch fixes the issues mentioned above. It mainly changes the code so it tries to do things without the colorkey and removes the automatic format conversion part from the SDLgfx_rotateSurface function. Getting the format right is something the caller has to do now and the required code has been added to the SW_RenderCopyEx function. There's a small change to the SW_CreateTexture function. RLE encoding a surface with an alpha mask can be a lossy process. Depending on how the user uses the RGBA channels, this may be undesired. The change that surfaces with an alpha mask don't get encoded makes the software renderer consistent with the other renderers. The SW_RenderCopyEx function now does these steps: Lock the source surface if necessary. Create a clone of the source by using the pixel buffer directly. Check the format and set a flag if a conversion is necessary. Check if scaling or cropping is necessary and set the flag for that as well. Check if color and alpha modulation has to be done before the rotate. Check if the source is an opaque surface. If not, it creates a mask surface that is necessary for the NONE blend mode. If any of the flags were set, a new surface is created and the source will be converted, scaled, cropped, and modulated. The rest of the function stays somewhat the same. The mask also needs to be rotated of course and then there is the NONE blend mode... It's surprisingly hard to get the pixel from a rotated surface to the destination buffer without affecting the pixel outside the rotated area. I found a way to do this with three blits which is pretty hard on the performance. Perhaps someone has an idea how to do this faster? As mentioned above, the SDLgfx_rotateSurface now only takes 8-bit paletted or 32-bit with alpha mask surfaces. It additionally sets the new surfaces up for the MOD blend mode. I shortly tested the 8-bit path of SDLgfx_rotateSurface and it seemed to work so far. This path is not used by the software renderer anyway.
2016-11-15 01:12:27 -08:00
if (mask == NULL) {
retval = -1;
} else {
SDL_SetSurfaceBlendMode(mask, SDL_BLENDMODE_MOD);
}
Fixed bug 3359 - Software renderer does incorrect blending with SDL_RenderCopyEx Simon Hug The software renderer produces incorrect results when blending textures at an angle with certain blend modes. It seems that there were some edge cases that weren't considered when the SW_RenderCopyEx function was last changed. Or another bug possibly covered up the problem. (More on that in another bug report.) Most of the issues come from the fact that the rotating function sets a black colorkey. This is problematic because black is most likely appearing in the surface and the final blit will ignore these pixels. Unless a colorkey is already set (the software renderer currently never sets one), it's very hard to find a free color. Of course it could scan over the whole image until one is found, but that seems inefficient. The following blend modes have issues when drawn at an angle. NONE: The black pixels get ignored, making them essentially transparent. This breaks the 'dstRGBA = srcRGBA' definition of the NONE blend mode. MOD: Again, the black pixels get ignored. This also breaks the 'dstRGB = dstRGB * srcRGB' definition of the MOD blend mode, where black pixels would make the destination black as well. A white colorkey will work though, with some preparations. BLEND: There are some issues when blending a texture with a translucent RGBA target texture. I - uh - forgot what the problem here exactly is. This patch fixes the issues mentioned above. It mainly changes the code so it tries to do things without the colorkey and removes the automatic format conversion part from the SDLgfx_rotateSurface function. Getting the format right is something the caller has to do now and the required code has been added to the SW_RenderCopyEx function. There's a small change to the SW_CreateTexture function. RLE encoding a surface with an alpha mask can be a lossy process. Depending on how the user uses the RGBA channels, this may be undesired. The change that surfaces with an alpha mask don't get encoded makes the software renderer consistent with the other renderers. The SW_RenderCopyEx function now does these steps: Lock the source surface if necessary. Create a clone of the source by using the pixel buffer directly. Check the format and set a flag if a conversion is necessary. Check if scaling or cropping is necessary and set the flag for that as well. Check if color and alpha modulation has to be done before the rotate. Check if the source is an opaque surface. If not, it creates a mask surface that is necessary for the NONE blend mode. If any of the flags were set, a new surface is created and the source will be converted, scaled, cropped, and modulated. The rest of the function stays somewhat the same. The mask also needs to be rotated of course and then there is the NONE blend mode... It's surprisingly hard to get the pixel from a rotated surface to the destination buffer without affecting the pixel outside the rotated area. I found a way to do this with three blits which is pretty hard on the performance. Perhaps someone has an idea how to do this faster? As mentioned above, the SDLgfx_rotateSurface now only takes 8-bit paletted or 32-bit with alpha mask surfaces. It additionally sets the new surfaces up for the MOD blend mode. I shortly tested the 8-bit path of SDLgfx_rotateSurface and it seemed to work so far. This path is not used by the software renderer anyway.
2016-11-15 01:12:27 -08:00
}
Fixed bug 3359 - Software renderer does incorrect blending with SDL_RenderCopyEx Simon Hug The software renderer produces incorrect results when blending textures at an angle with certain blend modes. It seems that there were some edge cases that weren't considered when the SW_RenderCopyEx function was last changed. Or another bug possibly covered up the problem. (More on that in another bug report.) Most of the issues come from the fact that the rotating function sets a black colorkey. This is problematic because black is most likely appearing in the surface and the final blit will ignore these pixels. Unless a colorkey is already set (the software renderer currently never sets one), it's very hard to find a free color. Of course it could scan over the whole image until one is found, but that seems inefficient. The following blend modes have issues when drawn at an angle. NONE: The black pixels get ignored, making them essentially transparent. This breaks the 'dstRGBA = srcRGBA' definition of the NONE blend mode. MOD: Again, the black pixels get ignored. This also breaks the 'dstRGB = dstRGB * srcRGB' definition of the MOD blend mode, where black pixels would make the destination black as well. A white colorkey will work though, with some preparations. BLEND: There are some issues when blending a texture with a translucent RGBA target texture. I - uh - forgot what the problem here exactly is. This patch fixes the issues mentioned above. It mainly changes the code so it tries to do things without the colorkey and removes the automatic format conversion part from the SDLgfx_rotateSurface function. Getting the format right is something the caller has to do now and the required code has been added to the SW_RenderCopyEx function. There's a small change to the SW_CreateTexture function. RLE encoding a surface with an alpha mask can be a lossy process. Depending on how the user uses the RGBA channels, this may be undesired. The change that surfaces with an alpha mask don't get encoded makes the software renderer consistent with the other renderers. The SW_RenderCopyEx function now does these steps: Lock the source surface if necessary. Create a clone of the source by using the pixel buffer directly. Check the format and set a flag if a conversion is necessary. Check if scaling or cropping is necessary and set the flag for that as well. Check if color and alpha modulation has to be done before the rotate. Check if the source is an opaque surface. If not, it creates a mask surface that is necessary for the NONE blend mode. If any of the flags were set, a new surface is created and the source will be converted, scaled, cropped, and modulated. The rest of the function stays somewhat the same. The mask also needs to be rotated of course and then there is the NONE blend mode... It's surprisingly hard to get the pixel from a rotated surface to the destination buffer without affecting the pixel outside the rotated area. I found a way to do this with three blits which is pretty hard on the performance. Perhaps someone has an idea how to do this faster? As mentioned above, the SDLgfx_rotateSurface now only takes 8-bit paletted or 32-bit with alpha mask surfaces. It additionally sets the new surfaces up for the MOD blend mode. I shortly tested the 8-bit path of SDLgfx_rotateSurface and it seemed to work so far. This path is not used by the software renderer anyway.
2016-11-15 01:12:27 -08:00
/* Create a new surface should there be a format mismatch or if scaling, cropping,
* or modulation is required. It's possible to use the source surface directly otherwise.
*/
if (!retval && (blitRequired || applyModulation)) {
SDL_Rect scale_rect = tmp_rect;
src_scaled = SDL_CreateSurface(final_rect->w, final_rect->h, SDL_PIXELFORMAT_ARGB8888);
Fixed bug 3359 - Software renderer does incorrect blending with SDL_RenderCopyEx Simon Hug The software renderer produces incorrect results when blending textures at an angle with certain blend modes. It seems that there were some edge cases that weren't considered when the SW_RenderCopyEx function was last changed. Or another bug possibly covered up the problem. (More on that in another bug report.) Most of the issues come from the fact that the rotating function sets a black colorkey. This is problematic because black is most likely appearing in the surface and the final blit will ignore these pixels. Unless a colorkey is already set (the software renderer currently never sets one), it's very hard to find a free color. Of course it could scan over the whole image until one is found, but that seems inefficient. The following blend modes have issues when drawn at an angle. NONE: The black pixels get ignored, making them essentially transparent. This breaks the 'dstRGBA = srcRGBA' definition of the NONE blend mode. MOD: Again, the black pixels get ignored. This also breaks the 'dstRGB = dstRGB * srcRGB' definition of the MOD blend mode, where black pixels would make the destination black as well. A white colorkey will work though, with some preparations. BLEND: There are some issues when blending a texture with a translucent RGBA target texture. I - uh - forgot what the problem here exactly is. This patch fixes the issues mentioned above. It mainly changes the code so it tries to do things without the colorkey and removes the automatic format conversion part from the SDLgfx_rotateSurface function. Getting the format right is something the caller has to do now and the required code has been added to the SW_RenderCopyEx function. There's a small change to the SW_CreateTexture function. RLE encoding a surface with an alpha mask can be a lossy process. Depending on how the user uses the RGBA channels, this may be undesired. The change that surfaces with an alpha mask don't get encoded makes the software renderer consistent with the other renderers. The SW_RenderCopyEx function now does these steps: Lock the source surface if necessary. Create a clone of the source by using the pixel buffer directly. Check the format and set a flag if a conversion is necessary. Check if scaling or cropping is necessary and set the flag for that as well. Check if color and alpha modulation has to be done before the rotate. Check if the source is an opaque surface. If not, it creates a mask surface that is necessary for the NONE blend mode. If any of the flags were set, a new surface is created and the source will be converted, scaled, cropped, and modulated. The rest of the function stays somewhat the same. The mask also needs to be rotated of course and then there is the NONE blend mode... It's surprisingly hard to get the pixel from a rotated surface to the destination buffer without affecting the pixel outside the rotated area. I found a way to do this with three blits which is pretty hard on the performance. Perhaps someone has an idea how to do this faster? As mentioned above, the SDLgfx_rotateSurface now only takes 8-bit paletted or 32-bit with alpha mask surfaces. It additionally sets the new surfaces up for the MOD blend mode. I shortly tested the 8-bit path of SDLgfx_rotateSurface and it seemed to work so far. This path is not used by the software renderer anyway.
2016-11-15 01:12:27 -08:00
if (src_scaled == NULL) {
retval = -1;
} else {
SDL_SetSurfaceBlendMode(src_clone, SDL_BLENDMODE_NONE);
2022-12-27 15:05:51 -08:00
retval = SDL_PrivateBlitSurfaceScaled(src_clone, srcrect, src_scaled, &scale_rect, texture->scaleMode);
SDL_DestroySurface(src_clone);
Fixed bug 3359 - Software renderer does incorrect blending with SDL_RenderCopyEx Simon Hug The software renderer produces incorrect results when blending textures at an angle with certain blend modes. It seems that there were some edge cases that weren't considered when the SW_RenderCopyEx function was last changed. Or another bug possibly covered up the problem. (More on that in another bug report.) Most of the issues come from the fact that the rotating function sets a black colorkey. This is problematic because black is most likely appearing in the surface and the final blit will ignore these pixels. Unless a colorkey is already set (the software renderer currently never sets one), it's very hard to find a free color. Of course it could scan over the whole image until one is found, but that seems inefficient. The following blend modes have issues when drawn at an angle. NONE: The black pixels get ignored, making them essentially transparent. This breaks the 'dstRGBA = srcRGBA' definition of the NONE blend mode. MOD: Again, the black pixels get ignored. This also breaks the 'dstRGB = dstRGB * srcRGB' definition of the MOD blend mode, where black pixels would make the destination black as well. A white colorkey will work though, with some preparations. BLEND: There are some issues when blending a texture with a translucent RGBA target texture. I - uh - forgot what the problem here exactly is. This patch fixes the issues mentioned above. It mainly changes the code so it tries to do things without the colorkey and removes the automatic format conversion part from the SDLgfx_rotateSurface function. Getting the format right is something the caller has to do now and the required code has been added to the SW_RenderCopyEx function. There's a small change to the SW_CreateTexture function. RLE encoding a surface with an alpha mask can be a lossy process. Depending on how the user uses the RGBA channels, this may be undesired. The change that surfaces with an alpha mask don't get encoded makes the software renderer consistent with the other renderers. The SW_RenderCopyEx function now does these steps: Lock the source surface if necessary. Create a clone of the source by using the pixel buffer directly. Check the format and set a flag if a conversion is necessary. Check if scaling or cropping is necessary and set the flag for that as well. Check if color and alpha modulation has to be done before the rotate. Check if the source is an opaque surface. If not, it creates a mask surface that is necessary for the NONE blend mode. If any of the flags were set, a new surface is created and the source will be converted, scaled, cropped, and modulated. The rest of the function stays somewhat the same. The mask also needs to be rotated of course and then there is the NONE blend mode... It's surprisingly hard to get the pixel from a rotated surface to the destination buffer without affecting the pixel outside the rotated area. I found a way to do this with three blits which is pretty hard on the performance. Perhaps someone has an idea how to do this faster? As mentioned above, the SDLgfx_rotateSurface now only takes 8-bit paletted or 32-bit with alpha mask surfaces. It additionally sets the new surfaces up for the MOD blend mode. I shortly tested the 8-bit path of SDLgfx_rotateSurface and it seemed to work so far. This path is not used by the software renderer anyway.
2016-11-15 01:12:27 -08:00
src_clone = src_scaled;
src_scaled = NULL;
}
}
Fixed bug 3359 - Software renderer does incorrect blending with SDL_RenderCopyEx Simon Hug The software renderer produces incorrect results when blending textures at an angle with certain blend modes. It seems that there were some edge cases that weren't considered when the SW_RenderCopyEx function was last changed. Or another bug possibly covered up the problem. (More on that in another bug report.) Most of the issues come from the fact that the rotating function sets a black colorkey. This is problematic because black is most likely appearing in the surface and the final blit will ignore these pixels. Unless a colorkey is already set (the software renderer currently never sets one), it's very hard to find a free color. Of course it could scan over the whole image until one is found, but that seems inefficient. The following blend modes have issues when drawn at an angle. NONE: The black pixels get ignored, making them essentially transparent. This breaks the 'dstRGBA = srcRGBA' definition of the NONE blend mode. MOD: Again, the black pixels get ignored. This also breaks the 'dstRGB = dstRGB * srcRGB' definition of the MOD blend mode, where black pixels would make the destination black as well. A white colorkey will work though, with some preparations. BLEND: There are some issues when blending a texture with a translucent RGBA target texture. I - uh - forgot what the problem here exactly is. This patch fixes the issues mentioned above. It mainly changes the code so it tries to do things without the colorkey and removes the automatic format conversion part from the SDLgfx_rotateSurface function. Getting the format right is something the caller has to do now and the required code has been added to the SW_RenderCopyEx function. There's a small change to the SW_CreateTexture function. RLE encoding a surface with an alpha mask can be a lossy process. Depending on how the user uses the RGBA channels, this may be undesired. The change that surfaces with an alpha mask don't get encoded makes the software renderer consistent with the other renderers. The SW_RenderCopyEx function now does these steps: Lock the source surface if necessary. Create a clone of the source by using the pixel buffer directly. Check the format and set a flag if a conversion is necessary. Check if scaling or cropping is necessary and set the flag for that as well. Check if color and alpha modulation has to be done before the rotate. Check if the source is an opaque surface. If not, it creates a mask surface that is necessary for the NONE blend mode. If any of the flags were set, a new surface is created and the source will be converted, scaled, cropped, and modulated. The rest of the function stays somewhat the same. The mask also needs to be rotated of course and then there is the NONE blend mode... It's surprisingly hard to get the pixel from a rotated surface to the destination buffer without affecting the pixel outside the rotated area. I found a way to do this with three blits which is pretty hard on the performance. Perhaps someone has an idea how to do this faster? As mentioned above, the SDLgfx_rotateSurface now only takes 8-bit paletted or 32-bit with alpha mask surfaces. It additionally sets the new surfaces up for the MOD blend mode. I shortly tested the 8-bit path of SDLgfx_rotateSurface and it seemed to work so far. This path is not used by the software renderer anyway.
2016-11-15 01:12:27 -08:00
/* SDLgfx_rotateSurface is going to make decisions depending on the blend mode. */
SDL_SetSurfaceBlendMode(src_clone, blendmode);
if (!retval) {
SDL_Rect rect_dest;
double cangle, sangle;
SDLgfx_rotozoomSurfaceSizeTrig(tmp_rect.w, tmp_rect.h, angle, center,
&rect_dest, &cangle, &sangle);
src_rotated = SDLgfx_rotateSurface(src_clone, angle,
(texture->scaleMode == SDL_SCALEMODE_NEAREST) ? 0 : 1, flip & SDL_FLIP_HORIZONTAL, flip & SDL_FLIP_VERTICAL,
&rect_dest, cangle, sangle, center);
Fixed bug 3359 - Software renderer does incorrect blending with SDL_RenderCopyEx Simon Hug The software renderer produces incorrect results when blending textures at an angle with certain blend modes. It seems that there were some edge cases that weren't considered when the SW_RenderCopyEx function was last changed. Or another bug possibly covered up the problem. (More on that in another bug report.) Most of the issues come from the fact that the rotating function sets a black colorkey. This is problematic because black is most likely appearing in the surface and the final blit will ignore these pixels. Unless a colorkey is already set (the software renderer currently never sets one), it's very hard to find a free color. Of course it could scan over the whole image until one is found, but that seems inefficient. The following blend modes have issues when drawn at an angle. NONE: The black pixels get ignored, making them essentially transparent. This breaks the 'dstRGBA = srcRGBA' definition of the NONE blend mode. MOD: Again, the black pixels get ignored. This also breaks the 'dstRGB = dstRGB * srcRGB' definition of the MOD blend mode, where black pixels would make the destination black as well. A white colorkey will work though, with some preparations. BLEND: There are some issues when blending a texture with a translucent RGBA target texture. I - uh - forgot what the problem here exactly is. This patch fixes the issues mentioned above. It mainly changes the code so it tries to do things without the colorkey and removes the automatic format conversion part from the SDLgfx_rotateSurface function. Getting the format right is something the caller has to do now and the required code has been added to the SW_RenderCopyEx function. There's a small change to the SW_CreateTexture function. RLE encoding a surface with an alpha mask can be a lossy process. Depending on how the user uses the RGBA channels, this may be undesired. The change that surfaces with an alpha mask don't get encoded makes the software renderer consistent with the other renderers. The SW_RenderCopyEx function now does these steps: Lock the source surface if necessary. Create a clone of the source by using the pixel buffer directly. Check the format and set a flag if a conversion is necessary. Check if scaling or cropping is necessary and set the flag for that as well. Check if color and alpha modulation has to be done before the rotate. Check if the source is an opaque surface. If not, it creates a mask surface that is necessary for the NONE blend mode. If any of the flags were set, a new surface is created and the source will be converted, scaled, cropped, and modulated. The rest of the function stays somewhat the same. The mask also needs to be rotated of course and then there is the NONE blend mode... It's surprisingly hard to get the pixel from a rotated surface to the destination buffer without affecting the pixel outside the rotated area. I found a way to do this with three blits which is pretty hard on the performance. Perhaps someone has an idea how to do this faster? As mentioned above, the SDLgfx_rotateSurface now only takes 8-bit paletted or 32-bit with alpha mask surfaces. It additionally sets the new surfaces up for the MOD blend mode. I shortly tested the 8-bit path of SDLgfx_rotateSurface and it seemed to work so far. This path is not used by the software renderer anyway.
2016-11-15 01:12:27 -08:00
if (src_rotated == NULL) {
retval = -1;
}
if (!retval && mask != NULL) {
/* The mask needed for the NONE blend mode gets rotated with the same parameters. */
mask_rotated = SDLgfx_rotateSurface(mask, angle,
SDL_FALSE, 0, 0,
&rect_dest, cangle, sangle, center);
Fixed bug 3359 - Software renderer does incorrect blending with SDL_RenderCopyEx Simon Hug The software renderer produces incorrect results when blending textures at an angle with certain blend modes. It seems that there were some edge cases that weren't considered when the SW_RenderCopyEx function was last changed. Or another bug possibly covered up the problem. (More on that in another bug report.) Most of the issues come from the fact that the rotating function sets a black colorkey. This is problematic because black is most likely appearing in the surface and the final blit will ignore these pixels. Unless a colorkey is already set (the software renderer currently never sets one), it's very hard to find a free color. Of course it could scan over the whole image until one is found, but that seems inefficient. The following blend modes have issues when drawn at an angle. NONE: The black pixels get ignored, making them essentially transparent. This breaks the 'dstRGBA = srcRGBA' definition of the NONE blend mode. MOD: Again, the black pixels get ignored. This also breaks the 'dstRGB = dstRGB * srcRGB' definition of the MOD blend mode, where black pixels would make the destination black as well. A white colorkey will work though, with some preparations. BLEND: There are some issues when blending a texture with a translucent RGBA target texture. I - uh - forgot what the problem here exactly is. This patch fixes the issues mentioned above. It mainly changes the code so it tries to do things without the colorkey and removes the automatic format conversion part from the SDLgfx_rotateSurface function. Getting the format right is something the caller has to do now and the required code has been added to the SW_RenderCopyEx function. There's a small change to the SW_CreateTexture function. RLE encoding a surface with an alpha mask can be a lossy process. Depending on how the user uses the RGBA channels, this may be undesired. The change that surfaces with an alpha mask don't get encoded makes the software renderer consistent with the other renderers. The SW_RenderCopyEx function now does these steps: Lock the source surface if necessary. Create a clone of the source by using the pixel buffer directly. Check the format and set a flag if a conversion is necessary. Check if scaling or cropping is necessary and set the flag for that as well. Check if color and alpha modulation has to be done before the rotate. Check if the source is an opaque surface. If not, it creates a mask surface that is necessary for the NONE blend mode. If any of the flags were set, a new surface is created and the source will be converted, scaled, cropped, and modulated. The rest of the function stays somewhat the same. The mask also needs to be rotated of course and then there is the NONE blend mode... It's surprisingly hard to get the pixel from a rotated surface to the destination buffer without affecting the pixel outside the rotated area. I found a way to do this with three blits which is pretty hard on the performance. Perhaps someone has an idea how to do this faster? As mentioned above, the SDLgfx_rotateSurface now only takes 8-bit paletted or 32-bit with alpha mask surfaces. It additionally sets the new surfaces up for the MOD blend mode. I shortly tested the 8-bit path of SDLgfx_rotateSurface and it seemed to work so far. This path is not used by the software renderer anyway.
2016-11-15 01:12:27 -08:00
if (mask_rotated == NULL) {
retval = -1;
}
}
if (!retval) {
tmp_rect.x = final_rect->x + rect_dest.x;
tmp_rect.y = final_rect->y + rect_dest.y;
tmp_rect.w = rect_dest.w;
tmp_rect.h = rect_dest.h;
Fixed bug 3359 - Software renderer does incorrect blending with SDL_RenderCopyEx Simon Hug The software renderer produces incorrect results when blending textures at an angle with certain blend modes. It seems that there were some edge cases that weren't considered when the SW_RenderCopyEx function was last changed. Or another bug possibly covered up the problem. (More on that in another bug report.) Most of the issues come from the fact that the rotating function sets a black colorkey. This is problematic because black is most likely appearing in the surface and the final blit will ignore these pixels. Unless a colorkey is already set (the software renderer currently never sets one), it's very hard to find a free color. Of course it could scan over the whole image until one is found, but that seems inefficient. The following blend modes have issues when drawn at an angle. NONE: The black pixels get ignored, making them essentially transparent. This breaks the 'dstRGBA = srcRGBA' definition of the NONE blend mode. MOD: Again, the black pixels get ignored. This also breaks the 'dstRGB = dstRGB * srcRGB' definition of the MOD blend mode, where black pixels would make the destination black as well. A white colorkey will work though, with some preparations. BLEND: There are some issues when blending a texture with a translucent RGBA target texture. I - uh - forgot what the problem here exactly is. This patch fixes the issues mentioned above. It mainly changes the code so it tries to do things without the colorkey and removes the automatic format conversion part from the SDLgfx_rotateSurface function. Getting the format right is something the caller has to do now and the required code has been added to the SW_RenderCopyEx function. There's a small change to the SW_CreateTexture function. RLE encoding a surface with an alpha mask can be a lossy process. Depending on how the user uses the RGBA channels, this may be undesired. The change that surfaces with an alpha mask don't get encoded makes the software renderer consistent with the other renderers. The SW_RenderCopyEx function now does these steps: Lock the source surface if necessary. Create a clone of the source by using the pixel buffer directly. Check the format and set a flag if a conversion is necessary. Check if scaling or cropping is necessary and set the flag for that as well. Check if color and alpha modulation has to be done before the rotate. Check if the source is an opaque surface. If not, it creates a mask surface that is necessary for the NONE blend mode. If any of the flags were set, a new surface is created and the source will be converted, scaled, cropped, and modulated. The rest of the function stays somewhat the same. The mask also needs to be rotated of course and then there is the NONE blend mode... It's surprisingly hard to get the pixel from a rotated surface to the destination buffer without affecting the pixel outside the rotated area. I found a way to do this with three blits which is pretty hard on the performance. Perhaps someone has an idea how to do this faster? As mentioned above, the SDLgfx_rotateSurface now only takes 8-bit paletted or 32-bit with alpha mask surfaces. It additionally sets the new surfaces up for the MOD blend mode. I shortly tested the 8-bit path of SDLgfx_rotateSurface and it seemed to work so far. This path is not used by the software renderer anyway.
2016-11-15 01:12:27 -08:00
/* The NONE blend mode needs some special care with non-opaque surfaces.
* Other blend modes or opaque surfaces can be blitted directly.
*/
if (blendmode != SDL_BLENDMODE_NONE || isOpaque) {
if (applyModulation == SDL_FALSE) {
/* If the modulation wasn't already applied, make it happen now. */
SDL_SetSurfaceAlphaMod(src_rotated, alphaMod);
SDL_SetSurfaceColorMod(src_rotated, rMod, gMod, bMod);
}
/* Renderer scaling, if needed */
retval = Blit_to_Screen(src_rotated, NULL, surface, &tmp_rect, scale_x, scale_y, texture->scaleMode);
Fixed bug 3359 - Software renderer does incorrect blending with SDL_RenderCopyEx Simon Hug The software renderer produces incorrect results when blending textures at an angle with certain blend modes. It seems that there were some edge cases that weren't considered when the SW_RenderCopyEx function was last changed. Or another bug possibly covered up the problem. (More on that in another bug report.) Most of the issues come from the fact that the rotating function sets a black colorkey. This is problematic because black is most likely appearing in the surface and the final blit will ignore these pixels. Unless a colorkey is already set (the software renderer currently never sets one), it's very hard to find a free color. Of course it could scan over the whole image until one is found, but that seems inefficient. The following blend modes have issues when drawn at an angle. NONE: The black pixels get ignored, making them essentially transparent. This breaks the 'dstRGBA = srcRGBA' definition of the NONE blend mode. MOD: Again, the black pixels get ignored. This also breaks the 'dstRGB = dstRGB * srcRGB' definition of the MOD blend mode, where black pixels would make the destination black as well. A white colorkey will work though, with some preparations. BLEND: There are some issues when blending a texture with a translucent RGBA target texture. I - uh - forgot what the problem here exactly is. This patch fixes the issues mentioned above. It mainly changes the code so it tries to do things without the colorkey and removes the automatic format conversion part from the SDLgfx_rotateSurface function. Getting the format right is something the caller has to do now and the required code has been added to the SW_RenderCopyEx function. There's a small change to the SW_CreateTexture function. RLE encoding a surface with an alpha mask can be a lossy process. Depending on how the user uses the RGBA channels, this may be undesired. The change that surfaces with an alpha mask don't get encoded makes the software renderer consistent with the other renderers. The SW_RenderCopyEx function now does these steps: Lock the source surface if necessary. Create a clone of the source by using the pixel buffer directly. Check the format and set a flag if a conversion is necessary. Check if scaling or cropping is necessary and set the flag for that as well. Check if color and alpha modulation has to be done before the rotate. Check if the source is an opaque surface. If not, it creates a mask surface that is necessary for the NONE blend mode. If any of the flags were set, a new surface is created and the source will be converted, scaled, cropped, and modulated. The rest of the function stays somewhat the same. The mask also needs to be rotated of course and then there is the NONE blend mode... It's surprisingly hard to get the pixel from a rotated surface to the destination buffer without affecting the pixel outside the rotated area. I found a way to do this with three blits which is pretty hard on the performance. Perhaps someone has an idea how to do this faster? As mentioned above, the SDLgfx_rotateSurface now only takes 8-bit paletted or 32-bit with alpha mask surfaces. It additionally sets the new surfaces up for the MOD blend mode. I shortly tested the 8-bit path of SDLgfx_rotateSurface and it seemed to work so far. This path is not used by the software renderer anyway.
2016-11-15 01:12:27 -08:00
} else {
/* The NONE blend mode requires three steps to get the pixels onto the destination surface.
* First, the area where the rotated pixels will be blitted to get set to zero.
* This is accomplished by simply blitting a mask with the NONE blend mode.
* The colorkey set by the rotate function will discard the correct pixels.
*/
SDL_Rect mask_rect = tmp_rect;
SDL_SetSurfaceBlendMode(mask_rotated, SDL_BLENDMODE_NONE);
/* Renderer scaling, if needed */
retval = Blit_to_Screen(mask_rotated, NULL, surface, &mask_rect, scale_x, scale_y, texture->scaleMode);
Fixed bug 3359 - Software renderer does incorrect blending with SDL_RenderCopyEx Simon Hug The software renderer produces incorrect results when blending textures at an angle with certain blend modes. It seems that there were some edge cases that weren't considered when the SW_RenderCopyEx function was last changed. Or another bug possibly covered up the problem. (More on that in another bug report.) Most of the issues come from the fact that the rotating function sets a black colorkey. This is problematic because black is most likely appearing in the surface and the final blit will ignore these pixels. Unless a colorkey is already set (the software renderer currently never sets one), it's very hard to find a free color. Of course it could scan over the whole image until one is found, but that seems inefficient. The following blend modes have issues when drawn at an angle. NONE: The black pixels get ignored, making them essentially transparent. This breaks the 'dstRGBA = srcRGBA' definition of the NONE blend mode. MOD: Again, the black pixels get ignored. This also breaks the 'dstRGB = dstRGB * srcRGB' definition of the MOD blend mode, where black pixels would make the destination black as well. A white colorkey will work though, with some preparations. BLEND: There are some issues when blending a texture with a translucent RGBA target texture. I - uh - forgot what the problem here exactly is. This patch fixes the issues mentioned above. It mainly changes the code so it tries to do things without the colorkey and removes the automatic format conversion part from the SDLgfx_rotateSurface function. Getting the format right is something the caller has to do now and the required code has been added to the SW_RenderCopyEx function. There's a small change to the SW_CreateTexture function. RLE encoding a surface with an alpha mask can be a lossy process. Depending on how the user uses the RGBA channels, this may be undesired. The change that surfaces with an alpha mask don't get encoded makes the software renderer consistent with the other renderers. The SW_RenderCopyEx function now does these steps: Lock the source surface if necessary. Create a clone of the source by using the pixel buffer directly. Check the format and set a flag if a conversion is necessary. Check if scaling or cropping is necessary and set the flag for that as well. Check if color and alpha modulation has to be done before the rotate. Check if the source is an opaque surface. If not, it creates a mask surface that is necessary for the NONE blend mode. If any of the flags were set, a new surface is created and the source will be converted, scaled, cropped, and modulated. The rest of the function stays somewhat the same. The mask also needs to be rotated of course and then there is the NONE blend mode... It's surprisingly hard to get the pixel from a rotated surface to the destination buffer without affecting the pixel outside the rotated area. I found a way to do this with three blits which is pretty hard on the performance. Perhaps someone has an idea how to do this faster? As mentioned above, the SDLgfx_rotateSurface now only takes 8-bit paletted or 32-bit with alpha mask surfaces. It additionally sets the new surfaces up for the MOD blend mode. I shortly tested the 8-bit path of SDLgfx_rotateSurface and it seemed to work so far. This path is not used by the software renderer anyway.
2016-11-15 01:12:27 -08:00
if (!retval) {
/* The next step copies the alpha value. This is done with the BLEND blend mode and
* by modulating the source colors with 0. Since the destination is all zeros, this
* will effectively set the destination alpha to the source alpha.
*/
SDL_SetSurfaceColorMod(src_rotated, 0, 0, 0);
mask_rect = tmp_rect;
/* Renderer scaling, if needed */
retval = Blit_to_Screen(src_rotated, NULL, surface, &mask_rect, scale_x, scale_y, texture->scaleMode);
Fixed bug 3359 - Software renderer does incorrect blending with SDL_RenderCopyEx Simon Hug The software renderer produces incorrect results when blending textures at an angle with certain blend modes. It seems that there were some edge cases that weren't considered when the SW_RenderCopyEx function was last changed. Or another bug possibly covered up the problem. (More on that in another bug report.) Most of the issues come from the fact that the rotating function sets a black colorkey. This is problematic because black is most likely appearing in the surface and the final blit will ignore these pixels. Unless a colorkey is already set (the software renderer currently never sets one), it's very hard to find a free color. Of course it could scan over the whole image until one is found, but that seems inefficient. The following blend modes have issues when drawn at an angle. NONE: The black pixels get ignored, making them essentially transparent. This breaks the 'dstRGBA = srcRGBA' definition of the NONE blend mode. MOD: Again, the black pixels get ignored. This also breaks the 'dstRGB = dstRGB * srcRGB' definition of the MOD blend mode, where black pixels would make the destination black as well. A white colorkey will work though, with some preparations. BLEND: There are some issues when blending a texture with a translucent RGBA target texture. I - uh - forgot what the problem here exactly is. This patch fixes the issues mentioned above. It mainly changes the code so it tries to do things without the colorkey and removes the automatic format conversion part from the SDLgfx_rotateSurface function. Getting the format right is something the caller has to do now and the required code has been added to the SW_RenderCopyEx function. There's a small change to the SW_CreateTexture function. RLE encoding a surface with an alpha mask can be a lossy process. Depending on how the user uses the RGBA channels, this may be undesired. The change that surfaces with an alpha mask don't get encoded makes the software renderer consistent with the other renderers. The SW_RenderCopyEx function now does these steps: Lock the source surface if necessary. Create a clone of the source by using the pixel buffer directly. Check the format and set a flag if a conversion is necessary. Check if scaling or cropping is necessary and set the flag for that as well. Check if color and alpha modulation has to be done before the rotate. Check if the source is an opaque surface. If not, it creates a mask surface that is necessary for the NONE blend mode. If any of the flags were set, a new surface is created and the source will be converted, scaled, cropped, and modulated. The rest of the function stays somewhat the same. The mask also needs to be rotated of course and then there is the NONE blend mode... It's surprisingly hard to get the pixel from a rotated surface to the destination buffer without affecting the pixel outside the rotated area. I found a way to do this with three blits which is pretty hard on the performance. Perhaps someone has an idea how to do this faster? As mentioned above, the SDLgfx_rotateSurface now only takes 8-bit paletted or 32-bit with alpha mask surfaces. It additionally sets the new surfaces up for the MOD blend mode. I shortly tested the 8-bit path of SDLgfx_rotateSurface and it seemed to work so far. This path is not used by the software renderer anyway.
2016-11-15 01:12:27 -08:00
if (!retval) {
/* The last step gets the color values in place. The ADD blend mode simply adds them to
* the destination (where the color values are all zero). However, because the ADD blend
* mode modulates the colors with the alpha channel, a surface without an alpha mask needs
* to be created. This makes all source pixels opaque and the colors get copied correctly.
*/
SDL_Surface *src_rotated_rgb;
int f = SDL_GetPixelFormatEnumForMasks(src_rotated->format->BitsPerPixel,
src_rotated->format->Rmask,
src_rotated->format->Gmask,
src_rotated->format->Bmask,
0);
src_rotated_rgb = SDL_CreateSurfaceFrom(src_rotated->pixels, src_rotated->w, src_rotated->h,
src_rotated->pitch, f);
Fixed bug 3359 - Software renderer does incorrect blending with SDL_RenderCopyEx Simon Hug The software renderer produces incorrect results when blending textures at an angle with certain blend modes. It seems that there were some edge cases that weren't considered when the SW_RenderCopyEx function was last changed. Or another bug possibly covered up the problem. (More on that in another bug report.) Most of the issues come from the fact that the rotating function sets a black colorkey. This is problematic because black is most likely appearing in the surface and the final blit will ignore these pixels. Unless a colorkey is already set (the software renderer currently never sets one), it's very hard to find a free color. Of course it could scan over the whole image until one is found, but that seems inefficient. The following blend modes have issues when drawn at an angle. NONE: The black pixels get ignored, making them essentially transparent. This breaks the 'dstRGBA = srcRGBA' definition of the NONE blend mode. MOD: Again, the black pixels get ignored. This also breaks the 'dstRGB = dstRGB * srcRGB' definition of the MOD blend mode, where black pixels would make the destination black as well. A white colorkey will work though, with some preparations. BLEND: There are some issues when blending a texture with a translucent RGBA target texture. I - uh - forgot what the problem here exactly is. This patch fixes the issues mentioned above. It mainly changes the code so it tries to do things without the colorkey and removes the automatic format conversion part from the SDLgfx_rotateSurface function. Getting the format right is something the caller has to do now and the required code has been added to the SW_RenderCopyEx function. There's a small change to the SW_CreateTexture function. RLE encoding a surface with an alpha mask can be a lossy process. Depending on how the user uses the RGBA channels, this may be undesired. The change that surfaces with an alpha mask don't get encoded makes the software renderer consistent with the other renderers. The SW_RenderCopyEx function now does these steps: Lock the source surface if necessary. Create a clone of the source by using the pixel buffer directly. Check the format and set a flag if a conversion is necessary. Check if scaling or cropping is necessary and set the flag for that as well. Check if color and alpha modulation has to be done before the rotate. Check if the source is an opaque surface. If not, it creates a mask surface that is necessary for the NONE blend mode. If any of the flags were set, a new surface is created and the source will be converted, scaled, cropped, and modulated. The rest of the function stays somewhat the same. The mask also needs to be rotated of course and then there is the NONE blend mode... It's surprisingly hard to get the pixel from a rotated surface to the destination buffer without affecting the pixel outside the rotated area. I found a way to do this with three blits which is pretty hard on the performance. Perhaps someone has an idea how to do this faster? As mentioned above, the SDLgfx_rotateSurface now only takes 8-bit paletted or 32-bit with alpha mask surfaces. It additionally sets the new surfaces up for the MOD blend mode. I shortly tested the 8-bit path of SDLgfx_rotateSurface and it seemed to work so far. This path is not used by the software renderer anyway.
2016-11-15 01:12:27 -08:00
if (src_rotated_rgb == NULL) {
retval = -1;
} else {
SDL_SetSurfaceBlendMode(src_rotated_rgb, SDL_BLENDMODE_ADD);
/* Renderer scaling, if needed */
retval = Blit_to_Screen(src_rotated_rgb, NULL, surface, &tmp_rect, scale_x, scale_y, texture->scaleMode);
SDL_DestroySurface(src_rotated_rgb);
Fixed bug 3359 - Software renderer does incorrect blending with SDL_RenderCopyEx Simon Hug The software renderer produces incorrect results when blending textures at an angle with certain blend modes. It seems that there were some edge cases that weren't considered when the SW_RenderCopyEx function was last changed. Or another bug possibly covered up the problem. (More on that in another bug report.) Most of the issues come from the fact that the rotating function sets a black colorkey. This is problematic because black is most likely appearing in the surface and the final blit will ignore these pixels. Unless a colorkey is already set (the software renderer currently never sets one), it's very hard to find a free color. Of course it could scan over the whole image until one is found, but that seems inefficient. The following blend modes have issues when drawn at an angle. NONE: The black pixels get ignored, making them essentially transparent. This breaks the 'dstRGBA = srcRGBA' definition of the NONE blend mode. MOD: Again, the black pixels get ignored. This also breaks the 'dstRGB = dstRGB * srcRGB' definition of the MOD blend mode, where black pixels would make the destination black as well. A white colorkey will work though, with some preparations. BLEND: There are some issues when blending a texture with a translucent RGBA target texture. I - uh - forgot what the problem here exactly is. This patch fixes the issues mentioned above. It mainly changes the code so it tries to do things without the colorkey and removes the automatic format conversion part from the SDLgfx_rotateSurface function. Getting the format right is something the caller has to do now and the required code has been added to the SW_RenderCopyEx function. There's a small change to the SW_CreateTexture function. RLE encoding a surface with an alpha mask can be a lossy process. Depending on how the user uses the RGBA channels, this may be undesired. The change that surfaces with an alpha mask don't get encoded makes the software renderer consistent with the other renderers. The SW_RenderCopyEx function now does these steps: Lock the source surface if necessary. Create a clone of the source by using the pixel buffer directly. Check the format and set a flag if a conversion is necessary. Check if scaling or cropping is necessary and set the flag for that as well. Check if color and alpha modulation has to be done before the rotate. Check if the source is an opaque surface. If not, it creates a mask surface that is necessary for the NONE blend mode. If any of the flags were set, a new surface is created and the source will be converted, scaled, cropped, and modulated. The rest of the function stays somewhat the same. The mask also needs to be rotated of course and then there is the NONE blend mode... It's surprisingly hard to get the pixel from a rotated surface to the destination buffer without affecting the pixel outside the rotated area. I found a way to do this with three blits which is pretty hard on the performance. Perhaps someone has an idea how to do this faster? As mentioned above, the SDLgfx_rotateSurface now only takes 8-bit paletted or 32-bit with alpha mask surfaces. It additionally sets the new surfaces up for the MOD blend mode. I shortly tested the 8-bit path of SDLgfx_rotateSurface and it seemed to work so far. This path is not used by the software renderer anyway.
2016-11-15 01:12:27 -08:00
}
}
}
SDL_DestroySurface(mask_rotated);
Fixed bug 3359 - Software renderer does incorrect blending with SDL_RenderCopyEx Simon Hug The software renderer produces incorrect results when blending textures at an angle with certain blend modes. It seems that there were some edge cases that weren't considered when the SW_RenderCopyEx function was last changed. Or another bug possibly covered up the problem. (More on that in another bug report.) Most of the issues come from the fact that the rotating function sets a black colorkey. This is problematic because black is most likely appearing in the surface and the final blit will ignore these pixels. Unless a colorkey is already set (the software renderer currently never sets one), it's very hard to find a free color. Of course it could scan over the whole image until one is found, but that seems inefficient. The following blend modes have issues when drawn at an angle. NONE: The black pixels get ignored, making them essentially transparent. This breaks the 'dstRGBA = srcRGBA' definition of the NONE blend mode. MOD: Again, the black pixels get ignored. This also breaks the 'dstRGB = dstRGB * srcRGB' definition of the MOD blend mode, where black pixels would make the destination black as well. A white colorkey will work though, with some preparations. BLEND: There are some issues when blending a texture with a translucent RGBA target texture. I - uh - forgot what the problem here exactly is. This patch fixes the issues mentioned above. It mainly changes the code so it tries to do things without the colorkey and removes the automatic format conversion part from the SDLgfx_rotateSurface function. Getting the format right is something the caller has to do now and the required code has been added to the SW_RenderCopyEx function. There's a small change to the SW_CreateTexture function. RLE encoding a surface with an alpha mask can be a lossy process. Depending on how the user uses the RGBA channels, this may be undesired. The change that surfaces with an alpha mask don't get encoded makes the software renderer consistent with the other renderers. The SW_RenderCopyEx function now does these steps: Lock the source surface if necessary. Create a clone of the source by using the pixel buffer directly. Check the format and set a flag if a conversion is necessary. Check if scaling or cropping is necessary and set the flag for that as well. Check if color and alpha modulation has to be done before the rotate. Check if the source is an opaque surface. If not, it creates a mask surface that is necessary for the NONE blend mode. If any of the flags were set, a new surface is created and the source will be converted, scaled, cropped, and modulated. The rest of the function stays somewhat the same. The mask also needs to be rotated of course and then there is the NONE blend mode... It's surprisingly hard to get the pixel from a rotated surface to the destination buffer without affecting the pixel outside the rotated area. I found a way to do this with three blits which is pretty hard on the performance. Perhaps someone has an idea how to do this faster? As mentioned above, the SDLgfx_rotateSurface now only takes 8-bit paletted or 32-bit with alpha mask surfaces. It additionally sets the new surfaces up for the MOD blend mode. I shortly tested the 8-bit path of SDLgfx_rotateSurface and it seemed to work so far. This path is not used by the software renderer anyway.
2016-11-15 01:12:27 -08:00
}
if (src_rotated != NULL) {
SDL_DestroySurface(src_rotated);
Fixed bug 3359 - Software renderer does incorrect blending with SDL_RenderCopyEx Simon Hug The software renderer produces incorrect results when blending textures at an angle with certain blend modes. It seems that there were some edge cases that weren't considered when the SW_RenderCopyEx function was last changed. Or another bug possibly covered up the problem. (More on that in another bug report.) Most of the issues come from the fact that the rotating function sets a black colorkey. This is problematic because black is most likely appearing in the surface and the final blit will ignore these pixels. Unless a colorkey is already set (the software renderer currently never sets one), it's very hard to find a free color. Of course it could scan over the whole image until one is found, but that seems inefficient. The following blend modes have issues when drawn at an angle. NONE: The black pixels get ignored, making them essentially transparent. This breaks the 'dstRGBA = srcRGBA' definition of the NONE blend mode. MOD: Again, the black pixels get ignored. This also breaks the 'dstRGB = dstRGB * srcRGB' definition of the MOD blend mode, where black pixels would make the destination black as well. A white colorkey will work though, with some preparations. BLEND: There are some issues when blending a texture with a translucent RGBA target texture. I - uh - forgot what the problem here exactly is. This patch fixes the issues mentioned above. It mainly changes the code so it tries to do things without the colorkey and removes the automatic format conversion part from the SDLgfx_rotateSurface function. Getting the format right is something the caller has to do now and the required code has been added to the SW_RenderCopyEx function. There's a small change to the SW_CreateTexture function. RLE encoding a surface with an alpha mask can be a lossy process. Depending on how the user uses the RGBA channels, this may be undesired. The change that surfaces with an alpha mask don't get encoded makes the software renderer consistent with the other renderers. The SW_RenderCopyEx function now does these steps: Lock the source surface if necessary. Create a clone of the source by using the pixel buffer directly. Check the format and set a flag if a conversion is necessary. Check if scaling or cropping is necessary and set the flag for that as well. Check if color and alpha modulation has to be done before the rotate. Check if the source is an opaque surface. If not, it creates a mask surface that is necessary for the NONE blend mode. If any of the flags were set, a new surface is created and the source will be converted, scaled, cropped, and modulated. The rest of the function stays somewhat the same. The mask also needs to be rotated of course and then there is the NONE blend mode... It's surprisingly hard to get the pixel from a rotated surface to the destination buffer without affecting the pixel outside the rotated area. I found a way to do this with three blits which is pretty hard on the performance. Perhaps someone has an idea how to do this faster? As mentioned above, the SDLgfx_rotateSurface now only takes 8-bit paletted or 32-bit with alpha mask surfaces. It additionally sets the new surfaces up for the MOD blend mode. I shortly tested the 8-bit path of SDLgfx_rotateSurface and it seemed to work so far. This path is not used by the software renderer anyway.
2016-11-15 01:12:27 -08:00
}
}
}
Fixed bug 3359 - Software renderer does incorrect blending with SDL_RenderCopyEx Simon Hug The software renderer produces incorrect results when blending textures at an angle with certain blend modes. It seems that there were some edge cases that weren't considered when the SW_RenderCopyEx function was last changed. Or another bug possibly covered up the problem. (More on that in another bug report.) Most of the issues come from the fact that the rotating function sets a black colorkey. This is problematic because black is most likely appearing in the surface and the final blit will ignore these pixels. Unless a colorkey is already set (the software renderer currently never sets one), it's very hard to find a free color. Of course it could scan over the whole image until one is found, but that seems inefficient. The following blend modes have issues when drawn at an angle. NONE: The black pixels get ignored, making them essentially transparent. This breaks the 'dstRGBA = srcRGBA' definition of the NONE blend mode. MOD: Again, the black pixels get ignored. This also breaks the 'dstRGB = dstRGB * srcRGB' definition of the MOD blend mode, where black pixels would make the destination black as well. A white colorkey will work though, with some preparations. BLEND: There are some issues when blending a texture with a translucent RGBA target texture. I - uh - forgot what the problem here exactly is. This patch fixes the issues mentioned above. It mainly changes the code so it tries to do things without the colorkey and removes the automatic format conversion part from the SDLgfx_rotateSurface function. Getting the format right is something the caller has to do now and the required code has been added to the SW_RenderCopyEx function. There's a small change to the SW_CreateTexture function. RLE encoding a surface with an alpha mask can be a lossy process. Depending on how the user uses the RGBA channels, this may be undesired. The change that surfaces with an alpha mask don't get encoded makes the software renderer consistent with the other renderers. The SW_RenderCopyEx function now does these steps: Lock the source surface if necessary. Create a clone of the source by using the pixel buffer directly. Check the format and set a flag if a conversion is necessary. Check if scaling or cropping is necessary and set the flag for that as well. Check if color and alpha modulation has to be done before the rotate. Check if the source is an opaque surface. If not, it creates a mask surface that is necessary for the NONE blend mode. If any of the flags were set, a new surface is created and the source will be converted, scaled, cropped, and modulated. The rest of the function stays somewhat the same. The mask also needs to be rotated of course and then there is the NONE blend mode... It's surprisingly hard to get the pixel from a rotated surface to the destination buffer without affecting the pixel outside the rotated area. I found a way to do this with three blits which is pretty hard on the performance. Perhaps someone has an idea how to do this faster? As mentioned above, the SDLgfx_rotateSurface now only takes 8-bit paletted or 32-bit with alpha mask surfaces. It additionally sets the new surfaces up for the MOD blend mode. I shortly tested the 8-bit path of SDLgfx_rotateSurface and it seemed to work so far. This path is not used by the software renderer anyway.
2016-11-15 01:12:27 -08:00
if (SDL_MUSTLOCK(src)) {
SDL_UnlockSurface(src);
}
if (mask != NULL) {
SDL_DestroySurface(mask);
Fixed bug 3359 - Software renderer does incorrect blending with SDL_RenderCopyEx Simon Hug The software renderer produces incorrect results when blending textures at an angle with certain blend modes. It seems that there were some edge cases that weren't considered when the SW_RenderCopyEx function was last changed. Or another bug possibly covered up the problem. (More on that in another bug report.) Most of the issues come from the fact that the rotating function sets a black colorkey. This is problematic because black is most likely appearing in the surface and the final blit will ignore these pixels. Unless a colorkey is already set (the software renderer currently never sets one), it's very hard to find a free color. Of course it could scan over the whole image until one is found, but that seems inefficient. The following blend modes have issues when drawn at an angle. NONE: The black pixels get ignored, making them essentially transparent. This breaks the 'dstRGBA = srcRGBA' definition of the NONE blend mode. MOD: Again, the black pixels get ignored. This also breaks the 'dstRGB = dstRGB * srcRGB' definition of the MOD blend mode, where black pixels would make the destination black as well. A white colorkey will work though, with some preparations. BLEND: There are some issues when blending a texture with a translucent RGBA target texture. I - uh - forgot what the problem here exactly is. This patch fixes the issues mentioned above. It mainly changes the code so it tries to do things without the colorkey and removes the automatic format conversion part from the SDLgfx_rotateSurface function. Getting the format right is something the caller has to do now and the required code has been added to the SW_RenderCopyEx function. There's a small change to the SW_CreateTexture function. RLE encoding a surface with an alpha mask can be a lossy process. Depending on how the user uses the RGBA channels, this may be undesired. The change that surfaces with an alpha mask don't get encoded makes the software renderer consistent with the other renderers. The SW_RenderCopyEx function now does these steps: Lock the source surface if necessary. Create a clone of the source by using the pixel buffer directly. Check the format and set a flag if a conversion is necessary. Check if scaling or cropping is necessary and set the flag for that as well. Check if color and alpha modulation has to be done before the rotate. Check if the source is an opaque surface. If not, it creates a mask surface that is necessary for the NONE blend mode. If any of the flags were set, a new surface is created and the source will be converted, scaled, cropped, and modulated. The rest of the function stays somewhat the same. The mask also needs to be rotated of course and then there is the NONE blend mode... It's surprisingly hard to get the pixel from a rotated surface to the destination buffer without affecting the pixel outside the rotated area. I found a way to do this with three blits which is pretty hard on the performance. Perhaps someone has an idea how to do this faster? As mentioned above, the SDLgfx_rotateSurface now only takes 8-bit paletted or 32-bit with alpha mask surfaces. It additionally sets the new surfaces up for the MOD blend mode. I shortly tested the 8-bit path of SDLgfx_rotateSurface and it seemed to work so far. This path is not used by the software renderer anyway.
2016-11-15 01:12:27 -08:00
}
if (src_clone != NULL) {
SDL_DestroySurface(src_clone);
}
return retval;
}
2021-03-16 15:14:58 +01:00
typedef struct GeometryFillData
{
SDL_Point dst;
SDL_Color color;
} GeometryFillData;
typedef struct GeometryCopyData
{
SDL_Point src;
SDL_Point dst;
SDL_Color color;
} GeometryCopyData;
static int SW_QueueGeometry(SDL_Renderer *renderer, SDL_RenderCommand *cmd, SDL_Texture *texture,
const float *xy, int xy_stride, const SDL_Color *color, int color_stride, const float *uv, int uv_stride,
int num_vertices, const void *indices, int num_indices, int size_indices,
float scale_x, float scale_y)
2021-03-16 15:14:58 +01:00
{
int i;
int count = indices ? num_indices : num_vertices;
void *verts;
2022-12-01 16:07:03 -05:00
size_t sz = texture != NULL ? sizeof(GeometryCopyData) : sizeof(GeometryFillData);
2021-03-16 15:14:58 +01:00
2022-12-01 16:07:03 -05:00
verts = SDL_AllocateRenderVertices(renderer, count * sz, 0, &cmd->data.draw.first);
if (verts == NULL) {
2021-03-16 15:14:58 +01:00
return -1;
}
cmd->data.draw.count = count;
size_indices = indices ? size_indices : 0;
2021-03-16 15:14:58 +01:00
if (texture) {
GeometryCopyData *ptr = (GeometryCopyData *)verts;
2021-03-16 15:14:58 +01:00
for (i = 0; i < count; i++) {
int j;
float *xy_;
SDL_Color col_;
float *uv_;
2021-04-23 12:00:14 +02:00
if (size_indices == 4) {
j = ((const Uint32 *)indices)[i];
2021-04-23 12:00:14 +02:00
} else if (size_indices == 2) {
j = ((const Uint16 *)indices)[i];
2021-04-23 12:00:14 +02:00
} else if (size_indices == 1) {
j = ((const Uint8 *)indices)[i];
} else {
j = i;
}
xy_ = (float *)((char *)xy + j * xy_stride);
col_ = *(SDL_Color *)((char *)color + j * color_stride);
uv_ = (float *)((char *)uv + j * uv_stride);
2021-03-16 15:14:58 +01:00
2021-04-01 20:18:05 +02:00
ptr->src.x = (int)(uv_[0] * texture->w);
ptr->src.y = (int)(uv_[1] * texture->h);
2021-03-16 15:14:58 +01:00
ptr->dst.x = (int)(xy_[0] * scale_x);
ptr->dst.y = (int)(xy_[1] * scale_y);
2021-03-16 15:14:58 +01:00
trianglepoint_2_fixedpoint(&ptr->dst);
ptr->color = col_;
2021-03-16 15:14:58 +01:00
ptr++;
}
2021-03-16 15:14:58 +01:00
} else {
GeometryFillData *ptr = (GeometryFillData *)verts;
2021-03-16 15:14:58 +01:00
for (i = 0; i < count; i++) {
int j;
float *xy_;
SDL_Color col_;
2021-04-23 12:00:14 +02:00
if (size_indices == 4) {
j = ((const Uint32 *)indices)[i];
2021-04-23 12:00:14 +02:00
} else if (size_indices == 2) {
j = ((const Uint16 *)indices)[i];
2021-04-23 12:00:14 +02:00
} else if (size_indices == 1) {
j = ((const Uint8 *)indices)[i];
} else {
j = i;
}
2021-03-16 15:14:58 +01:00
xy_ = (float *)((char *)xy + j * xy_stride);
col_ = *(SDL_Color *)((char *)color + j * color_stride);
ptr->dst.x = (int)(xy_[0] * scale_x);
ptr->dst.y = (int)(xy_[1] * scale_y);
2021-03-16 15:14:58 +01:00
trianglepoint_2_fixedpoint(&ptr->dst);
ptr->color = col_;
2021-03-16 15:14:58 +01:00
ptr++;
}
2021-03-16 15:14:58 +01:00
}
return 0;
}
static void PrepTextureForCopy(const SDL_RenderCommand *cmd)
{
const Uint8 r = cmd->data.draw.r;
const Uint8 g = cmd->data.draw.g;
const Uint8 b = cmd->data.draw.b;
const Uint8 a = cmd->data.draw.a;
const SDL_BlendMode blend = cmd->data.draw.blend;
SDL_Texture *texture = cmd->data.draw.texture;
SDL_Surface *surface = (SDL_Surface *)texture->driverdata;
const SDL_bool colormod = ((r & g & b) != 0xFF);
const SDL_bool alphamod = (a != 0xFF);
const SDL_bool blending = ((blend == SDL_BLENDMODE_ADD) || (blend == SDL_BLENDMODE_MOD) || (blend == SDL_BLENDMODE_MUL));
if (colormod || alphamod || blending) {
SDL_SetSurfaceRLE(surface, 0);
}
/* !!! FIXME: we can probably avoid some of these calls. */
SDL_SetSurfaceColorMod(surface, r, g, b);
SDL_SetSurfaceAlphaMod(surface, a);
SDL_SetSurfaceBlendMode(surface, blend);
}
static void SetDrawState(SDL_Surface *surface, SW_DrawStateCache *drawstate)
{
if (drawstate->surface_cliprect_dirty) {
const SDL_Rect *viewport = drawstate->viewport;
const SDL_Rect *cliprect = drawstate->cliprect;
2022-12-01 16:07:03 -05:00
SDL_assert_release(viewport != NULL); /* the higher level should have forced a SDL_RENDERCMD_SETVIEWPORT */
if (cliprect != NULL) {
SDL_Rect clip_rect;
clip_rect.x = cliprect->x + viewport->x;
clip_rect.y = cliprect->y + viewport->y;
clip_rect.w = cliprect->w;
clip_rect.h = cliprect->h;
SDL_GetRectIntersection(viewport, &clip_rect, &clip_rect);
SDL_SetSurfaceClipRect(surface, &clip_rect);
} else {
SDL_SetSurfaceClipRect(surface, drawstate->viewport);
}
drawstate->surface_cliprect_dirty = SDL_FALSE;
}
}
static int SW_RunCommandQueue(SDL_Renderer *renderer, SDL_RenderCommand *cmd, void *vertices, size_t vertsize)
{
SDL_Surface *surface = SW_ActivateRenderer(renderer);
SW_DrawStateCache drawstate;
if (surface == NULL) {
return -1;
}
drawstate.viewport = NULL;
drawstate.cliprect = NULL;
drawstate.surface_cliprect_dirty = SDL_TRUE;
while (cmd) {
switch (cmd->command) {
case SDL_RENDERCMD_SETDRAWCOLOR:
{
break; /* Not used in this backend. */
}
case SDL_RENDERCMD_SETVIEWPORT:
{
drawstate.viewport = &cmd->data.viewport.rect;
drawstate.surface_cliprect_dirty = SDL_TRUE;
break;
}
case SDL_RENDERCMD_SETCLIPRECT:
{
drawstate.cliprect = cmd->data.cliprect.enabled ? &cmd->data.cliprect.rect : NULL;
drawstate.surface_cliprect_dirty = SDL_TRUE;
break;
}
case SDL_RENDERCMD_CLEAR:
{
const Uint8 r = cmd->data.color.r;
const Uint8 g = cmd->data.color.g;
const Uint8 b = cmd->data.color.b;
const Uint8 a = cmd->data.color.a;
/* By definition the clear ignores the clip rect */
SDL_SetSurfaceClipRect(surface, NULL);
SDL_FillSurfaceRect(surface, NULL, SDL_MapRGBA(surface->format, r, g, b, a));
drawstate.surface_cliprect_dirty = SDL_TRUE;
break;
}
case SDL_RENDERCMD_DRAW_POINTS:
{
const Uint8 r = cmd->data.draw.r;
const Uint8 g = cmd->data.draw.g;
const Uint8 b = cmd->data.draw.b;
const Uint8 a = cmd->data.draw.a;
const int count = (int)cmd->data.draw.count;
SDL_Point *verts = (SDL_Point *)(((Uint8 *)vertices) + cmd->data.draw.first);
const SDL_BlendMode blend = cmd->data.draw.blend;
SetDrawState(surface, &drawstate);
/* Apply viewport */
if (drawstate.viewport != NULL && (drawstate.viewport->x || drawstate.viewport->y)) {
int i;
for (i = 0; i < count; i++) {
verts[i].x += drawstate.viewport->x;
verts[i].y += drawstate.viewport->y;
}
}
if (blend == SDL_BLENDMODE_NONE) {
SDL_DrawPoints(surface, verts, count, SDL_MapRGBA(surface->format, r, g, b, a));
} else {
SDL_BlendPoints(surface, verts, count, blend, r, g, b, a);
}
break;
}
case SDL_RENDERCMD_DRAW_LINES:
{
const Uint8 r = cmd->data.draw.r;
const Uint8 g = cmd->data.draw.g;
const Uint8 b = cmd->data.draw.b;
const Uint8 a = cmd->data.draw.a;
const int count = (int)cmd->data.draw.count;
SDL_Point *verts = (SDL_Point *)(((Uint8 *)vertices) + cmd->data.draw.first);
const SDL_BlendMode blend = cmd->data.draw.blend;
SetDrawState(surface, &drawstate);
/* Apply viewport */
if (drawstate.viewport != NULL && (drawstate.viewport->x || drawstate.viewport->y)) {
int i;
for (i = 0; i < count; i++) {
verts[i].x += drawstate.viewport->x;
verts[i].y += drawstate.viewport->y;
}
}
if (blend == SDL_BLENDMODE_NONE) {
SDL_DrawLines(surface, verts, count, SDL_MapRGBA(surface->format, r, g, b, a));
} else {
SDL_BlendLines(surface, verts, count, blend, r, g, b, a);
}
break;
}
case SDL_RENDERCMD_FILL_RECTS:
{
const Uint8 r = cmd->data.draw.r;
const Uint8 g = cmd->data.draw.g;
const Uint8 b = cmd->data.draw.b;
const Uint8 a = cmd->data.draw.a;
const int count = (int)cmd->data.draw.count;
SDL_Rect *verts = (SDL_Rect *)(((Uint8 *)vertices) + cmd->data.draw.first);
const SDL_BlendMode blend = cmd->data.draw.blend;
SetDrawState(surface, &drawstate);
/* Apply viewport */
if (drawstate.viewport != NULL && (drawstate.viewport->x || drawstate.viewport->y)) {
int i;
for (i = 0; i < count; i++) {
verts[i].x += drawstate.viewport->x;
verts[i].y += drawstate.viewport->y;
}
}
if (blend == SDL_BLENDMODE_NONE) {
SDL_FillSurfaceRects(surface, verts, count, SDL_MapRGBA(surface->format, r, g, b, a));
} else {
SDL_BlendFillRects(surface, verts, count, blend, r, g, b, a);
}
break;
}
case SDL_RENDERCMD_COPY:
{
SDL_Rect *verts = (SDL_Rect *)(((Uint8 *)vertices) + cmd->data.draw.first);
const SDL_Rect *srcrect = verts;
SDL_Rect *dstrect = verts + 1;
SDL_Texture *texture = cmd->data.draw.texture;
SDL_Surface *src = (SDL_Surface *)texture->driverdata;
SetDrawState(surface, &drawstate);
PrepTextureForCopy(cmd);
/* Apply viewport */
if (drawstate.viewport != NULL && (drawstate.viewport->x || drawstate.viewport->y)) {
dstrect->x += drawstate.viewport->x;
dstrect->y += drawstate.viewport->y;
}
if (srcrect->w == dstrect->w && srcrect->h == dstrect->h) {
SDL_BlitSurface(src, srcrect, surface, dstrect);
} else {
/* If scaling is ever done, permanently disable RLE (which doesn't support scaling)
* to avoid potentially frequent RLE encoding/decoding.
*/
SDL_SetSurfaceRLE(surface, 0);
/* Prevent to do scaling + clipping on viewport boundaries as it may lose proportion */
if (dstrect->x < 0 || dstrect->y < 0 || dstrect->x + dstrect->w > surface->w || dstrect->y + dstrect->h > surface->h) {
SDL_Surface *tmp = SDL_CreateSurface(dstrect->w, dstrect->h, src->format->format);
/* Scale to an intermediate surface, then blit */
if (tmp) {
SDL_Rect r;
SDL_BlendMode blendmode;
Uint8 alphaMod, rMod, gMod, bMod;
SDL_GetSurfaceBlendMode(src, &blendmode);
SDL_GetSurfaceAlphaMod(src, &alphaMod);
SDL_GetSurfaceColorMod(src, &rMod, &gMod, &bMod);
r.x = 0;
r.y = 0;
r.w = dstrect->w;
r.h = dstrect->h;
SDL_SetSurfaceBlendMode(src, SDL_BLENDMODE_NONE);
SDL_SetSurfaceColorMod(src, 255, 255, 255);
SDL_SetSurfaceAlphaMod(src, 255);
2022-12-27 15:05:51 -08:00
SDL_PrivateBlitSurfaceScaled(src, srcrect, tmp, &r, texture->scaleMode);
SDL_SetSurfaceColorMod(tmp, rMod, gMod, bMod);
SDL_SetSurfaceAlphaMod(tmp, alphaMod);
SDL_SetSurfaceBlendMode(tmp, blendmode);
SDL_BlitSurface(tmp, NULL, surface, dstrect);
SDL_DestroySurface(tmp);
/* No need to set back r/g/b/a/blendmode to 'src' since it's done in PrepTextureForCopy() */
}
} else {
2022-12-27 15:05:51 -08:00
SDL_PrivateBlitSurfaceScaled(src, srcrect, surface, dstrect, texture->scaleMode);
}
}
break;
}
case SDL_RENDERCMD_COPY_EX:
{
CopyExData *copydata = (CopyExData *)(((Uint8 *)vertices) + cmd->data.draw.first);
SetDrawState(surface, &drawstate);
PrepTextureForCopy(cmd);
/* Apply viewport */
if (drawstate.viewport != NULL && (drawstate.viewport->x || drawstate.viewport->y)) {
copydata->dstrect.x += drawstate.viewport->x;
copydata->dstrect.y += drawstate.viewport->y;
}
SW_RenderCopyEx(renderer, surface, cmd->data.draw.texture, &copydata->srcrect,
&copydata->dstrect, copydata->angle, &copydata->center, copydata->flip,
copydata->scale_x, copydata->scale_y);
break;
}
2021-03-16 15:14:58 +01:00
case SDL_RENDERCMD_GEOMETRY:
{
int i;
SDL_Rect *verts = (SDL_Rect *)(((Uint8 *)vertices) + cmd->data.draw.first);
const int count = (int)cmd->data.draw.count;
SDL_Texture *texture = cmd->data.draw.texture;
const SDL_BlendMode blend = cmd->data.draw.blend;
2021-03-16 15:14:58 +01:00
SetDrawState(surface, &drawstate);
2021-03-16 15:14:58 +01:00
if (texture) {
SDL_Surface *src = (SDL_Surface *)texture->driverdata;
2021-03-16 15:14:58 +01:00
GeometryCopyData *ptr = (GeometryCopyData *)verts;
PrepTextureForCopy(cmd);
/* Apply viewport */
if (drawstate.viewport != NULL && (drawstate.viewport->x || drawstate.viewport->y)) {
SDL_Point vp;
vp.x = drawstate.viewport->x;
vp.y = drawstate.viewport->y;
trianglepoint_2_fixedpoint(&vp);
for (i = 0; i < count; i++) {
ptr[i].dst.x += vp.x;
ptr[i].dst.y += vp.y;
}
}
for (i = 0; i < count; i += 3, ptr += 3) {
SDL_SW_BlitTriangle(
src,
&(ptr[0].src), &(ptr[1].src), &(ptr[2].src),
surface,
&(ptr[0].dst), &(ptr[1].dst), &(ptr[2].dst),
ptr[0].color, ptr[1].color, ptr[2].color);
}
} else {
GeometryFillData *ptr = (GeometryFillData *)verts;
/* Apply viewport */
if (drawstate.viewport != NULL && (drawstate.viewport->x || drawstate.viewport->y)) {
SDL_Point vp;
vp.x = drawstate.viewport->x;
vp.y = drawstate.viewport->y;
trianglepoint_2_fixedpoint(&vp);
for (i = 0; i < count; i++) {
ptr[i].dst.x += vp.x;
ptr[i].dst.y += vp.y;
2021-03-16 15:14:58 +01:00
}
}
for (i = 0; i < count; i += 3, ptr += 3) {
SDL_SW_FillTriangle(surface, &(ptr[0].dst), &(ptr[1].dst), &(ptr[2].dst), blend, ptr[0].color, ptr[1].color, ptr[2].color);
}
2021-03-16 15:14:58 +01:00
}
break;
}
2021-03-16 15:14:58 +01:00
case SDL_RENDERCMD_NO_OP:
break;
}
cmd = cmd->next;
}
return 0;
}
static int SW_RenderReadPixels(SDL_Renderer *renderer, const SDL_Rect *rect,
Uint32 format, void *pixels, int pitch)
{
SDL_Surface *surface = SW_ActivateRenderer(renderer);
Uint32 src_format;
void *src_pixels;
if (surface == NULL) {
return -1;
}
/* NOTE: The rect is already adjusted according to the viewport by
* SDL_RenderReadPixels.
*/
if (rect->x < 0 || rect->x + rect->w > surface->w ||
rect->y < 0 || rect->y + rect->h > surface->h) {
return SDL_SetError("Tried to read outside of surface bounds");
}
src_format = surface->format->format;
src_pixels = (void *)((Uint8 *)surface->pixels +
rect->y * surface->pitch +
rect->x * surface->format->BytesPerPixel);
return SDL_ConvertPixels(rect->w, rect->h,
src_format, src_pixels, surface->pitch,
format, pixels, pitch);
}
static int SW_RenderPresent(SDL_Renderer *renderer)
{
SDL_Window *window = renderer->window;
if (window == NULL) {
return -1;
}
return SDL_UpdateWindowSurface(window);
}
static void SW_DestroyTexture(SDL_Renderer *renderer, SDL_Texture *texture)
{
SDL_Surface *surface = (SDL_Surface *)texture->driverdata;
SDL_DestroySurface(surface);
}
static void SW_DestroyRenderer(SDL_Renderer *renderer)
{
SW_RenderData *data = (SW_RenderData *)renderer->driverdata;
SDL_free(data);
SDL_free(renderer);
}
static void SW_SelectBestFormats(SDL_Renderer *renderer, Uint32 format)
{
/* Prefer the format used by the framebuffer by default. */
renderer->info.texture_formats[renderer->info.num_texture_formats++] = format;
switch (format) {
case SDL_PIXELFORMAT_XRGB4444:
renderer->info.texture_formats[renderer->info.num_texture_formats++] = SDL_PIXELFORMAT_ARGB4444;
break;
case SDL_PIXELFORMAT_XBGR4444:
renderer->info.texture_formats[renderer->info.num_texture_formats++] = SDL_PIXELFORMAT_ABGR4444;
break;
case SDL_PIXELFORMAT_ARGB4444:
renderer->info.texture_formats[renderer->info.num_texture_formats++] = SDL_PIXELFORMAT_XRGB4444;
break;
case SDL_PIXELFORMAT_ABGR4444:
renderer->info.texture_formats[renderer->info.num_texture_formats++] = SDL_PIXELFORMAT_XBGR4444;
break;
case SDL_PIXELFORMAT_XRGB1555:
renderer->info.texture_formats[renderer->info.num_texture_formats++] = SDL_PIXELFORMAT_ARGB1555;
break;
case SDL_PIXELFORMAT_XBGR1555:
renderer->info.texture_formats[renderer->info.num_texture_formats++] = SDL_PIXELFORMAT_ABGR1555;
break;
case SDL_PIXELFORMAT_ARGB1555:
renderer->info.texture_formats[renderer->info.num_texture_formats++] = SDL_PIXELFORMAT_XRGB1555;
break;
case SDL_PIXELFORMAT_ABGR1555:
renderer->info.texture_formats[renderer->info.num_texture_formats++] = SDL_PIXELFORMAT_XBGR1555;
break;
case SDL_PIXELFORMAT_XRGB8888:
renderer->info.texture_formats[renderer->info.num_texture_formats++] = SDL_PIXELFORMAT_ARGB8888;
break;
case SDL_PIXELFORMAT_RGBX8888:
renderer->info.texture_formats[renderer->info.num_texture_formats++] = SDL_PIXELFORMAT_RGBA8888;
break;
case SDL_PIXELFORMAT_XBGR8888:
renderer->info.texture_formats[renderer->info.num_texture_formats++] = SDL_PIXELFORMAT_ABGR8888;
break;
case SDL_PIXELFORMAT_BGRX8888:
renderer->info.texture_formats[renderer->info.num_texture_formats++] = SDL_PIXELFORMAT_BGRA8888;
break;
case SDL_PIXELFORMAT_ARGB8888:
renderer->info.texture_formats[renderer->info.num_texture_formats++] = SDL_PIXELFORMAT_XRGB8888;
break;
case SDL_PIXELFORMAT_RGBA8888:
renderer->info.texture_formats[renderer->info.num_texture_formats++] = SDL_PIXELFORMAT_RGBX8888;
break;
case SDL_PIXELFORMAT_ABGR8888:
renderer->info.texture_formats[renderer->info.num_texture_formats++] = SDL_PIXELFORMAT_XBGR8888;
break;
case SDL_PIXELFORMAT_BGRA8888:
renderer->info.texture_formats[renderer->info.num_texture_formats++] = SDL_PIXELFORMAT_BGRX8888;
break;
}
/* Ensure that we always have a SDL_PACKEDLAYOUT_8888 format. Having a matching component order increases the
* chances of getting a fast path for blitting.
*/
if (SDL_ISPIXELFORMAT_PACKED(format)) {
if (SDL_PIXELLAYOUT(format) != SDL_PACKEDLAYOUT_8888) {
switch (SDL_PIXELORDER(format)) {
case SDL_PACKEDORDER_BGRX:
case SDL_PACKEDORDER_BGRA:
renderer->info.texture_formats[renderer->info.num_texture_formats++] = SDL_PIXELFORMAT_BGRX8888;
renderer->info.texture_formats[renderer->info.num_texture_formats++] = SDL_PIXELFORMAT_BGRA8888;
break;
case SDL_PACKEDORDER_RGBX:
case SDL_PACKEDORDER_RGBA:
renderer->info.texture_formats[renderer->info.num_texture_formats++] = SDL_PIXELFORMAT_RGBX8888;
renderer->info.texture_formats[renderer->info.num_texture_formats++] = SDL_PIXELFORMAT_RGBA8888;
break;
case SDL_PACKEDORDER_XBGR:
case SDL_PACKEDORDER_ABGR:
renderer->info.texture_formats[renderer->info.num_texture_formats++] = SDL_PIXELFORMAT_XBGR8888;
renderer->info.texture_formats[renderer->info.num_texture_formats++] = SDL_PIXELFORMAT_ABGR8888;
break;
case SDL_PACKEDORDER_XRGB:
case SDL_PACKEDORDER_ARGB:
default:
renderer->info.texture_formats[renderer->info.num_texture_formats++] = SDL_PIXELFORMAT_XRGB8888;
renderer->info.texture_formats[renderer->info.num_texture_formats++] = SDL_PIXELFORMAT_ARGB8888;
break;
}
}
} else {
renderer->info.texture_formats[renderer->info.num_texture_formats++] = SDL_PIXELFORMAT_XRGB8888;
renderer->info.texture_formats[renderer->info.num_texture_formats++] = SDL_PIXELFORMAT_ARGB8888;
}
}
SDL_Renderer *SW_CreateRendererForSurface(SDL_Surface *surface)
{
SDL_Renderer *renderer;
SW_RenderData *data;
if (surface == NULL) {
SDL_InvalidParamError("surface");
return NULL;
}
renderer = (SDL_Renderer *)SDL_calloc(1, sizeof(*renderer));
if (renderer == NULL) {
SDL_OutOfMemory();
return NULL;
}
data = (SW_RenderData *)SDL_calloc(1, sizeof(*data));
if (data == NULL) {
SW_DestroyRenderer(renderer);
SDL_OutOfMemory();
return NULL;
}
data->surface = surface;
data->window = surface;
renderer->WindowEvent = SW_WindowEvent;
renderer->GetOutputSize = SW_GetOutputSize;
renderer->CreateTexture = SW_CreateTexture;
renderer->UpdateTexture = SW_UpdateTexture;
renderer->LockTexture = SW_LockTexture;
renderer->UnlockTexture = SW_UnlockTexture;
renderer->SetTextureScaleMode = SW_SetTextureScaleMode;
renderer->SetRenderTarget = SW_SetRenderTarget;
renderer->QueueSetViewport = SW_QueueSetViewport;
renderer->QueueSetDrawColor = SW_QueueSetViewport; /* SetViewport and SetDrawColor are (currently) no-ops. */
renderer->QueueDrawPoints = SW_QueueDrawPoints;
renderer->QueueDrawLines = SW_QueueDrawPoints; /* lines and points queue vertices the same way. */
renderer->QueueFillRects = SW_QueueFillRects;
renderer->QueueCopy = SW_QueueCopy;
renderer->QueueCopyEx = SW_QueueCopyEx;
2021-03-16 15:14:58 +01:00
renderer->QueueGeometry = SW_QueueGeometry;
renderer->RunCommandQueue = SW_RunCommandQueue;
renderer->RenderReadPixels = SW_RenderReadPixels;
renderer->RenderPresent = SW_RenderPresent;
renderer->DestroyTexture = SW_DestroyTexture;
renderer->DestroyRenderer = SW_DestroyRenderer;
renderer->info = SW_RenderDriver.info;
renderer->driverdata = data;
SW_SelectBestFormats(renderer, surface->format->format);
SW_ActivateRenderer(renderer);
return renderer;
}
static SDL_Renderer *SW_CreateRenderer(SDL_Window *window, Uint32 flags)
{
const char *hint;
SDL_Surface *surface;
SDL_bool no_hint_set;
/* Set the vsync hint based on our flags, if it's not already set */
hint = SDL_GetHint(SDL_HINT_RENDER_VSYNC);
if (hint == NULL || !*hint) {
no_hint_set = SDL_TRUE;
} else {
no_hint_set = SDL_FALSE;
}
if (no_hint_set) {
SDL_SetHint(SDL_HINT_RENDER_VSYNC, (flags & SDL_RENDERER_PRESENTVSYNC) ? "1" : "0");
}
surface = SDL_GetWindowSurface(window);
/* Reset the vsync hint if we set it above */
if (no_hint_set) {
SDL_SetHint(SDL_HINT_RENDER_VSYNC, "");
}
if (surface == NULL) {
return NULL;
}
return SW_CreateRendererForSurface(surface);
}
SDL_RenderDriver SW_RenderDriver = {
SW_CreateRenderer,
{ "software",
(SDL_RENDERER_SOFTWARE | SDL_RENDERER_PRESENTVSYNC),
0,
{ /* formats filled in later */
SDL_PIXELFORMAT_UNKNOWN },
0,
0 }
};
#endif /* SDL_VIDEO_RENDER_SW && !SDL_RENDER_DISABLED */