mpo/VVVVVV
1
0
Fork 0
mirror of https://github.com/TerryCavanagh/VVVVVV.git synced 2024-11-04 18:29:41 +01:00
Code Issues Releases Wiki Activity
VVVVVV/desktop_version/src/GraphicsResources.cpp

577 lines
15 KiB
C++
Raw Normal View History

Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
#include "GraphicsResources.h"
Separate includes into sections and alphabetize them Okay, so basically here's the include layout that this game now consistently uses: [The "main" header file, if any (e.g. Graphics.h for Graphics.cpp)] [blank line] [All system includes, such as tinyxml2/physfs/utfcpp/SDL] [blank line] [All project includes, such as Game.h/Entity.h/etc.] And if applicable, another blank line, and then some special-case include screwy stuff (take a look at editor.cpp or FileSystemUtils.cpp, for example, they have ifdefs and defines with their includes).
2020-07-19 21:43:29 +02:00
Save screenshots with proper filenames Filenames are timestamped now, down to the second. If you take multiple screenshots in the same second, then the last one will overwrite the others. This seems to be how other screenshot programs operate so I don't think it matters if you can't take more than one per second. Additionally, 1x screenshots (320x240) will go in the 1x/ subdirectory, and 2x screenshots (640x480) will go in the 2x/ subdirectory.
2024-01-10 00:05:08 +01:00
#include <time.h>
Add support for translatable sprites Language folders can now have a graphics folder, with these files: - sprites.png and flipsprites.png: spritesheets which contain translated versions of the word enemies and checkpoints - spritesmask.xml: an XML file containing all the sprites that should be copied from the translated sprites and flipsprites images to the original sprites/flipsprites. This means that the translated spritesheets don't have to contain ALL sprites - they only have to contain the translated ones. When loading them, the game assembles a combined spritesheet with translated sprites replacing English ones as needed, and this sheet is used to visually substitute the normal sprites at rendering time. It's important to note that even if 32x32 enemies have pixel-perfect hitboxes, this is only a visual change. This has been discussed several times on Discord - basically we don't want to give people unfair advantages or disadvantages because of their language setting, or change existing gameplay and speedruns tactics, which may depend on the exact pixel arrangements of the enemies. Therefore, the hitboxes are still based on the English sprites. This should be basically unnoticeable for casual players, especially with some thought from translators and artists, but there will be an option in the speedrunner menu to display the original sprites all the time. I removed the `VVV_freefunc(SDL_FreeSurface, *tilesheet)` in make_array() in Graphics.cpp, which frees grphx.im_sprites_surf and grphx.im_flipsprites_surf. Since GraphicsResources::destroy() already frees these, it looks like the only purpose the one in make_array() serves is to do it earlier. But now we need them again later (when switching languages) so let's just not free them early.
2023-09-27 03:53:36 +02:00
#include <tinyxml2.h>
Replace all free calls with `VVV_free[func]` This replaces all calls to SDL_free with a new macro, VVV_free, that nulls the pointer afterwards. This mitigates any use-after-frees and also completely eliminates double-frees. The same is done for any function to free specific objects such as SDL_FreeSurface, with the VVV_freefunc macro. No exceptions for any of these calls, even if the pointer is discarded or zeroed afterwards anyway. Better safe than sorry. This is a macro rather than a function that takes in a pointer-to-pointer because such a function would have type issues that require casting and that's just not safe. Even though SDL_free and other SDL functions already check for NULL, the macro has a NULL check for other functions that don't. For example, FAudioVoice_DestroyVoice does not check for NULL. FILESYSTEM_freeMemory has been axed in favor of VVV_free because it functionally does the same thing except for `unsigned char*` only.
2022-12-01 07:30:16 +01:00
#include "Alloc.h"
Separate includes into sections and alphabetize them Okay, so basically here's the include layout that this game now consistently uses: [The "main" header file, if any (e.g. Graphics.h for Graphics.cpp)] [blank line] [All system includes, such as tinyxml2/physfs/utfcpp/SDL] [blank line] [All project includes, such as Game.h/Entity.h/etc.] And if applicable, another blank line, and then some special-case include screwy stuff (take a look at editor.cpp or FileSystemUtils.cpp, for example, they have ifdefs and defines with their includes).
2020-07-19 21:43:29 +02:00
#include "FileSystemUtils.h"
Add support for internal screenshots "But people already have screenshot tools", you might protest. The rationale is simple: If you play with any video setting other than 1x windowed (no stretching and no letterbox), then your screenshot will be too big if you want the internal resolution of 320x240, and downscaling will be an inconvenience. The point is to make screenshots based off of internal resolution so they are always pixel perfect and ideally never have to be altered once taken. I've added the keybind of F6 to do this. Right now it saves to a temporary test location with the same filename; future commits will save to properly-timestamped filenames.
2024-01-09 20:29:50 +01:00
#include "Graphics.h"
Move from surfaces to the SDL render system Ever since VVVVVV was initially ported to C++ in 2.0, it has used surfaces from SDL. The downside is, that's all software rendering. This commit moves most things off of surfaces, and all into GPU, by using textures and SDL_Renderer. Pixel-perfect collision has been kept by keeping a copy of sprites as surfaces. There's plans for pixel-perfect collision to use masks instead of reading pixel data directly, but that's out of scope for this commit. - `graphics.reloadresources()` is now called later in `main`, because textures cannot be created without a renderer. - This commit also removes a bunch of surface functions which are no longer needed. - This also recaches target textures in certain places for d3d9. - graphics.images was converted to a fixed-size array. - fillbox and fillboxabs use SDL_RenderDrawRect instead of drawing an outline using four filled rectangles - Update my name in the credits
2023-01-07 19:28:07 +01:00
#include "GraphicsUtil.h"
Add support for translatable sprites Language folders can now have a graphics folder, with these files: - sprites.png and flipsprites.png: spritesheets which contain translated versions of the word enemies and checkpoints - spritesmask.xml: an XML file containing all the sprites that should be copied from the translated sprites and flipsprites images to the original sprites/flipsprites. This means that the translated spritesheets don't have to contain ALL sprites - they only have to contain the translated ones. When loading them, the game assembles a combined spritesheet with translated sprites replacing English ones as needed, and this sheet is used to visually substitute the normal sprites at rendering time. It's important to note that even if 32x32 enemies have pixel-perfect hitboxes, this is only a visual change. This has been discussed several times on Discord - basically we don't want to give people unfair advantages or disadvantages because of their language setting, or change existing gameplay and speedruns tactics, which may depend on the exact pixel arrangements of the enemies. Therefore, the hitboxes are still based on the English sprites. This should be basically unnoticeable for casual players, especially with some thought from translators and artists, but there will be an option in the speedrunner menu to display the original sprites all the time. I removed the `VVV_freefunc(SDL_FreeSurface, *tilesheet)` in make_array() in Graphics.cpp, which frees grphx.im_sprites_surf and grphx.im_flipsprites_surf. Since GraphicsResources::destroy() already frees these, it looks like the only purpose the one in make_array() serves is to do it earlier. But now we need them again later (when switching languages) so let's just not free them early.
2023-09-27 03:53:36 +02:00
#include "Localization.h"
Replace all print calls with vlog calls This is pretty straight-forward to do.
2021-02-24 00:21:29 +01:00
#include "Vlogging.h"
Move from surfaces to the SDL render system Ever since VVVVVV was initially ported to C++ in 2.0, it has used surfaces from SDL. The downside is, that's all software rendering. This commit moves most things off of surfaces, and all into GPU, by using textures and SDL_Renderer. Pixel-perfect collision has been kept by keeping a copy of sprites as surfaces. There's plans for pixel-perfect collision to use masks instead of reading pixel data directly, but that's out of scope for this commit. - `graphics.reloadresources()` is now called later in `main`, because textures cannot be created without a renderer. - This commit also removes a bunch of surface functions which are no longer needed. - This also recaches target textures in certain places for d3d9. - graphics.images was converted to a fixed-size array. - fillbox and fillboxabs use SDL_RenderDrawRect instead of drawing an outline using four filled rectangles - Update my name in the credits
2023-01-07 19:28:07 +01:00
#include "Screen.h"
Add support for translatable sprites Language folders can now have a graphics folder, with these files: - sprites.png and flipsprites.png: spritesheets which contain translated versions of the word enemies and checkpoints - spritesmask.xml: an XML file containing all the sprites that should be copied from the translated sprites and flipsprites images to the original sprites/flipsprites. This means that the translated spritesheets don't have to contain ALL sprites - they only have to contain the translated ones. When loading them, the game assembles a combined spritesheet with translated sprites replacing English ones as needed, and this sheet is used to visually substitute the normal sprites at rendering time. It's important to note that even if 32x32 enemies have pixel-perfect hitboxes, this is only a visual change. This has been discussed several times on Discord - basically we don't want to give people unfair advantages or disadvantages because of their language setting, or change existing gameplay and speedruns tactics, which may depend on the exact pixel arrangements of the enemies. Therefore, the hitboxes are still based on the English sprites. This should be basically unnoticeable for casual players, especially with some thought from translators and artists, but there will be an option in the speedrunner menu to display the original sprites all the time. I removed the `VVV_freefunc(SDL_FreeSurface, *tilesheet)` in make_array() in Graphics.cpp, which frees grphx.im_sprites_surf and grphx.im_flipsprites_surf. Since GraphicsResources::destroy() already frees these, it looks like the only purpose the one in make_array() serves is to do it earlier. But now we need them again later (when switching languages) so let's just not free them early.
2023-09-27 03:53:36 +02:00
#include "XMLUtils.h"
Separate includes into sections and alphabetize them Okay, so basically here's the include layout that this game now consistently uses: [The "main" header file, if any (e.g. Graphics.h for Graphics.cpp)] [blank line] [All system includes, such as tinyxml2/physfs/utfcpp/SDL] [blank line] [All project includes, such as Game.h/Entity.h/etc.] And if applicable, another blank line, and then some special-case include screwy stuff (take a look at editor.cpp or FileSystemUtils.cpp, for example, they have ifdefs and defines with their includes).
2020-07-19 21:43:29 +02:00
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
// Used to load PNG data
extern "C"
{
Untabify every single file YOLO. This is a repeat of #642. As before, I just did rg -l '\t' | xargs -n 1 sed -i -e 's/\t/ /g' inside the desktop_version/ folder.
2021-09-07 03:56:39 +02:00
extern unsigned lodepng_decode32(
unsigned char** out,
unsigned* w,
unsigned* h,
const unsigned char* in,
size_t insize
);
Add support for internal screenshots "But people already have screenshot tools", you might protest. The rationale is simple: If you play with any video setting other than 1x windowed (no stretching and no letterbox), then your screenshot will be too big if you want the internal resolution of 320x240, and downscaling will be an inconvenience. The point is to make screenshots based off of internal resolution so they are always pixel perfect and ideally never have to be altered once taken. I've added the keybind of F6 to do this. Right now it saves to a temporary test location with the same filename; future commits will save to properly-timestamped filenames.
2024-01-09 20:29:50 +01:00
extern unsigned lodepng_encode24(
unsigned char** out,
size_t* outsize,
const unsigned char* image,
unsigned w,
unsigned h
);
`LoadImage`: Check LodePNG return value and print errors Dvoid from Discord just reported a crash when trying to load a custom tiles2.png that was encoded weirdly. The problem is that we don't check the return value from LodePNG, so LodePNG gives us a null pointer, and then SDL_CreateRGBSurfaceWithFormatFrom doesn't check this null pointer, which then propagates until we crash in SDL_ConvertSurfaceFormat (or rather, one of its sub-functions), and we would probably crash somewhere else anyway if it continued. After properly checking LodePNG's return value, along with printing the error, it turns out that Dvoid's custom tiles2.png had an "invalid CRC". I don't know what this means but it sounds worrying. `feh` can read the file correctly but it also reports a "CRC error".
2021-11-14 23:02:51 +01:00
extern const char* lodepng_error_text(unsigned code);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
Move from surfaces to the SDL render system Ever since VVVVVV was initially ported to C++ in 2.0, it has used surfaces from SDL. The downside is, that's all software rendering. This commit moves most things off of surfaces, and all into GPU, by using textures and SDL_Renderer. Pixel-perfect collision has been kept by keeping a copy of sprites as surfaces. There's plans for pixel-perfect collision to use masks instead of reading pixel data directly, but that's out of scope for this commit. - `graphics.reloadresources()` is now called later in `main`, because textures cannot be created without a renderer. - This commit also removes a bunch of surface functions which are no longer needed. - This also recaches target textures in certain places for d3d9. - graphics.images was converted to a fixed-size array. - fillbox and fillboxabs use SDL_RenderDrawRect instead of drawing an outline using four filled rectangles - Update my name in the credits
2023-01-07 19:28:07 +01:00
static SDL_Surface* LoadImageRaw(const char* filename, unsigned char** data)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Fix UB where image loading fails in certain cases
2023-08-24 01:10:41 +02:00
*data = NULL;
// Temporary storage for the image that's loaded
Untabify every single file YOLO. This is a repeat of #642. As before, I just did rg -l '\t' | xargs -n 1 sed -i -e 's/\t/ /g' inside the desktop_version/ folder.
2021-09-07 03:56:39 +02:00
SDL_Surface* loadedImage = NULL;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
Untabify every single file YOLO. This is a repeat of #642. As before, I just did rg -l '\t' | xargs -n 1 sed -i -e 's/\t/ /g' inside the desktop_version/ folder.
2021-09-07 03:56:39 +02:00
unsigned int width, height;
`LoadImage`: Check LodePNG return value and print errors Dvoid from Discord just reported a crash when trying to load a custom tiles2.png that was encoded weirdly. The problem is that we don't check the return value from LodePNG, so LodePNG gives us a null pointer, and then SDL_CreateRGBSurfaceWithFormatFrom doesn't check this null pointer, which then propagates until we crash in SDL_ConvertSurfaceFormat (or rather, one of its sub-functions), and we would probably crash somewhere else anyway if it continued. After properly checking LodePNG's return value, along with printing the error, it turns out that Dvoid's custom tiles2.png had an "invalid CRC". I don't know what this means but it sounds worrying. `feh` can read the file correctly but it also reports a "CRC error".
2021-11-14 23:02:51 +01:00
unsigned int error;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
Move from surfaces to the SDL render system Ever since VVVVVV was initially ported to C++ in 2.0, it has used surfaces from SDL. The downside is, that's all software rendering. This commit moves most things off of surfaces, and all into GPU, by using textures and SDL_Renderer. Pixel-perfect collision has been kept by keeping a copy of sprites as surfaces. There's plans for pixel-perfect collision to use masks instead of reading pixel data directly, but that's out of scope for this commit. - `graphics.reloadresources()` is now called later in `main`, because textures cannot be created without a renderer. - This commit also removes a bunch of surface functions which are no longer needed. - This also recaches target textures in certain places for d3d9. - graphics.images was converted to a fixed-size array. - fillbox and fillboxabs use SDL_RenderDrawRect instead of drawing an outline using four filled rectangles - Update my name in the credits
2023-01-07 19:28:07 +01:00
unsigned char* fileIn;
Untabify every single file YOLO. This is a repeat of #642. As before, I just did rg -l '\t' | xargs -n 1 sed -i -e 's/\t/ /g' inside the desktop_version/ folder.
2021-09-07 03:56:39 +02:00
size_t length;
Always add null terminator when loading files This removes the `addnull` argument from `FILESYSTEM_loadFileToMemory` and `FILESYSTEM_loadAssetToMemory`, and makes it so a null terminator is always appended no matter what. This simplifies things and removes the need for callers to make the decision about null termination and what its implications are. Then you get cases where null termination might not happen when it should be, such as the one df577c59ef16df8893e0628559de1b304e84b951 (#947) fixed. When FIQ added the `addnull` argument in 5862af4445bfd9c056de7ef9694f8cb31f9d469a (#117), I'm guessing he did it because he wanted to be cautious about adding the null terminator to every file, so he only did it for XML files, which was the only case needed at the time. But really, there's no downsides to always appending a null terminator. In fact, it's already always done whenever the STDIN buffer is loaded.
2023-03-18 23:12:24 +01:00
FILESYSTEM_loadAssetToMemory(filename, &fileIn, &length);
Untabify every single file YOLO. This is a repeat of #642. As before, I just did rg -l '\t' | xargs -n 1 sed -i -e 's/\t/ /g' inside the desktop_version/ folder.
2021-09-07 03:56:39 +02:00
if (fileIn == NULL)
{
SDL_assert(0 && "Image file missing!");
return NULL;
}
Move from surfaces to the SDL render system Ever since VVVVVV was initially ported to C++ in 2.0, it has used surfaces from SDL. The downside is, that's all software rendering. This commit moves most things off of surfaces, and all into GPU, by using textures and SDL_Renderer. Pixel-perfect collision has been kept by keeping a copy of sprites as surfaces. There's plans for pixel-perfect collision to use masks instead of reading pixel data directly, but that's out of scope for this commit. - `graphics.reloadresources()` is now called later in `main`, because textures cannot be created without a renderer. - This commit also removes a bunch of surface functions which are no longer needed. - This also recaches target textures in certain places for d3d9. - graphics.images was converted to a fixed-size array. - fillbox and fillboxabs use SDL_RenderDrawRect instead of drawing an outline using four filled rectangles - Update my name in the credits
2023-01-07 19:28:07 +01:00
error = lodepng_decode32(data, &width, &height, fileIn, length);
Replace all free calls with `VVV_free[func]` This replaces all calls to SDL_free with a new macro, VVV_free, that nulls the pointer afterwards. This mitigates any use-after-frees and also completely eliminates double-frees. The same is done for any function to free specific objects such as SDL_FreeSurface, with the VVV_freefunc macro. No exceptions for any of these calls, even if the pointer is discarded or zeroed afterwards anyway. Better safe than sorry. This is a macro rather than a function that takes in a pointer-to-pointer because such a function would have type issues that require casting and that's just not safe. Even though SDL_free and other SDL functions already check for NULL, the macro has a NULL check for other functions that don't. For example, FAudioVoice_DestroyVoice does not check for NULL. FILESYSTEM_freeMemory has been axed in favor of VVV_free because it functionally does the same thing except for `unsigned char*` only.
2022-12-01 07:30:16 +01:00
VVV_free(fileIn);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
`LoadImage`: Check LodePNG return value and print errors Dvoid from Discord just reported a crash when trying to load a custom tiles2.png that was encoded weirdly. The problem is that we don't check the return value from LodePNG, so LodePNG gives us a null pointer, and then SDL_CreateRGBSurfaceWithFormatFrom doesn't check this null pointer, which then propagates until we crash in SDL_ConvertSurfaceFormat (or rather, one of its sub-functions), and we would probably crash somewhere else anyway if it continued. After properly checking LodePNG's return value, along with printing the error, it turns out that Dvoid's custom tiles2.png had an "invalid CRC". I don't know what this means but it sounds worrying. `feh` can read the file correctly but it also reports a "CRC error".
2021-11-14 23:02:51 +01:00
if (error != 0)
{
vlog_error("Could not load %s: %s", filename, lodepng_error_text(error));
return NULL;
}
Fix surface color masks This fixes the color ordering of every SDL_Surface in the game. Basically, images need to be loaded in ABGR format (except if they don't have alpha, then you use RGB? I'm not sure what's going on here), and then they will be converted to RGB/RGBA afterwards. Due to the surfaces actually being BGR/BGRA, the game used to use getRGBA/getRGB to swap the colors back around to BGRA/BGR, but I've fixed those too.
2021-02-19 07:20:11 +01:00
loadedImage = SDL_CreateRGBSurfaceWithFormatFrom(
Move from surfaces to the SDL render system Ever since VVVVVV was initially ported to C++ in 2.0, it has used surfaces from SDL. The downside is, that's all software rendering. This commit moves most things off of surfaces, and all into GPU, by using textures and SDL_Renderer. Pixel-perfect collision has been kept by keeping a copy of sprites as surfaces. There's plans for pixel-perfect collision to use masks instead of reading pixel data directly, but that's out of scope for this commit. - `graphics.reloadresources()` is now called later in `main`, because textures cannot be created without a renderer. - This commit also removes a bunch of surface functions which are no longer needed. - This also recaches target textures in certain places for d3d9. - graphics.images was converted to a fixed-size array. - fillbox and fillboxabs use SDL_RenderDrawRect instead of drawing an outline using four filled rectangles - Update my name in the credits
2023-01-07 19:28:07 +01:00
*data,
Untabify every single file YOLO. This is a repeat of #642. As before, I just did rg -l '\t' | xargs -n 1 sed -i -e 's/\t/ /g' inside the desktop_version/ folder.
2021-09-07 03:56:39 +02:00
width,
height,
Remove `noAlpha` argument from `LoadImage` This is just to simplify the function. I really don't see any point in taking away the alpha for some images, other than to disappoint people who mod the game assets. It just complicates loading the image with no real gain. To reduce maintenance costs, let's remove this alternate code path. Also it's a default argument and I don't like default arguments.
2021-12-25 09:57:58 +01:00
32,
width * 4,
Fix loading of PNG resources on big-endian machines LodePNG always loads PNG in big-endian RGBA format. For this reason, when loading PNG files VVVVVV was specifying the format as ABGR and the conversion would then be performed by SDL. However, then running on big-endian machines, this conversion should not be performed at all, and the surface format should then be set to RGBA.
2024-01-22 16:32:15 +01:00
#if SDL_BYTEORDER == SDL_BIG_ENDIAN
SDL_PIXELFORMAT_RGBA8888
#else
Remove `noAlpha` argument from `LoadImage` This is just to simplify the function. I really don't see any point in taking away the alpha for some images, other than to disappoint people who mod the game assets. It just complicates loading the image with no real gain. To reduce maintenance costs, let's remove this alternate code path. Also it's a default argument and I don't like default arguments.
2021-12-25 09:57:58 +01:00
SDL_PIXELFORMAT_ABGR8888
Fix loading of PNG resources on big-endian machines LodePNG always loads PNG in big-endian RGBA format. For this reason, when loading PNG files VVVVVV was specifying the format as ABGR and the conversion would then be performed by SDL. However, then running on big-endian machines, this conversion should not be performed at all, and the surface format should then be set to RGBA.
2024-01-22 16:32:15 +01:00
#endif
Untabify every single file YOLO. This is a repeat of #642. As before, I just did rg -l '\t' | xargs -n 1 sed -i -e 's/\t/ /g' inside the desktop_version/ folder.
2021-09-07 03:56:39 +02:00
);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
Move from surfaces to the SDL render system Ever since VVVVVV was initially ported to C++ in 2.0, it has used surfaces from SDL. The downside is, that's all software rendering. This commit moves most things off of surfaces, and all into GPU, by using textures and SDL_Renderer. Pixel-perfect collision has been kept by keeping a copy of sprites as surfaces. There's plans for pixel-perfect collision to use masks instead of reading pixel data directly, but that's out of scope for this commit. - `graphics.reloadresources()` is now called later in `main`, because textures cannot be created without a renderer. - This commit also removes a bunch of surface functions which are no longer needed. - This also recaches target textures in certain places for d3d9. - graphics.images was converted to a fixed-size array. - fillbox and fillboxabs use SDL_RenderDrawRect instead of drawing an outline using four filled rectangles - Update my name in the credits
2023-01-07 19:28:07 +01:00
return loadedImage;
}
static SDL_Surface* LoadSurfaceFromRaw(SDL_Surface* loadedImage)
{
SDL_Surface* optimizedImage = SDL_ConvertSurfaceFormat(
loadedImage,
SDL_PIXELFORMAT_ARGB8888,
0
);
SDL_SetSurfaceBlendMode(optimizedImage, SDL_BLENDMODE_BLEND);
return optimizedImage;
}
SDL_Surface* LoadImageSurface(const char* filename)
{
unsigned char* data;
SDL_Surface* loadedImage = LoadImageRaw(filename, &data);
SDL_Surface* optimizedImage = LoadSurfaceFromRaw(loadedImage);
Untabify every single file YOLO. This is a repeat of #642. As before, I just did rg -l '\t' | xargs -n 1 sed -i -e 's/\t/ /g' inside the desktop_version/ folder.
2021-09-07 03:56:39 +02:00
if (loadedImage != NULL)
{
Replace all free calls with `VVV_free[func]` This replaces all calls to SDL_free with a new macro, VVV_free, that nulls the pointer afterwards. This mitigates any use-after-frees and also completely eliminates double-frees. The same is done for any function to free specific objects such as SDL_FreeSurface, with the VVV_freefunc macro. No exceptions for any of these calls, even if the pointer is discarded or zeroed afterwards anyway. Better safe than sorry. This is a macro rather than a function that takes in a pointer-to-pointer because such a function would have type issues that require casting and that's just not safe. Even though SDL_free and other SDL functions already check for NULL, the macro has a NULL check for other functions that don't. For example, FAudioVoice_DestroyVoice does not check for NULL. FILESYSTEM_freeMemory has been axed in favor of VVV_free because it functionally does the same thing except for `unsigned char*` only.
2022-12-01 07:30:16 +01:00
VVV_freefunc(SDL_FreeSurface, loadedImage);
Untabify every single file YOLO. This is a repeat of #642. As before, I just did rg -l '\t' | xargs -n 1 sed -i -e 's/\t/ /g' inside the desktop_version/ folder.
2021-09-07 03:56:39 +02:00
}
Move from surfaces to the SDL render system Ever since VVVVVV was initially ported to C++ in 2.0, it has used surfaces from SDL. The downside is, that's all software rendering. This commit moves most things off of surfaces, and all into GPU, by using textures and SDL_Renderer. Pixel-perfect collision has been kept by keeping a copy of sprites as surfaces. There's plans for pixel-perfect collision to use masks instead of reading pixel data directly, but that's out of scope for this commit. - `graphics.reloadresources()` is now called later in `main`, because textures cannot be created without a renderer. - This commit also removes a bunch of surface functions which are no longer needed. - This also recaches target textures in certain places for d3d9. - graphics.images was converted to a fixed-size array. - fillbox and fillboxabs use SDL_RenderDrawRect instead of drawing an outline using four filled rectangles - Update my name in the credits
2023-01-07 19:28:07 +01:00
VVV_free(data);
if (optimizedImage == NULL)
Untabify every single file YOLO. This is a repeat of #642. As before, I just did rg -l '\t' | xargs -n 1 sed -i -e 's/\t/ /g' inside the desktop_version/ folder.
2021-09-07 03:56:39 +02:00
{
vlog_error("Image not found: %s", filename);
SDL_assert(0 && "Image not found! See stderr.");
Move from surfaces to the SDL render system Ever since VVVVVV was initially ported to C++ in 2.0, it has used surfaces from SDL. The downside is, that's all software rendering. This commit moves most things off of surfaces, and all into GPU, by using textures and SDL_Renderer. Pixel-perfect collision has been kept by keeping a copy of sprites as surfaces. There's plans for pixel-perfect collision to use masks instead of reading pixel data directly, but that's out of scope for this commit. - `graphics.reloadresources()` is now called later in `main`, because textures cannot be created without a renderer. - This commit also removes a bunch of surface functions which are no longer needed. - This also recaches target textures in certain places for d3d9. - graphics.images was converted to a fixed-size array. - fillbox and fillboxabs use SDL_RenderDrawRect instead of drawing an outline using four filled rectangles - Update my name in the credits
2023-01-07 19:28:07 +01:00
}
return optimizedImage;
}
static SDL_Texture* LoadTextureFromRaw(const char* filename, SDL_Surface* loadedImage, const TextureLoadType loadtype)
{
if (loadedImage == NULL)
{
Untabify every single file YOLO. This is a repeat of #642. As before, I just did rg -l '\t' | xargs -n 1 sed -i -e 's/\t/ /g' inside the desktop_version/ folder.
2021-09-07 03:56:39 +02:00
return NULL;
}
Move from surfaces to the SDL render system Ever since VVVVVV was initially ported to C++ in 2.0, it has used surfaces from SDL. The downside is, that's all software rendering. This commit moves most things off of surfaces, and all into GPU, by using textures and SDL_Renderer. Pixel-perfect collision has been kept by keeping a copy of sprites as surfaces. There's plans for pixel-perfect collision to use masks instead of reading pixel data directly, but that's out of scope for this commit. - `graphics.reloadresources()` is now called later in `main`, because textures cannot be created without a renderer. - This commit also removes a bunch of surface functions which are no longer needed. - This also recaches target textures in certain places for d3d9. - graphics.images was converted to a fixed-size array. - fillbox and fillboxabs use SDL_RenderDrawRect instead of drawing an outline using four filled rectangles - Update my name in the credits
2023-01-07 19:28:07 +01:00
// Modify the surface with the load type.
// This could be done in LoadImageRaw, however currently, surfaces are only used for
// pixel perfect collision (which will be changed later) and the window icon.
switch (loadtype)
{
case TEX_WHITE:
SDL_LockSurface(loadedImage);
for (int y = 0; y < loadedImage->h; y++)
{
for (int x = 0; x < loadedImage->w; x++)
{
SDL_Color color = ReadPixel(loadedImage, x, y);
color.r = 255;
color.g = 255;
color.b = 255;
DrawPixel(loadedImage, x, y, color);
}
}
SDL_UnlockSurface(loadedImage);
break;
case TEX_GRAYSCALE:
SDL_LockSurface(loadedImage);
for (int y = 0; y < loadedImage->h; y++)
{
for (int x = 0; x < loadedImage->w; x++)
{
SDL_Color color = ReadPixel(loadedImage, x, y);
// Magic numbers used for grayscaling (eyes perceive certain colors brighter than others)
Uint8 r = color.r * 0.299;
Uint8 g = color.g * 0.587;
Uint8 b = color.b * 0.114;
const double gray = SDL_floor(r + g + b + 0.5);
color.r = gray;
color.g = gray;
color.b = gray;
DrawPixel(loadedImage, x, y, color);
}
}
SDL_UnlockSurface(loadedImage);
break;
default:
break;
}
//Create texture from surface pixels
SDL_Texture* texture = SDL_CreateTextureFromSurface(gameScreen.m_renderer, loadedImage);
if (texture == NULL)
{
vlog_error("Failed creating texture: %s. SDL error: %s\n", filename, SDL_GetError());
}
return texture;
}
Start rewrite of font system This is still a work in progress, but the existing font system has been removed and replaced by a new one, in Font.cpp. Design goals of the new font system include supporting colored button glyphs, different fonts for different languages, and larger fonts than 8x8 for Chinese, Japanese and Korean, while being able to support their 30000+ characters without hiccups, slowdowns or high memory usage. And to have more flexibility with fonts in general. Plus, Graphics.cpp was long enough as-is, so it's good to have a dedicated file for font storage. The old font system worked with a std::vector<SDL_Surface*> to store 8x8 surfaces for each character, and a std::map<int,int> to store mappings between codepoints and vector indexes. The new system has a per-font collection of pages for every block of 0x1000 (4096) codepoints, that may be allocated as needed. A glyph on a page contains the index of the glyph in the image (giving its coordinates), the advance (how much the cursor should advance, so the width of that glyph) and some flags which would be at least whether the glyph exists and whether it is colored. Most of the *new* features aren't implemented yet; it's currently hardcoded to the regular 8x8 font.png, but it should be functionally equivalent to the previous behavior. The only thing that doesn't really work yet is level-specific font.png, but that'll be supported again soon enough. This commit also adds fontmeta (xml) support. Since the fonts folder is mounted at graphics/, there are two main options for recognizing non-font.png fonts: the font files have to be prefixed with font (or font_) or some special file extension is involved to signal what files are fonts. I always had a font.xml in mind (so font_cn.xml, font_ja.xml, etc) but if there's ever gonna be a need for further xml files inside the graphics folder, we have a problem. So I named them .fontmeta instead. A .fontmeta file looks somewhat like this: <?xml version="1.0" encoding="UTF-8"?> <font_metadata> <width>12</width> <height>12</height> <white_teeth>1</white_teeth> <chars> <range start="0x20" end="0x7E"/> <range start="0x80" end="0x80"/> <range start="0xA0" end="0xDF"/> <range start="0x250" end="0x2A8"/> <range start="0x2AD" end="0x2AD"/> <range start="0x2C7" end="0x2C7"/> <range start="0x2C9" end="0x2CB"/> ... </chars> <special> <range start="0x00" end="0x1F" advance="6"/> <range start="0x61" end="0x66" color="1"/> <range start="0x63" end="0x63" color="0"/> </special> </font_metadata> The <chars> tag can be used to specify characters instead of in a .txt. The original idea was to just always use the existing .txt system for specifying the font charset, and only use the XML for the other stuff that the .txt doesn't cover. However, it's probably better to keep it simple if possible - having to only have a .png and a .fontmeta seems simpler than having the data spread out over three files. And a major advantage: Chinese fonts can have about 30000 characters! It's more efficient to be able to have a tag saying "now there's 20902 characters starting at U+4E00" than to include them all in a text file and having to UTF-8 decode every single one of them. If a font.txt exists, it takes priority over the <chars> tag, and in that case, there's no reason to include the <chars> tag in the XML. But font.txt has to be in the same directory as font.png, otherwise it is rejected. Same for font.fontmeta. If neither font.txt nor <chars> exist, then the font is seen as a 2.2-and-below-style ASCII font. In <special>: advance is the number of pixels the cursor advances after drawing the character (so the width of the character, without affecting the grid in the source image), color is whether the character should have its original colors retained when printed (for button glyphs). As for <white_teeth>: The renderer PR has replaced draw-time whitening of sprites/etc (using BlitSurfaceColoured) by load-time whitening of entire images (using LoadImage with TEX_WHITE as an argument). This means we have a problem: fonts have always had their glyphs whitened at printing time, and since I'm adding support for colored button glyphs, I changed it so glyphs would sometimes not be whitened. But if we can't whiten at print time, then we'd need to whiten at load time, and if we whiten the entire font, any colored glyphs will get destroyed too. If you whiten the image selectively, well, we need more code to target specific squares in the image, and it's kind of a waste when you need to whiten 30000 12x12 Chinese characters when you're only going to need a handful, but you don't know which ones. The solution: Whitening fonts is useless if all the non-colored glyphs are already white, so we don't need to do it anyway! However, any existing fonts that have non-white glyphs (and I know of at least one level like that) will still need to be whitened. So there is now a font property <white_teeth> that can be specified in the fontmeta, which indicates that the font is already pre-whitened. If not specified, traditional whitening behavior will be used, and the font cannot use colored glyphs.
2023-01-02 05:14:53 +01:00
SDL_Texture* LoadImage(const char *filename, const TextureLoadType loadtype)
Move from surfaces to the SDL render system Ever since VVVVVV was initially ported to C++ in 2.0, it has used surfaces from SDL. The downside is, that's all software rendering. This commit moves most things off of surfaces, and all into GPU, by using textures and SDL_Renderer. Pixel-perfect collision has been kept by keeping a copy of sprites as surfaces. There's plans for pixel-perfect collision to use masks instead of reading pixel data directly, but that's out of scope for this commit. - `graphics.reloadresources()` is now called later in `main`, because textures cannot be created without a renderer. - This commit also removes a bunch of surface functions which are no longer needed. - This also recaches target textures in certain places for d3d9. - graphics.images was converted to a fixed-size array. - fillbox and fillboxabs use SDL_RenderDrawRect instead of drawing an outline using four filled rectangles - Update my name in the credits
2023-01-07 19:28:07 +01:00
{
unsigned char* data;
SDL_Surface* loadedImage = LoadImageRaw(filename, &data);
SDL_Texture* texture = LoadTextureFromRaw(filename, loadedImage, loadtype);
if (loadedImage != NULL)
{
VVV_freefunc(SDL_FreeSurface, loadedImage);
}
VVV_free(data);
if (texture == NULL)
{
vlog_error("Image not found: %s", filename);
SDL_assert(0 && "Image not found! See stderr.");
}
return texture;
}
static SDL_Texture* LoadImage(const char* filename)
{
return LoadImage(filename, TEX_COLOR);
}
/* Any unneeded variants can be NULL */
static void LoadVariants(const char* filename, SDL_Texture** colored, SDL_Texture** white, SDL_Texture** grayscale)
{
unsigned char* data;
SDL_Surface* loadedImage = LoadImageRaw(filename, &data);
if (colored != NULL)
{
*colored = LoadTextureFromRaw(filename, loadedImage, TEX_COLOR);
if (*colored == NULL)
{
vlog_error("Image not found: %s", filename);
SDL_assert(0 && "Image not found! See stderr.");
}
}
if (grayscale != NULL)
{
*grayscale = LoadTextureFromRaw(filename, loadedImage, TEX_GRAYSCALE);
if (*grayscale == NULL)
{
vlog_error("Image not found: %s", filename);
SDL_assert(0 && "Image not found! See stderr.");
}
}
if (white != NULL)
{
*white = LoadTextureFromRaw(filename, loadedImage, TEX_WHITE);
if (*white == NULL)
{
vlog_error("Image not found: %s", filename);
SDL_assert(0 && "Image not found! See stderr.");
}
}
if (loadedImage != NULL)
{
VVV_freefunc(SDL_FreeSurface, loadedImage);
}
VVV_free(data);
}
/* The pointers `texture` and `surface` cannot be NULL */
static void LoadSprites(const char* filename, SDL_Texture** texture, SDL_Surface** surface)
{
unsigned char* data;
SDL_Surface* loadedImage = LoadImageRaw(filename, &data);
Whiten texture only after loading surface This fixes a regression where the red channel 0 glitch didn't work, because the surface was always whitened, because LoadSprites would whiten the image before converting it to surface. This regression happened because of #923. Fixes #962.
2023-03-31 04:54:46 +02:00
*surface = LoadSurfaceFromRaw(loadedImage);
if (*surface == NULL)
Move from surfaces to the SDL render system Ever since VVVVVV was initially ported to C++ in 2.0, it has used surfaces from SDL. The downside is, that's all software rendering. This commit moves most things off of surfaces, and all into GPU, by using textures and SDL_Renderer. Pixel-perfect collision has been kept by keeping a copy of sprites as surfaces. There's plans for pixel-perfect collision to use masks instead of reading pixel data directly, but that's out of scope for this commit. - `graphics.reloadresources()` is now called later in `main`, because textures cannot be created without a renderer. - This commit also removes a bunch of surface functions which are no longer needed. - This also recaches target textures in certain places for d3d9. - graphics.images was converted to a fixed-size array. - fillbox and fillboxabs use SDL_RenderDrawRect instead of drawing an outline using four filled rectangles - Update my name in the credits
2023-01-07 19:28:07 +01:00
{
vlog_error("Image not found: %s", filename);
SDL_assert(0 && "Image not found! See stderr.");
}
Whiten texture only after loading surface This fixes a regression where the red channel 0 glitch didn't work, because the surface was always whitened, because LoadSprites would whiten the image before converting it to surface. This regression happened because of #923. Fixes #962.
2023-03-31 04:54:46 +02:00
*texture = LoadTextureFromRaw(filename, loadedImage, TEX_WHITE);
if (*texture == NULL)
Move from surfaces to the SDL render system Ever since VVVVVV was initially ported to C++ in 2.0, it has used surfaces from SDL. The downside is, that's all software rendering. This commit moves most things off of surfaces, and all into GPU, by using textures and SDL_Renderer. Pixel-perfect collision has been kept by keeping a copy of sprites as surfaces. There's plans for pixel-perfect collision to use masks instead of reading pixel data directly, but that's out of scope for this commit. - `graphics.reloadresources()` is now called later in `main`, because textures cannot be created without a renderer. - This commit also removes a bunch of surface functions which are no longer needed. - This also recaches target textures in certain places for d3d9. - graphics.images was converted to a fixed-size array. - fillbox and fillboxabs use SDL_RenderDrawRect instead of drawing an outline using four filled rectangles - Update my name in the credits
2023-01-07 19:28:07 +01:00
{
vlog_error("Image not found: %s", filename);
SDL_assert(0 && "Image not found! See stderr.");
}
if (loadedImage != NULL)
{
VVV_freefunc(SDL_FreeSurface, loadedImage);
}
VVV_free(data);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
Add support for translatable sprites Language folders can now have a graphics folder, with these files: - sprites.png and flipsprites.png: spritesheets which contain translated versions of the word enemies and checkpoints - spritesmask.xml: an XML file containing all the sprites that should be copied from the translated sprites and flipsprites images to the original sprites/flipsprites. This means that the translated spritesheets don't have to contain ALL sprites - they only have to contain the translated ones. When loading them, the game assembles a combined spritesheet with translated sprites replacing English ones as needed, and this sheet is used to visually substitute the normal sprites at rendering time. It's important to note that even if 32x32 enemies have pixel-perfect hitboxes, this is only a visual change. This has been discussed several times on Discord - basically we don't want to give people unfair advantages or disadvantages because of their language setting, or change existing gameplay and speedruns tactics, which may depend on the exact pixel arrangements of the enemies. Therefore, the hitboxes are still based on the English sprites. This should be basically unnoticeable for casual players, especially with some thought from translators and artists, but there will be an option in the speedrunner menu to display the original sprites all the time. I removed the `VVV_freefunc(SDL_FreeSurface, *tilesheet)` in make_array() in Graphics.cpp, which frees grphx.im_sprites_surf and grphx.im_flipsprites_surf. Since GraphicsResources::destroy() already frees these, it looks like the only purpose the one in make_array() serves is to do it earlier. But now we need them again later (when switching languages) so let's just not free them early.
2023-09-27 03:53:36 +02:00
static void LoadSpritesTranslation(
const char* filename,
tinyxml2::XMLDocument* mask,
SDL_Surface* surface_english,
SDL_Texture** texture
) {
/* Create a sprites texture for display in another language.
* surface_english is used as a base. Parts of the translation (filename)
* will replace parts of the base, as instructed in the mask XML. */
if (surface_english == NULL)
{
vlog_error("LoadSpritesTranslation: English surface is NULL!");
return;
}
// Make a copy of the English sprites, for working with
SDL_Surface* working = GetSubSurface(
surface_english,
0, 0, surface_english->w, surface_english->h
);
if (working == NULL)
{
return;
}
SDL_Surface* translated;
{
unsigned char* data;
SDL_Surface* loaded_image = LoadImageRaw(filename, &data);
translated = LoadSurfaceFromRaw(loaded_image);
VVV_freefunc(SDL_FreeSurface, loaded_image);
VVV_free(data);
}
SDL_SetSurfaceBlendMode(translated, SDL_BLENDMODE_NONE);
tinyxml2::XMLHandle hMask(mask);
tinyxml2::XMLElement* pElem;
int sprite_w = 1, sprite_h = 1;
if ((pElem = mask->FirstChildElement()) != NULL)
{
sprite_w = pElem->IntAttribute("sprite_w", 1);
sprite_h = pElem->IntAttribute("sprite_h", 1);
}
FOR_EACH_XML_ELEMENT(hMask, pElem)
{
EXPECT_ELEM(pElem, "sprite");
int x = pElem->IntAttribute("x", 0);
int y = pElem->IntAttribute("y", 0);
SDL_Rect src;
src.x = x * sprite_w;
src.y = y * sprite_h;
src.w = pElem->IntAttribute("w", 1) * sprite_w;
src.h = pElem->IntAttribute("h", 1) * sprite_h;
SDL_Rect dst;
dst.x = pElem->IntAttribute("dx", x) * sprite_w;
dst.y = pElem->IntAttribute("dy", y) * sprite_h;
SDL_BlitSurface(translated, &src, working, &dst);
}
*texture = LoadTextureFromRaw(filename, working, TEX_WHITE);
VVV_freefunc(SDL_FreeSurface, translated);
VVV_freefunc(SDL_FreeSurface, working);
}
void GraphicsResources::init_translations(void)
{
VVV_freefunc(SDL_DestroyTexture, im_sprites_translated);
VVV_freefunc(SDL_DestroyTexture, im_flipsprites_translated);
if (loc::english_sprites)
{
return;
}
const char* langcode = loc::lang.c_str();
const char* path_template = "lang/%s/graphics/%s";
char path_xml[256];
char path_sprites[256];
char path_flipsprites[256];
SDL_snprintf(path_xml, sizeof(path_xml), path_template, langcode, "spritesmask.xml");
SDL_snprintf(path_sprites, sizeof(path_sprites), path_template, langcode, "sprites.png");
SDL_snprintf(path_flipsprites, sizeof(path_flipsprites), path_template, langcode, "flipsprites.png");
/* We don't want to apply main-game translations to level-specific (custom) sprites.
* Either sprites and translations are BOTH main-game, or BOTH level-specific.
* Our pivots are the XML (it _has_ to exist for translated sprites to work) and
* graphics/sprites.png (what sense does it make to have only flipsprites). */
if (FILESYSTEM_isAssetMounted(path_xml) != FILESYSTEM_isAssetMounted("graphics/sprites.png"))
{
return;
}
tinyxml2::XMLDocument doc_mask;
if (!FILESYSTEM_loadAssetTiXml2Document(path_xml, doc_mask))
{
// Only try to load the images if the XML document exists
return;
}
if (FILESYSTEM_areAssetsInSameRealDir(path_xml, path_sprites))
{
LoadSpritesTranslation(
path_sprites,
&doc_mask,
im_sprites_surf,
&im_sprites_translated
);
}
if (FILESYSTEM_areAssetsInSameRealDir(path_xml, path_flipsprites))
{
LoadSpritesTranslation(
path_flipsprites,
&doc_mask,
im_flipsprites_surf,
&im_flipsprites_translated
);
}
}
Allow using help/graphics/music/game/key/map/obj everywhere This commit makes `help`, `graphics`, `music`, `game`, `key`, `map`, and `obj` essentially static global objects that can be used everywhere. This is useful in case we ever need to add a new function in the future, so we don't have to bother with passing a new argument in which means we have to pass a new argument in to the function that calls that function which means having to pass a new argument into the function that calls THAT function, etc. which is a real headache when working on fan mods of the source code. Note that this changes NONE of the existing function signatures, it merely just makes those variables accessible everywhere in the same way `script` and `ed` are. Also note that some classes had to be initialized after the filesystem was initialized, but C++ would keep initializing them before the filesystem got initialized, because I *had* to put them at the top of `main.cpp`, or else they wouldn't be global variables. The only way to work around this was to use entityclass's initialization style (which I'm pretty sure entityclass of all things doesn't need to be initialized this way), where you actually initialize the class in an `init()` function, and so then you do `graphics.init()` after the filesystem initialization, AFTER doing `Graphics graphics` up at the top. I've had to do this for `graphics` (but only because its child GraphicsResources `grphx` needs to be initialized this way), `music`, and `game`. I don't think this will affect anything. Other than that, `help`, `key`, and `map` are still using the C++-intended method of having ClassName::ClassName() functions.
2020-01-29 08:35:03 +01:00
void GraphicsResources::init(void)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Move from surfaces to the SDL render system Ever since VVVVVV was initially ported to C++ in 2.0, it has used surfaces from SDL. The downside is, that's all software rendering. This commit moves most things off of surfaces, and all into GPU, by using textures and SDL_Renderer. Pixel-perfect collision has been kept by keeping a copy of sprites as surfaces. There's plans for pixel-perfect collision to use masks instead of reading pixel data directly, but that's out of scope for this commit. - `graphics.reloadresources()` is now called later in `main`, because textures cannot be created without a renderer. - This commit also removes a bunch of surface functions which are no longer needed. - This also recaches target textures in certain places for d3d9. - graphics.images was converted to a fixed-size array. - fillbox and fillboxabs use SDL_RenderDrawRect instead of drawing an outline using four filled rectangles - Update my name in the credits
2023-01-07 19:28:07 +01:00
LoadVariants("graphics/tiles.png", &im_tiles, &im_tiles_white, &im_tiles_tint);
LoadVariants("graphics/tiles2.png", &im_tiles2, NULL, &im_tiles2_tint);
LoadVariants("graphics/entcolours.png", &im_entcolours, NULL, &im_entcolours_tint);
LoadSprites("graphics/sprites.png", &im_sprites, &im_sprites_surf);
LoadSprites("graphics/flipsprites.png", &im_flipsprites, &im_flipsprites_surf);
im_tiles3 = LoadImage("graphics/tiles3.png");
im_teleporter = LoadImage("graphics/teleporter.png", TEX_WHITE);
im_image0 = LoadImage("graphics/levelcomplete.png");
im_image1 = LoadImage("graphics/minimap.png");
im_image2 = LoadImage("graphics/covered.png");
im_image3 = LoadImage("graphics/elephant.png", TEX_WHITE);
im_image4 = LoadImage("graphics/gamecomplete.png");
im_image5 = LoadImage("graphics/fliplevelcomplete.png");
im_image6 = LoadImage("graphics/flipgamecomplete.png");
im_image7 = LoadImage("graphics/site.png", TEX_WHITE);
im_image8 = LoadImage("graphics/site2.png", TEX_WHITE);
im_image9 = LoadImage("graphics/site3.png", TEX_WHITE);
im_image10 = LoadImage("graphics/ending.png");
im_image11 = LoadImage("graphics/site4.png", TEX_WHITE);
Add support for translatable sprites Language folders can now have a graphics folder, with these files: - sprites.png and flipsprites.png: spritesheets which contain translated versions of the word enemies and checkpoints - spritesmask.xml: an XML file containing all the sprites that should be copied from the translated sprites and flipsprites images to the original sprites/flipsprites. This means that the translated spritesheets don't have to contain ALL sprites - they only have to contain the translated ones. When loading them, the game assembles a combined spritesheet with translated sprites replacing English ones as needed, and this sheet is used to visually substitute the normal sprites at rendering time. It's important to note that even if 32x32 enemies have pixel-perfect hitboxes, this is only a visual change. This has been discussed several times on Discord - basically we don't want to give people unfair advantages or disadvantages because of their language setting, or change existing gameplay and speedruns tactics, which may depend on the exact pixel arrangements of the enemies. Therefore, the hitboxes are still based on the English sprites. This should be basically unnoticeable for casual players, especially with some thought from translators and artists, but there will be an option in the speedrunner menu to display the original sprites all the time. I removed the `VVV_freefunc(SDL_FreeSurface, *tilesheet)` in make_array() in Graphics.cpp, which frees grphx.im_sprites_surf and grphx.im_flipsprites_surf. Since GraphicsResources::destroy() already frees these, it looks like the only purpose the one in make_array() serves is to do it earlier. But now we need them again later (when switching languages) so let's just not free them early.
2023-09-27 03:53:36 +02:00
im_sprites_translated = NULL;
im_flipsprites_translated = NULL;
init_translations();
Move from surfaces to the SDL render system Ever since VVVVVV was initially ported to C++ in 2.0, it has used surfaces from SDL. The downside is, that's all software rendering. This commit moves most things off of surfaces, and all into GPU, by using textures and SDL_Renderer. Pixel-perfect collision has been kept by keeping a copy of sprites as surfaces. There's plans for pixel-perfect collision to use masks instead of reading pixel data directly, but that's out of scope for this commit. - `graphics.reloadresources()` is now called later in `main`, because textures cannot be created without a renderer. - This commit also removes a bunch of surface functions which are no longer needed. - This also recaches target textures in certain places for d3d9. - graphics.images was converted to a fixed-size array. - fillbox and fillboxabs use SDL_RenderDrawRect instead of drawing an outline using four filled rectangles - Update my name in the credits
2023-01-07 19:28:07 +01:00
im_image12 = SDL_CreateTexture(gameScreen.m_renderer, SDL_PIXELFORMAT_ARGB8888, SDL_TEXTUREACCESS_TARGET, 240, 180);
if (im_image12 == NULL)
{
vlog_error("Failed to create minimap texture: %s", SDL_GetError());
SDL_assert(0 && "Failed to create minimap texture! See stderr.");
return;
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
Fix some leaks
2020-06-07 22:29:48 +02:00
void GraphicsResources::destroy(void)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Move from surfaces to the SDL render system Ever since VVVVVV was initially ported to C++ in 2.0, it has used surfaces from SDL. The downside is, that's all software rendering. This commit moves most things off of surfaces, and all into GPU, by using textures and SDL_Renderer. Pixel-perfect collision has been kept by keeping a copy of sprites as surfaces. There's plans for pixel-perfect collision to use masks instead of reading pixel data directly, but that's out of scope for this commit. - `graphics.reloadresources()` is now called later in `main`, because textures cannot be created without a renderer. - This commit also removes a bunch of surface functions which are no longer needed. - This also recaches target textures in certain places for d3d9. - graphics.images was converted to a fixed-size array. - fillbox and fillboxabs use SDL_RenderDrawRect instead of drawing an outline using four filled rectangles - Update my name in the credits
2023-01-07 19:28:07 +01:00
#define CLEAR(img) VVV_freefunc(SDL_DestroyTexture, img)
Untabify every single file YOLO. This is a repeat of #642. As before, I just did rg -l '\t' | xargs -n 1 sed -i -e 's/\t/ /g' inside the desktop_version/ folder.
2021-09-07 03:56:39 +02:00
CLEAR(im_tiles);
Move from surfaces to the SDL render system Ever since VVVVVV was initially ported to C++ in 2.0, it has used surfaces from SDL. The downside is, that's all software rendering. This commit moves most things off of surfaces, and all into GPU, by using textures and SDL_Renderer. Pixel-perfect collision has been kept by keeping a copy of sprites as surfaces. There's plans for pixel-perfect collision to use masks instead of reading pixel data directly, but that's out of scope for this commit. - `graphics.reloadresources()` is now called later in `main`, because textures cannot be created without a renderer. - This commit also removes a bunch of surface functions which are no longer needed. - This also recaches target textures in certain places for d3d9. - graphics.images was converted to a fixed-size array. - fillbox and fillboxabs use SDL_RenderDrawRect instead of drawing an outline using four filled rectangles - Update my name in the credits
2023-01-07 19:28:07 +01:00
CLEAR(im_tiles_white);
CLEAR(im_tiles_tint);
Untabify every single file YOLO. This is a repeat of #642. As before, I just did rg -l '\t' | xargs -n 1 sed -i -e 's/\t/ /g' inside the desktop_version/ folder.
2021-09-07 03:56:39 +02:00
CLEAR(im_tiles2);
Move from surfaces to the SDL render system Ever since VVVVVV was initially ported to C++ in 2.0, it has used surfaces from SDL. The downside is, that's all software rendering. This commit moves most things off of surfaces, and all into GPU, by using textures and SDL_Renderer. Pixel-perfect collision has been kept by keeping a copy of sprites as surfaces. There's plans for pixel-perfect collision to use masks instead of reading pixel data directly, but that's out of scope for this commit. - `graphics.reloadresources()` is now called later in `main`, because textures cannot be created without a renderer. - This commit also removes a bunch of surface functions which are no longer needed. - This also recaches target textures in certain places for d3d9. - graphics.images was converted to a fixed-size array. - fillbox and fillboxabs use SDL_RenderDrawRect instead of drawing an outline using four filled rectangles - Update my name in the credits
2023-01-07 19:28:07 +01:00
CLEAR(im_tiles2_tint);
Untabify every single file YOLO. This is a repeat of #642. As before, I just did rg -l '\t' | xargs -n 1 sed -i -e 's/\t/ /g' inside the desktop_version/ folder.
2021-09-07 03:56:39 +02:00
CLEAR(im_tiles3);
CLEAR(im_entcolours);
Move from surfaces to the SDL render system Ever since VVVVVV was initially ported to C++ in 2.0, it has used surfaces from SDL. The downside is, that's all software rendering. This commit moves most things off of surfaces, and all into GPU, by using textures and SDL_Renderer. Pixel-perfect collision has been kept by keeping a copy of sprites as surfaces. There's plans for pixel-perfect collision to use masks instead of reading pixel data directly, but that's out of scope for this commit. - `graphics.reloadresources()` is now called later in `main`, because textures cannot be created without a renderer. - This commit also removes a bunch of surface functions which are no longer needed. - This also recaches target textures in certain places for d3d9. - graphics.images was converted to a fixed-size array. - fillbox and fillboxabs use SDL_RenderDrawRect instead of drawing an outline using four filled rectangles - Update my name in the credits
2023-01-07 19:28:07 +01:00
CLEAR(im_entcolours_tint);
Untabify every single file YOLO. This is a repeat of #642. As before, I just did rg -l '\t' | xargs -n 1 sed -i -e 's/\t/ /g' inside the desktop_version/ folder.
2021-09-07 03:56:39 +02:00
CLEAR(im_sprites);
CLEAR(im_flipsprites);
CLEAR(im_teleporter);
Ensure that all member attributes are initialized I ran the game through cppcheck and it spat out a bunch of member attributes that weren't being initialized. So I initialized them. In the previous version of this commit, I added constructors to GraphicsResources, otherlevelclass, labclass, warpclass, and finalclass, but flibit says this changes the code flow enough that it's risky to merge before 2.4, so I got rid of those constructors, too.
2020-07-06 22:04:34 +02:00
Untabify every single file YOLO. This is a repeat of #642. As before, I just did rg -l '\t' | xargs -n 1 sed -i -e 's/\t/ /g' inside the desktop_version/ folder.
2021-09-07 03:56:39 +02:00
CLEAR(im_image0);
CLEAR(im_image1);
CLEAR(im_image2);
CLEAR(im_image3);
CLEAR(im_image4);
CLEAR(im_image5);
CLEAR(im_image6);
CLEAR(im_image7);
CLEAR(im_image8);
CLEAR(im_image9);
CLEAR(im_image10);
CLEAR(im_image11);
CLEAR(im_image12);
Add support for translatable sprites Language folders can now have a graphics folder, with these files: - sprites.png and flipsprites.png: spritesheets which contain translated versions of the word enemies and checkpoints - spritesmask.xml: an XML file containing all the sprites that should be copied from the translated sprites and flipsprites images to the original sprites/flipsprites. This means that the translated spritesheets don't have to contain ALL sprites - they only have to contain the translated ones. When loading them, the game assembles a combined spritesheet with translated sprites replacing English ones as needed, and this sheet is used to visually substitute the normal sprites at rendering time. It's important to note that even if 32x32 enemies have pixel-perfect hitboxes, this is only a visual change. This has been discussed several times on Discord - basically we don't want to give people unfair advantages or disadvantages because of their language setting, or change existing gameplay and speedruns tactics, which may depend on the exact pixel arrangements of the enemies. Therefore, the hitboxes are still based on the English sprites. This should be basically unnoticeable for casual players, especially with some thought from translators and artists, but there will be an option in the speedrunner menu to display the original sprites all the time. I removed the `VVV_freefunc(SDL_FreeSurface, *tilesheet)` in make_array() in Graphics.cpp, which frees grphx.im_sprites_surf and grphx.im_flipsprites_surf. Since GraphicsResources::destroy() already frees these, it looks like the only purpose the one in make_array() serves is to do it earlier. But now we need them again later (when switching languages) so let's just not free them early.
2023-09-27 03:53:36 +02:00
CLEAR(im_sprites_translated);
CLEAR(im_flipsprites_translated);
Ensure that all member attributes are initialized I ran the game through cppcheck and it spat out a bunch of member attributes that weren't being initialized. So I initialized them. In the previous version of this commit, I added constructors to GraphicsResources, otherlevelclass, labclass, warpclass, and finalclass, but flibit says this changes the code flow enough that it's risky to merge before 2.4, so I got rid of those constructors, too.
2020-07-06 22:04:34 +02:00
#undef CLEAR
Move from surfaces to the SDL render system Ever since VVVVVV was initially ported to C++ in 2.0, it has used surfaces from SDL. The downside is, that's all software rendering. This commit moves most things off of surfaces, and all into GPU, by using textures and SDL_Renderer. Pixel-perfect collision has been kept by keeping a copy of sprites as surfaces. There's plans for pixel-perfect collision to use masks instead of reading pixel data directly, but that's out of scope for this commit. - `graphics.reloadresources()` is now called later in `main`, because textures cannot be created without a renderer. - This commit also removes a bunch of surface functions which are no longer needed. - This also recaches target textures in certain places for d3d9. - graphics.images was converted to a fixed-size array. - fillbox and fillboxabs use SDL_RenderDrawRect instead of drawing an outline using four filled rectangles - Update my name in the credits
2023-01-07 19:28:07 +01:00
VVV_freefunc(SDL_FreeSurface, im_sprites_surf);
VVV_freefunc(SDL_FreeSurface, im_flipsprites_surf);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
Add support for internal screenshots "But people already have screenshot tools", you might protest. The rationale is simple: If you play with any video setting other than 1x windowed (no stretching and no letterbox), then your screenshot will be too big if you want the internal resolution of 320x240, and downscaling will be an inconvenience. The point is to make screenshots based off of internal resolution so they are always pixel perfect and ideally never have to be altered once taken. I've added the keybind of F6 to do this. Right now it saves to a temporary test location with the same filename; future commits will save to properly-timestamped filenames.
2024-01-09 20:29:50 +01:00
bool SaveImage(const SDL_Surface* surface, const char* filename)
{
unsigned char* out;
size_t outsize;
unsigned int error;
bool success;
error = lodepng_encode24(
&out, &outsize,
(const unsigned char*) surface->pixels,
surface->w, surface->h
);
if (error != 0)
{
vlog_error("Could not save image: %s", lodepng_error_text(error));
return false;
}
success = FILESYSTEM_saveFile(filename, out, outsize);
SDL_free(out);
if (!success)
{
vlog_error("Could not save image");
}
return success;
}
bool SaveScreenshot(void)
{
Allow taking multiple screenshots in same second Dav999 notified me that if multiple screenshots are taken in the same second, the second screenshot has `_2` appended to it and so on. We do the same here by storing the current timestamp and a counter. This doesn't prevent overwriting files if you have system time that changes, or have multiple instances of VVVVVV running at the same time, but my position on those cases is as follows: Don't do that.
2024-01-10 02:16:58 +01:00
static time_t last_time = 0;
static int subsecond_counter = 0;
Add support for internal screenshots "But people already have screenshot tools", you might protest. The rationale is simple: If you play with any video setting other than 1x windowed (no stretching and no letterbox), then your screenshot will be too big if you want the internal resolution of 320x240, and downscaling will be an inconvenience. The point is to make screenshots based off of internal resolution so they are always pixel perfect and ideally never have to be altered once taken. I've added the keybind of F6 to do this. Right now it saves to a temporary test location with the same filename; future commits will save to properly-timestamped filenames.
2024-01-09 20:29:50 +01:00
bool success = TakeScreenshot(&graphics.tempScreenshot);
if (!success)
{
vlog_error("Could not take screenshot");
return false;
}
Save screenshots with proper filenames Filenames are timestamped now, down to the second. If you take multiple screenshots in the same second, then the last one will overwrite the others. This seems to be how other screenshot programs operate so I don't think it matters if you can't take more than one per second. Additionally, 1x screenshots (320x240) will go in the 1x/ subdirectory, and 2x screenshots (640x480) will go in the 2x/ subdirectory.
2024-01-10 00:05:08 +01:00
const time_t now = time(NULL);
const tm* date = localtime(&now);
Allow taking multiple screenshots in same second Dav999 notified me that if multiple screenshots are taken in the same second, the second screenshot has `_2` appended to it and so on. We do the same here by storing the current timestamp and a counter. This doesn't prevent overwriting files if you have system time that changes, or have multiple instances of VVVVVV running at the same time, but my position on those cases is as follows: Don't do that.
2024-01-10 02:16:58 +01:00
if (now != last_time)
{
last_time = now;
subsecond_counter = 0;
}
subsecond_counter++;
Save screenshots with proper filenames Filenames are timestamped now, down to the second. If you take multiple screenshots in the same second, then the last one will overwrite the others. This seems to be how other screenshot programs operate so I don't think it matters if you can't take more than one per second. Additionally, 1x screenshots (320x240) will go in the 1x/ subdirectory, and 2x screenshots (640x480) will go in the 2x/ subdirectory.
2024-01-10 00:05:08 +01:00
char timestamp[32];
strftime(timestamp, sizeof(timestamp), "%Y-%m-%d_%H-%M-%S", date);
Allow taking multiple screenshots in same second Dav999 notified me that if multiple screenshots are taken in the same second, the second screenshot has `_2` appended to it and so on. We do the same here by storing the current timestamp and a counter. This doesn't prevent overwriting files if you have system time that changes, or have multiple instances of VVVVVV running at the same time, but my position on those cases is as follows: Don't do that.
2024-01-10 02:16:58 +01:00
char name[32];
if (subsecond_counter > 1)
{
SDL_snprintf(name, sizeof(name), "%s_%i", timestamp, subsecond_counter);
}
else
{
SDL_strlcpy(name, timestamp, sizeof(name));
}
Save screenshots with proper filenames Filenames are timestamped now, down to the second. If you take multiple screenshots in the same second, then the last one will overwrite the others. This seems to be how other screenshot programs operate so I don't think it matters if you can't take more than one per second. Additionally, 1x screenshots (320x240) will go in the 1x/ subdirectory, and 2x screenshots (640x480) will go in the 2x/ subdirectory.
2024-01-10 00:05:08 +01:00
char filename[64];
Allow taking multiple screenshots in same second Dav999 notified me that if multiple screenshots are taken in the same second, the second screenshot has `_2` appended to it and so on. We do the same here by storing the current timestamp and a counter. This doesn't prevent overwriting files if you have system time that changes, or have multiple instances of VVVVVV running at the same time, but my position on those cases is as follows: Don't do that.
2024-01-10 02:16:58 +01:00
SDL_snprintf(filename, sizeof(filename), "screenshots/1x/%s_1x.png", name);
Save screenshots with proper filenames Filenames are timestamped now, down to the second. If you take multiple screenshots in the same second, then the last one will overwrite the others. This seems to be how other screenshot programs operate so I don't think it matters if you can't take more than one per second. Additionally, 1x screenshots (320x240) will go in the 1x/ subdirectory, and 2x screenshots (640x480) will go in the 2x/ subdirectory.
2024-01-10 00:05:08 +01:00
success = SaveImage(graphics.tempScreenshot, filename);
Add support for internal screenshots "But people already have screenshot tools", you might protest. The rationale is simple: If you play with any video setting other than 1x windowed (no stretching and no letterbox), then your screenshot will be too big if you want the internal resolution of 320x240, and downscaling will be an inconvenience. The point is to make screenshots based off of internal resolution so they are always pixel perfect and ideally never have to be altered once taken. I've added the keybind of F6 to do this. Right now it saves to a temporary test location with the same filename; future commits will save to properly-timestamped filenames.
2024-01-09 20:29:50 +01:00
if (!success)
{
return false;
}
Upscale screenshots 2x The plan is to have Steam screenshots always be 2x, but in the VVVVVV screenshots directory (for F6 keybind) save both 1x and 2x. Again, just for now, the 2x screenshot is being saved to a temporary location for testing and will get proper timestamps later.
2024-01-08 02:56:26 +01:00
success = UpscaleScreenshot2x(graphics.tempScreenshot, &graphics.tempScreenshot2x);
if (!success)
{
vlog_error("Could not upscale screenshot to 2x");
return false;
}
Allow taking multiple screenshots in same second Dav999 notified me that if multiple screenshots are taken in the same second, the second screenshot has `_2` appended to it and so on. We do the same here by storing the current timestamp and a counter. This doesn't prevent overwriting files if you have system time that changes, or have multiple instances of VVVVVV running at the same time, but my position on those cases is as follows: Don't do that.
2024-01-10 02:16:58 +01:00
SDL_snprintf(filename, sizeof(filename), "screenshots/2x/%s_2x.png", name);
Save screenshots with proper filenames Filenames are timestamped now, down to the second. If you take multiple screenshots in the same second, then the last one will overwrite the others. This seems to be how other screenshot programs operate so I don't think it matters if you can't take more than one per second. Additionally, 1x screenshots (320x240) will go in the 1x/ subdirectory, and 2x screenshots (640x480) will go in the 2x/ subdirectory.
2024-01-10 00:05:08 +01:00
success = SaveImage(graphics.tempScreenshot2x, filename);
Upscale screenshots 2x The plan is to have Steam screenshots always be 2x, but in the VVVVVV screenshots directory (for F6 keybind) save both 1x and 2x. Again, just for now, the 2x screenshot is being saved to a temporary location for testing and will get proper timestamps later.
2024-01-08 02:56:26 +01:00
if (!success)
{
return false;
}
Allow taking multiple screenshots in same second Dav999 notified me that if multiple screenshots are taken in the same second, the second screenshot has `_2` appended to it and so on. We do the same here by storing the current timestamp and a counter. This doesn't prevent overwriting files if you have system time that changes, or have multiple instances of VVVVVV running at the same time, but my position on those cases is as follows: Don't do that.
2024-01-10 02:16:58 +01:00
vlog_info("Saved screenshot %s", name);
Add support for internal screenshots "But people already have screenshot tools", you might protest. The rationale is simple: If you play with any video setting other than 1x windowed (no stretching and no letterbox), then your screenshot will be too big if you want the internal resolution of 320x240, and downscaling will be an inconvenience. The point is to make screenshots based off of internal resolution so they are always pixel perfect and ideally never have to be altered once taken. I've added the keybind of F6 to do this. Right now it saves to a temporary test location with the same filename; future commits will save to properly-timestamped filenames.
2024-01-09 20:29:50 +01:00
return true;
}
Reference in a new issue Copy permalink