Clipping Error

Tolito Delarosa · 2013-01-29T20:18:03

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! :)

For Beginners

Started by Tolito January 27, 2013 04:18 AM

12 comments, last by BeerNutts 11 years, 2 months ago

Tolito

256

Author

January 28, 2013 10:22 PM

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.

BeerNutts

4,410

January 28, 2013 10:59 PM

(Yes, it has strayed, sorry I'm so bull-headed about this :)

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!

My Gamedev Journal: 2D Game Making, the Easy Way

---(Old Blog, still has good info): 2dGameMaking
-----
"No one ever posts on that message board; it's too crowded." - Yoga Berra (sorta)

Tolito

256

Author

January 29, 2013 07:08 PM

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

BeerNutts

4,410

January 29, 2013 08:18 PM

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.

My Gamedev Journal: 2D Game Making, the Easy Way

---(Old Blog, still has good info): 2dGameMaking
-----
"No one ever posts on that message board; it's too crowded." - Yoga Berra (sorta)

Clipping Error

This topic is closed to new replies.

Popular Topics

Recommended Tutorials

Clipping Error

This topic is closed to new replies.

Popular Topics

Recommended Tutorials

Reticulating splines