We are currently migrating Bugzilla to GitHub issues.
Any changes made to the bug tracker now will be lost, so please do not post new bugs or make changes to them.
When we're done, all bug URLs will redirect to their equivalent location on the new bug tracker.

Bug 1537 - SDL_RenderCopy rendering issue
Summary: SDL_RenderCopy rendering issue
Status: RESOLVED WORKSFORME
Alias: None
Product: SDL
Classification: Unclassified
Component: video (show other bugs)
Version: HG 2.0
Hardware: x86 Windows 7
: P1 blocker
Assignee: Gabriel Jacobo
QA Contact: Sam Lantinga
URL:
Keywords: target-2.0.0
Depends on:
Blocks:
 
Reported: 2012-07-05 04:53 UTC by Jacek Dudek
Modified: 2013-08-01 22:42 UTC (History)
1 user (show)

See Also:

Attachments
Project with different versions of SDL libraries. (8.42 MB, application/octet-stream)
2012-07-05 04:53 UTC, Jacek Dudek 		Details
View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Jacek Dudek 2012-07-05 04:53:21 UTC 
Created attachment 897 [details]
Project with different versions of SDL libraries.

problem discussed <a href="http://forums.libsdl.org/viewtopic.php?p=33217&sid=ecd1702bc6015a5b07d40dc54c254a89">here</a> 

Bug occured while using streaming acess to texture and "by hand" replacing pixels. 

Attached project works fine for commit 6319 but not for any later version.
Comment 1 Sam Lantinga 2013-05-22 01:08:43 UTC 
Gabriel, can you look at this for the SDL 2.0 release?

Thanks!
Comment 2 Gabriel Jacobo 2013-05-22 12:49:59 UTC 
I don't have access to a Windows system with Visual Studio to figure this one out. 

Looking back on the thread, I now understand that there was no regression in SDL_RenderCopy (if I understand correctly), but the problem was that SDL_RenderCopyEX didn't produce the desired output (all black).

Given that creating a texture from a surface works, I think there could be a problem with the alpha channel, or the blend mode (it is not set in the example AFAICT). A simple test case would be useful to confirm this, but I'm fairly confident the problem doesn't lie with SDL.
Comment 3 Ryan C. Gordon 2013-07-12 18:52:55 UTC 
(Sorry if you get a lot of copies of this email, we're touching dozens of bug reports right now.)

Tagging a bunch of bugs as target-2.0.0, Priority 1.

This means we're in the final stretch for an official SDL 2.0.0 release! These are the bugs we really want to fix before shipping if humanly possible.

That being said, we don't promise to fix them because of this tag, we just want to make sure we don't forget to deal with them before we bless a final 2.0.0 release, and generally be organized about what we're aiming to ship.

Hopefully you'll hear more about this bug soon. If you have more information (including "this got fixed at some point, nevermind"), we would love to have you come add more information to the bug report when you have a moment.

Thanks!
--ryan.
Comment 4 Ryan C. Gordon 2013-08-01 22:42:35 UTC 
Just tried the attached project on Windows...works fine with both the "broken" version of the library and the non-broken one. Maybe it's an uninitialized variable in the application somewhere? Questionable that this worked on Windows up to an SDL revision that only makes a change in the X11 test in the configure script...that sounds like an app bug to me.

I'm closing this one. If someone can demonstrate it's still a problem, please reopen this bug.

--ryan.