mpo/VVVVVV
1
0
Fork 0
mirror of https://github.com/TerryCavanagh/VVVVVV.git synced 2024-11-05 02:39:41 +01:00
Code Issues Releases Wiki Activity
VVVVVV/desktop_version/src/Screen.cpp

376 lines
9.7 KiB
C++
Raw Normal View History

Extern `gameScreen`, remove `screenbuffer` I know earlier I removed the gameScreen extern in favor of using screenbuffer, but that was only to be consistent. After further consideration, I have found that it's actually really stupid. There's no reason to be accessing it through screenbuffer, and it's probably an artifact of 2.0-2.2 passing stack-allocated otherwise-global classes everywhere through function arguments. Also, it leads to stupid bugs where screenbuffer could potentially be NULL, which has already resulted in various annoying crashes in the past. Although those could be fixed by simply initializing screenbuffer at the very top of main(), but, why not just scrap the whole thing anyway? So that's what I'm doing. As a nice side effect, I've removed the transitive include of Screen.h from Graphics.h. This could've been done already since it only includes it for the pointer anyway, but it's still good to do it now.
2021-12-25 08:56:47 +01:00
#define GAMESCREEN_DEFINITION
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
#include "Screen.h"
Fix transitive includes in Screen.cpp Screen.cpp wasn't explicitly including SDL.h, instead relying on Screen.h to include it. It was also relying on SDL.h to include stdio.h on Linux, which breaks because SDL.h doesn't include stdio.h on Windows. So stdio.h is now explicitly included as well. stdlib.h is not used in this file.
2021-02-27 19:44:01 +01:00
#include <SDL.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
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"
Refactor `Screen.cpp` to use named constants No more hardcoded 320s and 240s here.
2022-03-13 01:46:58 +01:00
#include "Constants.h"
Abort and print error if window/renderer cannot be created This aborts and prints the error from SDL_GetError() if SDL_CreateWindow() or SDL_CreateRenderer() fails. We abort because there's not much point in continuing if the window or renderer can't be created. There might be a use case for running the game in headless mode, but let's code that in explicitly if we ever want it.
2023-01-29 08:41:44 +01:00
#include "Exit.h"
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
#include "FileSystemUtils.h"
Move graphic options menu update to toggleFullScreen This fixes a bug where using the fullscreen toggle keybind (Alt+Enter, Alt+F, or F11) wouldn't update the color of the "resize to nearest" menu option. The color doesn't functionally change anything - the option still won't work, and will still have the message telling you that you need to be in windowed mode when you move your menu selection to it - but it's an easy inconsistency to fix; just move the menu recreation in to Screen::toggleFullScreen() itself.
2021-04-23 01:19:20 +02:00
#include "Game.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 "Graphics.h"
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
#include "GraphicsUtil.h"
Add branch name to window title in brackets The branch name will be added to the window title if it is an interim version, e.g. "VVVVVV [master]". This makes it easier for developers to tell at a glance which build of the game they're running.
2023-01-16 21:59:48 +01:00
#include "InterimVersion.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 "Render.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"
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
De-C++-ify `struct ScreenSettings` This includes: - Removing the constructor in favor of actually being able to see that there's an actual function called being made initializing the struct - Removing the use of a reference in Screen::init() in favor of using a pointer - Adding the struct qualifier everywhere (it's not much typing), although technically you could typedef it in C, but I'd rather much not typedef just to remove a tag qualifier
2021-12-25 09:18:51 +01:00
void ScreenSettings_default(struct ScreenSettings* _this)
Factor out screen settings to ScreenSettings struct It's a bit annoying to pass each screen setting individually, would be nice if we could just wrap it up in a nice struct and pass that instead.
2020-11-13 01:29:11 +01:00
{
Store display index of window to settings I have this annoying issue where the game will open on the wrong monitor in fullscreen mode, because that monitor is considered to be display 0, whereas the primary monitor I want is display 1. To mitigate this somewhat, the game now stores the display index that it was closed on, and will save it to settings. Then the next time the game opens, it will open on that display index. This should work pretty well as long as you aren't changing your monitor setup constantly. Of course, none of this applies if your window manager is busted. For example, on GNOME Wayland, which is what I use, in windowed mode the game will always open on the monitor the cursor is on, and it won't even be centered in the monitor. But it works fine if I use XWayland via SDL_VIDEODRIVER=x11.
2023-03-21 08:23:42 +01:00
_this->windowDisplay = 0;
Default width and height settings to 640x480 While the window is initialized with 640x480, the screen settings defaulted to 320x240, which is a tiny window. The screen settings take priority over the initialized window, so people with no previous settings file will get 320x240. This makes it so they get 640x480 instead. The window is still initialized to 640x480 (constants used for clarity) just in case there's some weirdness if it's initialized to a potentially odd resolution from the user's settings file.
2023-01-16 21:45:40 +01:00
_this->windowWidth = SCREEN_WIDTH_PIXELS * 2;
_this->windowHeight = SCREEN_HEIGHT_PIXELS * 2;
De-C++-ify `struct ScreenSettings` This includes: - Removing the constructor in favor of actually being able to see that there's an actual function called being made initializing the struct - Removing the use of a reference in Screen::init() in favor of using a pointer - Adding the struct qualifier everywhere (it's not much typing), although technically you could typedef it in C, but I'd rather much not typedef just to remove a tag qualifier
2021-12-25 09:18:51 +01:00
_this->fullscreen = false;
_this->useVsync = true; // Now that uncapped is the default...
Default to integer scaling mode Issue #849 suggested making integer be the default on Big Picture and Steam Deck, but after thinking about it more, I think it's better and more simple to just default to integer mode in general. Reason being that people in Big Picture shouldn't expect the picture to look different if they're out of Big Picture but still in fullscreen, or have the picture look different in fullscreen depending on if they launched the game for the first time in Big Picture or not. And besides, the less lines of code, the better. So I'm just making integer mode the default.
2021-12-26 08:11:17 +01:00
_this->scalingMode = SCALING_INTEGER;
De-C++-ify `struct ScreenSettings` This includes: - Removing the constructor in favor of actually being able to see that there's an actual function called being made initializing the struct - Removing the use of a reference in Screen::init() in favor of using a pointer - Adding the struct qualifier everywhere (it's not much typing), although technically you could typedef it in C, but I'd rather much not typedef just to remove a tag qualifier
2021-12-25 09:18:51 +01:00
_this->linearFilter = false;
_this->badSignal = false;
Factor out screen settings to ScreenSettings struct It's a bit annoying to pass each screen setting individually, would be nice if we could just wrap it up in a nice struct and pass that instead.
2020-11-13 01:29:11 +01:00
}
De-C++-ify `struct ScreenSettings` This includes: - Removing the constructor in favor of actually being able to see that there's an actual function called being made initializing the struct - Removing the use of a reference in Screen::init() in favor of using a pointer - Adding the struct qualifier everywhere (it's not much typing), although technically you could typedef it in C, but I'd rather much not typedef just to remove a tag qualifier
2021-12-25 09:18:51 +01:00
void Screen::init(const struct ScreenSettings* settings)
Factor out screen settings to ScreenSettings struct It's a bit annoying to pass each screen setting individually, would be nice if we could just wrap it up in a nice struct and pass that instead.
2020-11-13 01:29:11 +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
m_window = NULL;
m_renderer = NULL;
Store display index of window to settings I have this annoying issue where the game will open on the wrong monitor in fullscreen mode, because that monitor is considered to be display 0, whereas the primary monitor I want is display 1. To mitigate this somewhat, the game now stores the display index that it was closed on, and will save it to settings. Then the next time the game opens, it will open on that display index. This should work pretty well as long as you aren't changing your monitor setup constantly. Of course, none of this applies if your window manager is busted. For example, on GNOME Wayland, which is what I use, in windowed mode the game will always open on the monitor the cursor is on, and it won't even be centered in the monitor. But it works fine if I use XWayland via SDL_VIDEODRIVER=x11.
2023-03-21 08:23:42 +01:00
windowDisplay = settings->windowDisplay;
Persist windowed mode size through fullscreen mode Previously, the game would not store the size of the window itself, and would always call SDL_GetRendererOutputSize() (via Screen::GetWindowSize()) to figure out the size of the window. The only problem is, this would return the size of the whole monitor if the game was in fullscreen mode. And the only place where the original windowed mode size was stored would be in SDL itself, but that wouldn't persist after the game was closed. So, if you exited the game while in fullscreen mode, then your window size would get set to the size of your monitor (1920 by 1080 in my case). Then when you opened the game and toggled fullscreen off, it would go back to the default window size, which is 640 by 480. This is made worse, however, if you were in forced fullscreen mode when you previously exited the game in windowed mode. In that case, the game saves the size of 1920 by 1080, but doesn't save that you were in fullscreen mode, so opening the game not in forced fullscreen mode would result in you having a 1920 by 1080 window, but in windowed mode. Meaning that not even fullscreening and unfullscreening would put the game window back to normal size. The solution, of course, is to just store the window size ourselves, like any other screen setting, and only use GetWindowSize() if needed. And just to make things clear, I've also renamed the GetWindowSize() function to GetScreenSize(), because if it was named "window" it could lead one to think that it would always return the size of the screen in windowed mode, when in fact it returns the size of the screen whatever mode it is in - fullscreen size if in fullscreen mode and window size if in windowed mode. And doing this also fixes the FIXME above Screen::isForcedFullscreen().
2023-03-21 04:59:37 +01:00
windowWidth = settings->windowWidth;
windowHeight = settings->windowHeight;
De-C++-ify `struct ScreenSettings` This includes: - Removing the constructor in favor of actually being able to see that there's an actual function called being made initializing the struct - Removing the use of a reference in Screen::init() in favor of using a pointer - Adding the struct qualifier everywhere (it's not much typing), although technically you could typedef it in C, but I'd rather much not typedef just to remove a tag qualifier
2021-12-25 09:18:51 +01:00
isWindowed = !settings->fullscreen;
scalingMode = settings->scalingMode;
isFiltered = settings->linearFilter;
Persist windowed mode size through fullscreen mode Previously, the game would not store the size of the window itself, and would always call SDL_GetRendererOutputSize() (via Screen::GetWindowSize()) to figure out the size of the window. The only problem is, this would return the size of the whole monitor if the game was in fullscreen mode. And the only place where the original windowed mode size was stored would be in SDL itself, but that wouldn't persist after the game was closed. So, if you exited the game while in fullscreen mode, then your window size would get set to the size of your monitor (1920 by 1080 in my case). Then when you opened the game and toggled fullscreen off, it would go back to the default window size, which is 640 by 480. This is made worse, however, if you were in forced fullscreen mode when you previously exited the game in windowed mode. In that case, the game saves the size of 1920 by 1080, but doesn't save that you were in fullscreen mode, so opening the game not in forced fullscreen mode would result in you having a 1920 by 1080 window, but in windowed mode. Meaning that not even fullscreening and unfullscreening would put the game window back to normal size. The solution, of course, is to just store the window size ourselves, like any other screen setting, and only use GetWindowSize() if needed. And just to make things clear, I've also renamed the GetWindowSize() function to GetScreenSize(), because if it was named "window" it could lead one to think that it would always return the size of the screen in windowed mode, when in fact it returns the size of the screen whatever mode it is in - fullscreen size if in fullscreen mode and window size if in windowed mode. And doing this also fixes the FIXME above Screen::isForcedFullscreen().
2023-03-21 04:59:37 +01:00
badSignalEffect = settings->badSignal;
De-C++-ify `struct ScreenSettings` This includes: - Removing the constructor in favor of actually being able to see that there's an actual function called being made initializing the struct - Removing the use of a reference in Screen::init() in favor of using a pointer - Adding the struct qualifier everywhere (it's not much typing), although technically you could typedef it in C, but I'd rather much not typedef just to remove a tag qualifier
2021-12-25 09:18:51 +01:00
vsync = settings->useVsync;
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_SetHintWithPriority(
SDL_HINT_RENDER_SCALE_QUALITY,
isFiltered ? "linear" : "nearest",
SDL_HINT_OVERRIDE
);
SDL_SetHintWithPriority(
SDL_HINT_RENDER_VSYNC,
vsync ? "1" : "0",
SDL_HINT_OVERRIDE
);
// Uncomment this next line when you need to debug -flibit
// SDL_SetHintWithPriority(SDL_HINT_RENDER_DRIVER, "software", SDL_HINT_OVERRIDE);
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
m_window = SDL_CreateWindow(
"VVVVVV",
Store display index of window to settings I have this annoying issue where the game will open on the wrong monitor in fullscreen mode, because that monitor is considered to be display 0, whereas the primary monitor I want is display 1. To mitigate this somewhat, the game now stores the display index that it was closed on, and will save it to settings. Then the next time the game opens, it will open on that display index. This should work pretty well as long as you aren't changing your monitor setup constantly. Of course, none of this applies if your window manager is busted. For example, on GNOME Wayland, which is what I use, in windowed mode the game will always open on the monitor the cursor is on, and it won't even be centered in the monitor. But it works fine if I use XWayland via SDL_VIDEODRIVER=x11.
2023-03-21 08:23:42 +01:00
SDL_WINDOWPOS_CENTERED_DISPLAY(windowDisplay),
SDL_WINDOWPOS_CENTERED_DISPLAY(windowDisplay),
Default width and height settings to 640x480 While the window is initialized with 640x480, the screen settings defaulted to 320x240, which is a tiny window. The screen settings take priority over the initialized window, so people with no previous settings file will get 320x240. This makes it so they get 640x480 instead. The window is still initialized to 640x480 (constants used for clarity) just in case there's some weirdness if it's initialized to a potentially odd resolution from the user's settings file.
2023-01-16 21:45:40 +01:00
SCREEN_WIDTH_PIXELS * 2,
SCREEN_HEIGHT_PIXELS * 2,
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
SDL_WINDOW_HIDDEN | SDL_WINDOW_RESIZABLE | SDL_WINDOW_ALLOW_HIGHDPI
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
Abort and print error if window/renderer cannot be created This aborts and prints the error from SDL_GetError() if SDL_CreateWindow() or SDL_CreateRenderer() fails. We abort because there's not much point in continuing if the window or renderer can't be created. There might be a use case for running the game in headless mode, but let's code that in explicitly if we ever want it.
2023-01-29 08:41:44 +01:00
if (m_window == NULL)
{
vlog_error("Could not create window: %s", SDL_GetError());
VVV_exit(1);
}
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
m_renderer = SDL_CreateRenderer(m_window, -1, SDL_RENDERER_ACCELERATED | SDL_RENDERER_TARGETTEXTURE);
Abort and print error if window/renderer cannot be created This aborts and prints the error from SDL_GetError() if SDL_CreateWindow() or SDL_CreateRenderer() fails. We abort because there's not much point in continuing if the window or renderer can't be created. There might be a use case for running the game in headless mode, but let's code that in explicitly if we ever want it.
2023-01-29 08:41:44 +01:00
if (m_renderer == NULL)
{
vlog_error("Could not create renderer: %s", SDL_GetError());
VVV_exit(1);
}
Add branch name to window title in brackets The branch name will be added to the window title if it is an interim version, e.g. "VVVVVV [master]". This makes it easier for developers to tell at a glance which build of the game they're running.
2023-01-16 21:59:48 +01:00
#ifdef INTERIM_VERSION_EXISTS
/* Branch name limits are ill-defined but on GitHub it's ~256 chars
* ( https://stackoverflow.com/a/24014513/ ).
* Really though, just don't use super long branch names. */
char title[256];
SDL_snprintf(title, sizeof(title), "VVVVVV [%s]", BRANCH_NAME);
SDL_SetWindowTitle(m_window, title);
#else
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_SetWindowTitle(m_window, "VVVVVV");
Add branch name to window title in brackets The branch name will be added to the window title if it is an interim version, e.g. "VVVVVV [master]". This makes it easier for developers to tell at a glance which build of the game they're running.
2023-01-16 21:59:48 +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
Set minimum window size (to 320 x 240) This sets the minimum window size (to 320 x 240), so that the window cannot be resized to lower than that. This is because there's no utility in having a game window smaller than that, and it provides a bonus convenience of being able to resize the game to exactly 320x240 without needing to be exactly precise about it. This idea was suggested by Dav999.
2023-01-29 08:37:24 +01:00
SDL_SetWindowMinimumSize(m_window, SCREEN_WIDTH_PIXELS, SCREEN_HEIGHT_PIXELS);
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
LoadIcon();
Persist windowed mode size through fullscreen mode Previously, the game would not store the size of the window itself, and would always call SDL_GetRendererOutputSize() (via Screen::GetWindowSize()) to figure out the size of the window. The only problem is, this would return the size of the whole monitor if the game was in fullscreen mode. And the only place where the original windowed mode size was stored would be in SDL itself, but that wouldn't persist after the game was closed. So, if you exited the game while in fullscreen mode, then your window size would get set to the size of your monitor (1920 by 1080 in my case). Then when you opened the game and toggled fullscreen off, it would go back to the default window size, which is 640 by 480. This is made worse, however, if you were in forced fullscreen mode when you previously exited the game in windowed mode. In that case, the game saves the size of 1920 by 1080, but doesn't save that you were in fullscreen mode, so opening the game not in forced fullscreen mode would result in you having a 1920 by 1080 window, but in windowed mode. Meaning that not even fullscreening and unfullscreening would put the game window back to normal size. The solution, of course, is to just store the window size ourselves, like any other screen setting, and only use GetWindowSize() if needed. And just to make things clear, I've also renamed the GetWindowSize() function to GetScreenSize(), because if it was named "window" it could lead one to think that it would always return the size of the screen in windowed mode, when in fact it returns the size of the screen whatever mode it is in - fullscreen size if in fullscreen mode and window size if in windowed mode. And doing this also fixes the FIXME above Screen::isForcedFullscreen().
2023-03-21 04:59:37 +01:00
ResizeScreen(windowWidth, windowHeight);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
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 Screen::destroy(void)
Add Screen::destroy() In order to have squeaky-clean memory management, we'll need to clean up all the things that Screen allocates. This is the function to call to do so.
2021-02-16 02:47:11 +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
/* Order matters! */
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_DestroyRenderer, m_renderer);
VVV_freefunc(SDL_DestroyWindow, m_window);
Add Screen::destroy() In order to have squeaky-clean memory management, we'll need to clean up all the things that Screen allocates. This is the function to call to do so.
2021-02-16 02:47:11 +01:00
}
De-C++-ify `struct ScreenSettings` This includes: - Removing the constructor in favor of actually being able to see that there's an actual function called being made initializing the struct - Removing the use of a reference in Screen::init() in favor of using a pointer - Adding the struct qualifier everywhere (it's not much typing), although technically you could typedef it in C, but I'd rather much not typedef just to remove a tag qualifier
2021-12-25 09:18:51 +01:00
void Screen::GetSettings(struct ScreenSettings* settings)
Allow Game::savestats() to accept a pointer to ScreenSettings Another step to fix the bug #556 is to allow Game::savestats() to accept a pointer to an existing ScreenSettings struct. This entails refactoring Game::savesettings() and Game::serializesettings() to accept the function as well, along with adding Screen::GetSettings() so the settings of the current Screen can be easily grabbed.
2020-12-22 01:34:16 +01:00
{
Store display index of window to settings I have this annoying issue where the game will open on the wrong monitor in fullscreen mode, because that monitor is considered to be display 0, whereas the primary monitor I want is display 1. To mitigate this somewhat, the game now stores the display index that it was closed on, and will save it to settings. Then the next time the game opens, it will open on that display index. This should work pretty well as long as you aren't changing your monitor setup constantly. Of course, none of this applies if your window manager is busted. For example, on GNOME Wayland, which is what I use, in windowed mode the game will always open on the monitor the cursor is on, and it won't even be centered in the monitor. But it works fine if I use XWayland via SDL_VIDEODRIVER=x11.
2023-03-21 08:23:42 +01:00
windowDisplay = SDL_GetWindowDisplayIndex(m_window);
if (windowDisplay < 0)
{
vlog_error("Error: could not get display index: %s", SDL_GetError());
windowDisplay = 0;
}
settings->windowDisplay = windowDisplay;
Persist windowed mode size through fullscreen mode Previously, the game would not store the size of the window itself, and would always call SDL_GetRendererOutputSize() (via Screen::GetWindowSize()) to figure out the size of the window. The only problem is, this would return the size of the whole monitor if the game was in fullscreen mode. And the only place where the original windowed mode size was stored would be in SDL itself, but that wouldn't persist after the game was closed. So, if you exited the game while in fullscreen mode, then your window size would get set to the size of your monitor (1920 by 1080 in my case). Then when you opened the game and toggled fullscreen off, it would go back to the default window size, which is 640 by 480. This is made worse, however, if you were in forced fullscreen mode when you previously exited the game in windowed mode. In that case, the game saves the size of 1920 by 1080, but doesn't save that you were in fullscreen mode, so opening the game not in forced fullscreen mode would result in you having a 1920 by 1080 window, but in windowed mode. Meaning that not even fullscreening and unfullscreening would put the game window back to normal size. The solution, of course, is to just store the window size ourselves, like any other screen setting, and only use GetWindowSize() if needed. And just to make things clear, I've also renamed the GetWindowSize() function to GetScreenSize(), because if it was named "window" it could lead one to think that it would always return the size of the screen in windowed mode, when in fact it returns the size of the screen whatever mode it is in - fullscreen size if in fullscreen mode and window size if in windowed mode. And doing this also fixes the FIXME above Screen::isForcedFullscreen().
2023-03-21 04:59:37 +01:00
settings->windowWidth = windowWidth;
settings->windowHeight = windowHeight;
Allow Game::savestats() to accept a pointer to ScreenSettings Another step to fix the bug #556 is to allow Game::savestats() to accept a pointer to an existing ScreenSettings struct. This entails refactoring Game::savesettings() and Game::serializesettings() to accept the function as well, along with adding Screen::GetSettings() so the settings of the current Screen can be easily grabbed.
2020-12-22 01:34:16 +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
settings->fullscreen = !isWindowed;
settings->useVsync = vsync;
Rename stretch mode to scaling mode internally It's been long overdue that this variable be named properly. 2.2 added integer scaling mode (thanks Ethan), 2.3 renamed it to scaling mode. Now 2.4 will properly call it what it is so people won't be confused by it. The ScreenSettings struct member is renamed from stretch to scalingMode along with the Screen class member being renamed, as well as the toggleStretchMode function being renamed to toggleScalingMode as well. Unfortunately, due to compatibility, we can't change the <stretch> XML tag.
2021-12-23 04:54:59 +01:00
settings->scalingMode = scalingMode;
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
settings->linearFilter = isFiltered;
settings->badSignal = badSignalEffect;
Allow Game::savestats() to accept a pointer to ScreenSettings Another step to fix the bug #556 is to allow Game::savestats() to accept a pointer to an existing ScreenSettings struct. This entails refactoring Game::savesettings() and Game::serializesettings() to accept the function as well, along with adding Screen::GetSettings() so the settings of the current Screen can be easily grabbed.
2020-12-22 01:34:16 +01:00
}
Use `LoadImage` in `LoadIcon` This de-duplicates the code, simplifying the codebase and reducing the number of code paths that needs to be maintained. It also adds robustness checks to LoadIcon that weren't there before (checking that loading the file succeeded and that decoding the file also succeeded). Now, you might think that loading the image with alpha will change things in some way. But actually, I tested it, and I'm pretty sure it doesn't. Since my window manager, i3, doesn't display icons, I've had to resort to this hacky multi-liner ( https://unix.stackexchange.com/a/48866 ) to dump the icon to a PAM file. I don't know what a PAM file is and all my various attempts to convert it into something readable failed. But what I did instead was just grab the icon of the game before this commit (on 2.3, just to be extra sure), and `diff`ed it with the grabbed icon now, and they end up being the exact same file. So there's literally no difference. The only other consideration is that LoadImage needs to be exported, since it's implemented in GraphicsResources.cpp. I just opted to forward-declare it right before LoadIcon in Screen.cpp, since it's really the only other time it's used. No need to create a new header file for it or anything.
2021-12-25 10:27:33 +01:00
#ifdef __APPLE__
/* Apple doesn't like icons anymore... */
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 Screen::LoadIcon(void)
Factor out icon loading to Screen::LoadIcon() This is so it can be called multiple times without having to duplicate code.
2020-11-01 04:25:27 +01:00
{
Use `LoadImage` in `LoadIcon` This de-duplicates the code, simplifying the codebase and reducing the number of code paths that needs to be maintained. It also adds robustness checks to LoadIcon that weren't there before (checking that loading the file succeeded and that decoding the file also succeeded). Now, you might think that loading the image with alpha will change things in some way. But actually, I tested it, and I'm pretty sure it doesn't. Since my window manager, i3, doesn't display icons, I've had to resort to this hacky multi-liner ( https://unix.stackexchange.com/a/48866 ) to dump the icon to a PAM file. I don't know what a PAM file is and all my various attempts to convert it into something readable failed. But what I did instead was just grab the icon of the game before this commit (on 2.3, just to be extra sure), and `diff`ed it with the grabbed icon now, and they end up being the exact same file. So there's literally no difference. The only other consideration is that LoadImage needs to be exported, since it's implemented in GraphicsResources.cpp. I just opted to forward-declare it right before LoadIcon in Screen.cpp, since it's really the only other time it's used. No need to create a new header file for it or anything.
2021-12-25 10:27:33 +01:00
}
#else
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
SDL_Surface* LoadImageSurface(const char* filename);
Use `LoadImage` in `LoadIcon` This de-duplicates the code, simplifying the codebase and reducing the number of code paths that needs to be maintained. It also adds robustness checks to LoadIcon that weren't there before (checking that loading the file succeeded and that decoding the file also succeeded). Now, you might think that loading the image with alpha will change things in some way. But actually, I tested it, and I'm pretty sure it doesn't. Since my window manager, i3, doesn't display icons, I've had to resort to this hacky multi-liner ( https://unix.stackexchange.com/a/48866 ) to dump the icon to a PAM file. I don't know what a PAM file is and all my various attempts to convert it into something readable failed. But what I did instead was just grab the icon of the game before this commit (on 2.3, just to be extra sure), and `diff`ed it with the grabbed icon now, and they end up being the exact same file. So there's literally no difference. The only other consideration is that LoadImage needs to be exported, since it's implemented in GraphicsResources.cpp. I just opted to forward-declare it right before LoadIcon in Screen.cpp, since it's really the only other time it's used. No need to create a new header file for it or anything.
2021-12-25 10:27:33 +01:00
void Screen::LoadIcon(void)
{
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
SDL_Surface* icon = LoadImageSurface("VVVVVV.png");
Use `LoadImage` in `LoadIcon` This de-duplicates the code, simplifying the codebase and reducing the number of code paths that needs to be maintained. It also adds robustness checks to LoadIcon that weren't there before (checking that loading the file succeeded and that decoding the file also succeeded). Now, you might think that loading the image with alpha will change things in some way. But actually, I tested it, and I'm pretty sure it doesn't. Since my window manager, i3, doesn't display icons, I've had to resort to this hacky multi-liner ( https://unix.stackexchange.com/a/48866 ) to dump the icon to a PAM file. I don't know what a PAM file is and all my various attempts to convert it into something readable failed. But what I did instead was just grab the icon of the game before this commit (on 2.3, just to be extra sure), and `diff`ed it with the grabbed icon now, and they end up being the exact same file. So there's literally no difference. The only other consideration is that LoadImage needs to be exported, since it's implemented in GraphicsResources.cpp. I just opted to forward-declare it right before LoadIcon in Screen.cpp, since it's really the only other time it's used. No need to create a new header file for it or anything.
2021-12-25 10:27:33 +01:00
if (icon == NULL)
{
return;
}
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_SetWindowIcon(m_window, icon);
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, icon);
Factor out icon loading to Screen::LoadIcon() This is so it can be called multiple times without having to duplicate code.
2020-11-01 04:25:27 +01:00
}
Use `LoadImage` in `LoadIcon` This de-duplicates the code, simplifying the codebase and reducing the number of code paths that needs to be maintained. It also adds robustness checks to LoadIcon that weren't there before (checking that loading the file succeeded and that decoding the file also succeeded). Now, you might think that loading the image with alpha will change things in some way. But actually, I tested it, and I'm pretty sure it doesn't. Since my window manager, i3, doesn't display icons, I've had to resort to this hacky multi-liner ( https://unix.stackexchange.com/a/48866 ) to dump the icon to a PAM file. I don't know what a PAM file is and all my various attempts to convert it into something readable failed. But what I did instead was just grab the icon of the game before this commit (on 2.3, just to be extra sure), and `diff`ed it with the grabbed icon now, and they end up being the exact same file. So there's literally no difference. The only other consideration is that LoadImage needs to be exported, since it's implemented in GraphicsResources.cpp. I just opted to forward-declare it right before LoadIcon in Screen.cpp, since it's really the only other time it's used. No need to create a new header file for it or anything.
2021-12-25 10:27:33 +01:00
#endif /* __APPLE__ */
Factor out icon loading to Screen::LoadIcon() This is so it can be called multiple times without having to duplicate code.
2020-11-01 04:25:27 +01:00
Do proper error handling inside Screen::ResizeScreen() Instead of passing the error codes out of the function, just handle the errors directly as they happen, and fail gracefully if something goes wrong instead of continuing.
2020-03-13 23:22:37 +01:00
void Screen::ResizeScreen(int x, int y)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Store display index of window to settings I have this annoying issue where the game will open on the wrong monitor in fullscreen mode, because that monitor is considered to be display 0, whereas the primary monitor I want is display 1. To mitigate this somewhat, the game now stores the display index that it was closed on, and will save it to settings. Then the next time the game opens, it will open on that display index. This should work pretty well as long as you aren't changing your monitor setup constantly. Of course, none of this applies if your window manager is busted. For example, on GNOME Wayland, which is what I use, in windowed mode the game will always open on the monitor the cursor is on, and it won't even be centered in the monitor. But it works fine if I use XWayland via SDL_VIDEODRIVER=x11.
2023-03-21 08:23:42 +01:00
windowDisplay = SDL_GetWindowDisplayIndex(m_window);
if (windowDisplay < 0)
{
vlog_error("Error: could not get display index: %s", SDL_GetError());
windowDisplay = 0;
}
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 (x != -1 && y != -1)
{
// This is a user resize!
Persist windowed mode size through fullscreen mode Previously, the game would not store the size of the window itself, and would always call SDL_GetRendererOutputSize() (via Screen::GetWindowSize()) to figure out the size of the window. The only problem is, this would return the size of the whole monitor if the game was in fullscreen mode. And the only place where the original windowed mode size was stored would be in SDL itself, but that wouldn't persist after the game was closed. So, if you exited the game while in fullscreen mode, then your window size would get set to the size of your monitor (1920 by 1080 in my case). Then when you opened the game and toggled fullscreen off, it would go back to the default window size, which is 640 by 480. This is made worse, however, if you were in forced fullscreen mode when you previously exited the game in windowed mode. In that case, the game saves the size of 1920 by 1080, but doesn't save that you were in fullscreen mode, so opening the game not in forced fullscreen mode would result in you having a 1920 by 1080 window, but in windowed mode. Meaning that not even fullscreening and unfullscreening would put the game window back to normal size. The solution, of course, is to just store the window size ourselves, like any other screen setting, and only use GetWindowSize() if needed. And just to make things clear, I've also renamed the GetWindowSize() function to GetScreenSize(), because if it was named "window" it could lead one to think that it would always return the size of the screen in windowed mode, when in fact it returns the size of the screen whatever mode it is in - fullscreen size if in fullscreen mode and window size if in windowed mode. And doing this also fixes the FIXME above Screen::isForcedFullscreen().
2023-03-21 04:59:37 +01:00
windowWidth = x;
windowHeight = y;
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
}
Add forced fullscreen mode This is mainly to make sure the game is definitely set to fullscreen in Big Picture and on the Steam Deck, and to also remove windowed options that wouldn't make sense if you're not on a desktop (toggling fullscreen, resize to nearest). Those options would also be removed on console and mobile too. There's a bit of an annoying bug where if you launch the game in forced fullscreen mode, but then exit and relaunch in normal mode, your game will have fullscreen window sizes but it won't be fullscreen. This is because forced fullscreen mode tries to preserve your non-forced fullscreen setting, but due to the way window sizes are stored and queried, it can't preserve the non-forced window size. This is a bit difficult to work around, so I'm just putting in a FIXME here because we can fix it later and I'd rather have a slightly buggy forced fullscreen mode than not have one at all. Closes #849.
2021-12-26 07:55:55 +01:00
if (!isWindowed || isForcedFullscreen())
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
{
int result = SDL_SetWindowFullscreen(m_window, SDL_WINDOW_FULLSCREEN_DESKTOP);
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
recacheTextures();
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 (result != 0)
{
vlog_error("Error: could not set the game to fullscreen mode: %s", SDL_GetError());
return;
}
}
else
{
int result = SDL_SetWindowFullscreen(m_window, 0);
if (result != 0)
{
Fix texture cache missing in certain situations after resizing the window
2023-08-23 03:03:10 +02:00
recacheTextures();
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("Error: could not set the game to windowed mode: %s", SDL_GetError());
return;
}
if (x != -1 && y != -1)
{
Persist windowed mode size through fullscreen mode Previously, the game would not store the size of the window itself, and would always call SDL_GetRendererOutputSize() (via Screen::GetWindowSize()) to figure out the size of the window. The only problem is, this would return the size of the whole monitor if the game was in fullscreen mode. And the only place where the original windowed mode size was stored would be in SDL itself, but that wouldn't persist after the game was closed. So, if you exited the game while in fullscreen mode, then your window size would get set to the size of your monitor (1920 by 1080 in my case). Then when you opened the game and toggled fullscreen off, it would go back to the default window size, which is 640 by 480. This is made worse, however, if you were in forced fullscreen mode when you previously exited the game in windowed mode. In that case, the game saves the size of 1920 by 1080, but doesn't save that you were in fullscreen mode, so opening the game not in forced fullscreen mode would result in you having a 1920 by 1080 window, but in windowed mode. Meaning that not even fullscreening and unfullscreening would put the game window back to normal size. The solution, of course, is to just store the window size ourselves, like any other screen setting, and only use GetWindowSize() if needed. And just to make things clear, I've also renamed the GetWindowSize() function to GetScreenSize(), because if it was named "window" it could lead one to think that it would always return the size of the screen in windowed mode, when in fact it returns the size of the screen whatever mode it is in - fullscreen size if in fullscreen mode and window size if in windowed mode. And doing this also fixes the FIXME above Screen::isForcedFullscreen().
2023-03-21 04:59:37 +01:00
SDL_SetWindowSize(m_window, windowWidth, windowHeight);
Store display index of window to settings I have this annoying issue where the game will open on the wrong monitor in fullscreen mode, because that monitor is considered to be display 0, whereas the primary monitor I want is display 1. To mitigate this somewhat, the game now stores the display index that it was closed on, and will save it to settings. Then the next time the game opens, it will open on that display index. This should work pretty well as long as you aren't changing your monitor setup constantly. Of course, none of this applies if your window manager is busted. For example, on GNOME Wayland, which is what I use, in windowed mode the game will always open on the monitor the cursor is on, and it won't even be centered in the monitor. But it works fine if I use XWayland via SDL_VIDEODRIVER=x11.
2023-03-21 08:23:42 +01:00
SDL_SetWindowPosition(
m_window,
SDL_WINDOWPOS_CENTERED_DISPLAY(windowDisplay),
SDL_WINDOWPOS_CENTERED_DISPLAY(windowDisplay)
);
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
}
Fix texture cache missing in certain situations after resizing the window
2023-08-23 03:03:10 +02:00
recacheTextures();
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
}
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 Screen::ResizeToNearestMultiple(void)
Add "resize to nearest" graphics option If you want your game window to simply be exactly 320x240, or 640x480, or 960x720 etc. then it's really annoying that there's no easy way to do this (to clarify, this is different from integer mode, which controls the size of the game INSIDE the window). The easiest way would be having to close the game, go into unlock.vvv, and edit the window size manually. VCE has a 1x/2x/3x/4x graphics option to solve this, although it does not account for actual monitor size (those 1x/2x/3x/4x modes are all you get, whether or not you have a monitor too small for some of them or too big for any of them to be what you want). I discussed this with flibit, and he said that VCE's approach (if it accounted for monitor size) wouldn't work on high-retina displays or high DPIs, because getting the actual multiplier to account for those monitors is kind of a pain. So the next best thing would be to add an option that resizes to the nearest perfect multiple of 320x240. That way you could simply resize the window and let the game correct any imperfect dimensions automatically.
2020-06-30 07:02:21 +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
int w, h;
Persist windowed mode size through fullscreen mode Previously, the game would not store the size of the window itself, and would always call SDL_GetRendererOutputSize() (via Screen::GetWindowSize()) to figure out the size of the window. The only problem is, this would return the size of the whole monitor if the game was in fullscreen mode. And the only place where the original windowed mode size was stored would be in SDL itself, but that wouldn't persist after the game was closed. So, if you exited the game while in fullscreen mode, then your window size would get set to the size of your monitor (1920 by 1080 in my case). Then when you opened the game and toggled fullscreen off, it would go back to the default window size, which is 640 by 480. This is made worse, however, if you were in forced fullscreen mode when you previously exited the game in windowed mode. In that case, the game saves the size of 1920 by 1080, but doesn't save that you were in fullscreen mode, so opening the game not in forced fullscreen mode would result in you having a 1920 by 1080 window, but in windowed mode. Meaning that not even fullscreening and unfullscreening would put the game window back to normal size. The solution, of course, is to just store the window size ourselves, like any other screen setting, and only use GetWindowSize() if needed. And just to make things clear, I've also renamed the GetWindowSize() function to GetScreenSize(), because if it was named "window" it could lead one to think that it would always return the size of the screen in windowed mode, when in fact it returns the size of the screen whatever mode it is in - fullscreen size if in fullscreen mode and window size if in windowed mode. And doing this also fixes the FIXME above Screen::isForcedFullscreen().
2023-03-21 04:59:37 +01:00
GetScreenSize(&w, &h);
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
// Check aspect ratio first
bool using_width;
int usethisdimension, usethisratio;
if ((float) w / (float) h > 4.0 / 3.0)
{
// Width is bigger, so it's limited by height
usethisdimension = h;
Refactor `Screen.cpp` to use named constants No more hardcoded 320s and 240s here.
2022-03-13 01:46:58 +01:00
usethisratio = SCREEN_HEIGHT_PIXELS;
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
using_width = false;
}
else
{
// Height is bigger, so it's limited by width. Or we're exactly 4:3 already
usethisdimension = w;
Refactor `Screen.cpp` to use named constants No more hardcoded 320s and 240s here.
2022-03-13 01:46:58 +01:00
usethisratio = SCREEN_WIDTH_PIXELS;
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
using_width = true;
}
int floor = (usethisdimension / usethisratio) * usethisratio;
int ceiling = floor + usethisratio;
int final_dimension;
if (usethisdimension - floor < ceiling - usethisdimension)
{
// Floor is nearest
final_dimension = floor;
}
else
{
// Ceiling is nearest. Or we're exactly on a multiple already
final_dimension = ceiling;
}
if (final_dimension == 0)
{
// We're way too small!
Refactor `Screen.cpp` to use named constants No more hardcoded 320s and 240s here.
2022-03-13 01:46:58 +01:00
ResizeScreen(SCREEN_WIDTH_PIXELS, SCREEN_HEIGHT_PIXELS);
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;
}
if (using_width)
{
ResizeScreen(final_dimension, final_dimension / 4 * 3);
}
else
{
ResizeScreen(final_dimension * 4 / 3, final_dimension);
}
Add "resize to nearest" graphics option If you want your game window to simply be exactly 320x240, or 640x480, or 960x720 etc. then it's really annoying that there's no easy way to do this (to clarify, this is different from integer mode, which controls the size of the game INSIDE the window). The easiest way would be having to close the game, go into unlock.vvv, and edit the window size manually. VCE has a 1x/2x/3x/4x graphics option to solve this, although it does not account for actual monitor size (those 1x/2x/3x/4x modes are all you get, whether or not you have a monitor too small for some of them or too big for any of them to be what you want). I discussed this with flibit, and he said that VCE's approach (if it accounted for monitor size) wouldn't work on high-retina displays or high DPIs, because getting the actual multiplier to account for those monitors is kind of a pain. So the next best thing would be to add an option that resizes to the nearest perfect multiple of 320x240. That way you could simply resize the window and let the game correct any imperfect dimensions automatically.
2020-06-30 07:02:21 +02:00
}
Persist windowed mode size through fullscreen mode Previously, the game would not store the size of the window itself, and would always call SDL_GetRendererOutputSize() (via Screen::GetWindowSize()) to figure out the size of the window. The only problem is, this would return the size of the whole monitor if the game was in fullscreen mode. And the only place where the original windowed mode size was stored would be in SDL itself, but that wouldn't persist after the game was closed. So, if you exited the game while in fullscreen mode, then your window size would get set to the size of your monitor (1920 by 1080 in my case). Then when you opened the game and toggled fullscreen off, it would go back to the default window size, which is 640 by 480. This is made worse, however, if you were in forced fullscreen mode when you previously exited the game in windowed mode. In that case, the game saves the size of 1920 by 1080, but doesn't save that you were in fullscreen mode, so opening the game not in forced fullscreen mode would result in you having a 1920 by 1080 window, but in windowed mode. Meaning that not even fullscreening and unfullscreening would put the game window back to normal size. The solution, of course, is to just store the window size ourselves, like any other screen setting, and only use GetWindowSize() if needed. And just to make things clear, I've also renamed the GetWindowSize() function to GetScreenSize(), because if it was named "window" it could lead one to think that it would always return the size of the screen in windowed mode, when in fact it returns the size of the screen whatever mode it is in - fullscreen size if in fullscreen mode and window size if in windowed mode. And doing this also fixes the FIXME above Screen::isForcedFullscreen().
2023-03-21 04:59:37 +01:00
void Screen::GetScreenSize(int* x, int* y)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
`GetWindowSize`: Initialize out values if `GetRendererOutput` fails Issue #870 showed one of the problems that this game has, namely that it only sometimes checks SDL return values, and did not do so in this case. Part of the cause of #870 is that Screen::GetWindowSize does not check the return value of SDL_GetRendererOutputSize, so when that function fails (as in the case where m_renderer is NULL and does not exist), it does not initialize the out values, so it ends up writing uninitialized values to the save files. We need to make sure every function's return value is checked, not just SDL functions, but that will have to be done later.
2022-03-13 01:47:23 +01:00
if (SDL_GetRendererOutputSize(m_renderer, x, y) != 0)
{
vlog_error("Could not get window size: %s", SDL_GetError());
/* Initialize to safe defaults */
*x = SCREEN_WIDTH_PIXELS;
*y = SCREEN_HEIGHT_PIXELS;
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
Always update scaling before rendering This fixes the following bug that only occurs on Wayland: If the game is configured to be fullscreened and in stretch mode, on startup, it won't be in stretch mode. It will appear to be in letterbox mode, but the game still thinks it's in stretch mode. This is because during the ResizeScreen() call on startup, for whatever reason, the window size will be reported to be the default size (640 by 480) instead of the screen resolution of the monitor, as one would expect from being in fullscreen. It seems like when the game queries the window size, the window isn't actually in fullscreen at that time, even though this is after fullscreen has been set to true. To fix this, I decided to always update the logical size before SDL_RenderPresent() is called. To make this neater, I put the scaling code in its own function named UpdateScaling(). This bug has existed since 2.3 and does not occur on X11. I tested this on GNOME Wayland, and for testing it on X11, I used Openbox in a Xephyr session while running VVVVVV with SDL_VIDEODRIVER=x11.
2023-03-21 04:31:31 +01:00
void Screen::UpdateScaling(void)
{
int width;
int height;
if (scalingMode == SCALING_STRETCH)
{
Persist windowed mode size through fullscreen mode Previously, the game would not store the size of the window itself, and would always call SDL_GetRendererOutputSize() (via Screen::GetWindowSize()) to figure out the size of the window. The only problem is, this would return the size of the whole monitor if the game was in fullscreen mode. And the only place where the original windowed mode size was stored would be in SDL itself, but that wouldn't persist after the game was closed. So, if you exited the game while in fullscreen mode, then your window size would get set to the size of your monitor (1920 by 1080 in my case). Then when you opened the game and toggled fullscreen off, it would go back to the default window size, which is 640 by 480. This is made worse, however, if you were in forced fullscreen mode when you previously exited the game in windowed mode. In that case, the game saves the size of 1920 by 1080, but doesn't save that you were in fullscreen mode, so opening the game not in forced fullscreen mode would result in you having a 1920 by 1080 window, but in windowed mode. Meaning that not even fullscreening and unfullscreening would put the game window back to normal size. The solution, of course, is to just store the window size ourselves, like any other screen setting, and only use GetWindowSize() if needed. And just to make things clear, I've also renamed the GetWindowSize() function to GetScreenSize(), because if it was named "window" it could lead one to think that it would always return the size of the screen in windowed mode, when in fact it returns the size of the screen whatever mode it is in - fullscreen size if in fullscreen mode and window size if in windowed mode. And doing this also fixes the FIXME above Screen::isForcedFullscreen().
2023-03-21 04:59:37 +01:00
GetScreenSize(&width, &height);
Always update scaling before rendering This fixes the following bug that only occurs on Wayland: If the game is configured to be fullscreened and in stretch mode, on startup, it won't be in stretch mode. It will appear to be in letterbox mode, but the game still thinks it's in stretch mode. This is because during the ResizeScreen() call on startup, for whatever reason, the window size will be reported to be the default size (640 by 480) instead of the screen resolution of the monitor, as one would expect from being in fullscreen. It seems like when the game queries the window size, the window isn't actually in fullscreen at that time, even though this is after fullscreen has been set to true. To fix this, I decided to always update the logical size before SDL_RenderPresent() is called. To make this neater, I put the scaling code in its own function named UpdateScaling(). This bug has existed since 2.3 and does not occur on X11. I tested this on GNOME Wayland, and for testing it on X11, I used Openbox in a Xephyr session while running VVVVVV with SDL_VIDEODRIVER=x11.
2023-03-21 04:31:31 +01:00
}
else
{
width = SCREEN_WIDTH_PIXELS;
height = SCREEN_HEIGHT_PIXELS;
}
int result = SDL_RenderSetLogicalSize(m_renderer, width, height);
if (result != 0)
{
vlog_error("Error: could not set logical size: %s", SDL_GetError());
return;
}
result = SDL_RenderSetIntegerScale(m_renderer, (SDL_bool) (scalingMode == SCALING_INTEGER));
if (result != 0)
{
vlog_error("Error: could not set scale: %s", SDL_GetError());
}
}
Style: Fixup instances of `void` arguments The style we have here is that functions with no arguments are to have explicit `void` arguments, even though this doesn't apply in C++, because it does apply in C. Unfortunately, some have slipped through the cracks. This commit fixes them.
2023-03-18 23:24:14 +01:00
void Screen::RenderPresent(void)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Always update scaling before rendering This fixes the following bug that only occurs on Wayland: If the game is configured to be fullscreened and in stretch mode, on startup, it won't be in stretch mode. It will appear to be in letterbox mode, but the game still thinks it's in stretch mode. This is because during the ResizeScreen() call on startup, for whatever reason, the window size will be reported to be the default size (640 by 480) instead of the screen resolution of the monitor, as one would expect from being in fullscreen. It seems like when the game queries the window size, the window isn't actually in fullscreen at that time, even though this is after fullscreen has been set to true. To fix this, I decided to always update the logical size before SDL_RenderPresent() is called. To make this neater, I put the scaling code in its own function named UpdateScaling(). This bug has existed since 2.3 and does not occur on X11. I tested this on GNOME Wayland, and for testing it on X11, I used Openbox in a Xephyr session while running VVVVVV with SDL_VIDEODRIVER=x11.
2023-03-21 04:31:31 +01:00
/* In certain cases, the window size might mismatch with the logical size.
* So it's better to just always call this. */
UpdateScaling();
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_RenderPresent(m_renderer);
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
graphics.clear();
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
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 Screen::toggleFullScreen(void)
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
isWindowed = !isWindowed;
Persist windowed mode size through fullscreen mode Previously, the game would not store the size of the window itself, and would always call SDL_GetRendererOutputSize() (via Screen::GetWindowSize()) to figure out the size of the window. The only problem is, this would return the size of the whole monitor if the game was in fullscreen mode. And the only place where the original windowed mode size was stored would be in SDL itself, but that wouldn't persist after the game was closed. So, if you exited the game while in fullscreen mode, then your window size would get set to the size of your monitor (1920 by 1080 in my case). Then when you opened the game and toggled fullscreen off, it would go back to the default window size, which is 640 by 480. This is made worse, however, if you were in forced fullscreen mode when you previously exited the game in windowed mode. In that case, the game saves the size of 1920 by 1080, but doesn't save that you were in fullscreen mode, so opening the game not in forced fullscreen mode would result in you having a 1920 by 1080 window, but in windowed mode. Meaning that not even fullscreening and unfullscreening would put the game window back to normal size. The solution, of course, is to just store the window size ourselves, like any other screen setting, and only use GetWindowSize() if needed. And just to make things clear, I've also renamed the GetWindowSize() function to GetScreenSize(), because if it was named "window" it could lead one to think that it would always return the size of the screen in windowed mode, when in fact it returns the size of the screen whatever mode it is in - fullscreen size if in fullscreen mode and window size if in windowed mode. And doing this also fixes the FIXME above Screen::isForcedFullscreen().
2023-03-21 04:59:37 +01:00
ResizeScreen(windowWidth, windowHeight);
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 (game.currentmenuname == Menu::graphicoptions)
{
/* Recreate menu to update "resize to nearest" */
game.createmenu(game.currentmenuname, true);
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
Rename stretch mode to scaling mode internally It's been long overdue that this variable be named properly. 2.2 added integer scaling mode (thanks Ethan), 2.3 renamed it to scaling mode. Now 2.4 will properly call it what it is so people won't be confused by it. The ScreenSettings struct member is renamed from stretch to scalingMode along with the Screen class member being renamed, as well as the toggleStretchMode function being renamed to toggleScalingMode as well. Unfortunately, due to compatibility, we can't change the <stretch> XML tag.
2021-12-23 04:54:59 +01:00
void Screen::toggleScalingMode(void)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Add and use scaling mode enum This enum is to just make each mode be readable, instead of mysterious 0/1/2 values. It's not a strictly-typed enum because we still have to serialize it as ints in the XML, but it's better than just leaving them as ints. This also adds a NUM_SCALING_MODES enum, so we don't have to hardcode that 3 when cycling scaling modes anymore.
2021-12-26 08:05:14 +01:00
scalingMode = (scalingMode + 1) % NUM_SCALING_MODES;
Always update scaling before rendering This fixes the following bug that only occurs on Wayland: If the game is configured to be fullscreened and in stretch mode, on startup, it won't be in stretch mode. It will appear to be in letterbox mode, but the game still thinks it's in stretch mode. This is because during the ResizeScreen() call on startup, for whatever reason, the window size will be reported to be the default size (640 by 480) instead of the screen resolution of the monitor, as one would expect from being in fullscreen. It seems like when the game queries the window size, the window isn't actually in fullscreen at that time, even though this is after fullscreen has been set to true. To fix this, I decided to always update the logical size before SDL_RenderPresent() is called. To make this neater, I put the scaling code in its own function named UpdateScaling(). This bug has existed since 2.3 and does not occur on X11. I tested this on GNOME Wayland, and for testing it on X11, I used Openbox in a Xephyr session while running VVVVVV with SDL_VIDEODRIVER=x11.
2023-03-21 04:31:31 +01:00
UpdateScaling();
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
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 Screen::toggleLinearFilter(void)
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
isFiltered = !isFiltered;
SDL_SetHintWithPriority(
SDL_HINT_RENDER_SCALE_QUALITY,
isFiltered ? "linear" : "nearest",
SDL_HINT_OVERRIDE
);
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
SDL_DestroyTexture(graphics.gameTexture);
graphics.gameTexture = SDL_CreateTexture(
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
m_renderer,
SDL_PIXELFORMAT_ARGB8888,
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
SDL_TEXTUREACCESS_TARGET,
Refactor `Screen.cpp` to use named constants No more hardcoded 320s and 240s here.
2022-03-13 01:46:58 +01:00
SCREEN_WIDTH_PIXELS,
SCREEN_HEIGHT_PIXELS
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
if (graphics.gameTexture == NULL)
{
vlog_error("Could not create game texture: %s", SDL_GetError());
return;
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
Move the VSync work to Screen. The problem we're running into is entirely contained in the Screen - we need to either decouple graphics context init from Screen::init or we need to take out the screenbuffer interaction from loadstats (which I'm more in favor of since we can just pull the config values and pass them to Screen::init later).
2020-07-02 06:19:40 +02:00
Fix VSync renderer workaround SDL just got an API to toggle VSync without having to tear down the renderer ( libsdl-org/SDL#4157 ). We can remove the workaround and use that instead. For now, we are putting it behind an ifdef until SDL 2.0.18 officially releases in November. Fixes #831.
2021-09-15 05:23:22 +02:00
void Screen::toggleVSync(void)
Move the VSync work to Screen. The problem we're running into is entirely contained in the Screen - we need to either decouple graphics context init from Screen::init or we need to take out the screenbuffer interaction from loadstats (which I'm more in favor of since we can just pull the config values and pass them to Screen::init later).
2020-07-02 06:19:40 +02:00
{
Fix VSync renderer workaround SDL just got an API to toggle VSync without having to tear down the renderer ( libsdl-org/SDL#4157 ). We can remove the workaround and use that instead. For now, we are putting it behind an ifdef until SDL 2.0.18 officially releases in November. Fixes #831.
2021-09-15 05:23:22 +02:00
vsync = !vsync;
SDL_RenderSetVSync(m_renderer, (int) vsync);
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
recacheTextures();
}
void Screen::recacheTextures(void)
{
// Fix for d3d9, which clears target textures sometimes (ex. toggling vsync, switching fullscreen, etc...)
// Signal cached textures to be redrawn fully
graphics.backgrounddrawn = false;
graphics.foregrounddrawn = false;
graphics.towerbg.tdrawback = true;
graphics.titlebg.tdrawback = true;
if (game.ingame_titlemode)
{
// Redraw the cached gameplay texture if we're in the in-game menu.
// Additionally, reset alpha so things don't jitter when re-entering gameplay.
float oldAlpha = graphics.alpha;
graphics.alpha = 0;
gamerender();
graphics.alpha = oldAlpha;
}
Move the VSync work to Screen. The problem we're running into is entirely contained in the Screen - we need to either decouple graphics context init from Screen::init or we need to take out the screenbuffer interaction from loadstats (which I'm more in favor of since we can just pull the config values and pass them to Screen::init later).
2020-07-02 06:19:40 +02:00
}
Add forced fullscreen mode This is mainly to make sure the game is definitely set to fullscreen in Big Picture and on the Steam Deck, and to also remove windowed options that wouldn't make sense if you're not on a desktop (toggling fullscreen, resize to nearest). Those options would also be removed on console and mobile too. There's a bit of an annoying bug where if you launch the game in forced fullscreen mode, but then exit and relaunch in normal mode, your game will have fullscreen window sizes but it won't be fullscreen. This is because forced fullscreen mode tries to preserve your non-forced fullscreen setting, but due to the way window sizes are stored and queried, it can't preserve the non-forced window size. This is a bit difficult to work around, so I'm just putting in a FIXME here because we can fix it later and I'd rather have a slightly buggy forced fullscreen mode than not have one at all. Closes #849.
2021-12-26 07:55:55 +01:00
bool Screen::isForcedFullscreen(void)
{
/* This is just a check to see if we're on a desktop or tenfoot setup.
* If you're working on a tenfoot-only build, add a def that always
* returns true!
*/
return SDL_GetHintBoolean("SteamTenfoot", SDL_FALSE);
}
Reference in a new issue Copy permalink