2015-06-21 17:33:46 +02:00
|
|
|
/*
|
|
|
|
|
Simple DirectMedia Layer
|
2023-01-09 09:41:41 -08:00
|
|
|
Copyright (C) 1997-2023 Sam Lantinga <slouken@libsdl.org>
|
2015-06-21 17:33:46 +02:00
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
*/
|
2022-11-29 18:34:15 -08:00
|
|
|
#include "SDL_internal.h"
|
2015-06-21 17:33:46 +02:00
|
|
|
|
2023-03-29 21:49:01 +00:00
|
|
|
#if SDL_VIDEO_RENDER_SW && !defined(SDL_RENDER_DISABLED)
|
2015-06-21 17:33:46 +02:00
|
|
|
|
|
|
|
|
#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"
|
2015-06-21 17:33:46 +02:00
|
|
|
|
|
|
|
|
/* SDL surface based renderer implementation */
|
|
|
|
|
|
2019-06-11 14:09:53 -04:00
|
|
|
typedef struct
|
|
|
|
|
{
|
|
|
|
|
const SDL_Rect *viewport;
|
|
|
|
|
const SDL_Rect *cliprect;
|
|
|
|
|
SDL_bool surface_cliprect_dirty;
|
|
|
|
|
} SW_DrawStateCache;
|
|
|
|
|
|
2015-06-21 17:33:46 +02:00
|
|
|
typedef struct
|
|
|
|
|
{
|
|
|
|
|
SDL_Surface *surface;
|
|
|
|
|
SDL_Surface *window;
|
|
|
|
|
} SW_RenderData;
|
|
|
|
|
|
2022-11-30 12:51:59 -08:00
|
|
|
static SDL_Surface *SW_ActivateRenderer(SDL_Renderer *renderer)
|
2015-06-21 17:33:46 +02:00
|
|
|
{
|
2022-11-30 12:51:59 -08:00
|
|
|
SW_RenderData *data = (SW_RenderData *)renderer->driverdata;
|
2015-06-21 17:33:46 +02:00
|
|
|
|
|
|
|
|
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;
|
|
|
|
|
}
|
|
|
|
|
|
2022-11-30 12:51:59 -08:00
|
|
|
static void SW_WindowEvent(SDL_Renderer *renderer, const SDL_WindowEvent *event)
|
2015-06-21 17:33:46 +02:00
|
|
|
{
|
2022-11-30 12:51:59 -08:00
|
|
|
SW_RenderData *data = (SW_RenderData *)renderer->driverdata;
|
2015-06-21 17:33:46 +02:00
|
|
|
|
2023-01-28 15:22:16 -08:00
|
|
|
if (event->type == SDL_EVENT_WINDOW_PIXEL_SIZE_CHANGED) {
|
2015-06-21 17:33:46 +02:00
|
|
|
data->surface = NULL;
|
|
|
|
|
data->window = NULL;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2022-11-30 12:51:59 -08:00
|
|
|
static int SW_GetOutputSize(SDL_Renderer *renderer, int *w, int *h)
|
2015-06-21 17:33:46 +02:00
|
|
|
{
|
2022-11-30 12:51:59 -08:00
|
|
|
SW_RenderData *data = (SW_RenderData *)renderer->driverdata;
|
2015-06-21 17:33:46 +02:00
|
|
|
|
2019-06-18 10:08:19 -07:00
|
|
|
if (data->surface) {
|
2015-06-21 17:33:46 +02:00
|
|
|
if (w) {
|
2019-06-18 10:08:19 -07:00
|
|
|
*w = data->surface->w;
|
2015-06-21 17:33:46 +02:00
|
|
|
}
|
|
|
|
|
if (h) {
|
2019-06-18 10:08:19 -07:00
|
|
|
*h = data->surface->h;
|
2015-06-21 17:33:46 +02:00
|
|
|
}
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
2019-06-18 10:08:19 -07:00
|
|
|
|
|
|
|
|
if (renderer->window) {
|
2023-01-11 19:45:01 -07:00
|
|
|
SDL_GetWindowSizeInPixels(renderer->window, w, h);
|
2019-06-18 10:08:19 -07:00
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
2022-01-17 17:22:30 +01:00
|
|
|
return SDL_SetError("Software renderer doesn't have an output surface");
|
2015-06-21 17:33:46 +02:00
|
|
|
}
|
|
|
|
|
|
2022-11-30 12:51:59 -08:00
|
|
|
static int SW_CreateTexture(SDL_Renderer *renderer, SDL_Texture *texture)
|
2015-06-21 17:33:46 +02:00
|
|
|
{
|
2022-12-01 17:04:02 +01:00
|
|
|
SDL_Surface *surface = SDL_CreateSurface(texture->w, texture->h, texture->format);
|
2015-06-21 17:33:46 +02:00
|
|
|
|
2022-12-01 17:04:02 +01:00
|
|
|
if (surface == NULL) {
|
|
|
|
|
return SDL_SetError("Cannot create surface");
|
2015-06-21 17:33:46 +02:00
|
|
|
}
|
2022-12-01 17:04:02 +01:00
|
|
|
texture->driverdata = surface;
|
2021-10-24 17:16:49 +02:00
|
|
|
SDL_SetSurfaceColorMod(texture->driverdata, texture->color.r, texture->color.g, texture->color.b);
|
|
|
|
|
SDL_SetSurfaceAlphaMod(texture->driverdata, texture->color.a);
|
2015-06-21 17:33:46 +02:00
|
|
|
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.
|
|
|
|
|
*/
|
2022-12-01 17:04:02 +01:00
|
|
|
if (texture->access == SDL_TEXTUREACCESS_STATIC && !surface->format->Amask) {
|
2015-06-21 17:33:46 +02:00
|
|
|
SDL_SetSurfaceRLE(texture->driverdata, 1);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (!texture->driverdata) {
|
|
|
|
|
return -1;
|
|
|
|
|
}
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
2022-11-30 12:51:59 -08:00
|
|
|
static int SW_UpdateTexture(SDL_Renderer *renderer, SDL_Texture *texture,
|
|
|
|
|
const SDL_Rect *rect, const void *pixels, int pitch)
|
2015-06-21 17:33:46 +02:00
|
|
|
{
|
2022-11-30 12:51:59 -08:00
|
|
|
SDL_Surface *surface = (SDL_Surface *)texture->driverdata;
|
2015-06-21 17:33:46 +02:00
|
|
|
Uint8 *src, *dst;
|
|
|
|
|
int row;
|
|
|
|
|
size_t length;
|
|
|
|
|
|
2022-11-27 17:38:43 +01:00
|
|
|
if (SDL_MUSTLOCK(surface)) {
|
2015-06-21 17:33:46 +02:00
|
|
|
SDL_LockSurface(surface);
|
2022-11-27 17:38:43 +01:00
|
|
|
}
|
2022-11-30 12:51:59 -08:00
|
|
|
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;
|
2015-06-21 17:33:46 +02:00
|
|
|
for (row = 0; row < rect->h; ++row) {
|
|
|
|
|
SDL_memcpy(dst, src, length);
|
|
|
|
|
src += pitch;
|
|
|
|
|
dst += surface->pitch;
|
|
|
|
|
}
|
2022-11-27 17:38:43 +01:00
|
|
|
if (SDL_MUSTLOCK(surface)) {
|
2015-06-21 17:33:46 +02:00
|
|
|
SDL_UnlockSurface(surface);
|
2022-11-27 17:38:43 +01:00
|
|
|
}
|
2015-06-21 17:33:46 +02:00
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
2022-11-30 12:51:59 -08:00
|
|
|
static int SW_LockTexture(SDL_Renderer *renderer, SDL_Texture *texture,
|
|
|
|
|
const SDL_Rect *rect, void **pixels, int *pitch)
|
2015-06-21 17:33:46 +02:00
|
|
|
{
|
2022-11-30 12:51:59 -08:00
|
|
|
SDL_Surface *surface = (SDL_Surface *)texture->driverdata;
|
2015-06-21 17:33:46 +02:00
|
|
|
|
|
|
|
|
*pixels =
|
2022-11-30 12:51:59 -08:00
|
|
|
(void *)((Uint8 *)surface->pixels + rect->y * surface->pitch +
|
|
|
|
|
rect->x * surface->format->BytesPerPixel);
|
2015-06-21 17:33:46 +02:00
|
|
|
*pitch = surface->pitch;
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
2022-11-30 12:51:59 -08:00
|
|
|
static void SW_UnlockTexture(SDL_Renderer *renderer, SDL_Texture *texture)
|
2015-06-21 17:33:46 +02:00
|
|
|
{
|
|
|
|
|
}
|
|
|
|
|
|
2022-11-30 12:51:59 -08:00
|
|
|
static void SW_SetTextureScaleMode(SDL_Renderer *renderer, SDL_Texture *texture, SDL_ScaleMode scaleMode)
|
2019-12-22 13:39:44 -08:00
|
|
|
{
|
|
|
|
|
}
|
|
|
|
|
|
2022-11-30 12:51:59 -08:00
|
|
|
static int SW_SetRenderTarget(SDL_Renderer *renderer, SDL_Texture *texture)
|
2015-06-21 17:33:46 +02:00
|
|
|
{
|
2022-11-30 12:51:59 -08:00
|
|
|
SW_RenderData *data = (SW_RenderData *)renderer->driverdata;
|
2015-06-21 17:33:46 +02:00
|
|
|
|
2019-06-18 10:08:19 -07:00
|
|
|
if (texture) {
|
2022-11-30 12:51:59 -08:00
|
|
|
data->surface = (SDL_Surface *)texture->driverdata;
|
2015-06-21 17:33:46 +02:00
|
|
|
} else {
|
|
|
|
|
data->surface = data->window;
|
|
|
|
|
}
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
2022-11-30 12:51:59 -08:00
|
|
|
static int SW_QueueSetViewport(SDL_Renderer *renderer, SDL_RenderCommand *cmd)
|
2015-06-21 17:33:46 +02:00
|
|
|
{
|
2022-11-30 12:51:59 -08:00
|
|
|
return 0; /* nothing to do in this backend. */
|
2015-06-21 17:33:46 +02:00
|
|
|
}
|
|
|
|
|
|
2022-11-30 12:51:59 -08:00
|
|
|
static int SW_QueueDrawPoints(SDL_Renderer *renderer, SDL_RenderCommand *cmd, const SDL_FPoint *points, int count)
|
2015-06-21 17:33:46 +02:00
|
|
|
{
|
2022-11-30 12:51:59 -08:00
|
|
|
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;
|
2015-06-21 17:33:46 +02:00
|
|
|
|
2022-11-27 17:38:43 +01:00
|
|
|
if (verts == NULL) {
|
2015-06-21 17:33:46 +02:00
|
|
|
return -1;
|
|
|
|
|
}
|
|
|
|
|
|
2018-10-03 23:37:29 -04:00
|
|
|
cmd->data.draw.count = count;
|
2015-06-21 17:33:46 +02:00
|
|
|
|
2021-11-24 16:45:06 +01:00
|
|
|
for (i = 0; i < count; i++, verts++, points++) {
|
|
|
|
|
verts->x = (int)points->x;
|
|
|
|
|
verts->y = (int)points->y;
|
2015-06-21 17:33:46 +02:00
|
|
|
}
|
|
|
|
|
|
2018-10-03 23:37:29 -04:00
|
|
|
return 0;
|
2015-06-21 17:33:46 +02:00
|
|
|
}
|
|
|
|
|
|
2022-11-30 12:51:59 -08:00
|
|
|
static int SW_QueueFillRects(SDL_Renderer *renderer, SDL_RenderCommand *cmd, const SDL_FRect *rects, int count)
|
2015-06-21 17:33:46 +02:00
|
|
|
{
|
2022-11-30 12:51:59 -08:00
|
|
|
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;
|
2015-06-21 17:33:46 +02:00
|
|
|
|
2022-11-27 17:38:43 +01:00
|
|
|
if (verts == NULL) {
|
2015-06-21 17:33:46 +02:00
|
|
|
return -1;
|
|
|
|
|
}
|
|
|
|
|
|
2018-10-03 23:37:29 -04:00
|
|
|
cmd->data.draw.count = count;
|
2015-06-21 17:33:46 +02:00
|
|
|
|
2021-11-24 16:45:06 +01:00
|
|
|
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);
|
2015-06-21 17:33:46 +02:00
|
|
|
}
|
|
|
|
|
|
2018-10-03 23:37:29 -04:00
|
|
|
return 0;
|
2015-06-21 17:33:46 +02:00
|
|
|
}
|
|
|
|
|
|
2022-11-30 12:51:59 -08:00
|
|
|
static int SW_QueueCopy(SDL_Renderer *renderer, SDL_RenderCommand *cmd, SDL_Texture *texture,
|
2023-03-02 08:56:54 -08:00
|
|
|
const SDL_FRect *srcrect, const SDL_FRect *dstrect)
|
2015-06-21 17:33:46 +02:00
|
|
|
{
|
2022-11-30 12:51:59 -08:00
|
|
|
SDL_Rect *verts = (SDL_Rect *)SDL_AllocateRenderVertices(renderer, 2 * sizeof(SDL_Rect), 0, &cmd->data.draw.first);
|
2015-06-21 17:33:46 +02:00
|
|
|
|
2022-11-27 17:38:43 +01:00
|
|
|
if (verts == NULL) {
|
2015-06-21 17:33:46 +02:00
|
|
|
return -1;
|
|
|
|
|
}
|
|
|
|
|
|
2018-10-03 23:37:29 -04:00
|
|
|
cmd->data.draw.count = 1;
|
2015-06-21 17:33:46 +02:00
|
|
|
|
2023-03-02 08:56:54 -08:00
|
|
|
verts->x = (int)srcrect->x;
|
|
|
|
|
verts->y = (int)srcrect->y;
|
|
|
|
|
verts->w = (int)srcrect->w;
|
|
|
|
|
verts->h = (int)srcrect->h;
|
2018-10-03 23:37:29 -04:00
|
|
|
verts++;
|
|
|
|
|
|
2021-11-24 16:45:06 +01:00
|
|
|
verts->x = (int)dstrect->x;
|
|
|
|
|
verts->y = (int)dstrect->y;
|
2018-10-03 23:37:29 -04:00
|
|
|
verts->w = (int)dstrect->w;
|
|
|
|
|
verts->h = (int)dstrect->h;
|
2015-06-21 17:33:46 +02:00
|
|
|
|
2018-10-03 23:37:29 -04:00
|
|
|
return 0;
|
2015-06-21 17:33:46 +02:00
|
|
|
}
|
|
|
|
|
|
2018-10-03 23:37:29 -04:00
|
|
|
typedef struct CopyExData
|
|
|
|
|
{
|
|
|
|
|
SDL_Rect srcrect;
|
|
|
|
|
SDL_Rect dstrect;
|
|
|
|
|
double angle;
|
|
|
|
|
SDL_FPoint center;
|
|
|
|
|
SDL_RendererFlip flip;
|
2022-02-15 11:33:56 +01:00
|
|
|
float scale_x;
|
|
|
|
|
float scale_y;
|
2018-10-03 23:37:29 -04:00
|
|
|
} CopyExData;
|
|
|
|
|
|
2022-11-30 12:51:59 -08:00
|
|
|
static int SW_QueueCopyEx(SDL_Renderer *renderer, SDL_RenderCommand *cmd, SDL_Texture *texture,
|
2023-03-02 08:56:54 -08:00
|
|
|
const SDL_FRect *srcrect, const SDL_FRect *dstrect,
|
2022-11-30 12:51:59 -08:00
|
|
|
const double angle, const SDL_FPoint *center, const SDL_RendererFlip flip, float scale_x, float scale_y)
|
2015-06-21 17:33:46 +02:00
|
|
|
{
|
2022-11-30 12:51:59 -08:00
|
|
|
CopyExData *verts = (CopyExData *)SDL_AllocateRenderVertices(renderer, sizeof(CopyExData), 0, &cmd->data.draw.first);
|
2015-06-21 17:33:46 +02:00
|
|
|
|
2022-11-27 17:38:43 +01:00
|
|
|
if (verts == NULL) {
|
2015-06-21 17:33:46 +02:00
|
|
|
return -1;
|
|
|
|
|
}
|
|
|
|
|
|
2018-10-03 23:37:29 -04:00
|
|
|
cmd->data.draw.count = 1;
|
|
|
|
|
|
2023-03-02 08:56:54 -08:00
|
|
|
verts->srcrect.x = (int)srcrect->x;
|
|
|
|
|
verts->srcrect.y = (int)srcrect->y;
|
|
|
|
|
verts->srcrect.w = (int)srcrect->w;
|
|
|
|
|
verts->srcrect.h = (int)srcrect->h;
|
2021-11-24 16:45:06 +01:00
|
|
|
verts->dstrect.x = (int)dstrect->x;
|
|
|
|
|
verts->dstrect.y = (int)dstrect->y;
|
2018-10-03 23:37:29 -04:00
|
|
|
verts->dstrect.w = (int)dstrect->w;
|
|
|
|
|
verts->dstrect.h = (int)dstrect->h;
|
|
|
|
|
verts->angle = angle;
|
2022-06-17 10:22:28 -07:00
|
|
|
SDL_copyp(&verts->center, center);
|
2018-10-03 23:37:29 -04:00
|
|
|
verts->flip = flip;
|
2022-02-15 11:33:56 +01:00
|
|
|
verts->scale_x = scale_x;
|
|
|
|
|
verts->scale_y = scale_y;
|
2015-06-21 17:33:46 +02:00
|
|
|
|
2018-10-03 23:37:29 -04:00
|
|
|
return 0;
|
2015-06-21 17:33:46 +02:00
|
|
|
}
|
|
|
|
|
|
2022-11-30 12:51:59 -08:00
|
|
|
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)
|
2022-02-15 11:33:56 +01:00
|
|
|
{
|
|
|
|
|
int retval;
|
|
|
|
|
/* Renderer scaling, if needed */
|
|
|
|
|
if (scale_x != 1.0f || scale_y != 1.0f) {
|
|
|
|
|
SDL_Rect r;
|
2022-11-30 12:51:59 -08:00
|
|
|
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);
|
2022-02-15 11:33:56 +01:00
|
|
|
} else {
|
|
|
|
|
retval = SDL_BlitSurface(src, srcrect, surface, dstrect);
|
|
|
|
|
}
|
|
|
|
|
return retval;
|
|
|
|
|
}
|
|
|
|
|
|
2022-11-30 12:51:59 -08:00
|
|
|
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)
|
2015-06-21 17:33:46 +02:00
|
|
|
{
|
2022-11-30 12:51:59 -08:00
|
|
|
SDL_Surface *src = (SDL_Surface *)texture->driverdata;
|
2018-10-03 23:37:29 -04:00
|
|
|
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;
|
2022-02-15 10:02:34 +01:00
|
|
|
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;
|
2015-06-21 17:33:46 +02:00
|
|
|
|
2022-11-27 17:38:43 +01:00
|
|
|
if (surface == NULL) {
|
2015-06-21 17:33:46 +02:00
|
|
|
return -1;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
tmp_rect.x = 0;
|
|
|
|
|
tmp_rect.y = 0;
|
2018-10-03 23:37:29 -04:00
|
|
|
tmp_rect.w = final_rect->w;
|
|
|
|
|
tmp_rect.h = final_rect->h;
|
2015-06-21 17:33:46 +02: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
|
|
|
/* 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.
|
|
|
|
|
*/
|
2022-12-01 17:04:02 +01:00
|
|
|
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);
|
2015-06-21 17:33:46 +02: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
|
|
|
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. */
|
2018-10-03 23:37:29 -04:00
|
|
|
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;
|
|
|
|
|
}
|
|
|
|
|
|
2018-10-30 07:00:03 -07:00
|
|
|
/* 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;
|
|
|
|
|
}
|
|
|
|
|
|
2020-01-16 08:52:59 -08:00
|
|
|
/* 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) {
|
2022-12-01 17:04:02 +01:00
|
|
|
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);
|
2015-06-21 17:33:46 +02: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
|
|
|
}
|
2015-06-21 17:33:46 +02: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;
|
2022-12-01 17:04:02 +01:00
|
|
|
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);
|
2022-12-27 06:36:39 -08:00
|
|
|
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;
|
2015-06-21 17:33:46 +02: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
|
|
|
/* SDLgfx_rotateSurface is going to make decisions depending on the blend mode. */
|
|
|
|
|
SDL_SetSurfaceBlendMode(src_clone, blendmode);
|
|
|
|
|
|
2015-06-21 17:33:46 +02:00
|
|
|
if (!retval) {
|
2022-02-17 23:11:02 +01:00
|
|
|
SDL_Rect rect_dest;
|
2022-02-15 10:02:34 +01:00
|
|
|
double cangle, sangle;
|
|
|
|
|
|
2022-02-17 23:11:02 +01:00
|
|
|
SDLgfx_rotozoomSurfaceSizeTrig(tmp_rect.w, tmp_rect.h, angle, center,
|
2022-11-30 12:51:59 -08:00
|
|
|
&rect_dest, &cangle, &sangle);
|
2022-02-17 23:11:02 +01:00
|
|
|
src_rotated = SDLgfx_rotateSurface(src_clone, angle,
|
2023-02-03 13:23:02 -08:00
|
|
|
(texture->scaleMode == SDL_SCALEMODE_NEAREST) ? 0 : 1, flip & SDL_FLIP_HORIZONTAL, flip & SDL_FLIP_VERTICAL,
|
2022-11-30 12:51:59 -08:00
|
|
|
&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. */
|
2022-02-17 23:11:02 +01:00
|
|
|
mask_rotated = SDLgfx_rotateSurface(mask, angle,
|
2022-11-30 12:51:59 -08:00
|
|
|
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) {
|
2022-02-17 23:11:02 +01:00
|
|
|
|
|
|
|
|
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;
|
2015-06-21 17:33:46 +02: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
|
|
|
/* 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);
|
|
|
|
|
}
|
2022-02-15 11:33:56 +01:00
|
|
|
/* 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);
|
2022-02-15 11:33:56 +01:00
|
|
|
/* 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;
|
2022-02-15 11:33:56 +01:00
|
|
|
/* 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;
|
2022-12-27 06:08:13 -08:00
|
|
|
int f = SDL_GetPixelFormatEnumForMasks(src_rotated->format->BitsPerPixel,
|
2022-12-01 17:04:02 +01:00
|
|
|
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);
|
2022-02-15 11:33:56 +01:00
|
|
|
/* Renderer scaling, if needed */
|
|
|
|
|
retval = Blit_to_Screen(src_rotated_rgb, NULL, surface, &tmp_rect, scale_x, scale_y, texture->scaleMode);
|
2022-12-27 06:36:39 -08:00
|
|
|
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
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
2022-12-27 06:36:39 -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) {
|
2022-12-27 06:36:39 -08:00
|
|
|
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
|
|
|
}
|
2015-06-21 17:33:46 +02: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) {
|
2022-12-27 06:36:39 -08:00
|
|
|
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) {
|
2022-12-27 06:36:39 -08:00
|
|
|
SDL_DestroySurface(src_clone);
|
2015-06-21 17:33:46 +02:00
|
|
|
}
|
|
|
|
|
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;
|
|
|
|
|
|
2022-11-30 12:51:59 -08:00
|
|
|
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);
|
2022-11-27 17:38:43 +01:00
|
|
|
if (verts == NULL) {
|
2021-03-16 15:14:58 +01:00
|
|
|
return -1;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
cmd->data.draw.count = count;
|
2021-08-27 07:44:03 +02:00
|
|
|
size_indices = indices ? size_indices : 0;
|
2021-03-16 15:14:58 +01:00
|
|
|
|
|
|
|
|
if (texture) {
|
2022-11-30 12:51:59 -08:00
|
|
|
GeometryCopyData *ptr = (GeometryCopyData *)verts;
|
2021-03-16 15:14:58 +01:00
|
|
|
for (i = 0; i < count; i++) {
|
2021-04-01 09:49:16 +02:00
|
|
|
int j;
|
2021-04-01 11:47:45 +02:00
|
|
|
float *xy_;
|
|
|
|
|
SDL_Color col_;
|
|
|
|
|
float *uv_;
|
2021-04-23 12:00:14 +02:00
|
|
|
if (size_indices == 4) {
|
2021-04-01 09:49:16 +02:00
|
|
|
j = ((const Uint32 *)indices)[i];
|
2021-04-23 12:00:14 +02:00
|
|
|
} else if (size_indices == 2) {
|
2021-04-01 09:49:16 +02:00
|
|
|
j = ((const Uint16 *)indices)[i];
|
2021-04-23 12:00:14 +02:00
|
|
|
} else if (size_indices == 1) {
|
2021-04-01 09:49:16 +02:00
|
|
|
j = ((const Uint8 *)indices)[i];
|
|
|
|
|
} else {
|
|
|
|
|
j = i;
|
|
|
|
|
}
|
|
|
|
|
|
2022-11-30 12:51:59 -08:00
|
|
|
xy_ = (float *)((char *)xy + j * xy_stride);
|
|
|
|
|
col_ = *(SDL_Color *)((char *)color + j * color_stride);
|
2021-04-01 09:49:16 +02:00
|
|
|
|
2022-11-30 12:51:59 -08:00
|
|
|
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
|
|
|
|
2021-11-24 16:45:06 +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);
|
|
|
|
|
|
2021-04-01 09:49:16 +02:00
|
|
|
ptr->color = col_;
|
2021-03-16 15:14:58 +01:00
|
|
|
|
|
|
|
|
ptr++;
|
2022-11-30 12:51:59 -08:00
|
|
|
}
|
2021-03-16 15:14:58 +01:00
|
|
|
} else {
|
2022-11-30 12:51:59 -08:00
|
|
|
GeometryFillData *ptr = (GeometryFillData *)verts;
|
2021-03-16 15:14:58 +01:00
|
|
|
|
|
|
|
|
for (i = 0; i < count; i++) {
|
2021-04-01 09:49:16 +02:00
|
|
|
int j;
|
2021-04-01 11:47:45 +02:00
|
|
|
float *xy_;
|
|
|
|
|
SDL_Color col_;
|
2021-04-23 12:00:14 +02:00
|
|
|
if (size_indices == 4) {
|
2021-04-01 09:49:16 +02:00
|
|
|
j = ((const Uint32 *)indices)[i];
|
2021-04-23 12:00:14 +02:00
|
|
|
} else if (size_indices == 2) {
|
2021-04-01 09:49:16 +02:00
|
|
|
j = ((const Uint16 *)indices)[i];
|
2021-04-23 12:00:14 +02:00
|
|
|
} else if (size_indices == 1) {
|
2021-04-01 09:49:16 +02:00
|
|
|
j = ((const Uint8 *)indices)[i];
|
|
|
|
|
} else {
|
|
|
|
|
j = i;
|
|
|
|
|
}
|
2021-03-16 15:14:58 +01:00
|
|
|
|
2022-11-30 12:51:59 -08:00
|
|
|
xy_ = (float *)((char *)xy + j * xy_stride);
|
|
|
|
|
col_ = *(SDL_Color *)((char *)color + j * color_stride);
|
2021-04-01 09:49:16 +02:00
|
|
|
|
2021-11-24 16:45:06 +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);
|
|
|
|
|
|
2021-04-01 09:49:16 +02:00
|
|
|
ptr->color = col_;
|
2021-03-16 15:14:58 +01:00
|
|
|
|
|
|
|
|
ptr++;
|
2022-11-30 12:51:59 -08:00
|
|
|
}
|
2021-03-16 15:14:58 +01:00
|
|
|
}
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
2022-11-30 12:51:59 -08:00
|
|
|
static void PrepTextureForCopy(const SDL_RenderCommand *cmd)
|
2018-10-03 23:37:29 -04:00
|
|
|
{
|
|
|
|
|
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;
|
2022-11-30 12:51:59 -08:00
|
|
|
SDL_Surface *surface = (SDL_Surface *)texture->driverdata;
|
2018-11-14 22:38:58 -05:00
|
|
|
const SDL_bool colormod = ((r & g & b) != 0xFF);
|
|
|
|
|
const SDL_bool alphamod = (a != 0xFF);
|
2020-01-16 08:52:59 -08:00
|
|
|
const SDL_bool blending = ((blend == SDL_BLENDMODE_ADD) || (blend == SDL_BLENDMODE_MOD) || (blend == SDL_BLENDMODE_MUL));
|
2018-10-03 23:37:29 -04:00
|
|
|
|
2018-11-14 22:38:58 -05:00
|
|
|
if (colormod || alphamod || blending) {
|
2018-10-03 23:37:29 -04:00
|
|
|
SDL_SetSurfaceRLE(surface, 0);
|
|
|
|
|
}
|
|
|
|
|
|
2018-11-14 22:38:58 -05:00
|
|
|
/* !!! FIXME: we can probably avoid some of these calls. */
|
|
|
|
|
SDL_SetSurfaceColorMod(surface, r, g, b);
|
|
|
|
|
SDL_SetSurfaceAlphaMod(surface, a);
|
2018-10-03 23:37:29 -04:00
|
|
|
SDL_SetSurfaceBlendMode(surface, blend);
|
|
|
|
|
}
|
|
|
|
|
|
2022-11-30 12:51:59 -08:00
|
|
|
static void SetDrawState(SDL_Surface *surface, SW_DrawStateCache *drawstate)
|
2019-06-11 14:09:53 -04:00
|
|
|
{
|
2019-06-11 15:06:35 -04:00
|
|
|
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 */
|
2019-06-11 15:06:35 -04:00
|
|
|
|
|
|
|
|
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;
|
2022-12-27 11:01:11 -08:00
|
|
|
SDL_GetRectIntersection(viewport, &clip_rect, &clip_rect);
|
2022-12-27 06:36:39 -08:00
|
|
|
SDL_SetSurfaceClipRect(surface, &clip_rect);
|
2019-06-11 15:06:35 -04:00
|
|
|
} else {
|
2022-12-27 06:36:39 -08:00
|
|
|
SDL_SetSurfaceClipRect(surface, drawstate->viewport);
|
2019-06-11 14:09:53 -04:00
|
|
|
}
|
2019-06-11 15:06:35 -04:00
|
|
|
drawstate->surface_cliprect_dirty = SDL_FALSE;
|
2019-06-11 14:09:53 -04:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2022-11-30 12:51:59 -08:00
|
|
|
static int SW_RunCommandQueue(SDL_Renderer *renderer, SDL_RenderCommand *cmd, void *vertices, size_t vertsize)
|
2018-10-03 23:37:29 -04:00
|
|
|
{
|
|
|
|
|
SDL_Surface *surface = SW_ActivateRenderer(renderer);
|
2019-06-11 14:09:53 -04:00
|
|
|
SW_DrawStateCache drawstate;
|
2018-10-03 23:37:29 -04:00
|
|
|
|
2022-11-27 17:38:43 +01:00
|
|
|
if (surface == NULL) {
|
2018-10-03 23:37:29 -04:00
|
|
|
return -1;
|
|
|
|
|
}
|
|
|
|
|
|
2019-06-11 14:09:53 -04:00
|
|
|
drawstate.viewport = NULL;
|
|
|
|
|
drawstate.cliprect = NULL;
|
|
|
|
|
drawstate.surface_cliprect_dirty = SDL_TRUE;
|
|
|
|
|
|
2018-10-03 23:37:29 -04:00
|
|
|
while (cmd) {
|
|
|
|
|
switch (cmd->command) {
|
2022-11-30 12:51:59 -08:00
|
|
|
case SDL_RENDERCMD_SETDRAWCOLOR:
|
|
|
|
|
{
|
|
|
|
|
break; /* Not used in this backend. */
|
|
|
|
|
}
|
2018-10-03 23:37:29 -04:00
|
|
|
|
2022-11-30 12:51:59 -08:00
|
|
|
case SDL_RENDERCMD_SETVIEWPORT:
|
|
|
|
|
{
|
|
|
|
|
drawstate.viewport = &cmd->data.viewport.rect;
|
|
|
|
|
drawstate.surface_cliprect_dirty = SDL_TRUE;
|
|
|
|
|
break;
|
|
|
|
|
}
|
2018-10-03 23:37:29 -04:00
|
|
|
|
2022-11-30 12:51:59 -08:00
|
|
|
case SDL_RENDERCMD_SETCLIPRECT:
|
|
|
|
|
{
|
|
|
|
|
drawstate.cliprect = cmd->data.cliprect.enabled ? &cmd->data.cliprect.rect : NULL;
|
|
|
|
|
drawstate.surface_cliprect_dirty = SDL_TRUE;
|
|
|
|
|
break;
|
|
|
|
|
}
|
2021-11-24 16:45:06 +01:00
|
|
|
|
2022-11-30 12:51:59 -08:00
|
|
|
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 */
|
2022-12-27 06:36:39 -08:00
|
|
|
SDL_SetSurfaceClipRect(surface, NULL);
|
|
|
|
|
SDL_FillSurfaceRect(surface, NULL, SDL_MapRGBA(surface->format, r, g, b, a));
|
2022-11-30 12:51:59 -08:00
|
|
|
drawstate.surface_cliprect_dirty = SDL_TRUE;
|
|
|
|
|
break;
|
|
|
|
|
}
|
2021-11-24 16:45:06 +01:00
|
|
|
|
2022-11-30 12:51:59 -08:00
|
|
|
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;
|
2018-10-03 23:37:29 -04:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2022-11-30 12:51:59 -08:00
|
|
|
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;
|
|
|
|
|
}
|
2021-11-24 16:45:06 +01:00
|
|
|
|
2022-11-30 12:51:59 -08:00
|
|
|
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;
|
2018-10-03 23:37:29 -04:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2022-11-30 12:51:59 -08:00
|
|
|
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;
|
|
|
|
|
}
|
2021-11-24 16:45:06 +01:00
|
|
|
|
2022-11-30 12:51:59 -08:00
|
|
|
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;
|
2021-11-24 16:45:06 +01:00
|
|
|
}
|
2022-11-30 12:51:59 -08:00
|
|
|
}
|
2021-11-24 16:45:06 +01:00
|
|
|
|
2022-11-30 12:51:59 -08:00
|
|
|
if (blend == SDL_BLENDMODE_NONE) {
|
2022-12-27 06:36:39 -08:00
|
|
|
SDL_FillSurfaceRects(surface, verts, count, SDL_MapRGBA(surface->format, r, g, b, a));
|
2022-11-30 12:51:59 -08:00
|
|
|
} else {
|
|
|
|
|
SDL_BlendFillRects(surface, verts, count, blend, r, g, b, a);
|
2018-10-03 23:37:29 -04:00
|
|
|
}
|
2022-11-30 12:51:59 -08:00
|
|
|
break;
|
|
|
|
|
}
|
2018-10-03 23:37:29 -04:00
|
|
|
|
2022-11-30 12:51:59 -08:00
|
|
|
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;
|
2018-10-03 23:37:29 -04:00
|
|
|
|
2022-11-30 12:51:59 -08:00
|
|
|
SetDrawState(surface, &drawstate);
|
2019-06-11 14:09:53 -04:00
|
|
|
|
2022-11-30 12:51:59 -08:00
|
|
|
PrepTextureForCopy(cmd);
|
2018-10-03 23:37:29 -04:00
|
|
|
|
2022-11-30 12:51:59 -08:00
|
|
|
/* Apply viewport */
|
|
|
|
|
if (drawstate.viewport != NULL && (drawstate.viewport->x || drawstate.viewport->y)) {
|
|
|
|
|
dstrect->x += drawstate.viewport->x;
|
|
|
|
|
dstrect->y += drawstate.viewport->y;
|
|
|
|
|
}
|
2021-11-24 16:45:06 +01:00
|
|
|
|
2022-11-30 12:51:59 -08:00
|
|
|
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) {
|
2022-12-01 17:04:02 +01:00
|
|
|
SDL_Surface *tmp = SDL_CreateSurface(dstrect->w, dstrect->h, src->format->format);
|
2022-11-30 12:51:59 -08:00
|
|
|
/* 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);
|
2022-11-30 12:51:59 -08:00
|
|
|
|
|
|
|
|
SDL_SetSurfaceColorMod(tmp, rMod, gMod, bMod);
|
|
|
|
|
SDL_SetSurfaceAlphaMod(tmp, alphaMod);
|
|
|
|
|
SDL_SetSurfaceBlendMode(tmp, blendmode);
|
|
|
|
|
|
|
|
|
|
SDL_BlitSurface(tmp, NULL, surface, dstrect);
|
2022-12-27 06:36:39 -08:00
|
|
|
SDL_DestroySurface(tmp);
|
2022-11-30 12:51:59 -08:00
|
|
|
/* No need to set back r/g/b/a/blendmode to 'src' since it's done in PrepTextureForCopy() */
|
2022-01-28 17:24:59 +01:00
|
|
|
}
|
2022-11-30 12:51:59 -08:00
|
|
|
} else {
|
2022-12-27 15:05:51 -08:00
|
|
|
SDL_PrivateBlitSurfaceScaled(src, srcrect, surface, dstrect, texture->scaleMode);
|
2018-10-03 23:37:29 -04:00
|
|
|
}
|
|
|
|
|
}
|
2022-11-30 12:51:59 -08:00
|
|
|
break;
|
|
|
|
|
}
|
2018-10-03 23:37:29 -04:00
|
|
|
|
2022-11-30 12:51:59 -08:00
|
|
|
case SDL_RENDERCMD_COPY_EX:
|
|
|
|
|
{
|
|
|
|
|
CopyExData *copydata = (CopyExData *)(((Uint8 *)vertices) + cmd->data.draw.first);
|
|
|
|
|
SetDrawState(surface, &drawstate);
|
|
|
|
|
PrepTextureForCopy(cmd);
|
2021-11-24 16:45:06 +01:00
|
|
|
|
2022-11-30 12:51:59 -08:00
|
|
|
/* Apply viewport */
|
|
|
|
|
if (drawstate.viewport != NULL && (drawstate.viewport->x || drawstate.viewport->y)) {
|
|
|
|
|
copydata->dstrect.x += drawstate.viewport->x;
|
|
|
|
|
copydata->dstrect.y += drawstate.viewport->y;
|
2018-10-03 23:37:29 -04:00
|
|
|
}
|
|
|
|
|
|
2022-11-30 12:51:59 -08:00
|
|
|
SW_RenderCopyEx(renderer, surface, cmd->data.draw.texture, ©data->srcrect,
|
|
|
|
|
©data->dstrect, copydata->angle, ©data->center, copydata->flip,
|
|
|
|
|
copydata->scale_x, copydata->scale_y);
|
|
|
|
|
break;
|
|
|
|
|
}
|
2021-03-16 15:14:58 +01:00
|
|
|
|
2022-11-30 12:51:59 -08: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
|
|
|
|
2022-11-30 12:51:59 -08:00
|
|
|
SetDrawState(surface, &drawstate);
|
2021-03-16 15:14:58 +01:00
|
|
|
|
2022-11-30 12:51:59 -08:00
|
|
|
if (texture) {
|
|
|
|
|
SDL_Surface *src = (SDL_Surface *)texture->driverdata;
|
2021-03-16 15:14:58 +01:00
|
|
|
|
2022-11-30 12:51:59 -08:00
|
|
|
GeometryCopyData *ptr = (GeometryCopyData *)verts;
|
2021-11-24 16:45:06 +01:00
|
|
|
|
2022-11-30 12:51:59 -08:00
|
|
|
PrepTextureForCopy(cmd);
|
2021-11-24 16:45:06 +01:00
|
|
|
|
2022-11-30 12:51:59 -08:00
|
|
|
/* 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-11-24 16:45:06 +01:00
|
|
|
}
|
2022-11-30 12:51:59 -08:00
|
|
|
}
|
2021-11-24 16:45:06 +01:00
|
|
|
|
2022-11-30 12:51:59 -08:00
|
|
|
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
|
|
|
}
|
|
|
|
|
}
|
2022-11-30 12:51:59 -08: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
|
|
|
}
|
2022-11-30 12:51:59 -08:00
|
|
|
break;
|
|
|
|
|
}
|
2021-03-16 15:14:58 +01:00
|
|
|
|
2022-11-30 12:51:59 -08:00
|
|
|
case SDL_RENDERCMD_NO_OP:
|
|
|
|
|
break;
|
2018-10-03 23:37:29 -04:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
cmd = cmd->next;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
2022-11-30 12:51:59 -08:00
|
|
|
static int SW_RenderReadPixels(SDL_Renderer *renderer, const SDL_Rect *rect,
|
|
|
|
|
Uint32 format, void *pixels, int pitch)
|
2015-06-21 17:33:46 +02:00
|
|
|
{
|
|
|
|
|
SDL_Surface *surface = SW_ActivateRenderer(renderer);
|
|
|
|
|
Uint32 src_format;
|
|
|
|
|
void *src_pixels;
|
|
|
|
|
|
2022-11-27 17:38:43 +01:00
|
|
|
if (surface == NULL) {
|
2015-06-21 17:33:46 +02:00
|
|
|
return -1;
|
|
|
|
|
}
|
|
|
|
|
|
2017-08-11 11:54:24 -07:00
|
|
|
/* NOTE: The rect is already adjusted according to the viewport by
|
|
|
|
|
* SDL_RenderReadPixels.
|
|
|
|
|
*/
|
2015-06-21 17:33:46 +02:00
|
|
|
|
2022-11-30 12:51:59 -08:00
|
|
|
if (rect->x < 0 || rect->x + rect->w > surface->w ||
|
|
|
|
|
rect->y < 0 || rect->y + rect->h > surface->h) {
|
2015-06-21 17:33:46 +02:00
|
|
|
return SDL_SetError("Tried to read outside of surface bounds");
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
src_format = surface->format->format;
|
2022-11-30 12:51:59 -08:00
|
|
|
src_pixels = (void *)((Uint8 *)surface->pixels +
|
|
|
|
|
rect->y * surface->pitch +
|
|
|
|
|
rect->x * surface->format->BytesPerPixel);
|
2015-06-21 17:33:46 +02:00
|
|
|
|
|
|
|
|
return SDL_ConvertPixels(rect->w, rect->h,
|
|
|
|
|
src_format, src_pixels, surface->pitch,
|
|
|
|
|
format, pixels, pitch);
|
|
|
|
|
}
|
|
|
|
|
|
2022-11-30 12:51:59 -08:00
|
|
|
static int SW_RenderPresent(SDL_Renderer *renderer)
|
2015-06-21 17:33:46 +02:00
|
|
|
{
|
|
|
|
|
SDL_Window *window = renderer->window;
|
|
|
|
|
|
2022-11-27 17:38:43 +01:00
|
|
|
if (window == NULL) {
|
2022-09-15 01:00:12 -07:00
|
|
|
return -1;
|
2015-06-21 17:33:46 +02:00
|
|
|
}
|
2022-09-15 01:00:12 -07:00
|
|
|
return SDL_UpdateWindowSurface(window);
|
2015-06-21 17:33:46 +02:00
|
|
|
}
|
|
|
|
|
|
2022-11-30 12:51:59 -08:00
|
|
|
static void SW_DestroyTexture(SDL_Renderer *renderer, SDL_Texture *texture)
|
2015-06-21 17:33:46 +02:00
|
|
|
{
|
2022-11-30 12:51:59 -08:00
|
|
|
SDL_Surface *surface = (SDL_Surface *)texture->driverdata;
|
2015-06-21 17:33:46 +02:00
|
|
|
|
2022-12-27 06:36:39 -08:00
|
|
|
SDL_DestroySurface(surface);
|
2015-06-21 17:33:46 +02:00
|
|
|
}
|
|
|
|
|
|
2022-11-30 12:51:59 -08:00
|
|
|
static void SW_DestroyRenderer(SDL_Renderer *renderer)
|
2015-06-21 17:33:46 +02:00
|
|
|
{
|
2022-11-30 12:51:59 -08:00
|
|
|
SW_RenderData *data = (SW_RenderData *)renderer->driverdata;
|
2015-06-21 17:33:46 +02:00
|
|
|
|
|
|
|
|
SDL_free(data);
|
|
|
|
|
SDL_free(renderer);
|
|
|
|
|
}
|
|
|
|
|
|
2022-11-30 12:51:59 -08:00
|
|
|
static void SW_SelectBestFormats(SDL_Renderer *renderer, Uint32 format)
|
2022-10-15 12:36:07 +01:00
|
|
|
{
|
|
|
|
|
/* 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;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2023-05-23 11:29:41 -07:00
|
|
|
SDL_Renderer *SW_CreateRendererForSurface(SDL_Surface *surface)
|
2018-10-03 23:37:29 -04:00
|
|
|
{
|
|
|
|
|
SDL_Renderer *renderer;
|
|
|
|
|
SW_RenderData *data;
|
|
|
|
|
|
2022-11-27 17:38:43 +01:00
|
|
|
if (surface == NULL) {
|
2022-01-17 16:26:02 +01:00
|
|
|
SDL_InvalidParamError("surface");
|
2018-10-03 23:37:29 -04:00
|
|
|
return NULL;
|
|
|
|
|
}
|
|
|
|
|
|
2022-11-30 12:51:59 -08:00
|
|
|
renderer = (SDL_Renderer *)SDL_calloc(1, sizeof(*renderer));
|
2022-11-27 17:38:43 +01:00
|
|
|
if (renderer == NULL) {
|
2018-10-03 23:37:29 -04:00
|
|
|
SDL_OutOfMemory();
|
|
|
|
|
return NULL;
|
|
|
|
|
}
|
|
|
|
|
|
2022-11-30 12:51:59 -08:00
|
|
|
data = (SW_RenderData *)SDL_calloc(1, sizeof(*data));
|
2022-11-27 17:38:43 +01:00
|
|
|
if (data == NULL) {
|
2018-10-03 23:37:29 -04:00
|
|
|
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;
|
2019-12-22 13:39:44 -08:00
|
|
|
renderer->SetTextureScaleMode = SW_SetTextureScaleMode;
|
2018-10-03 23:37:29 -04:00
|
|
|
renderer->SetRenderTarget = SW_SetRenderTarget;
|
|
|
|
|
renderer->QueueSetViewport = SW_QueueSetViewport;
|
2022-11-30 12:51:59 -08:00
|
|
|
renderer->QueueSetDrawColor = SW_QueueSetViewport; /* SetViewport and SetDrawColor are (currently) no-ops. */
|
2018-10-03 23:37:29 -04:00
|
|
|
renderer->QueueDrawPoints = SW_QueueDrawPoints;
|
2022-11-30 12:51:59 -08:00
|
|
|
renderer->QueueDrawLines = SW_QueueDrawPoints; /* lines and points queue vertices the same way. */
|
2018-10-03 23:37:29 -04:00
|
|
|
renderer->QueueFillRects = SW_QueueFillRects;
|
|
|
|
|
renderer->QueueCopy = SW_QueueCopy;
|
|
|
|
|
renderer->QueueCopyEx = SW_QueueCopyEx;
|
2021-03-16 15:14:58 +01:00
|
|
|
renderer->QueueGeometry = SW_QueueGeometry;
|
2018-10-03 23:37:29 -04:00
|
|
|
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;
|
|
|
|
|
|
2022-10-15 12:36:07 +01:00
|
|
|
SW_SelectBestFormats(renderer, surface->format->format);
|
|
|
|
|
|
2018-10-03 23:37:29 -04:00
|
|
|
SW_ActivateRenderer(renderer);
|
|
|
|
|
|
|
|
|
|
return renderer;
|
|
|
|
|
}
|
|
|
|
|
|
2022-11-30 12:51:59 -08:00
|
|
|
static SDL_Renderer *SW_CreateRenderer(SDL_Window *window, Uint32 flags)
|
2018-10-03 23:37:29 -04:00
|
|
|
{
|
2021-08-10 12:02:17 -07:00
|
|
|
const char *hint;
|
2018-10-03 23:37:29 -04:00
|
|
|
SDL_Surface *surface;
|
2021-12-08 09:41:33 +01:00
|
|
|
SDL_bool no_hint_set;
|
2018-10-03 23:37:29 -04:00
|
|
|
|
2021-08-10 12:02:17 -07:00
|
|
|
/* Set the vsync hint based on our flags, if it's not already set */
|
|
|
|
|
hint = SDL_GetHint(SDL_HINT_RENDER_VSYNC);
|
2022-11-27 17:38:43 +01:00
|
|
|
if (hint == NULL || !*hint) {
|
2021-12-08 09:41:33 +01:00
|
|
|
no_hint_set = SDL_TRUE;
|
|
|
|
|
} else {
|
|
|
|
|
no_hint_set = SDL_FALSE;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (no_hint_set) {
|
2021-08-10 12:02:17 -07:00
|
|
|
SDL_SetHint(SDL_HINT_RENDER_VSYNC, (flags & SDL_RENDERER_PRESENTVSYNC) ? "1" : "0");
|
|
|
|
|
}
|
|
|
|
|
|
2018-10-03 23:37:29 -04:00
|
|
|
surface = SDL_GetWindowSurface(window);
|
2021-08-10 12:02:17 -07:00
|
|
|
|
|
|
|
|
/* Reset the vsync hint if we set it above */
|
2021-12-08 09:41:33 +01:00
|
|
|
if (no_hint_set) {
|
2021-08-10 12:02:17 -07:00
|
|
|
SDL_SetHint(SDL_HINT_RENDER_VSYNC, "");
|
|
|
|
|
}
|
|
|
|
|
|
2022-11-27 17:38:43 +01:00
|
|
|
if (surface == NULL) {
|
2018-10-03 23:37:29 -04:00
|
|
|
return NULL;
|
|
|
|
|
}
|
|
|
|
|
return SW_CreateRendererForSurface(surface);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
SDL_RenderDriver SW_RenderDriver = {
|
|
|
|
|
SW_CreateRenderer,
|
2022-11-30 12:51:59 -08:00
|
|
|
{ "software",
|
2023-02-03 12:25:46 -08:00
|
|
|
(SDL_RENDERER_SOFTWARE | SDL_RENDERER_PRESENTVSYNC),
|
2022-11-30 12:51:59 -08:00
|
|
|
0,
|
|
|
|
|
{ /* formats filled in later */
|
|
|
|
|
SDL_PIXELFORMAT_UNKNOWN },
|
|
|
|
|
0,
|
|
|
|
|
0 }
|
2018-10-03 23:37:29 -04:00
|
|
|
};
|
|
|
|
|
|
2020-01-23 01:00:52 -08:00
|
|
|
#endif /* SDL_VIDEO_RENDER_SW && !SDL_RENDER_DISABLED */
|