Code: Select all
void Graphics::PutPixelClipped(int x, int y, Color c)
{
if( x >= 0 && x < ScreenWidth &&
y <= 0 && y < ScreenHeight )
{
PutPixel(x,y,c);
}
}
Code: Select all
void Graphics::PutPixelClipped(int x, int y, Color c)
{
if( x >= 0 && x < ScreenWidth &&
y <= 0 && y < ScreenHeight )
{
PutPixel(x,y,c);
}
}
Awesome The bullets aren't doing anything yet. I plan on having them disappear when they hit the mines but haven't decided if they're going to effect the mines.chili wrote:I just played space balls. Lookin good bro! Music really adds something to a demo. I gotta work on that .ogg file support in the framework sometime soonish.
Do the balls you shoot have any effect as of yet?
As for your question, we won't be able to do clipping WELL for a little while yet. Once we are able to load sprite pixels into arrays from .bmp files, then we can do proper sprite BitBltting (Bit Block Transferring). And when we do that, we can adjust the start/end points of the x and y loops to only draw the pixels that will appear inside the screen region.
However, to load bitmaps we need to know about pointers, strings, file access, 2D array organization, so were still a few episode away from that.
As papa says, for now you can do per-pixel testing for any sprites that may be partly off the screen. It is very slow, but it should be fine for a moderate amount of smallish sprites. If you need a better performance boost, you can make 2 versions of the draw function. A clipping version and a non-clipping version. Then you do a rect test to see if the sprite is completely in the window. If so, call non-clipping draw. Otherwise, call clipping draw.
No don't say sorryalbinopapa wrote:I forgot about the massive putpixel calls and changing them all over to use either or would be a pain, sorry.
It's not a hassle at all.Yumtard wrote:No don't say sorryalbinopapa wrote:I forgot about the massive putpixel calls and changing them all over to use either or would be a pain, sorry.
Was an interesting solution. Actually ended up using it for the mines.
Because I was getting errors when a mine exploded near the end of the screen since the explosion is bigger than the actual mines, so needed to add PutPixelClipped for the explosion and while I was at it I also added it for the mines to make the glide in and out of screen smoothly
Raw pointers are used not-so-often in modern C++ because in most cases they can be replaced with the safer-and-sexier-syntaxed &reference, or when we need a pointer, we wrap it up in a smart pointer container. I use more pointer-like objects (smart pointers, iterators) than I do actual pointers. They still have their uses though, and a lot of APIs and like to return handles to objects as raw pointers (Box2D, Unreal Engine for instance).Yumtard wrote: Pointers, constructors and deconstructors are topics I want to "master" as of now i understand what they are but am unsure how and when to actually use them in practice
Sounds awesomechili wrote:Raw pointers are used not-so-often in modern C++ because in most cases they can be replaced with the safer-and-sexier-syntaxed &reference, or when we need a pointer, we wrap it up in a smart pointer container. I use more pointer-like objects (smart pointers, iterators) than I do actual pointers. They still have their uses though, and a lot of APIs and like to return handles to objects as raw pointers (Box2D, Unreal Engine for instance).Yumtard wrote: Pointers, constructors and deconstructors are topics I want to "master" as of now i understand what they are but am unsure how and when to actually use them in practice
Deconstructors aren't used much either because we like to use things that deconstruct themselves automatically. That being said, I will be going over them in the beginning of Intermediate.
Beginner will run up to T24 and then we will start Intermediate, diving balls deep into pointers