Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

SDL_BlitSurface only blits in a small square #662

Closed
SDLBugzilla opened this issue Feb 10, 2021 · 0 comments
Closed

SDL_BlitSurface only blits in a small square #662

SDLBugzilla opened this issue Feb 10, 2021 · 0 comments

Comments

@SDLBugzilla
Copy link
Collaborator

SDLBugzilla commented Feb 10, 2021

This bug report was migrated from our old Bugzilla tracker.

These attachments are available in the static archive:

Reported in version: 1.2.14
Reported for operating system, platform: Linux, x86_64

Comments on the original bug report:

On 2012-01-24 09:26:46 +0000, Edouard Timsit wrote:

Created attachment 803
bliting of 300*200 pointed BMP.

Hi,

SDL_BlitSurface has a restricted effect in the screen, 1/2 times with the same code.

SDL_BlitSurface works in a very small part of the screen, a small square at left top of it. Wherever I blit whatever surface, only the part included in this square will be... "seeable", the rest of the screen remaining black.

It happens with the most simple code.SDL Video initialization, screen initialization, surface pointer initialization, bmp loading into it, screen bliting over, flip, signature return.

( Ubuntu 11.10, 3.0.0-15-generic-pae kerne, Intel Pentium CPU G620 therefore no video card.l, and of course the last version of SDL. I don't know if it's important to notice it, but the bug i'm reporting occured after weeks of great working of the SDL and reinstalled SDL. )

Thanks

On 2012-01-28 07:36:03 +0000, Sam Lantinga wrote:

Does it happen with SDL 1.2.15? Make sure you uninstall SDL 1.2.14 first...
http://www.libsdl.org/download.php

On 2012-01-29 04:22:46 +0000, Edouard Timsit wrote:

Thanks for your response.

It happens with SDL 1.2.15 too... Maybe the pentium G620 technology ?

On 2012-01-29 23:39:09 +0000, Edouard Timsit wrote:

Or clipped screen...

On 2012-01-30 17:13:38 +0000, Sam Lantinga wrote:

Do you have problems with the SDL test programs that come with the source archive?
http://www.libsdl.org/download.php

If not, can you post a simple example that shows the problem?

On 2012-01-31 06:58:29 +0000, Edouard Timsit wrote:

Created attachment 809
The most simple program

On 2012-01-31 07:06:28 +0000, Edouard Timsit wrote:

Created attachment 810
the result of this program

VERY VERY rarely, the program runs fine. So rarely that I lost patience trying to screenshot it.

On 2012-01-31 07:09:57 +0000, Edouard Timsit wrote:

The testblitspeed :
"Non-blitting crap accounted for 0 percent of this run.
63975 blits took 9972ms (6415fps).

( Sorry for triple post )

I ran an executable compiled by someone and it worked fine. But when I compile, bug happens.

On 2012-01-31 11:00:53 +0000, Edouard Timsit wrote:

(In reply to comment # 7)

The testblitspeed :
"Non-blitting crap accounted for 0 percent of this run.
63975 blits took 9972ms (6415fps).

( Sorry for triple post )

I ran an executable compiled by someone and it worked fine. But when I compile,
bug happens.

Sorry for editing again. I made the same program but this time with a loop :

while(1)
{
SDL_BlitSurface(test, NULL, ecran, &whereTo);
SDL_Flip(ecran);
SDL_Delay(250);
SDL_FillRect( ecran, 0, SDL_MapRGB( ecran->format, 0, 0, 0 ) );
SDL_Flip(ecran);
SDL_Delay(250);
}

The first blit doesn't work, but all the other works great !

On 2012-01-31 17:53:49 +0000, Sam Lantinga wrote:

In the sample program you provided you are not filling out the whereTo width and height. You must set those to the same values as the sample width and height.

On 2012-02-01 00:01:04 +0000, Edouard Timsit wrote:

When I learned SDL, I've been taught that w and h of the destination rect where not used by SDL_BlitSurface. Sorry for that. But even if I set whereTo.w and whereTo.h, it doesn't work at first time, but all of the next blit in the loop I wrote are working great.

while(1)
{
whereTo.x = -250;
whereTo.y = -80;
whereTo.w = 400;
whereTo.h = 200;
SDL_BlitSurface(test, NULL, ecran, &whereTo);
SDL_Flip(ecran);
SDL_Delay(500);
SDL_FillRect( ecran, 0, SDL_MapRGB( ecran->format, 0, 0, 0 ) );
SDL_Flip(ecran);
SDL_Delay(500);
}

On 2012-02-01 05:46:51 +0000, Sam Lantinga wrote:

The sample.bmp dimensions included with the SDL tests are 408 x 167

On 2012-02-01 12:46:09 +0000, Edouard Timsit wrote:

Sorry for being insistant, but even if the right w and h it doesn't fix the problem...

On 2012-02-01 21:11:52 +0000, Sam Lantinga wrote:

I haven't been able to reproduce it here. Have you tried debugging it and see what's happening there?

On 2012-02-02 01:14:54 +0000, Edouard Timsit wrote:

Debugger says :
Warning: GDB: Failed to set controlling terminal: Operation non permited

I don't know if it can help you, but I tried another code.
Like I said, blit and then flip doesn't work. But it works great with a SDL_Delay before.

SDL Initialization :
Blit
Flip
//Doesn't work

But :

SDL_Delay(100)
Blit
Flip
// Works fine.

On 2012-02-06 16:34:01 +0000, Rafał Mużyło wrote:

The problem seems to lie completely elsewhere.
I can reproduce it...if whereTo.x = -250;whereTo.y = -80;
but not if whereTo.x = -250;whereTo.y = -80;.
Is that a good enough hint ?

Seriously though, I haven't really (or fully) investigated it, but it comes down to something simple: SDL_BlitSurface modifies it's destrect argument, so this is not quite a bug, just a not quite expected behavior.
On any subsequent iterations after the first one with the given in comment 5 test data (both code and sample.bmp), whereTo.x==whereTo.y==0.

So, the first result (the small update in the corner) is actually the correct one.

On 2012-02-06 16:53:19 +0000, Rafał Mużyło wrote:

...a typo; it was meant to read
"...but not if whereTo.x = 250;whereTo.y = 80;...."

On 2012-02-06 23:59:11 +0000, Edouard Timsit wrote:

Can't it be the result of the OS ? I have two computer with Ubuntu, the two of them have the same bug and this bug disapear with a SDL_Delay just after SDL_Initialisation... But without SDL_Delay, no matter wich w or h was set, the screen seems to be this small square.

On 2012-02-07 00:00:06 +0000, Edouard Timsit wrote:

  • "no matter witch w, h, x or y was set..."

On 2012-02-07 07:09:38 +0000, Rafał Mużyło wrote:

Try something like this:
for(i = 0; i<7; i++)
{
//SDL_Delay(2000);
SDL_BlitSurface(test, NULL, ecran, &whereTo);
//fprintf(stderr, "rect x: %d, y: %d\n", whereTo.x, whereTo.y);
whereTo.x = -250;
whereTo.y = -80;
SDL_Flip(ecran);
SDL_UpdateRect(ecran, 0, 0, 0, 0);
SDL_Delay(2000);
SDL_FillRect( ecran, 0, SDL_MapRGB( ecran->format, 0, 0, 0 ) );
SDL_Flip(ecran);
SDL_Delay(250);
}

(longer delays, so you can actually see the result)

Result is consistent then - on each blit only the small area in the corner is affected. TBH, only part of this behavior, that's unexpected, is that input rectangle (that is data initially provided) gets modified.

Looking at the source, it seems to be due to the solution chosen to pass data between _UpperBlit and _LowerBlit.

On 2012-05-12 11:24:11 +0000, Paulo Bardes wrote:

I have the same problem... It seems that the problem is the screen surface, because even operations like SDL_FillRect() only fill a small part of the screen. Also it only happens on the first time I use the screen surface, after I do anything else it behaves as expected...

On 2012-05-12 11:32:53 +0000, Paulo Bardes wrote:

Created attachment 855
Simple bug test

On 2012-05-12 11:52:29 +0000, Paulo Bardes wrote:

BTW: I'm also using Ubuntu (12.04 - 64 bits) and my sdl version is also 1.2.15

I've tested the exact same code compiled in another machine with Ubuntu (11.10 - 32 bits) and SDL 1.2.15 too, and the bug was gone...

On 2013-11-02 03:13:46 +0000, Rubinson Ivan wrote:

You need to set whereTo.w and whereTo.h

On 2013-11-03 19:03:30 +0000, Sam Lantinga wrote:

Rubinson Ivan is correct.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant