Followers 0

# Clipping Error

## 13 posts in this topic

I don't know if the problem would be classified as a clipping error or what, but sometimes the tops/bottoms of sprites shift to the left or the right or a block is cut out of them. It isn't a major problem and only shows up for a single frame, but it still occurs and I am still able to catch it. I am using SDL alongside C. What can I do to eliminate this problem? I have attached an example image, where the sprite on the left is the original and the ones on the right are the modified ones. Thank you! :)

0

##### Share on other sites

Well, in order to eliminate it we'll need to find out what's causing it. Could you give us some information that may help narrow those possibilities down?

0

##### Share on other sites

Here is the basic layout of the code. Maybe I am doing something ineffectively:

SDL_Init(SDL_INIT_EVERYTHING);
SDL_Surface *screen=SDL_SetVideoMode( 200, 200, 32, SDL_SWSURFACE ), *sprite=IMG_Load("sprite.png");
SDL_Rect location;
while(1) {
/* Code here to move it. */
SDL_BlitSurface(sprite,NULL,screen,&location);
SDL_Flip(screen);
SDL_Delay(35); }


Could the delay possibly be causing the problem? I need a way to keep it from hogging the processing power to itself and using a delay is the only thing that came to mind. Thanks!

0

##### Share on other sites

This might be a bit of an obvious one but best to eliminate the simple factors first. Are the images in your sprite sheet aligned properly. As the image may be starting off the top of your sprites drawing box.

Or is your drawing rectangle of your sprite being set in a slightly offset position.

These are assuming you're using a single sprite sheet and are only drawing a specific area of the sprite sheet using a rectangle. Though without knowing how you're drawing your sprite exactly or the image you're drawing from makes it a little more difficult.

0

##### Share on other sites

I am using a sprite sheet and have the proper coordinates, yes. As I have stated, it is not a constant issue that happens on every frame nor a certain frame, so I don't think it is in the code itself. It is barely noticeable and easiest to catch when the game is running and you take a screenshot of it with the keyboard key for that. Is this because SDL_Flip does not replace the whole screen area all at once but instead starts at the bottom and goes up in blocks? Or starts at the top and goes down? I can see how this could cause the rendering issue in screenshots taken. The top half of the player is from the old position and the bottom half is from the new position... so everything below a certain line is new and everything above it is the previously flipped screen. I'm wondering what I can do so I can take a screenshot of the game without the refresh issue being involved.

So I think I have found the problem. It isn't anything to do with my code (which I already figured), but instead has to do with the way SDL is refreshing the graphics. Is there anything whatsoever I can do about this? Thank you!

EDIT: It rarely ever happens. Is it really anything to be concerned about? I may be over-thinking everything...

Edited by Tolito
0

##### Share on other sites
Could it be an artifact from v sync shearing? Meaning, is it just whem your screen has updatwd in the middle of sdl drawing to screen? Try to turn on v sync and see if it still happens.
1

##### Share on other sites

Just did a reputation++; for you! Is it possible to enable V-Sync-ing software-side via SDL, or will whoever plays the game have to enable it? Thank you! :) Definitely a topic for me to research! :)

0

##### Share on other sites

Just did a reputation++; for you! Is it possible to enable V-Sync-ing software-side via SDL, or will whoever plays the game have to enable it? Thank you! Definitely a topic for me to research!

Check the top 2 responses.  It seems SDl doesn't natively support it, but it may be turned on via a OpenGL call.

BTW, may I suggest you look into SFML?  IMO, it's a better multimedia API solution.  You don't have to use it, but I advise at least looking into it.  Having used both (SDL and SFML), I find SFML to be FAR superior.

1

##### Share on other sites

More reputation++; for you! I found the line of code for it and added it to my code. I don't see it often, so I haven't noticed and changes yet... hopefully it has eliminated the problem!

Thanks for the recommendation! I did some research on it to find that it is a lot easier to catch on to than SDL and that it is higher level. For me, higher level stuff is just more confusing (even though higher level is meant to be more understandable). I noticed that it is still in early stages and not as portable as SDL, and that SDL has better performance. SFML sounds like something to keep an eye on, but I prefer SDL and the low level atmosphere. Thank you for bringing it to my attention, and thank you very much for providing the solution to my problem!

Edited by Tolito
0

##### Share on other sites

I noticed that it is still in early stages and not as portable as SDL, and that SDL has better performance.

Where did you hear that?  You're looking at the wrong thing if you think SFML is in the early stages.  You'll find SFML has MUCH better performance than SDL.

About 2 years ago, I was trying to write a game in SDL (as I had used it multiple times before on other projects), and it included a rotating sprite.  SDL's doesn't natively support rotation, so I tried using using SDL_gfx to rotate an image, and it worked, but it was awfully slow.

So, I then tried it SFML, and using sf::Sprite::setRotation(), there was no delay.  It was night and day.  I would never consider going back to SDL after using SFML.

BTW, SFML also has sf::Window::setVerticalSyncEnabled() to control v-sync form the application.

SDL is fine for many things, but I'll never go back to it after using SFML for the last 2 years.

Good luck and have fun!

0

##### Share on other sites

Perhaps I was looking at something outdated. As for rotation, that was because SDL_gfx modifies the pixels of the surface itself, using trigonometry and all of that. SMFL, relying on OpenGL, maps loaded graphics to 3D surfaces, which can easily be rotated (so the renderer handles the rotation instead of the actual image data having to be modified to perform a rotation).

Whenever I feel like it, I may install SMFL and write a simple program in it and write an SDL version of it and compare things like file-size, how much memory is used by each one, and the like. There are just so many graphical libraries out there, each with their ups and downs. Thanks again, and have a great day!

EDIT:

I would like to also provide a link to a video I found pertaining to this subject:

EDIT:

What he says about SDL being the most low-level, how it is the API of choice for working on a low level, it being C-based, and all of that... those things and more are the reasons I prefer SDL.

This topic has kind of strayed. LOL.

Edited by Tolito
0

##### Share on other sites

Be careful listening to his advice from that video.  From some of the things he said as well as his comments from the video, it sounds like he's not too sure of himself.  In an answer to why SFML was benchmarked at 4000% faster than SDL, his reply included:

"Also sfml supports C++ which in a sense is more effecient than the C language." Which is a 100% not a reason for SFML to be faster than SDL

The proper answer is SFML is built upon HW accelerated API's.  It uses OpenGL for all GFX functions, and it uses OpenAL for all audio functions.  Do you want spatial audio in your game?  You won't find that in SDL.

He also says silly things like SDL handles transparent color key "better", and "I believe that SFML is missing some features."  He doesn't say which features, just he believes it's missing some.

Finally, my favorite, he says the reason SFML is bad is because it's too easy and it includes things that make programming games easier, like Views.  Views are a powerful tool in SFML, and are used for much more than scrolling. I've used them for rotating the view around a top-down player.

My suggestion, and you will probably do this, is to research all of them yourself.  I've never used Allegro, so I can't comment on it.

Good luck and have fun!

0

##### Share on other sites

Actually, he said what was missing from SFML was the low-level modification of surfaces. With him saying C++ is more efficient than C, that is not a reason indeed. C++ is higher level and meant to be easier to understand, whereas C is lower level. I have rewritten a C++ program in C before and the resulting executable was thirty times smaller. Many people seem to be intertwining high-level (and easier to understand) with actual efficiency. In the future, I will be storing graphics in my own formats, which will be loaded into SDL as surfaces, which must be done at a low level. SDL seems to support this the best out of them all.

The fact that hardware acceleration is also an option with SDL, which serves as a handy container for OpenGL and can run alongside OpenAL just makes it all boil down to preference. Pretty much the same thing can be done with all of them, with exceptions here and there. I prefer low-level access and even low-level code, and you prefer a higher-level way of doing things. Let's leave it at that. :P

0

##### Share on other sites

Actually, he said what was missing from SFML was the low-level modification of surfaces. ... In the future, I will be storing graphics in my own formats, which will be loaded into SDL as surfaces, which must be done at a low level. SDL seems to support this the best out of them all.

I can't help it:

sf::Texture  Do you want to manipulate the surface on the graphics card memory?

sf::Image Or do you want to manipulate the surface living in RAM?

They both have loadFromMemory and update functions you can pass memory to.

And, seriously, halfway through, when talking about SFML he says, and I quote, "Also, SFML is missing a few features, I believe, that is, uh, easy to work around, but, I believe it is missing a few features that I would often like."

That's it.

He doesn't say anything at all about what features it's missing. No further explanation.

The other things he says, SDL allows you to change the transparent color key.  While Allegro and SFML also provide this feature, (and this is a quote) "But, SDL, I believe, implements it better."  What?  That's it? No reason?  I don't buy SDL implements such a simple feature "better", and he uses it as a reason.

I can't take anyone serious who would compare the different API's like that.

0

## Create an account

Register a new account