mpo/VVVVVV
1
0
Fork 0
mirror of https://github.com/TerryCavanagh/VVVVVV.git synced 2024-06-26 06:28:30 +02:00
Code Issues Releases Wiki Activity
556e3a110a
VVVVVV/desktop_version/src/GraphicsUtil.h

43 lines
1.5 KiB
C
Raw Normal View History

Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
#ifndef GRAPHICSUTIL_H
#define GRAPHICSUTIL_H
Consistently use angle brackets for SDL.h includes That's how it should be done, because the SDL headers aren't going to be installed in this repository. The game was a bit inconsistent before but now it isn't anymore.
2020-07-19 06:21:27 +02:00
#include <SDL.h>
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
void setRect(SDL_Rect& _r, int x, int y, int w, int h);
SDL_Surface* GetSubSurface( SDL_Surface* metaSurface, int x, int y, int width, int height );
Use SDL_Color for colors instead of colourTransform colourTransform is a struct with only one member, a Uint32. The issue with `Uint32`s is that it requires a bunch of bit shifting logic to edit the colors. The issue with bit shifting logic is that people have a tendency to hardcode the shift amounts instead of using the shift amount variables of the SDL_PixelFormat, which makes it annoying to change the color masks of surfaces. This commit fixes both issues by unhardcoding the bit shift amounts in DrawPixel and ReadPixel, and by axing the `Uint32`s in favor of using SDL_Color. According to the SDL_PixelFormat documentation ( https://wiki.libsdl.org/SDL2/SDL_PixelFormat ), the logic to read and draw to pixels from colors below 32-bit was just wrong. Specifically, for 8-bit, there's a color palette used instead of some intrinsic color information stored in the pixel itself. But we shouldn't need that logic anyways because we don't use colors below 32-bit. So I axed that too.
2023-01-02 01:36:43 +01:00
SDL_Color ReadPixel(const SDL_Surface* surface, int x, int y);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
SDL_Surface * ScaleSurface( SDL_Surface *Surface, int Width, int Height, SDL_Surface * Dest = NULL );
void BlitSurfaceStandard( SDL_Surface* _src, SDL_Rect* _srcRect, SDL_Surface* _dest, SDL_Rect* _destRect );
Use SDL_Color for colors instead of colourTransform colourTransform is a struct with only one member, a Uint32. The issue with `Uint32`s is that it requires a bunch of bit shifting logic to edit the colors. The issue with bit shifting logic is that people have a tendency to hardcode the shift amounts instead of using the shift amount variables of the SDL_PixelFormat, which makes it annoying to change the color masks of surfaces. This commit fixes both issues by unhardcoding the bit shift amounts in DrawPixel and ReadPixel, and by axing the `Uint32`s in favor of using SDL_Color. According to the SDL_PixelFormat documentation ( https://wiki.libsdl.org/SDL2/SDL_PixelFormat ), the logic to read and draw to pixels from colors below 32-bit was just wrong. Specifically, for 8-bit, there's a color palette used instead of some intrinsic color information stored in the pixel itself. But we shouldn't need that logic anyways because we don't use colors below 32-bit. So I axed that too.
2023-01-02 01:36:43 +01:00
void BlitSurfaceColoured(SDL_Surface* src, const SDL_Rect* src_rect, SDL_Surface* dest, SDL_Rect* dest_rect, SDL_Color color);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
Use SDL_Color for colors instead of colourTransform colourTransform is a struct with only one member, a Uint32. The issue with `Uint32`s is that it requires a bunch of bit shifting logic to edit the colors. The issue with bit shifting logic is that people have a tendency to hardcode the shift amounts instead of using the shift amount variables of the SDL_PixelFormat, which makes it annoying to change the color masks of surfaces. This commit fixes both issues by unhardcoding the bit shift amounts in DrawPixel and ReadPixel, and by axing the `Uint32`s in favor of using SDL_Color. According to the SDL_PixelFormat documentation ( https://wiki.libsdl.org/SDL2/SDL_PixelFormat ), the logic to read and draw to pixels from colors below 32-bit was just wrong. Specifically, for 8-bit, there's a color palette used instead of some intrinsic color information stored in the pixel itself. But we shouldn't need that logic anyways because we don't use colors below 32-bit. So I axed that too.
2023-01-02 01:36:43 +01:00
void BlitSurfaceTinted(SDL_Surface* src, const SDL_Rect* src_rect, SDL_Surface* dest, SDL_Rect* dest_rect, SDL_Color color);
Add BlitSurfaceTinted() This will be used to change the color of existing textures while preserving their lightness values.
2020-06-30 00:05:57 +02:00
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
void FillRect( SDL_Surface* surface, const int x, const int y, const int w, const int h, const int r, int g, int b );
void FillRect( SDL_Surface* surface, const int r, int g, int b );
Use SDL_Color for colors instead of colourTransform colourTransform is a struct with only one member, a Uint32. The issue with `Uint32`s is that it requires a bunch of bit shifting logic to edit the colors. The issue with bit shifting logic is that people have a tendency to hardcode the shift amounts instead of using the shift amount variables of the SDL_PixelFormat, which makes it annoying to change the color masks of surfaces. This commit fixes both issues by unhardcoding the bit shift amounts in DrawPixel and ReadPixel, and by axing the `Uint32`s in favor of using SDL_Color. According to the SDL_PixelFormat documentation ( https://wiki.libsdl.org/SDL2/SDL_PixelFormat ), the logic to read and draw to pixels from colors below 32-bit was just wrong. Specifically, for 8-bit, there's a color palette used instead of some intrinsic color information stored in the pixel itself. But we shouldn't need that logic anyways because we don't use colors below 32-bit. So I axed that too.
2023-01-02 01:36:43 +01:00
void FillRect( SDL_Surface* surface, SDL_Rect& rect, const int r, int g, int b );
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
Use SDL_Color for colors instead of colourTransform colourTransform is a struct with only one member, a Uint32. The issue with `Uint32`s is that it requires a bunch of bit shifting logic to edit the colors. The issue with bit shifting logic is that people have a tendency to hardcode the shift amounts instead of using the shift amount variables of the SDL_PixelFormat, which makes it annoying to change the color masks of surfaces. This commit fixes both issues by unhardcoding the bit shift amounts in DrawPixel and ReadPixel, and by axing the `Uint32`s in favor of using SDL_Color. According to the SDL_PixelFormat documentation ( https://wiki.libsdl.org/SDL2/SDL_PixelFormat ), the logic to read and draw to pixels from colors below 32-bit was just wrong. Specifically, for 8-bit, there's a color palette used instead of some intrinsic color information stored in the pixel itself. But we shouldn't need that logic anyways because we don't use colors below 32-bit. So I axed that too.
2023-01-02 01:36:43 +01:00
void FillRect(SDL_Surface* surface, SDL_Rect rect, SDL_Color color);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
Use SDL_Color for colors instead of colourTransform colourTransform is a struct with only one member, a Uint32. The issue with `Uint32`s is that it requires a bunch of bit shifting logic to edit the colors. The issue with bit shifting logic is that people have a tendency to hardcode the shift amounts instead of using the shift amount variables of the SDL_PixelFormat, which makes it annoying to change the color masks of surfaces. This commit fixes both issues by unhardcoding the bit shift amounts in DrawPixel and ReadPixel, and by axing the `Uint32`s in favor of using SDL_Color. According to the SDL_PixelFormat documentation ( https://wiki.libsdl.org/SDL2/SDL_PixelFormat ), the logic to read and draw to pixels from colors below 32-bit was just wrong. Specifically, for 8-bit, there's a color palette used instead of some intrinsic color information stored in the pixel itself. But we shouldn't need that logic anyways because we don't use colors below 32-bit. So I axed that too.
2023-01-02 01:36:43 +01:00
void FillRect(SDL_Surface* surface, SDL_Color color);
void FillRect(SDL_Surface* surface, int x, int y, int w, int h, SDL_Color color);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
Use SDL_Color for colors instead of colourTransform colourTransform is a struct with only one member, a Uint32. The issue with `Uint32`s is that it requires a bunch of bit shifting logic to edit the colors. The issue with bit shifting logic is that people have a tendency to hardcode the shift amounts instead of using the shift amount variables of the SDL_PixelFormat, which makes it annoying to change the color masks of surfaces. This commit fixes both issues by unhardcoding the bit shift amounts in DrawPixel and ReadPixel, and by axing the `Uint32`s in favor of using SDL_Color. According to the SDL_PixelFormat documentation ( https://wiki.libsdl.org/SDL2/SDL_PixelFormat ), the logic to read and draw to pixels from colors below 32-bit was just wrong. Specifically, for 8-bit, there's a color palette used instead of some intrinsic color information stored in the pixel itself. But we shouldn't need that logic anyways because we don't use colors below 32-bit. So I axed that too.
2023-01-02 01:36:43 +01:00
void FillRect(SDL_Surface* surface, int r, int g, int b, int a);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
Add ClearSurface() This is a function that does what it says - it clears the given surface. This just means doing a FillRect(), but it's better to use this function because it conveys intent better.
2021-02-26 00:26:12 +01:00
void ClearSurface(SDL_Surface* surface);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
void ScrollSurface(SDL_Surface* _src, int pX, int py);
SDL_Surface * FlipSurfaceVerticle(SDL_Surface* _src);
Explicitly declare void for all void parameter functions (#628) Apparently in C, if you have `void test();`, it's completely okay to do `test(2);`. The function will take in the argument, but just discard it and throw it away. It's like a trash can, and a rude one at that. If you declare it like `void test(void);`, this is prevented. This is not a problem in C++ - doing `void test();` and `test(2);` is guaranteed to result in a compile error (this also means that right now, at least in all `.cpp` files, nobody is ever calling a void parameter function with arguments and having their arguments be thrown away). However, we may not be using C++ in the future, so I just want to lay down the precedent that if a function takes in no arguments, you must explicitly declare it as such. I would've added `-Wstrict-prototypes`, but it produces an annoying warning message saying it doesn't work in C++ mode if you're compiling in C++ mode. So it can be added later.
2021-02-25 23:23:59 +01:00
void UpdateFilter(void);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
SDL_Surface* ApplyFilter( SDL_Surface* _src );
#endif /* GRAPHICSUTIL_H */
Reference in New Issue Copy Permalink