mpo/VVVVVV
1
0
Fork 0
mirror of https://github.com/TerryCavanagh/VVVVVV.git synced 2024-11-16 16:09:42 +01:00
Code Issues Releases Wiki Activity
VVVVVV/desktop_version/src/main.cpp

987 lines
25 KiB
C++
Raw Normal View History

Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
#include <SDL.h>
Move Emscripten includes to top of `main.cpp` All system header includes should come before project-specific includes (includes specific to this game), while coming after the include specific to the given file (if any; main.cpp doesn't have any).
2021-09-20 22:47:53 +02:00
#ifdef __EMSCRIPTEN__
#include <emscripten.h>
#include <emscripten/html5.h>
#endif
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
Rename editor.h to CustomLevels.h This accompanies the editor.cpp -> CustomLevels.cpp change; I'll be splitting out the editor functions in the next commit. The name of the include guard has been changed as well, but not anything else.
2021-02-20 08:19:09 +01:00
#include "CustomLevels.h"
Add deferred callbacks to game loop Sometimes, there needs to be code that gets ran at the end of the game loop, otherwise rendering issues might occur. Currently, we do this by special-casing each deferred routine (e.g. shouldreturntoeditor), but it would be better if we could generalize this deference instead. Deferred callbacks can be added using the DEFER_CALLBACK macro. It takes in one argument, which is the name of a function, and that function must be a void function that takes in no arguments. Also, due to annoying C++ quirks, void functions taking no arguments cannot be attributes of objects (because they have an implicit `this` parameter), so it's recommended to create each callback separately before using the DEFER_CALLBACK macro.
2020-12-24 08:24:31 +01:00
#include "DeferCallbacks.h"
Move editor functions to separate header Editor functions now live in Editor.h, which is a new file - the existing editor.h has been renamed to CustomLevels.h.
2021-02-20 08:21:58 +01:00
#include "Editor.h"
Remove unnecessary includes from header files Including a header file inside another header file means a bunch of files are going to be unnecessarily recompiled whenever that inner header file is changed. So I minimized the amount of header files included in a header file, and only included the ones that were necessary (system includes don't count, I'm only talking about includes from within this project). Then the includes are only in the .cpp files themselves. This also minimizes problems such as a NO_CUSTOM_LEVELS build failing because some file depended on an include that got included in editor.h, which is another benefit of removing unnecessary includes from header files.
2020-07-19 21:05:41 +02:00
#include "Enums.h"
#include "Entity.h"
Clean up all program close paths to use VVV_exit() Wow, there are a lot of these. All of these exit paths now use VVV_exit() instead, which attempts to save unlock.vvv and settings.vvv, and also frees all resources so Valgrind is happy. This is a good thing, because previously unlock.vvv/settings.vvv wouldn't be written to if we decided to bail for a given reason.
2021-02-16 03:53:17 +01:00
#include "Exit.h"
Separate includes into sections and alphabetize them Okay, so basically here's the include layout that this game now consistently uses: [The "main" header file, if any (e.g. Graphics.h for Graphics.cpp)] [blank line] [All system includes, such as tinyxml2/physfs/utfcpp/SDL] [blank line] [All project includes, such as Game.h/Entity.h/etc.] And if applicable, another blank line, and then some special-case include screwy stuff (take a look at editor.cpp or FileSystemUtils.cpp, for example, they have ifdefs and defines with their includes).
2020-07-19 21:43:29 +02:00
#include "FileSystemUtils.h"
Start rewrite of font system This is still a work in progress, but the existing font system has been removed and replaced by a new one, in Font.cpp. Design goals of the new font system include supporting colored button glyphs, different fonts for different languages, and larger fonts than 8x8 for Chinese, Japanese and Korean, while being able to support their 30000+ characters without hiccups, slowdowns or high memory usage. And to have more flexibility with fonts in general. Plus, Graphics.cpp was long enough as-is, so it's good to have a dedicated file for font storage. The old font system worked with a std::vector<SDL_Surface*> to store 8x8 surfaces for each character, and a std::map<int,int> to store mappings between codepoints and vector indexes. The new system has a per-font collection of pages for every block of 0x1000 (4096) codepoints, that may be allocated as needed. A glyph on a page contains the index of the glyph in the image (giving its coordinates), the advance (how much the cursor should advance, so the width of that glyph) and some flags which would be at least whether the glyph exists and whether it is colored. Most of the *new* features aren't implemented yet; it's currently hardcoded to the regular 8x8 font.png, but it should be functionally equivalent to the previous behavior. The only thing that doesn't really work yet is level-specific font.png, but that'll be supported again soon enough. This commit also adds fontmeta (xml) support. Since the fonts folder is mounted at graphics/, there are two main options for recognizing non-font.png fonts: the font files have to be prefixed with font (or font_) or some special file extension is involved to signal what files are fonts. I always had a font.xml in mind (so font_cn.xml, font_ja.xml, etc) but if there's ever gonna be a need for further xml files inside the graphics folder, we have a problem. So I named them .fontmeta instead. A .fontmeta file looks somewhat like this: <?xml version="1.0" encoding="UTF-8"?> <font_metadata> <width>12</width> <height>12</height> <white_teeth>1</white_teeth> <chars> <range start="0x20" end="0x7E"/> <range start="0x80" end="0x80"/> <range start="0xA0" end="0xDF"/> <range start="0x250" end="0x2A8"/> <range start="0x2AD" end="0x2AD"/> <range start="0x2C7" end="0x2C7"/> <range start="0x2C9" end="0x2CB"/> ... </chars> <special> <range start="0x00" end="0x1F" advance="6"/> <range start="0x61" end="0x66" color="1"/> <range start="0x63" end="0x63" color="0"/> </special> </font_metadata> The <chars> tag can be used to specify characters instead of in a .txt. The original idea was to just always use the existing .txt system for specifying the font charset, and only use the XML for the other stuff that the .txt doesn't cover. However, it's probably better to keep it simple if possible - having to only have a .png and a .fontmeta seems simpler than having the data spread out over three files. And a major advantage: Chinese fonts can have about 30000 characters! It's more efficient to be able to have a tag saying "now there's 20902 characters starting at U+4E00" than to include them all in a text file and having to UTF-8 decode every single one of them. If a font.txt exists, it takes priority over the <chars> tag, and in that case, there's no reason to include the <chars> tag in the XML. But font.txt has to be in the same directory as font.png, otherwise it is rejected. Same for font.fontmeta. If neither font.txt nor <chars> exist, then the font is seen as a 2.2-and-below-style ASCII font. In <special>: advance is the number of pixels the cursor advances after drawing the character (so the width of the character, without affecting the grid in the source image), color is whether the character should have its original colors retained when printed (for button glyphs). As for <white_teeth>: The renderer PR has replaced draw-time whitening of sprites/etc (using BlitSurfaceColoured) by load-time whitening of entire images (using LoadImage with TEX_WHITE as an argument). This means we have a problem: fonts have always had their glyphs whitened at printing time, and since I'm adding support for colored button glyphs, I changed it so glyphs would sometimes not be whitened. But if we can't whiten at print time, then we'd need to whiten at load time, and if we whiten the entire font, any colored glyphs will get destroyed too. If you whiten the image selectively, well, we need more code to target specific squares in the image, and it's kind of a waste when you need to whiten 30000 12x12 Chinese characters when you're only going to need a handful, but you don't know which ones. The solution: Whitening fonts is useless if all the non-colored glyphs are already white, so we don't need to do it anyway! However, any existing fonts that have non-white glyphs (and I know of at least one level like that) will still need to be whitened. So there is now a font property <white_teeth> that can be specified in the fontmeta, which indicates that the font is already pre-whitened. If not specified, traditional whitening behavior will be used, and the font cannot use colored glyphs.
2023-01-02 05:14:53 +01:00
#include "Font.h"
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
#include "Game.h"
#include "Graphics.h"
Use SDL_Color for colors instead of colourTransform colourTransform is a struct with only one member, a Uint32. The issue with `Uint32`s is that it requires a bunch of bit shifting logic to edit the colors. The issue with bit shifting logic is that people have a tendency to hardcode the shift amounts instead of using the shift amount variables of the SDL_PixelFormat, which makes it annoying to change the color masks of surfaces. This commit fixes both issues by unhardcoding the bit shift amounts in DrawPixel and ReadPixel, and by axing the `Uint32`s in favor of using SDL_Color. According to the SDL_PixelFormat documentation ( https://wiki.libsdl.org/SDL2/SDL_PixelFormat ), the logic to read and draw to pixels from colors below 32-bit was just wrong. Specifically, for 8-bit, there's a color palette used instead of some intrinsic color information stored in the pixel itself. But we shouldn't need that logic anyways because we don't use colors below 32-bit. So I axed that too.
2023-01-02 01:36:43 +01:00
#include "GraphicsUtil.h"
Separate includes into sections and alphabetize them Okay, so basically here's the include layout that this game now consistently uses: [The "main" header file, if any (e.g. Graphics.h for Graphics.cpp)] [blank line] [All system includes, such as tinyxml2/physfs/utfcpp/SDL] [blank line] [All project includes, such as Game.h/Entity.h/etc.] And if applicable, another blank line, and then some special-case include screwy stuff (take a look at editor.cpp or FileSystemUtils.cpp, for example, they have ifdefs and defines with their includes).
2020-07-19 21:43:29 +02:00
#include "Input.h"
Optimize recompilation from changing commit hash This reworks how the commit hash and date are compiled so that if they're changed (and they're changed often), only one source file needs to be recompiled in order to update it everywhere in the game, no matter how many source files use the hash or date. The commit hash and date are now declared in InterimVersion.h (and they need `extern "C"` guards because otherwise it results in a link fail on MSVC because MSVC is stupid). To do this, what now happens is that upon every rebuild, InterimVersion.in.c is processed to create InterimVersion.out.c, then InterimVersion.out.c is compiled into its own static library that is then linked with VVVVVV. (Why didn't I just simply add it to the list of VVVVVV source files? Well, doing it _now_ does nothing because at that point the horse is already out of the barn, and the VVVVVV executable has already been declared, so I can't modify its sources. And I can't do it before either, because we depend on the VVVVVV executable existing to do the interim version logic. I could probably work around this by cleverly moving around lines, but that'd separate related logic from each other.) And yes, the naming convention has changed. Not only did I rename Version to InterimVersion (to clearly differentiate it from ReleaseVersion, which I'll be adding later), I also named the files InterimVersion.in.c and InterimVersion.out.c instead of InterimVersion.c.in and InterimVersion.c.out. I needed to put the file extension on the end because otherwise CMake wouldn't recognize what kind of language it is, and I mean like yeah duh of course it doesn't, my text editor doesn't recognize it either.
2022-08-23 06:21:23 +02:00
#include "InterimVersion.h"
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
#include "KeyPoll.h"
Add localization "foundation" (many code changes) This commit adds most of the code changes necessary for making the game translatable, but does not yet "unhardcode" nearly all of the strings (except in a few cases where it was hard to separate added loc::gettexts from foundational code changes, or all the localization- related menus which were also added by this commit.) This commit is part of rewritten history of the localization branch. The original (unsquashed) commit history can be found here: https://github.com/Dav999-v/VVVVVV/tree/localization-orig
2022-12-30 22:57:24 +01:00
#include "Localization.h"
#include "LocalizationStorage.h"
Separate includes into sections and alphabetize them Okay, so basically here's the include layout that this game now consistently uses: [The "main" header file, if any (e.g. Graphics.h for Graphics.cpp)] [blank line] [All system includes, such as tinyxml2/physfs/utfcpp/SDL] [blank line] [All project includes, such as Game.h/Entity.h/etc.] And if applicable, another blank line, and then some special-case include screwy stuff (take a look at editor.cpp or FileSystemUtils.cpp, for example, they have ifdefs and defines with their includes).
2020-07-19 21:43:29 +02:00
#include "Logic.h"
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
#include "Map.h"
Remove unnecessary includes from header files Including a header file inside another header file means a bunch of files are going to be unnecessarily recompiled whenever that inner header file is changed. So I minimized the amount of header files included in a header file, and only included the ones that were necessary (system includes don't count, I'm only talking about includes from within this project). Then the includes are only in the .cpp files themselves. This also minimizes problems such as a NO_CUSTOM_LEVELS build failing because some file depended on an include that got included in editor.h, which is another benefit of removing unnecessary includes from header files.
2020-07-19 21:05:41 +02:00
#include "Music.h"
Separate includes into sections and alphabetize them Okay, so basically here's the include layout that this game now consistently uses: [The "main" header file, if any (e.g. Graphics.h for Graphics.cpp)] [blank line] [All system includes, such as tinyxml2/physfs/utfcpp/SDL] [blank line] [All project includes, such as Game.h/Entity.h/etc.] And if applicable, another blank line, and then some special-case include screwy stuff (take a look at editor.cpp or FileSystemUtils.cpp, for example, they have ifdefs and defines with their includes).
2020-07-19 21:43:29 +02:00
#include "Network.h"
#include "preloader.h"
De-duplicate release version I'm fine with putting the release version in a header file, thus necessitating the need to recompile every file that includes it if it's changed, simply because it's not supposed to be changed that often. The SDL_arraysize is necessary because sometimes we'll have subreleases (e.g. 2.4.1, 2.4.2, 2.4.3), and who knows, maybe we'll get to 2.10 someday.
2022-08-23 06:22:57 +02:00
#include "ReleaseVersion.h"
Separate includes into sections and alphabetize them Okay, so basically here's the include layout that this game now consistently uses: [The "main" header file, if any (e.g. Graphics.h for Graphics.cpp)] [blank line] [All system includes, such as tinyxml2/physfs/utfcpp/SDL] [blank line] [All project includes, such as Game.h/Entity.h/etc.] And if applicable, another blank line, and then some special-case include screwy stuff (take a look at editor.cpp or FileSystemUtils.cpp, for example, they have ifdefs and defines with their includes).
2020-07-19 21:43:29 +02:00
#include "Render.h"
Move all fixed-timestep render updates to new file RenderFixed.cpp As part of fixing #464, I'll need to move these pieces of code around easily. In #220 I just kind of shoved them awkwardly in whatever fixed function would be last called in the gamestate loop, which I shouldn't have done as I've now had to make formal fixed-render functions anyway. Because these fixed functions need to be called directly before a render function, and I'm fixing the order to put render functions in their proper place, so I need to be able to move these around easily, and making them function calls instead of inlined makes them easier to manipulate.
2020-11-08 00:47:49 +01:00
#include "RenderFixed.h"
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
#include "Screen.h"
#include "Script.h"
Silence various warnings in builds removing content The MAKEANDPLAY, NO_CUSTOM_LEVELS, and NO_EDITOR defines remove content or features. However, they then raise several warnings because of some cases, functions, or variables that end up not being used. This silences them by using the UNUSED macro, or by adding a default catch-all case if the define is defined (so unhandled cases will still raise warnings in a build that doesn't have these defines).
2023-02-04 09:14:04 +01:00
#include "Unused.h"
Separate includes into sections and alphabetize them Okay, so basically here's the include layout that this game now consistently uses: [The "main" header file, if any (e.g. Graphics.h for Graphics.cpp)] [blank line] [All system includes, such as tinyxml2/physfs/utfcpp/SDL] [blank line] [All project includes, such as Game.h/Entity.h/etc.] And if applicable, another blank line, and then some special-case include screwy stuff (take a look at editor.cpp or FileSystemUtils.cpp, for example, they have ifdefs and defines with their includes).
2020-07-19 21:43:29 +02:00
#include "UtilityClass.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
scriptclass script;
Move all editor-specific attributes to a new editorclass This is a pretty hefty commit! But essentially, I made a new editorclass object, and moved all functions and variables that only get used in the in-game level editor to that class. This cleanly demarcates which things are in the editor and which things are just general custom level stuff. Then I fixed up all the callers. I also fixed up some NO_CUSTOM_LEVELS and NO_EDITOR ifdefs, too, in several places.
2021-02-21 00:40:11 +01:00
#ifndef NO_CUSTOM_LEVELS
Rename edentity to customentities This fixes the fact that the name of the singular type is plural, but the name of the plural array is singular. Which has always annoyed me, too. Also this makes it more clear that custom entities don't have much to do with the editor.
2021-02-21 01:01:39 +01:00
std::vector<CustomEntity> customentities;
Move all editor-specific attributes to a new editorclass This is a pretty hefty commit! But essentially, I made a new editorclass object, and moved all functions and variables that only get used in the in-game level editor to that class. This cleanly demarcates which things are in the editor and which things are just general custom level stuff. Then I fixed up all the callers. I also fixed up some NO_CUSTOM_LEVELS and NO_EDITOR ifdefs, too, in several places.
2021-02-21 00:40:11 +01:00
customlevelclass cl;
# ifndef NO_EDITOR
Fix mixed indentation in main.cpp Also fix the indentation of preprocessor statements.
2020-04-02 23:43:50 +02:00
editorclass ed;
Move all editor-specific attributes to a new editorclass This is a pretty hefty commit! But essentially, I made a new editorclass object, and moved all functions and variables that only get used in the in-game level editor to that class. This cleanly demarcates which things are in the editor and which things are just general custom level stuff. Then I fixed up all the callers. I also fixed up some NO_CUSTOM_LEVELS and NO_EDITOR ifdefs, too, in several places.
2021-02-21 00:40:11 +01:00
# endif
Add option to compile without the level editor
2020-02-10 01:53:01 +01:00
#endif
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
Allow using help/graphics/music/game/key/map/obj everywhere This commit makes `help`, `graphics`, `music`, `game`, `key`, `map`, and `obj` essentially static global objects that can be used everywhere. This is useful in case we ever need to add a new function in the future, so we don't have to bother with passing a new argument in which means we have to pass a new argument in to the function that calls that function which means having to pass a new argument into the function that calls THAT function, etc. which is a real headache when working on fan mods of the source code. Note that this changes NONE of the existing function signatures, it merely just makes those variables accessible everywhere in the same way `script` and `ed` are. Also note that some classes had to be initialized after the filesystem was initialized, but C++ would keep initializing them before the filesystem got initialized, because I *had* to put them at the top of `main.cpp`, or else they wouldn't be global variables. The only way to work around this was to use entityclass's initialization style (which I'm pretty sure entityclass of all things doesn't need to be initialized this way), where you actually initialize the class in an `init()` function, and so then you do `graphics.init()` after the filesystem initialization, AFTER doing `Graphics graphics` up at the top. I've had to do this for `graphics` (but only because its child GraphicsResources `grphx` needs to be initialized this way), `music`, and `game`. I don't think this will affect anything. Other than that, `help`, `key`, and `map` are still using the C++-intended method of having ClassName::ClassName() functions.
2020-01-29 08:35:03 +01:00
UtilityClass help;
Graphics graphics;
musicclass music;
Game game;
KeyPoll key;
mapclass map;
entityclass obj;
Move gameScreen off of the stack and onto the heap Just so it can be properly used globally like all the other classes.
2020-06-13 20:44:01 +02:00
Screen gameScreen;
Allow using help/graphics/music/game/key/map/obj everywhere This commit makes `help`, `graphics`, `music`, `game`, `key`, `map`, and `obj` essentially static global objects that can be used everywhere. This is useful in case we ever need to add a new function in the future, so we don't have to bother with passing a new argument in which means we have to pass a new argument in to the function that calls that function which means having to pass a new argument into the function that calls THAT function, etc. which is a real headache when working on fan mods of the source code. Note that this changes NONE of the existing function signatures, it merely just makes those variables accessible everywhere in the same way `script` and `ed` are. Also note that some classes had to be initialized after the filesystem was initialized, but C++ would keep initializing them before the filesystem got initialized, because I *had* to put them at the top of `main.cpp`, or else they wouldn't be global variables. The only way to work around this was to use entityclass's initialization style (which I'm pretty sure entityclass of all things doesn't need to be initialized this way), where you actually initialize the class in an `init()` function, and so then you do `graphics.init()` after the filesystem initialization, AFTER doing `Graphics graphics` up at the top. I've had to do this for `graphics` (but only because its child GraphicsResources `grphx` needs to be initialized this way), `music`, and `game`. I don't think this will affect anything. Other than that, `help`, `key`, and `map` are still using the C++-intended method of having ClassName::ClassName() functions.
2020-01-29 08:35:03 +01:00
Clean up unnecessary exports and add static keywords This patch cleans up unnecessary exports from header files (there were only a few), as well as adds the static keyword to all symbols that aren't exported and are specific to a file. This helps the linker out in not doing any unnecessary work, speeding it up and avoiding silent symbol conflicts (otherwise two symbols with the same name (and type/signature in C++) would quietly resolve as okay by the linker).
2021-01-10 18:14:37 +01:00
static bool startinplaytest = false;
static bool savefileplaytest = false;
static int savex = 0;
static int savey = 0;
static int saverx = 0;
static int savery = 0;
static int savegc = 0;
static int savemusic = 0;
static std::string playassets;
static std::string playtestname;
Switch over to using `SDL_GetTicks64()` SDL_GetTicks64() is a function that got added in SDL 2.0.18, which is just an SDL_GetTicks() without a value that wraps every ~49 days, instead wrapping after the sun explodes and kills us all. Oh sorry, didn't mean to get existential. For now, put this behind an SDL_VERSION_ATLEAST guard, which will be removed when SDL 2.0.18 officially releases and we can update to it.
2021-10-26 03:16:47 +02:00
static volatile Uint64 time_ = 0;
static volatile Uint64 timePrev = 0;
Clean up unnecessary exports and add static keywords This patch cleans up unnecessary exports from header files (there were only a few), as well as adds the static keyword to all symbols that aren't exported and are specific to a file. This helps the linker out in not doing any unnecessary work, speeding it up and avoiding silent symbol conflicts (otherwise two symbols with the same name (and type/signature in C++) would quietly resolve as okay by the linker).
2021-01-10 18:14:37 +01:00
static volatile Uint32 accumulator = 0;
Use Emscripten's main loop On Emscripten, SDL_Delay is implemented as a busy loop. In addition, everything happens on a single thread. This effectively means that you have to let Emscripten manage the main loop, since if you do it yourself the browser will just be frozen.
2021-03-31 21:06:26 +02:00
#ifndef __EMSCRIPTEN__
Switch over to using `SDL_GetTicks64()` SDL_GetTicks64() is a function that got added in SDL 2.0.18, which is just an SDL_GetTicks() without a value that wraps every ~49 days, instead wrapping after the sun explodes and kills us all. Oh sorry, didn't mean to get existential. For now, put this behind an SDL_VERSION_ATLEAST guard, which will be removed when SDL 2.0.18 officially releases and we can update to it.
2021-10-26 03:16:47 +02:00
static volatile Uint64 f_time = 0;
static volatile Uint64 f_timePrev = 0;
Use Emscripten's main loop On Emscripten, SDL_Delay is implemented as a busy loop. In addition, everything happens on a single thread. This effectively means that you have to let Emscripten manage the main loop, since if you do it yourself the browser will just be frozen.
2021-03-31 21:06:26 +02:00
#endif
Put the main game loop inside its own function Makes main() less of one giant blob of code.
2020-06-14 20:45:36 +02:00
Generalize game loop order and fix it to what it was in 2.2 Okay, so the reason why all render functions were moved to the end of the frame in #220 is because it's simpler to call two fixed functions and then a delta function instead of one fixed function, then a delta function, and then another fixed function. This is because fixed functions need special handling inside deltaloop(), and you can't simply duplicate this handling after calling a delta function. Oh, and to make matters worse, it's not always fixed-delta-fixed, sometimes (like in MAPMODE and TELEPORTERMODE) it's delta-fixed-fixed, so we'd need to handle that somehow too. The solution here is to generalize the game loop and factor out each function, instead of hardcoding it. Instead of having hardcoded case-switches directly in the loop, I made a function that returns an array of functions for a given gamestate, along with the number of functions, then the game loop processes it accordingly. In fixedloop(), it iterates over the array and executes each function until it reaches a delta function, at which point it stops. And when it reaches the end of the array, it goes back to the start of the array. But anyway, if it gets to a delta function, it'll stop the loop and finish fixedloop(). Then deltaloop() will call the delta function. And then on the next frame, the function index will be incremented again, so fixedloop() will call the fixed functions again. Actually, the previous game loop was actually made up of one big loop, with a gamestate function loop nested inside it, flanked with code that ran at the start and end of the "big loop". This would be easy to handle with one loop (just include the beginning and end functions with the gamestate functions in the array), except that the gamestate functions could suddenly be swapped out with unfocused functions (the ones that run when you unfocus the window) at any time (well, on frame boundaries, since key.isActive only got checked once, guarding the entire "inner loop" - and I made sure that changing key.isActive wouldn't immediately apply, just like the previous game loop order) - so I had to add yet another layer of indirection, where the gamestate functions could immediately be swapped out with the unfocused functions (while still running the beginning and end code, because that was how the previous loop order worked, after all). This also fixes a regression that the game loop that #220 introduced had, where if the fixed functions switched the gamestate, the game would prematurely start rendering the gamestate function of the new gamestate in the deltaframes, which was a source of some deltaframe glitches. But fixing this is likely to just as well cause deltaframe glitches, so it'd be better to fix this along with fixing the loop order, and only have one round of QA to do in the end, instead of doing one round after each change separately. Fixes #464... but this isn't the end of the patchset. There are bugs that need to be fixed, and kludges that need to be reverted.
2020-11-07 01:08:22 +01:00
enum FuncType
{
Func_null,
Func_fixed,
Move key.Poll() calls to just before input funcs In order to re-remove the 1-frame input delay, we will have to poll input right after rendering a frame - in other words, just before an input function gets called. To do this, I've added a new function enum type - Func_input - that is the same as a fixed function, but before its function gets called, key.Poll() gets called. And all input functions have been updated to use this enum accordingly.
2021-03-15 10:56:46 +01:00
Func_input,
Generalize game loop order and fix it to what it was in 2.2 Okay, so the reason why all render functions were moved to the end of the frame in #220 is because it's simpler to call two fixed functions and then a delta function instead of one fixed function, then a delta function, and then another fixed function. This is because fixed functions need special handling inside deltaloop(), and you can't simply duplicate this handling after calling a delta function. Oh, and to make matters worse, it's not always fixed-delta-fixed, sometimes (like in MAPMODE and TELEPORTERMODE) it's delta-fixed-fixed, so we'd need to handle that somehow too. The solution here is to generalize the game loop and factor out each function, instead of hardcoding it. Instead of having hardcoded case-switches directly in the loop, I made a function that returns an array of functions for a given gamestate, along with the number of functions, then the game loop processes it accordingly. In fixedloop(), it iterates over the array and executes each function until it reaches a delta function, at which point it stops. And when it reaches the end of the array, it goes back to the start of the array. But anyway, if it gets to a delta function, it'll stop the loop and finish fixedloop(). Then deltaloop() will call the delta function. And then on the next frame, the function index will be incremented again, so fixedloop() will call the fixed functions again. Actually, the previous game loop was actually made up of one big loop, with a gamestate function loop nested inside it, flanked with code that ran at the start and end of the "big loop". This would be easy to handle with one loop (just include the beginning and end functions with the gamestate functions in the array), except that the gamestate functions could suddenly be swapped out with unfocused functions (the ones that run when you unfocus the window) at any time (well, on frame boundaries, since key.isActive only got checked once, guarding the entire "inner loop" - and I made sure that changing key.isActive wouldn't immediately apply, just like the previous game loop order) - so I had to add yet another layer of indirection, where the gamestate functions could immediately be swapped out with the unfocused functions (while still running the beginning and end code, because that was how the previous loop order worked, after all). This also fixes a regression that the game loop that #220 introduced had, where if the fixed functions switched the gamestate, the game would prematurely start rendering the gamestate function of the new gamestate in the deltaframes, which was a source of some deltaframe glitches. But fixing this is likely to just as well cause deltaframe glitches, so it'd be better to fix this along with fixing the loop order, and only have one round of QA to do in the end, instead of doing one round after each change separately. Fixes #464... but this isn't the end of the patchset. There are bugs that need to be fixed, and kludges that need to be reverted.
2020-11-07 01:08:22 +01:00
Func_delta
};
struct ImplFunc
{
enum FuncType type;
void (*func)(void);
};
static void runscript(void)
{
script.run();
}
static void teleportermodeinput(void)
{
if (game.useteleporter)
{
teleporterinput();
}
else
{
script.run();
gameinput();
}
}
/* Only gets used in EDITORMODE. I assume the compiler will optimize this away
* if this is a NO_CUSTOM_LEVELS or NO_EDITOR build
*/
static void flipmodeoff(void)
{
graphics.flipmode = false;
}
static void focused_begin(void);
static void focused_end(void);
static const inline struct ImplFunc* get_gamestate_funcs(
const int gamestate,
int* num_implfuncs
) {
switch (gamestate)
{
#define FUNC_LIST_BEGIN(GAMESTATE) \
case GAMESTATE: \
{ \
static const struct ImplFunc implfuncs[] = { \
{Func_fixed, focused_begin},
#define FUNC_LIST_END \
{Func_fixed, focused_end} \
}; \
*num_implfuncs = SDL_arraysize(implfuncs); \
return implfuncs; \
}
FUNC_LIST_BEGIN(GAMEMODE)
Remove script.dontrunnextframe kludge Now that the game loop order is fixed, this kludge (on top of kludge) is no longer needed, and can be safely removed.
2020-11-08 01:49:32 +01:00
{Func_fixed, runscript},
Generalize game loop order and fix it to what it was in 2.2 Okay, so the reason why all render functions were moved to the end of the frame in #220 is because it's simpler to call two fixed functions and then a delta function instead of one fixed function, then a delta function, and then another fixed function. This is because fixed functions need special handling inside deltaloop(), and you can't simply duplicate this handling after calling a delta function. Oh, and to make matters worse, it's not always fixed-delta-fixed, sometimes (like in MAPMODE and TELEPORTERMODE) it's delta-fixed-fixed, so we'd need to handle that somehow too. The solution here is to generalize the game loop and factor out each function, instead of hardcoding it. Instead of having hardcoded case-switches directly in the loop, I made a function that returns an array of functions for a given gamestate, along with the number of functions, then the game loop processes it accordingly. In fixedloop(), it iterates over the array and executes each function until it reaches a delta function, at which point it stops. And when it reaches the end of the array, it goes back to the start of the array. But anyway, if it gets to a delta function, it'll stop the loop and finish fixedloop(). Then deltaloop() will call the delta function. And then on the next frame, the function index will be incremented again, so fixedloop() will call the fixed functions again. Actually, the previous game loop was actually made up of one big loop, with a gamestate function loop nested inside it, flanked with code that ran at the start and end of the "big loop". This would be easy to handle with one loop (just include the beginning and end functions with the gamestate functions in the array), except that the gamestate functions could suddenly be swapped out with unfocused functions (the ones that run when you unfocus the window) at any time (well, on frame boundaries, since key.isActive only got checked once, guarding the entire "inner loop" - and I made sure that changing key.isActive wouldn't immediately apply, just like the previous game loop order) - so I had to add yet another layer of indirection, where the gamestate functions could immediately be swapped out with the unfocused functions (while still running the beginning and end code, because that was how the previous loop order worked, after all). This also fixes a regression that the game loop that #220 introduced had, where if the fixed functions switched the gamestate, the game would prematurely start rendering the gamestate function of the new gamestate in the deltaframes, which was a source of some deltaframe glitches. But fixing this is likely to just as well cause deltaframe glitches, so it'd be better to fix this along with fixing the loop order, and only have one round of QA to do in the end, instead of doing one round after each change separately. Fixes #464... but this isn't the end of the patchset. There are bugs that need to be fixed, and kludges that need to be reverted.
2020-11-07 01:08:22 +01:00
{Func_fixed, gamerenderfixed},
{Func_delta, gamerender},
Re-remove 1-frame input delay To do this, GAMEMODE input needs to be processed, and Viridian needs to be moved, in the same sequence between render frames. So just move gameinput to after gamerender. Yes, this is not 2.2 order, but gameinput only handles player input and nothing else - plus a 1-frame input delay feels really awful to play with in over-30-mode.
2021-03-15 10:46:29 +01:00
{Func_input, gameinput},
Generalize game loop order and fix it to what it was in 2.2 Okay, so the reason why all render functions were moved to the end of the frame in #220 is because it's simpler to call two fixed functions and then a delta function instead of one fixed function, then a delta function, and then another fixed function. This is because fixed functions need special handling inside deltaloop(), and you can't simply duplicate this handling after calling a delta function. Oh, and to make matters worse, it's not always fixed-delta-fixed, sometimes (like in MAPMODE and TELEPORTERMODE) it's delta-fixed-fixed, so we'd need to handle that somehow too. The solution here is to generalize the game loop and factor out each function, instead of hardcoding it. Instead of having hardcoded case-switches directly in the loop, I made a function that returns an array of functions for a given gamestate, along with the number of functions, then the game loop processes it accordingly. In fixedloop(), it iterates over the array and executes each function until it reaches a delta function, at which point it stops. And when it reaches the end of the array, it goes back to the start of the array. But anyway, if it gets to a delta function, it'll stop the loop and finish fixedloop(). Then deltaloop() will call the delta function. And then on the next frame, the function index will be incremented again, so fixedloop() will call the fixed functions again. Actually, the previous game loop was actually made up of one big loop, with a gamestate function loop nested inside it, flanked with code that ran at the start and end of the "big loop". This would be easy to handle with one loop (just include the beginning and end functions with the gamestate functions in the array), except that the gamestate functions could suddenly be swapped out with unfocused functions (the ones that run when you unfocus the window) at any time (well, on frame boundaries, since key.isActive only got checked once, guarding the entire "inner loop" - and I made sure that changing key.isActive wouldn't immediately apply, just like the previous game loop order) - so I had to add yet another layer of indirection, where the gamestate functions could immediately be swapped out with the unfocused functions (while still running the beginning and end code, because that was how the previous loop order worked, after all). This also fixes a regression that the game loop that #220 introduced had, where if the fixed functions switched the gamestate, the game would prematurely start rendering the gamestate function of the new gamestate in the deltaframes, which was a source of some deltaframe glitches. But fixing this is likely to just as well cause deltaframe glitches, so it'd be better to fix this along with fixing the loop order, and only have one round of QA to do in the end, instead of doing one round after each change separately. Fixes #464... but this isn't the end of the patchset. There are bugs that need to be fixed, and kludges that need to be reverted.
2020-11-07 01:08:22 +01:00
{Func_fixed, gamelogic},
FUNC_LIST_END
FUNC_LIST_BEGIN(TITLEMODE)
Move key.Poll() calls to just before input funcs In order to re-remove the 1-frame input delay, we will have to poll input right after rendering a frame - in other words, just before an input function gets called. To do this, I've added a new function enum type - Func_input - that is the same as a fixed function, but before its function gets called, key.Poll() gets called. And all input functions have been updated to use this enum accordingly.
2021-03-15 10:56:46 +01:00
{Func_input, titleinput},
Generalize game loop order and fix it to what it was in 2.2 Okay, so the reason why all render functions were moved to the end of the frame in #220 is because it's simpler to call two fixed functions and then a delta function instead of one fixed function, then a delta function, and then another fixed function. This is because fixed functions need special handling inside deltaloop(), and you can't simply duplicate this handling after calling a delta function. Oh, and to make matters worse, it's not always fixed-delta-fixed, sometimes (like in MAPMODE and TELEPORTERMODE) it's delta-fixed-fixed, so we'd need to handle that somehow too. The solution here is to generalize the game loop and factor out each function, instead of hardcoding it. Instead of having hardcoded case-switches directly in the loop, I made a function that returns an array of functions for a given gamestate, along with the number of functions, then the game loop processes it accordingly. In fixedloop(), it iterates over the array and executes each function until it reaches a delta function, at which point it stops. And when it reaches the end of the array, it goes back to the start of the array. But anyway, if it gets to a delta function, it'll stop the loop and finish fixedloop(). Then deltaloop() will call the delta function. And then on the next frame, the function index will be incremented again, so fixedloop() will call the fixed functions again. Actually, the previous game loop was actually made up of one big loop, with a gamestate function loop nested inside it, flanked with code that ran at the start and end of the "big loop". This would be easy to handle with one loop (just include the beginning and end functions with the gamestate functions in the array), except that the gamestate functions could suddenly be swapped out with unfocused functions (the ones that run when you unfocus the window) at any time (well, on frame boundaries, since key.isActive only got checked once, guarding the entire "inner loop" - and I made sure that changing key.isActive wouldn't immediately apply, just like the previous game loop order) - so I had to add yet another layer of indirection, where the gamestate functions could immediately be swapped out with the unfocused functions (while still running the beginning and end code, because that was how the previous loop order worked, after all). This also fixes a regression that the game loop that #220 introduced had, where if the fixed functions switched the gamestate, the game would prematurely start rendering the gamestate function of the new gamestate in the deltaframes, which was a source of some deltaframe glitches. But fixing this is likely to just as well cause deltaframe glitches, so it'd be better to fix this along with fixing the loop order, and only have one round of QA to do in the end, instead of doing one round after each change separately. Fixes #464... but this isn't the end of the patchset. There are bugs that need to be fixed, and kludges that need to be reverted.
2020-11-07 01:08:22 +01:00
{Func_fixed, titlerenderfixed},
{Func_delta, titlerender},
{Func_fixed, titlelogic},
FUNC_LIST_END
FUNC_LIST_BEGIN(MAPMODE)
{Func_fixed, maprenderfixed},
{Func_delta, maprender},
Move key.Poll() calls to just before input funcs In order to re-remove the 1-frame input delay, we will have to poll input right after rendering a frame - in other words, just before an input function gets called. To do this, I've added a new function enum type - Func_input - that is the same as a fixed function, but before its function gets called, key.Poll() gets called. And all input functions have been updated to use this enum accordingly.
2021-03-15 10:56:46 +01:00
{Func_input, mapinput},
Generalize game loop order and fix it to what it was in 2.2 Okay, so the reason why all render functions were moved to the end of the frame in #220 is because it's simpler to call two fixed functions and then a delta function instead of one fixed function, then a delta function, and then another fixed function. This is because fixed functions need special handling inside deltaloop(), and you can't simply duplicate this handling after calling a delta function. Oh, and to make matters worse, it's not always fixed-delta-fixed, sometimes (like in MAPMODE and TELEPORTERMODE) it's delta-fixed-fixed, so we'd need to handle that somehow too. The solution here is to generalize the game loop and factor out each function, instead of hardcoding it. Instead of having hardcoded case-switches directly in the loop, I made a function that returns an array of functions for a given gamestate, along with the number of functions, then the game loop processes it accordingly. In fixedloop(), it iterates over the array and executes each function until it reaches a delta function, at which point it stops. And when it reaches the end of the array, it goes back to the start of the array. But anyway, if it gets to a delta function, it'll stop the loop and finish fixedloop(). Then deltaloop() will call the delta function. And then on the next frame, the function index will be incremented again, so fixedloop() will call the fixed functions again. Actually, the previous game loop was actually made up of one big loop, with a gamestate function loop nested inside it, flanked with code that ran at the start and end of the "big loop". This would be easy to handle with one loop (just include the beginning and end functions with the gamestate functions in the array), except that the gamestate functions could suddenly be swapped out with unfocused functions (the ones that run when you unfocus the window) at any time (well, on frame boundaries, since key.isActive only got checked once, guarding the entire "inner loop" - and I made sure that changing key.isActive wouldn't immediately apply, just like the previous game loop order) - so I had to add yet another layer of indirection, where the gamestate functions could immediately be swapped out with the unfocused functions (while still running the beginning and end code, because that was how the previous loop order worked, after all). This also fixes a regression that the game loop that #220 introduced had, where if the fixed functions switched the gamestate, the game would prematurely start rendering the gamestate function of the new gamestate in the deltaframes, which was a source of some deltaframe glitches. But fixing this is likely to just as well cause deltaframe glitches, so it'd be better to fix this along with fixing the loop order, and only have one round of QA to do in the end, instead of doing one round after each change separately. Fixes #464... but this isn't the end of the patchset. There are bugs that need to be fixed, and kludges that need to be reverted.
2020-11-07 01:08:22 +01:00
{Func_fixed, maplogic},
FUNC_LIST_END
FUNC_LIST_BEGIN(TELEPORTERMODE)
Call teleporterrenderfixed in TELEPORTERMODE This restores it to 2.2 behavior, where the cutscene bars timer also ticked in TELEPORTERMODE. It was a 2.3 regression that the cutscene bars timer didn't tick there. This makes it so if you manage to get stuck in TELEPORTERMODE when a cutscene ends, the cutscene won't be stuck on untilbars() waiting for the cutscene bars to go away, since the cutscene bars timer now ticks.
2021-09-02 20:46:56 +02:00
{Func_fixed, teleporterrenderfixed},
Generalize game loop order and fix it to what it was in 2.2 Okay, so the reason why all render functions were moved to the end of the frame in #220 is because it's simpler to call two fixed functions and then a delta function instead of one fixed function, then a delta function, and then another fixed function. This is because fixed functions need special handling inside deltaloop(), and you can't simply duplicate this handling after calling a delta function. Oh, and to make matters worse, it's not always fixed-delta-fixed, sometimes (like in MAPMODE and TELEPORTERMODE) it's delta-fixed-fixed, so we'd need to handle that somehow too. The solution here is to generalize the game loop and factor out each function, instead of hardcoding it. Instead of having hardcoded case-switches directly in the loop, I made a function that returns an array of functions for a given gamestate, along with the number of functions, then the game loop processes it accordingly. In fixedloop(), it iterates over the array and executes each function until it reaches a delta function, at which point it stops. And when it reaches the end of the array, it goes back to the start of the array. But anyway, if it gets to a delta function, it'll stop the loop and finish fixedloop(). Then deltaloop() will call the delta function. And then on the next frame, the function index will be incremented again, so fixedloop() will call the fixed functions again. Actually, the previous game loop was actually made up of one big loop, with a gamestate function loop nested inside it, flanked with code that ran at the start and end of the "big loop". This would be easy to handle with one loop (just include the beginning and end functions with the gamestate functions in the array), except that the gamestate functions could suddenly be swapped out with unfocused functions (the ones that run when you unfocus the window) at any time (well, on frame boundaries, since key.isActive only got checked once, guarding the entire "inner loop" - and I made sure that changing key.isActive wouldn't immediately apply, just like the previous game loop order) - so I had to add yet another layer of indirection, where the gamestate functions could immediately be swapped out with the unfocused functions (while still running the beginning and end code, because that was how the previous loop order worked, after all). This also fixes a regression that the game loop that #220 introduced had, where if the fixed functions switched the gamestate, the game would prematurely start rendering the gamestate function of the new gamestate in the deltaframes, which was a source of some deltaframe glitches. But fixing this is likely to just as well cause deltaframe glitches, so it'd be better to fix this along with fixing the loop order, and only have one round of QA to do in the end, instead of doing one round after each change separately. Fixes #464... but this isn't the end of the patchset. There are bugs that need to be fixed, and kludges that need to be reverted.
2020-11-07 01:08:22 +01:00
{Func_delta, teleporterrender},
Move key.Poll() calls to just before input funcs In order to re-remove the 1-frame input delay, we will have to poll input right after rendering a frame - in other words, just before an input function gets called. To do this, I've added a new function enum type - Func_input - that is the same as a fixed function, but before its function gets called, key.Poll() gets called. And all input functions have been updated to use this enum accordingly.
2021-03-15 10:56:46 +01:00
{Func_input, teleportermodeinput},
Generalize game loop order and fix it to what it was in 2.2 Okay, so the reason why all render functions were moved to the end of the frame in #220 is because it's simpler to call two fixed functions and then a delta function instead of one fixed function, then a delta function, and then another fixed function. This is because fixed functions need special handling inside deltaloop(), and you can't simply duplicate this handling after calling a delta function. Oh, and to make matters worse, it's not always fixed-delta-fixed, sometimes (like in MAPMODE and TELEPORTERMODE) it's delta-fixed-fixed, so we'd need to handle that somehow too. The solution here is to generalize the game loop and factor out each function, instead of hardcoding it. Instead of having hardcoded case-switches directly in the loop, I made a function that returns an array of functions for a given gamestate, along with the number of functions, then the game loop processes it accordingly. In fixedloop(), it iterates over the array and executes each function until it reaches a delta function, at which point it stops. And when it reaches the end of the array, it goes back to the start of the array. But anyway, if it gets to a delta function, it'll stop the loop and finish fixedloop(). Then deltaloop() will call the delta function. And then on the next frame, the function index will be incremented again, so fixedloop() will call the fixed functions again. Actually, the previous game loop was actually made up of one big loop, with a gamestate function loop nested inside it, flanked with code that ran at the start and end of the "big loop". This would be easy to handle with one loop (just include the beginning and end functions with the gamestate functions in the array), except that the gamestate functions could suddenly be swapped out with unfocused functions (the ones that run when you unfocus the window) at any time (well, on frame boundaries, since key.isActive only got checked once, guarding the entire "inner loop" - and I made sure that changing key.isActive wouldn't immediately apply, just like the previous game loop order) - so I had to add yet another layer of indirection, where the gamestate functions could immediately be swapped out with the unfocused functions (while still running the beginning and end code, because that was how the previous loop order worked, after all). This also fixes a regression that the game loop that #220 introduced had, where if the fixed functions switched the gamestate, the game would prematurely start rendering the gamestate function of the new gamestate in the deltaframes, which was a source of some deltaframe glitches. But fixing this is likely to just as well cause deltaframe glitches, so it'd be better to fix this along with fixing the loop order, and only have one round of QA to do in the end, instead of doing one round after each change separately. Fixes #464... but this isn't the end of the patchset. There are bugs that need to be fixed, and kludges that need to be reverted.
2020-11-07 01:08:22 +01:00
{Func_fixed, maplogic},
FUNC_LIST_END
FUNC_LIST_BEGIN(GAMECOMPLETE)
{Func_fixed, gamecompleterenderfixed},
{Func_delta, gamecompleterender},
Move key.Poll() calls to just before input funcs In order to re-remove the 1-frame input delay, we will have to poll input right after rendering a frame - in other words, just before an input function gets called. To do this, I've added a new function enum type - Func_input - that is the same as a fixed function, but before its function gets called, key.Poll() gets called. And all input functions have been updated to use this enum accordingly.
2021-03-15 10:56:46 +01:00
{Func_input, gamecompleteinput},
Generalize game loop order and fix it to what it was in 2.2 Okay, so the reason why all render functions were moved to the end of the frame in #220 is because it's simpler to call two fixed functions and then a delta function instead of one fixed function, then a delta function, and then another fixed function. This is because fixed functions need special handling inside deltaloop(), and you can't simply duplicate this handling after calling a delta function. Oh, and to make matters worse, it's not always fixed-delta-fixed, sometimes (like in MAPMODE and TELEPORTERMODE) it's delta-fixed-fixed, so we'd need to handle that somehow too. The solution here is to generalize the game loop and factor out each function, instead of hardcoding it. Instead of having hardcoded case-switches directly in the loop, I made a function that returns an array of functions for a given gamestate, along with the number of functions, then the game loop processes it accordingly. In fixedloop(), it iterates over the array and executes each function until it reaches a delta function, at which point it stops. And when it reaches the end of the array, it goes back to the start of the array. But anyway, if it gets to a delta function, it'll stop the loop and finish fixedloop(). Then deltaloop() will call the delta function. And then on the next frame, the function index will be incremented again, so fixedloop() will call the fixed functions again. Actually, the previous game loop was actually made up of one big loop, with a gamestate function loop nested inside it, flanked with code that ran at the start and end of the "big loop". This would be easy to handle with one loop (just include the beginning and end functions with the gamestate functions in the array), except that the gamestate functions could suddenly be swapped out with unfocused functions (the ones that run when you unfocus the window) at any time (well, on frame boundaries, since key.isActive only got checked once, guarding the entire "inner loop" - and I made sure that changing key.isActive wouldn't immediately apply, just like the previous game loop order) - so I had to add yet another layer of indirection, where the gamestate functions could immediately be swapped out with the unfocused functions (while still running the beginning and end code, because that was how the previous loop order worked, after all). This also fixes a regression that the game loop that #220 introduced had, where if the fixed functions switched the gamestate, the game would prematurely start rendering the gamestate function of the new gamestate in the deltaframes, which was a source of some deltaframe glitches. But fixing this is likely to just as well cause deltaframe glitches, so it'd be better to fix this along with fixing the loop order, and only have one round of QA to do in the end, instead of doing one round after each change separately. Fixes #464... but this isn't the end of the patchset. There are bugs that need to be fixed, and kludges that need to be reverted.
2020-11-07 01:08:22 +01:00
{Func_fixed, gamecompletelogic},
FUNC_LIST_END
FUNC_LIST_BEGIN(GAMECOMPLETE2)
{Func_delta, gamecompleterender2},
Move key.Poll() calls to just before input funcs In order to re-remove the 1-frame input delay, we will have to poll input right after rendering a frame - in other words, just before an input function gets called. To do this, I've added a new function enum type - Func_input - that is the same as a fixed function, but before its function gets called, key.Poll() gets called. And all input functions have been updated to use this enum accordingly.
2021-03-15 10:56:46 +01:00
{Func_input, gamecompleteinput2},
Generalize game loop order and fix it to what it was in 2.2 Okay, so the reason why all render functions were moved to the end of the frame in #220 is because it's simpler to call two fixed functions and then a delta function instead of one fixed function, then a delta function, and then another fixed function. This is because fixed functions need special handling inside deltaloop(), and you can't simply duplicate this handling after calling a delta function. Oh, and to make matters worse, it's not always fixed-delta-fixed, sometimes (like in MAPMODE and TELEPORTERMODE) it's delta-fixed-fixed, so we'd need to handle that somehow too. The solution here is to generalize the game loop and factor out each function, instead of hardcoding it. Instead of having hardcoded case-switches directly in the loop, I made a function that returns an array of functions for a given gamestate, along with the number of functions, then the game loop processes it accordingly. In fixedloop(), it iterates over the array and executes each function until it reaches a delta function, at which point it stops. And when it reaches the end of the array, it goes back to the start of the array. But anyway, if it gets to a delta function, it'll stop the loop and finish fixedloop(). Then deltaloop() will call the delta function. And then on the next frame, the function index will be incremented again, so fixedloop() will call the fixed functions again. Actually, the previous game loop was actually made up of one big loop, with a gamestate function loop nested inside it, flanked with code that ran at the start and end of the "big loop". This would be easy to handle with one loop (just include the beginning and end functions with the gamestate functions in the array), except that the gamestate functions could suddenly be swapped out with unfocused functions (the ones that run when you unfocus the window) at any time (well, on frame boundaries, since key.isActive only got checked once, guarding the entire "inner loop" - and I made sure that changing key.isActive wouldn't immediately apply, just like the previous game loop order) - so I had to add yet another layer of indirection, where the gamestate functions could immediately be swapped out with the unfocused functions (while still running the beginning and end code, because that was how the previous loop order worked, after all). This also fixes a regression that the game loop that #220 introduced had, where if the fixed functions switched the gamestate, the game would prematurely start rendering the gamestate function of the new gamestate in the deltaframes, which was a source of some deltaframe glitches. But fixing this is likely to just as well cause deltaframe glitches, so it'd be better to fix this along with fixing the loop order, and only have one round of QA to do in the end, instead of doing one round after each change separately. Fixes #464... but this isn't the end of the patchset. There are bugs that need to be fixed, and kludges that need to be reverted.
2020-11-07 01:08:22 +01:00
{Func_fixed, gamecompletelogic2},
FUNC_LIST_END
Silence various warnings in builds removing content The MAKEANDPLAY, NO_CUSTOM_LEVELS, and NO_EDITOR defines remove content or features. However, they then raise several warnings because of some cases, functions, or variables that end up not being used. This silences them by using the UNUSED macro, or by adding a default catch-all case if the define is defined (so unhandled cases will still raise warnings in a build that doesn't have these defines).
2023-02-04 09:14:04 +01:00
#if defined(NO_CUSTOM_LEVELS) || defined(NO_EDITOR)
UNUSED(flipmodeoff);
#else
Generalize game loop order and fix it to what it was in 2.2 Okay, so the reason why all render functions were moved to the end of the frame in #220 is because it's simpler to call two fixed functions and then a delta function instead of one fixed function, then a delta function, and then another fixed function. This is because fixed functions need special handling inside deltaloop(), and you can't simply duplicate this handling after calling a delta function. Oh, and to make matters worse, it's not always fixed-delta-fixed, sometimes (like in MAPMODE and TELEPORTERMODE) it's delta-fixed-fixed, so we'd need to handle that somehow too. The solution here is to generalize the game loop and factor out each function, instead of hardcoding it. Instead of having hardcoded case-switches directly in the loop, I made a function that returns an array of functions for a given gamestate, along with the number of functions, then the game loop processes it accordingly. In fixedloop(), it iterates over the array and executes each function until it reaches a delta function, at which point it stops. And when it reaches the end of the array, it goes back to the start of the array. But anyway, if it gets to a delta function, it'll stop the loop and finish fixedloop(). Then deltaloop() will call the delta function. And then on the next frame, the function index will be incremented again, so fixedloop() will call the fixed functions again. Actually, the previous game loop was actually made up of one big loop, with a gamestate function loop nested inside it, flanked with code that ran at the start and end of the "big loop". This would be easy to handle with one loop (just include the beginning and end functions with the gamestate functions in the array), except that the gamestate functions could suddenly be swapped out with unfocused functions (the ones that run when you unfocus the window) at any time (well, on frame boundaries, since key.isActive only got checked once, guarding the entire "inner loop" - and I made sure that changing key.isActive wouldn't immediately apply, just like the previous game loop order) - so I had to add yet another layer of indirection, where the gamestate functions could immediately be swapped out with the unfocused functions (while still running the beginning and end code, because that was how the previous loop order worked, after all). This also fixes a regression that the game loop that #220 introduced had, where if the fixed functions switched the gamestate, the game would prematurely start rendering the gamestate function of the new gamestate in the deltaframes, which was a source of some deltaframe glitches. But fixing this is likely to just as well cause deltaframe glitches, so it'd be better to fix this along with fixing the loop order, and only have one round of QA to do in the end, instead of doing one round after each change separately. Fixes #464... but this isn't the end of the patchset. There are bugs that need to be fixed, and kludges that need to be reverted.
2020-11-07 01:08:22 +01:00
FUNC_LIST_BEGIN(EDITORMODE)
{Func_fixed, flipmodeoff},
Move key.Poll() calls to just before input funcs In order to re-remove the 1-frame input delay, we will have to poll input right after rendering a frame - in other words, just before an input function gets called. To do this, I've added a new function enum type - Func_input - that is the same as a fixed function, but before its function gets called, key.Poll() gets called. And all input functions have been updated to use this enum accordingly.
2021-03-15 10:56:46 +01:00
{Func_input, editorinput},
Fix gravity/warp lines being modified during draw While warp lines were being drawn, they also got resized to automatically fit between collision. In renderfixed, gravity lines are resized the same way. Doing logic while drawing is very poor practice, so resizing of these has been moved into logic, and merged together. Aside from some more cleanup, this commit also removes the very poorly done right click emulation, when you hold CTRL and click. It never worked well in the past, and even requires a right click to use, so there's not really any point to keeping it around.
2023-03-02 21:28:02 +01:00
{Func_fixed, editorlogic},
Generalize game loop order and fix it to what it was in 2.2 Okay, so the reason why all render functions were moved to the end of the frame in #220 is because it's simpler to call two fixed functions and then a delta function instead of one fixed function, then a delta function, and then another fixed function. This is because fixed functions need special handling inside deltaloop(), and you can't simply duplicate this handling after calling a delta function. Oh, and to make matters worse, it's not always fixed-delta-fixed, sometimes (like in MAPMODE and TELEPORTERMODE) it's delta-fixed-fixed, so we'd need to handle that somehow too. The solution here is to generalize the game loop and factor out each function, instead of hardcoding it. Instead of having hardcoded case-switches directly in the loop, I made a function that returns an array of functions for a given gamestate, along with the number of functions, then the game loop processes it accordingly. In fixedloop(), it iterates over the array and executes each function until it reaches a delta function, at which point it stops. And when it reaches the end of the array, it goes back to the start of the array. But anyway, if it gets to a delta function, it'll stop the loop and finish fixedloop(). Then deltaloop() will call the delta function. And then on the next frame, the function index will be incremented again, so fixedloop() will call the fixed functions again. Actually, the previous game loop was actually made up of one big loop, with a gamestate function loop nested inside it, flanked with code that ran at the start and end of the "big loop". This would be easy to handle with one loop (just include the beginning and end functions with the gamestate functions in the array), except that the gamestate functions could suddenly be swapped out with unfocused functions (the ones that run when you unfocus the window) at any time (well, on frame boundaries, since key.isActive only got checked once, guarding the entire "inner loop" - and I made sure that changing key.isActive wouldn't immediately apply, just like the previous game loop order) - so I had to add yet another layer of indirection, where the gamestate functions could immediately be swapped out with the unfocused functions (while still running the beginning and end code, because that was how the previous loop order worked, after all). This also fixes a regression that the game loop that #220 introduced had, where if the fixed functions switched the gamestate, the game would prematurely start rendering the gamestate function of the new gamestate in the deltaframes, which was a source of some deltaframe glitches. But fixing this is likely to just as well cause deltaframe glitches, so it'd be better to fix this along with fixing the loop order, and only have one round of QA to do in the end, instead of doing one round after each change separately. Fixes #464... but this isn't the end of the patchset. There are bugs that need to be fixed, and kludges that need to be reverted.
2020-11-07 01:08:22 +01:00
{Func_fixed, editorrenderfixed},
{Func_delta, editorrender},
FUNC_LIST_END
#endif
FUNC_LIST_BEGIN(PRELOADER)
Move key.Poll() calls to just before input funcs In order to re-remove the 1-frame input delay, we will have to poll input right after rendering a frame - in other words, just before an input function gets called. To do this, I've added a new function enum type - Func_input - that is the same as a fixed function, but before its function gets called, key.Poll() gets called. And all input functions have been updated to use this enum accordingly.
2021-03-15 10:56:46 +01:00
{Func_input, preloaderinput},
Generalize game loop order and fix it to what it was in 2.2 Okay, so the reason why all render functions were moved to the end of the frame in #220 is because it's simpler to call two fixed functions and then a delta function instead of one fixed function, then a delta function, and then another fixed function. This is because fixed functions need special handling inside deltaloop(), and you can't simply duplicate this handling after calling a delta function. Oh, and to make matters worse, it's not always fixed-delta-fixed, sometimes (like in MAPMODE and TELEPORTERMODE) it's delta-fixed-fixed, so we'd need to handle that somehow too. The solution here is to generalize the game loop and factor out each function, instead of hardcoding it. Instead of having hardcoded case-switches directly in the loop, I made a function that returns an array of functions for a given gamestate, along with the number of functions, then the game loop processes it accordingly. In fixedloop(), it iterates over the array and executes each function until it reaches a delta function, at which point it stops. And when it reaches the end of the array, it goes back to the start of the array. But anyway, if it gets to a delta function, it'll stop the loop and finish fixedloop(). Then deltaloop() will call the delta function. And then on the next frame, the function index will be incremented again, so fixedloop() will call the fixed functions again. Actually, the previous game loop was actually made up of one big loop, with a gamestate function loop nested inside it, flanked with code that ran at the start and end of the "big loop". This would be easy to handle with one loop (just include the beginning and end functions with the gamestate functions in the array), except that the gamestate functions could suddenly be swapped out with unfocused functions (the ones that run when you unfocus the window) at any time (well, on frame boundaries, since key.isActive only got checked once, guarding the entire "inner loop" - and I made sure that changing key.isActive wouldn't immediately apply, just like the previous game loop order) - so I had to add yet another layer of indirection, where the gamestate functions could immediately be swapped out with the unfocused functions (while still running the beginning and end code, because that was how the previous loop order worked, after all). This also fixes a regression that the game loop that #220 introduced had, where if the fixed functions switched the gamestate, the game would prematurely start rendering the gamestate function of the new gamestate in the deltaframes, which was a source of some deltaframe glitches. But fixing this is likely to just as well cause deltaframe glitches, so it'd be better to fix this along with fixing the loop order, and only have one round of QA to do in the end, instead of doing one round after each change separately. Fixes #464... but this isn't the end of the patchset. There are bugs that need to be fixed, and kludges that need to be reverted.
2020-11-07 01:08:22 +01:00
{Func_fixed, preloaderrenderfixed},
{Func_delta, preloaderrender},
FUNC_LIST_END
#undef FUNC_LIST_END
#undef FUNC_LIST_BEGIN
}
SDL_assert(0 && "Invalid gamestate!");
return NULL;
}
enum IndexCode
{
Index_none,
Index_end
};
static const struct ImplFunc* gamestate_funcs = NULL;
static int num_gamestate_funcs = 0;
static int gamestate_func_index = -1;
static enum IndexCode increment_gamestate_func_index(void)
{
gamestate_func_index++;
if (gamestate_func_index == num_gamestate_funcs)
{
/* Reached the end of current gamestate order.
* Re-fetch for new order if gamestate changed.
*/
gamestate_funcs = get_gamestate_funcs(
game.gamestate,
&num_gamestate_funcs
);
Add deferred callbacks to game loop Sometimes, there needs to be code that gets ran at the end of the game loop, otherwise rendering issues might occur. Currently, we do this by special-casing each deferred routine (e.g. shouldreturntoeditor), but it would be better if we could generalize this deference instead. Deferred callbacks can be added using the DEFER_CALLBACK macro. It takes in one argument, which is the name of a function, and that function must be a void function that takes in no arguments. Also, due to annoying C++ quirks, void functions taking no arguments cannot be attributes of objects (because they have an implicit `this` parameter), so it's recommended to create each callback separately before using the DEFER_CALLBACK macro.
2020-12-24 08:24:31 +01:00
/* Also run callbacks that were deferred to end of func sequence. */
DEFER_execute_callbacks();
Generalize game loop order and fix it to what it was in 2.2 Okay, so the reason why all render functions were moved to the end of the frame in #220 is because it's simpler to call two fixed functions and then a delta function instead of one fixed function, then a delta function, and then another fixed function. This is because fixed functions need special handling inside deltaloop(), and you can't simply duplicate this handling after calling a delta function. Oh, and to make matters worse, it's not always fixed-delta-fixed, sometimes (like in MAPMODE and TELEPORTERMODE) it's delta-fixed-fixed, so we'd need to handle that somehow too. The solution here is to generalize the game loop and factor out each function, instead of hardcoding it. Instead of having hardcoded case-switches directly in the loop, I made a function that returns an array of functions for a given gamestate, along with the number of functions, then the game loop processes it accordingly. In fixedloop(), it iterates over the array and executes each function until it reaches a delta function, at which point it stops. And when it reaches the end of the array, it goes back to the start of the array. But anyway, if it gets to a delta function, it'll stop the loop and finish fixedloop(). Then deltaloop() will call the delta function. And then on the next frame, the function index will be incremented again, so fixedloop() will call the fixed functions again. Actually, the previous game loop was actually made up of one big loop, with a gamestate function loop nested inside it, flanked with code that ran at the start and end of the "big loop". This would be easy to handle with one loop (just include the beginning and end functions with the gamestate functions in the array), except that the gamestate functions could suddenly be swapped out with unfocused functions (the ones that run when you unfocus the window) at any time (well, on frame boundaries, since key.isActive only got checked once, guarding the entire "inner loop" - and I made sure that changing key.isActive wouldn't immediately apply, just like the previous game loop order) - so I had to add yet another layer of indirection, where the gamestate functions could immediately be swapped out with the unfocused functions (while still running the beginning and end code, because that was how the previous loop order worked, after all). This also fixes a regression that the game loop that #220 introduced had, where if the fixed functions switched the gamestate, the game would prematurely start rendering the gamestate function of the new gamestate in the deltaframes, which was a source of some deltaframe glitches. But fixing this is likely to just as well cause deltaframe glitches, so it'd be better to fix this along with fixing the loop order, and only have one round of QA to do in the end, instead of doing one round after each change separately. Fixes #464... but this isn't the end of the patchset. There are bugs that need to be fixed, and kludges that need to be reverted.
2020-11-07 01:08:22 +01:00
gamestate_func_index = 0;
return Index_end;
}
return Index_none;
}
static void unfocused_run(void);
static const struct ImplFunc unfocused_func_list[] = {
Add braces around sub-object in unfocused_func_list Clang warns on this. This doesn't fix anything but it does ensure that whoever's reading it won't be focused as to whether or not omitting the second set of braces is legal or not.
2021-03-21 21:53:29 +01:00
{
Func_input, /* we still need polling when unfocused */
Split Func_input and Func_delta when unfocused Without this, `fixedloop` will loop infinitely until focus is regained. However, Emscripten won't actually know that focus is regained until `fixedloop` returns.
2021-09-07 17:45:45 +02:00
NULL
},
{
Func_delta,
Add braces around sub-object in unfocused_func_list Clang warns on this. This doesn't fix anything but it does ensure that whoever's reading it won't be focused as to whether or not omitting the second set of braces is legal or not.
2021-03-21 21:53:29 +01:00
unfocused_run
}
Generalize game loop order and fix it to what it was in 2.2 Okay, so the reason why all render functions were moved to the end of the frame in #220 is because it's simpler to call two fixed functions and then a delta function instead of one fixed function, then a delta function, and then another fixed function. This is because fixed functions need special handling inside deltaloop(), and you can't simply duplicate this handling after calling a delta function. Oh, and to make matters worse, it's not always fixed-delta-fixed, sometimes (like in MAPMODE and TELEPORTERMODE) it's delta-fixed-fixed, so we'd need to handle that somehow too. The solution here is to generalize the game loop and factor out each function, instead of hardcoding it. Instead of having hardcoded case-switches directly in the loop, I made a function that returns an array of functions for a given gamestate, along with the number of functions, then the game loop processes it accordingly. In fixedloop(), it iterates over the array and executes each function until it reaches a delta function, at which point it stops. And when it reaches the end of the array, it goes back to the start of the array. But anyway, if it gets to a delta function, it'll stop the loop and finish fixedloop(). Then deltaloop() will call the delta function. And then on the next frame, the function index will be incremented again, so fixedloop() will call the fixed functions again. Actually, the previous game loop was actually made up of one big loop, with a gamestate function loop nested inside it, flanked with code that ran at the start and end of the "big loop". This would be easy to handle with one loop (just include the beginning and end functions with the gamestate functions in the array), except that the gamestate functions could suddenly be swapped out with unfocused functions (the ones that run when you unfocus the window) at any time (well, on frame boundaries, since key.isActive only got checked once, guarding the entire "inner loop" - and I made sure that changing key.isActive wouldn't immediately apply, just like the previous game loop order) - so I had to add yet another layer of indirection, where the gamestate functions could immediately be swapped out with the unfocused functions (while still running the beginning and end code, because that was how the previous loop order worked, after all). This also fixes a regression that the game loop that #220 introduced had, where if the fixed functions switched the gamestate, the game would prematurely start rendering the gamestate function of the new gamestate in the deltaframes, which was a source of some deltaframe glitches. But fixing this is likely to just as well cause deltaframe glitches, so it'd be better to fix this along with fixing the loop order, and only have one round of QA to do in the end, instead of doing one round after each change separately. Fixes #464... but this isn't the end of the patchset. There are bugs that need to be fixed, and kludges that need to be reverted.
2020-11-07 01:08:22 +01:00
};
static const struct ImplFunc* unfocused_funcs = unfocused_func_list;
static int num_unfocused_funcs = SDL_arraysize(unfocused_func_list);
Fix a crash on first unfocus
2021-03-21 22:19:08 +01:00
static int unfocused_func_index = 0; // This does not get incremented on start, do NOT use -1!
Generalize game loop order and fix it to what it was in 2.2 Okay, so the reason why all render functions were moved to the end of the frame in #220 is because it's simpler to call two fixed functions and then a delta function instead of one fixed function, then a delta function, and then another fixed function. This is because fixed functions need special handling inside deltaloop(), and you can't simply duplicate this handling after calling a delta function. Oh, and to make matters worse, it's not always fixed-delta-fixed, sometimes (like in MAPMODE and TELEPORTERMODE) it's delta-fixed-fixed, so we'd need to handle that somehow too. The solution here is to generalize the game loop and factor out each function, instead of hardcoding it. Instead of having hardcoded case-switches directly in the loop, I made a function that returns an array of functions for a given gamestate, along with the number of functions, then the game loop processes it accordingly. In fixedloop(), it iterates over the array and executes each function until it reaches a delta function, at which point it stops. And when it reaches the end of the array, it goes back to the start of the array. But anyway, if it gets to a delta function, it'll stop the loop and finish fixedloop(). Then deltaloop() will call the delta function. And then on the next frame, the function index will be incremented again, so fixedloop() will call the fixed functions again. Actually, the previous game loop was actually made up of one big loop, with a gamestate function loop nested inside it, flanked with code that ran at the start and end of the "big loop". This would be easy to handle with one loop (just include the beginning and end functions with the gamestate functions in the array), except that the gamestate functions could suddenly be swapped out with unfocused functions (the ones that run when you unfocus the window) at any time (well, on frame boundaries, since key.isActive only got checked once, guarding the entire "inner loop" - and I made sure that changing key.isActive wouldn't immediately apply, just like the previous game loop order) - so I had to add yet another layer of indirection, where the gamestate functions could immediately be swapped out with the unfocused functions (while still running the beginning and end code, because that was how the previous loop order worked, after all). This also fixes a regression that the game loop that #220 introduced had, where if the fixed functions switched the gamestate, the game would prematurely start rendering the gamestate function of the new gamestate in the deltaframes, which was a source of some deltaframe glitches. But fixing this is likely to just as well cause deltaframe glitches, so it'd be better to fix this along with fixing the loop order, and only have one round of QA to do in the end, instead of doing one round after each change separately. Fixes #464... but this isn't the end of the patchset. There are bugs that need to be fixed, and kludges that need to be reverted.
2020-11-07 01:08:22 +01:00
static enum IndexCode increment_unfocused_func_index(void)
{
unfocused_func_index++;
if (unfocused_func_index == num_unfocused_funcs)
{
unfocused_func_index = 0;
return Index_end;
}
return Index_none;
}
static const struct ImplFunc** active_funcs = NULL;
static int* num_active_funcs = NULL;
static int* active_func_index = NULL;
static enum IndexCode (*increment_func_index)(void) = NULL;
enum LoopCode
{
Loop_continue,
Loop_stop
};
static enum LoopCode loop_assign_active_funcs(void)
{
if (key.isActive)
{
active_funcs = &gamestate_funcs;
num_active_funcs = &num_gamestate_funcs;
active_func_index = &gamestate_func_index;
increment_func_index = &increment_gamestate_func_index;
}
else
{
active_funcs = &unfocused_funcs;
num_active_funcs = &num_unfocused_funcs;
active_func_index = &unfocused_func_index;
increment_func_index = &increment_unfocused_func_index;
}
return Loop_continue;
}
static enum LoopCode loop_run_active_funcs(void)
{
while ((*active_funcs)[*active_func_index].type != Func_delta)
{
const struct ImplFunc* implfunc = &(*active_funcs)[*active_func_index];
enum IndexCode index_code;
Add option to re-enable 1-frame input delay This is an option for speedrunners whose muscle memory is precisely trained and used to the 1-frame input delay that existed in 2.2 and below. It is located in Game Options -> Advanced Options, and is off by default. To re-add the 1-frame input delay, we simply move the key.Poll() to the start of the frame, instead of before an input function gets ran - undoing what #535 did. There is a frame ordering-sensitive issue here, where toggling game.inputdelay at the wrong time could cause double-polling. However, we only toggle it in an input function, which regardless is always guaranteed to be ran after key.Poll() (it either happened at the start of the frame or just before the input function got ran), so this is not an issue. But, in case we ever need to toggle this variable in the future, we can just use the defer callbacks system to defer the toggle to the end of the frame - also added by #535. Added at the request of Habeechee on the VVVVVV speedrunning Discord server.
2021-04-02 00:39:56 +02:00
if (implfunc->type == Func_input && !game.inputdelay)
Move key.Poll() calls to just before input funcs In order to re-remove the 1-frame input delay, we will have to poll input right after rendering a frame - in other words, just before an input function gets called. To do this, I've added a new function enum type - Func_input - that is the same as a fixed function, but before its function gets called, key.Poll() gets called. And all input functions have been updated to use this enum accordingly.
2021-03-15 10:56:46 +01:00
{
key.Poll();
}
Generalize game loop order and fix it to what it was in 2.2 Okay, so the reason why all render functions were moved to the end of the frame in #220 is because it's simpler to call two fixed functions and then a delta function instead of one fixed function, then a delta function, and then another fixed function. This is because fixed functions need special handling inside deltaloop(), and you can't simply duplicate this handling after calling a delta function. Oh, and to make matters worse, it's not always fixed-delta-fixed, sometimes (like in MAPMODE and TELEPORTERMODE) it's delta-fixed-fixed, so we'd need to handle that somehow too. The solution here is to generalize the game loop and factor out each function, instead of hardcoding it. Instead of having hardcoded case-switches directly in the loop, I made a function that returns an array of functions for a given gamestate, along with the number of functions, then the game loop processes it accordingly. In fixedloop(), it iterates over the array and executes each function until it reaches a delta function, at which point it stops. And when it reaches the end of the array, it goes back to the start of the array. But anyway, if it gets to a delta function, it'll stop the loop and finish fixedloop(). Then deltaloop() will call the delta function. And then on the next frame, the function index will be incremented again, so fixedloop() will call the fixed functions again. Actually, the previous game loop was actually made up of one big loop, with a gamestate function loop nested inside it, flanked with code that ran at the start and end of the "big loop". This would be easy to handle with one loop (just include the beginning and end functions with the gamestate functions in the array), except that the gamestate functions could suddenly be swapped out with unfocused functions (the ones that run when you unfocus the window) at any time (well, on frame boundaries, since key.isActive only got checked once, guarding the entire "inner loop" - and I made sure that changing key.isActive wouldn't immediately apply, just like the previous game loop order) - so I had to add yet another layer of indirection, where the gamestate functions could immediately be swapped out with the unfocused functions (while still running the beginning and end code, because that was how the previous loop order worked, after all). This also fixes a regression that the game loop that #220 introduced had, where if the fixed functions switched the gamestate, the game would prematurely start rendering the gamestate function of the new gamestate in the deltaframes, which was a source of some deltaframe glitches. But fixing this is likely to just as well cause deltaframe glitches, so it'd be better to fix this along with fixing the loop order, and only have one round of QA to do in the end, instead of doing one round after each change separately. Fixes #464... but this isn't the end of the patchset. There are bugs that need to be fixed, and kludges that need to be reverted.
2020-11-07 01:08:22 +01:00
if (implfunc->type != Func_null && implfunc->func != NULL)
{
implfunc->func();
}
index_code = increment_func_index();
if (index_code == Index_end)
{
return Loop_continue;
}
}
Fix filter/screenshake/flash update order In 2.2, at render time, the game rendered screenshakes and flashes if their timers were above 0, and then decremented them afterwards. The game would also update the analogue filter right before rendering it, too. In 2.3, this was changed so the flash and screenshake timers were unified, and also done at the end of the frame - right before rendering happened. This resulted in 1-frame flashes and screenshakes not rendering at all. The other changes in this patchset don't fix this either. The analogue filter was also in the wrong order, but that is less of an issue than flashes and screenshakes. So, what I've done is made the flash and screenshake timers update right before the loop switches over to rendering, and only decrements them when we switch back to fixed functions (after rendering). The analogue filter is also updated right before rendering as well. This restores 1-frame flashes and screenshakes, as well as restores the correct order of analogue filter updates.
2021-03-18 01:53:17 +01:00
/* About to switch over to rendering... but call this first. */
graphics.renderfixedpre();
Generalize game loop order and fix it to what it was in 2.2 Okay, so the reason why all render functions were moved to the end of the frame in #220 is because it's simpler to call two fixed functions and then a delta function instead of one fixed function, then a delta function, and then another fixed function. This is because fixed functions need special handling inside deltaloop(), and you can't simply duplicate this handling after calling a delta function. Oh, and to make matters worse, it's not always fixed-delta-fixed, sometimes (like in MAPMODE and TELEPORTERMODE) it's delta-fixed-fixed, so we'd need to handle that somehow too. The solution here is to generalize the game loop and factor out each function, instead of hardcoding it. Instead of having hardcoded case-switches directly in the loop, I made a function that returns an array of functions for a given gamestate, along with the number of functions, then the game loop processes it accordingly. In fixedloop(), it iterates over the array and executes each function until it reaches a delta function, at which point it stops. And when it reaches the end of the array, it goes back to the start of the array. But anyway, if it gets to a delta function, it'll stop the loop and finish fixedloop(). Then deltaloop() will call the delta function. And then on the next frame, the function index will be incremented again, so fixedloop() will call the fixed functions again. Actually, the previous game loop was actually made up of one big loop, with a gamestate function loop nested inside it, flanked with code that ran at the start and end of the "big loop". This would be easy to handle with one loop (just include the beginning and end functions with the gamestate functions in the array), except that the gamestate functions could suddenly be swapped out with unfocused functions (the ones that run when you unfocus the window) at any time (well, on frame boundaries, since key.isActive only got checked once, guarding the entire "inner loop" - and I made sure that changing key.isActive wouldn't immediately apply, just like the previous game loop order) - so I had to add yet another layer of indirection, where the gamestate functions could immediately be swapped out with the unfocused functions (while still running the beginning and end code, because that was how the previous loop order worked, after all). This also fixes a regression that the game loop that #220 introduced had, where if the fixed functions switched the gamestate, the game would prematurely start rendering the gamestate function of the new gamestate in the deltaframes, which was a source of some deltaframe glitches. But fixing this is likely to just as well cause deltaframe glitches, so it'd be better to fix this along with fixing the loop order, and only have one round of QA to do in the end, instead of doing one round after each change separately. Fixes #464... but this isn't the end of the patchset. There are bugs that need to be fixed, and kludges that need to be reverted.
2020-11-07 01:08:22 +01:00
return Loop_stop;
}
static enum LoopCode loop_begin(void);
static enum LoopCode loop_end(void);
static enum LoopCode (*const meta_funcs[])(void) = {
loop_begin,
loop_assign_active_funcs,
loop_run_active_funcs,
loop_end
};
static int meta_func_index = 0;
static void inline fixedloop(void)
{
while (true)
{
enum LoopCode loop_code = meta_funcs[meta_func_index]();
if (loop_code == Loop_stop)
{
break;
}
meta_func_index = (meta_func_index + 1) % SDL_arraysize(meta_funcs);
}
}
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
static void inline deltaloop(void);
Put the main game loop inside its own function Makes main() less of one giant blob of code.
2020-06-14 20:45:36 +02: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
static void cleanup(void);
Move cleanup code to separate function I will need to re-use this code, so it's best that it not be copy-pasted.
2021-02-16 02:52:41 +01:00
Use Emscripten's main loop On Emscripten, SDL_Delay is implemented as a busy loop. In addition, everything happens on a single thread. This effectively means that you have to let Emscripten manage the main loop, since if you do it yourself the browser will just be frozen.
2021-03-31 21:06:26 +02:00
#ifdef __EMSCRIPTEN__
Declare `emscriptenloop` as `static` It's not going to link with anything in a different translation unit, so just to make sure, we declare it as static.
2021-09-20 22:48:49 +02:00
static void emscriptenloop(void)
Use Emscripten's main loop On Emscripten, SDL_Delay is implemented as a busy loop. In addition, everything happens on a single thread. This effectively means that you have to let Emscripten manage the main loop, since if you do it yourself the browser will just be frozen.
2021-03-31 21:06:26 +02:00
{
timePrev = time_;
Switch over to using `SDL_GetTicks64()` SDL_GetTicks64() is a function that got added in SDL 2.0.18, which is just an SDL_GetTicks() without a value that wraps every ~49 days, instead wrapping after the sun explodes and kills us all. Oh sorry, didn't mean to get existential. For now, put this behind an SDL_VERSION_ATLEAST guard, which will be removed when SDL 2.0.18 officially releases and we can update to it.
2021-10-26 03:16:47 +02:00
time_ = SDL_GetTicks64();
Use Emscripten's main loop On Emscripten, SDL_Delay is implemented as a busy loop. In addition, everything happens on a single thread. This effectively means that you have to let Emscripten manage the main loop, since if you do it yourself the browser will just be frozen.
2021-03-31 21:06:26 +02:00
deltaloop();
}
#endif
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
int main(int argc, char *argv[])
{
Add -basedir option to specify base user directory (#154) Useful for maintaining multiple save files or for debugging
2020-02-09 00:49:03 +01:00
char* baseDir = NULL;
char* assetsPath = NULL;
Add localization "foundation" (many code changes) This commit adds most of the code changes necessary for making the game translatable, but does not yet "unhardcode" nearly all of the strings (except in a few cases where it was hard to separate added loc::gettexts from foundational code changes, or all the localization- related menus which were also added by this commit.) This commit is part of rewritten history of the localization branch. The original (unsquashed) commit history can be found here: https://github.com/Dav999-v/VVVVVV/tree/localization-orig
2022-12-30 22:57:24 +01:00
char* langDir = NULL;
char* fontsDir = NULL;
Seed with frame counter instead of `SDL_GetTicks` Using SDL_GetTicks() to seed the Gravitron RNG caused many reproducibility issues while syncing https://tasvideos.org/7575S . To fix this, add a frame counter, which is a number that is incremented every frame and never resets, and use it instead. If someone needs to switch back to SDL_GetTicks() for old TASes, then provide the -seed-use-sdl-getticks command-line option for them.
2022-11-14 23:10:24 +01:00
bool seed_use_sdl_getticks = false;
Add `-console` option on Windows This adds the `-console` command-line option (for Win32 only) so the game can spawn an attached console window which will contain all console output. This is to make it easier for people to debug on Windows systems. Otherwise, the only way to get console output would be to either compile the application as a console app (i.e. switch the subsystem to console) - which is undesirable for regular users as this makes it so a console is always spawned even when unwanted - or launch the game with shell arguments that make it so output is redirected to a file. As a result, color checking support is factored out of vlog_init() into its own function, even though we don't support colors on Windows.
2022-11-15 04:34:48 +01:00
#ifdef _WIN32
bool open_console = false;
#endif
Add -assets option to specify data.zip (#139) This is useful for distributions, which may not want to put data.zip in the same directory as the binary. This can't be distribution-specific due to the license ("Altered source/binary versions must be plainly marked as such, and must not be misrepresented as being the original software.").
2020-02-03 00:28:26 +01:00
Add colors to logging This includes the bold as well. INFO is just default, WARN is yellow, ERROR is red. We try to automatically detect if the output is a TTY (and thus supports colors), and don't emit colors if so. Windows 10 supports ANSI color codes starting with a specific build, but we don't care to emit whatever garbage Microsoft invented for builds older than that.
2021-02-24 00:22:28 +01:00
vlog_init();
De-duplicate and add safety checks to CLI args, fix brace style The command-line argument parsing code has a lot of copy-paste. This copy-paste would get even worse if I added safety checks to make sure you couldn't index argv out-of-bounds by having an argument like `-renderer` without having anything after it, i.e. you'd be doing the command `./VVVVVV -renderer`. Previously, only the playtest arguments (apart from the recently-added `playassets`) had this safety check, but the message it printed whenever the safety check failed was always "-playing option requires one argument" regardless of whatever argument actually failed to be parsed. So I fixed it so that all arguments actually output the correct corresponding failed argument instead. Also, `strcmp(argv[i], <name>) == 0` is really kind of noisy, even if you understand what it does perfectly well. So I refactored it with a bunch of macros. ARG() just does the strcmp() char* comparison, and ARG_INNER() does the safety check and returns 1, along with printing a message, if the safety check fails.
2020-06-22 01:15:28 +02:00
for (int i = 1; i < argc; ++i)
{
Reduce dependency on libc functions During 2.3 development, there's been a gradual shift to using SDL stdlib functions instead of libc functions, but there are still some libc functions (or the same libc function but from the STL) in the code. Well, this patch replaces all the rest of them in one fell swoop. SDL's stdlib can replace most of these, but its SDL_min() and SDL_max() are inadequate - they aren't really functions, they're more like macros with a nasty penchant for double-evaluation. So I just made my own VVV_min() and VVV_max() functions and placed them in Maths.h instead, then replaced all the previous usages of min(), max(), std::min(), std::max(), SDL_min(), and SDL_max() with VVV_min() and VVV_max(). Additionally, there's no SDL_isxdigit(), so I just implemented my own VVV_isxdigit(). SDL has SDL_malloc() and SDL_free(), but they have some refcounting built in to them, so in order to use them with LodePNG, I have to replace the malloc() and free() that LodePNG uses. Which isn't too hard, I did it in a new file called ThirdPartyDeps.c, and LodePNG is now compiled with the LODEPNG_NO_COMPILE_ALLOCATORS definition. Lastly, I also refactored the awful strcpy() and strcat() usages in PLATFORM_migrateSaveData() to use SDL_snprintf() instead. I know save migration is getting axed in 2.4, but it still bothers me to have something like that in the codebase otherwise. Without further ado, here is the full list of functions that the codebase now uses: - SDL_strlcpy() instead of strcpy() - SDL_strlcat() instead of strcat() - SDL_snprintf() instead of sprintf(), strcpy(), or strcat() (see above) - VVV_min() instead of min(), std::min(), or SDL_min() - VVV_max() instead of max(), std::max(), or SDL_max() - VVV_isxdigit() instead of isxdigit() - SDL_strcmp() instead of strcmp() - SDL_strcasecmp() instead of strcasecmp() or Win32 strcmpi() - SDL_strstr() instead of strstr() - SDL_strlen() instead of strlen() - SDL_sscanf() instead of sscanf() - SDL_getenv() instead of getenv() - SDL_malloc() instead of malloc() (replacing in LodePNG as well) - SDL_free() instead of free() (replacing in LodePNG as well)
2021-01-12 01:17:45 +01:00
#define ARG(name) (SDL_strcmp(argv[i], name) == 0)
De-duplicate and add safety checks to CLI args, fix brace style The command-line argument parsing code has a lot of copy-paste. This copy-paste would get even worse if I added safety checks to make sure you couldn't index argv out-of-bounds by having an argument like `-renderer` without having anything after it, i.e. you'd be doing the command `./VVVVVV -renderer`. Previously, only the playtest arguments (apart from the recently-added `playassets`) had this safety check, but the message it printed whenever the safety check failed was always "-playing option requires one argument" regardless of whatever argument actually failed to be parsed. So I fixed it so that all arguments actually output the correct corresponding failed argument instead. Also, `strcmp(argv[i], <name>) == 0` is really kind of noisy, even if you understand what it does perfectly well. So I refactored it with a bunch of macros. ARG() just does the strcmp() char* comparison, and ARG_INNER() does the safety check and returns 1, along with printing a message, if the safety check fails.
2020-06-22 01:15:28 +02:00
#define ARG_INNER(code) \
if (i + 1 < argc) \
{ \
code \
} \
else \
{ \
Replace all print calls with vlog calls This is pretty straight-forward to do.
2021-02-24 00:21:29 +01:00
vlog_error("%s option requires one argument.", argv[i]); \
Clean up all program close paths to use VVV_exit() Wow, there are a lot of these. All of these exit paths now use VVV_exit() instead, which attempts to save unlock.vvv and settings.vvv, and also frees all resources so Valgrind is happy. This is a good thing, because previously unlock.vvv/settings.vvv wouldn't be written to if we decided to bail for a given reason.
2021-02-16 03:53:17 +01:00
VVV_exit(1); \
De-duplicate and add safety checks to CLI args, fix brace style The command-line argument parsing code has a lot of copy-paste. This copy-paste would get even worse if I added safety checks to make sure you couldn't index argv out-of-bounds by having an argument like `-renderer` without having anything after it, i.e. you'd be doing the command `./VVVVVV -renderer`. Previously, only the playtest arguments (apart from the recently-added `playassets`) had this safety check, but the message it printed whenever the safety check failed was always "-playing option requires one argument" regardless of whatever argument actually failed to be parsed. So I fixed it so that all arguments actually output the correct corresponding failed argument instead. Also, `strcmp(argv[i], <name>) == 0` is really kind of noisy, even if you understand what it does perfectly well. So I refactored it with a bunch of macros. ARG() just does the strcmp() char* comparison, and ARG_INNER() does the safety check and returns 1, along with printing a message, if the safety check fails.
2020-06-22 01:15:28 +02:00
}
Add `-version` command-line argument Probably should have done this earlier in 2.3, but better late than never. This makes it easier for third-party programs like Ved to detect what version of the game this is. Slightly quick-n-dirty for now, I'll de-duplicate the version number later, and add commit hash and date if applicable.
2022-05-23 23:34:36 +02:00
if (ARG("-version"))
{
/* Just print the version and exit. No vlogging. */
Add build type to `-version` This adds the build type in brackets in `-version` output after e.g. "VVVVVV v2.4". The build type is MAKEANDPLAY, NO_CUSTOM_LEVELS, or NO_EDITOR (which are not necessarily mutually exclusive). This is appended on to the end of the first line so as to not break Ved's existing `-version` check which only checks if the beginning of STDOUT is "VVVVVV" followed by any version number.
2023-02-02 22:08:40 +01:00
puts(
"VVVVVV " RELEASE_VERSION
#ifdef MAKEANDPLAY
" [M&P]"
#endif
#ifdef NO_CUSTOM_LEVELS
" [no custom levels]"
#endif
#ifdef NO_EDITOR
" [no editor]"
#endif
);
Add commit hash & date to `-version` flag output This prints the commit hash and date in the same order as they are printed on the title screen.
2022-08-23 06:27:20 +02:00
#ifdef INTERIM_VERSION_EXISTS
puts(COMMIT_DATE);
puts(INTERIM_COMMIT);
Add branch name to interim version information This is useful for developers who may have multiple builds of the game from various different branches and may easily forget which build of the game is what. This shows up in the bottom-right corner of the title screen and also with the `-version` command-line option, and in the status message printed when building the game.
2023-01-08 04:18:28 +01:00
puts(BRANCH_NAME);
Add commit hash & date to `-version` flag output This prints the commit hash and date in the same order as they are printed on the title screen.
2022-08-23 06:27:20 +02:00
#endif
Add `-version` command-line argument Probably should have done this earlier in 2.3, but better late than never. This makes it easier for third-party programs like Ved to detect what version of the game this is. Slightly quick-n-dirty for now, I'll de-duplicate the version number later, and add commit hash and date if applicable.
2022-05-23 23:34:36 +02:00
VVV_exit(0);
}
Add `-addresses` command-line argument This prints the address of every global class to the console, and then exits. This is useful for autosplitters, which read memory addresses directly. Any time a new version of the game is shipped, this makes updating the autosplitters much easier as people don't have to find the addresses of the global classes themselves.
2023-02-18 05:41:11 +01:00
else if (ARG("-addresses"))
{
#ifndef NO_CUSTOM_LEVELS
printf("cl : %p\n", (void*) &cl);
# ifndef NO_EDITOR
printf("ed : %p\n", (void*) &ed);
# endif
#endif
printf("game : %p\n", (void*) &game);
printf("gameScreen : %p\n", (void*) &gameScreen);
printf("graphics : %p\n", (void*) &graphics);
printf("help : %p\n", (void*) &help);
printf("key : %p\n", (void*) &key);
printf("map : %p\n", (void*) &map);
printf("music : %p\n", (void*) &music);
printf("obj : %p\n", (void*) &obj);
printf("script : %p\n", (void*) &script);
VVV_exit(0);
}
Add `-version` command-line argument Probably should have done this earlier in 2.3, but better late than never. This makes it easier for third-party programs like Ved to detect what version of the game this is. Slightly quick-n-dirty for now, I'll de-duplicate the version number later, and add commit hash and date if applicable.
2022-05-23 23:34:36 +02:00
else if (ARG("-renderer"))
De-duplicate and add safety checks to CLI args, fix brace style The command-line argument parsing code has a lot of copy-paste. This copy-paste would get even worse if I added safety checks to make sure you couldn't index argv out-of-bounds by having an argument like `-renderer` without having anything after it, i.e. you'd be doing the command `./VVVVVV -renderer`. Previously, only the playtest arguments (apart from the recently-added `playassets`) had this safety check, but the message it printed whenever the safety check failed was always "-playing option requires one argument" regardless of whatever argument actually failed to be parsed. So I fixed it so that all arguments actually output the correct corresponding failed argument instead. Also, `strcmp(argv[i], <name>) == 0` is really kind of noisy, even if you understand what it does perfectly well. So I refactored it with a bunch of macros. ARG() just does the strcmp() char* comparison, and ARG_INNER() does the safety check and returns 1, along with printing a message, if the safety check fails.
2020-06-22 01:15:28 +02:00
{
ARG_INNER({
Fix -playx/y/rx/ry/gc/music looking at wrong argument In my previous PR, I wrongly assumed that I could just replace the `i` handling code of those options with an `i++;` at the beginning, and thus I could put all blocks' `i++;` into ARG_INNER(). Well I was wrong, because the code was written the original way for a reason, namely that we still need `i` to point to the -playx/y/rx/ry/gc/music argv so we can re-compare which argument led us into this code block.
2020-06-22 03:37:44 +02:00
i++;
De-duplicate and add safety checks to CLI args, fix brace style The command-line argument parsing code has a lot of copy-paste. This copy-paste would get even worse if I added safety checks to make sure you couldn't index argv out-of-bounds by having an argument like `-renderer` without having anything after it, i.e. you'd be doing the command `./VVVVVV -renderer`. Previously, only the playtest arguments (apart from the recently-added `playassets`) had this safety check, but the message it printed whenever the safety check failed was always "-playing option requires one argument" regardless of whatever argument actually failed to be parsed. So I fixed it so that all arguments actually output the correct corresponding failed argument instead. Also, `strcmp(argv[i], <name>) == 0` is really kind of noisy, even if you understand what it does perfectly well. So I refactored it with a bunch of macros. ARG() just does the strcmp() char* comparison, and ARG_INNER() does the safety check and returns 1, along with printing a message, if the safety check fails.
2020-06-22 01:15:28 +02:00
SDL_SetHintWithPriority(SDL_HINT_RENDER_DRIVER, argv[i], SDL_HINT_OVERRIDE);
})
}
else if (ARG("-basedir"))
{
ARG_INNER({
Fix -playx/y/rx/ry/gc/music looking at wrong argument In my previous PR, I wrongly assumed that I could just replace the `i` handling code of those options with an `i++;` at the beginning, and thus I could put all blocks' `i++;` into ARG_INNER(). Well I was wrong, because the code was written the original way for a reason, namely that we still need `i` to point to the -playx/y/rx/ry/gc/music argv so we can re-compare which argument led us into this code block.
2020-06-22 03:37:44 +02:00
i++;
De-duplicate and add safety checks to CLI args, fix brace style The command-line argument parsing code has a lot of copy-paste. This copy-paste would get even worse if I added safety checks to make sure you couldn't index argv out-of-bounds by having an argument like `-renderer` without having anything after it, i.e. you'd be doing the command `./VVVVVV -renderer`. Previously, only the playtest arguments (apart from the recently-added `playassets`) had this safety check, but the message it printed whenever the safety check failed was always "-playing option requires one argument" regardless of whatever argument actually failed to be parsed. So I fixed it so that all arguments actually output the correct corresponding failed argument instead. Also, `strcmp(argv[i], <name>) == 0` is really kind of noisy, even if you understand what it does perfectly well. So I refactored it with a bunch of macros. ARG() just does the strcmp() char* comparison, and ARG_INNER() does the safety check and returns 1, along with printing a message, if the safety check fails.
2020-06-22 01:15:28 +02:00
baseDir = argv[i];
})
}
else if (ARG("-assets"))
{
ARG_INNER({
Fix -playx/y/rx/ry/gc/music looking at wrong argument In my previous PR, I wrongly assumed that I could just replace the `i` handling code of those options with an `i++;` at the beginning, and thus I could put all blocks' `i++;` into ARG_INNER(). Well I was wrong, because the code was written the original way for a reason, namely that we still need `i` to point to the -playx/y/rx/ry/gc/music argv so we can re-compare which argument led us into this code block.
2020-06-22 03:37:44 +02:00
i++;
De-duplicate and add safety checks to CLI args, fix brace style The command-line argument parsing code has a lot of copy-paste. This copy-paste would get even worse if I added safety checks to make sure you couldn't index argv out-of-bounds by having an argument like `-renderer` without having anything after it, i.e. you'd be doing the command `./VVVVVV -renderer`. Previously, only the playtest arguments (apart from the recently-added `playassets`) had this safety check, but the message it printed whenever the safety check failed was always "-playing option requires one argument" regardless of whatever argument actually failed to be parsed. So I fixed it so that all arguments actually output the correct corresponding failed argument instead. Also, `strcmp(argv[i], <name>) == 0` is really kind of noisy, even if you understand what it does perfectly well. So I refactored it with a bunch of macros. ARG() just does the strcmp() char* comparison, and ARG_INNER() does the safety check and returns 1, along with printing a message, if the safety check fails.
2020-06-22 01:15:28 +02:00
assetsPath = argv[i];
})
}
Add localization "foundation" (many code changes) This commit adds most of the code changes necessary for making the game translatable, but does not yet "unhardcode" nearly all of the strings (except in a few cases where it was hard to separate added loc::gettexts from foundational code changes, or all the localization- related menus which were also added by this commit.) This commit is part of rewritten history of the localization branch. The original (unsquashed) commit history can be found here: https://github.com/Dav999-v/VVVVVV/tree/localization-orig
2022-12-30 22:57:24 +01:00
else if (ARG("-langdir"))
{
ARG_INNER({
i++;
langDir = argv[i];
})
}
else if (ARG("-fontsdir"))
{
ARG_INNER({
i++;
fontsDir = argv[i];
})
}
De-duplicate and add safety checks to CLI args, fix brace style The command-line argument parsing code has a lot of copy-paste. This copy-paste would get even worse if I added safety checks to make sure you couldn't index argv out-of-bounds by having an argument like `-renderer` without having anything after it, i.e. you'd be doing the command `./VVVVVV -renderer`. Previously, only the playtest arguments (apart from the recently-added `playassets`) had this safety check, but the message it printed whenever the safety check failed was always "-playing option requires one argument" regardless of whatever argument actually failed to be parsed. So I fixed it so that all arguments actually output the correct corresponding failed argument instead. Also, `strcmp(argv[i], <name>) == 0` is really kind of noisy, even if you understand what it does perfectly well. So I refactored it with a bunch of macros. ARG() just does the strcmp() char* comparison, and ARG_INNER() does the safety check and returns 1, along with printing a message, if the safety check fails.
2020-06-22 01:15:28 +02:00
else if (ARG("-playing") || ARG("-p"))
{
ARG_INNER({
Fix -playx/y/rx/ry/gc/music looking at wrong argument In my previous PR, I wrongly assumed that I could just replace the `i` handling code of those options with an `i++;` at the beginning, and thus I could put all blocks' `i++;` into ARG_INNER(). Well I was wrong, because the code was written the original way for a reason, namely that we still need `i` to point to the -playx/y/rx/ry/gc/music argv so we can re-compare which argument led us into this code block.
2020-06-22 03:37:44 +02:00
i++;
Implement command-line playtesting (#163)
2020-04-09 21:03:24 +02:00
startinplaytest = true;
playtestname = std::string("levels/");
playtestname.append(argv[i]);
playtestname.append(std::string(".vvvvvv"));
De-duplicate and add safety checks to CLI args, fix brace style The command-line argument parsing code has a lot of copy-paste. This copy-paste would get even worse if I added safety checks to make sure you couldn't index argv out-of-bounds by having an argument like `-renderer` without having anything after it, i.e. you'd be doing the command `./VVVVVV -renderer`. Previously, only the playtest arguments (apart from the recently-added `playassets`) had this safety check, but the message it printed whenever the safety check failed was always "-playing option requires one argument" regardless of whatever argument actually failed to be parsed. So I fixed it so that all arguments actually output the correct corresponding failed argument instead. Also, `strcmp(argv[i], <name>) == 0` is really kind of noisy, even if you understand what it does perfectly well. So I refactored it with a bunch of macros. ARG() just does the strcmp() char* comparison, and ARG_INNER() does the safety check and returns 1, along with printing a message, if the safety check fails.
2020-06-22 01:15:28 +02:00
})
}
else if (ARG("-playx") || ARG("-playy") ||
ARG("-playrx") || ARG("-playry") ||
ARG("-playgc") || ARG("-playmusic"))
{
ARG_INNER({
Implement command-line playtesting (#163)
2020-04-09 21:03:24 +02:00
savefileplaytest = true;
Replace all usages of atoi() with help.Int() This will prevent any undefined behavior that might occur as a result of having invalid input passed into atoi().
2020-08-07 06:31:29 +02:00
int v = help.Int(argv[i+1]);
De-duplicate and add safety checks to CLI args, fix brace style The command-line argument parsing code has a lot of copy-paste. This copy-paste would get even worse if I added safety checks to make sure you couldn't index argv out-of-bounds by having an argument like `-renderer` without having anything after it, i.e. you'd be doing the command `./VVVVVV -renderer`. Previously, only the playtest arguments (apart from the recently-added `playassets`) had this safety check, but the message it printed whenever the safety check failed was always "-playing option requires one argument" regardless of whatever argument actually failed to be parsed. So I fixed it so that all arguments actually output the correct corresponding failed argument instead. Also, `strcmp(argv[i], <name>) == 0` is really kind of noisy, even if you understand what it does perfectly well. So I refactored it with a bunch of macros. ARG() just does the strcmp() char* comparison, and ARG_INNER() does the safety check and returns 1, along with printing a message, if the safety check fails.
2020-06-22 01:15:28 +02:00
if (ARG("-playx")) savex = v;
else if (ARG("-playy")) savey = v;
else if (ARG("-playrx")) saverx = v;
else if (ARG("-playry")) savery = v;
else if (ARG("-playgc")) savegc = v;
else if (ARG("-playmusic")) savemusic = v;
Fix -playx/y/rx/ry/gc/music looking at wrong argument In my previous PR, I wrongly assumed that I could just replace the `i` handling code of those options with an `i++;` at the beginning, and thus I could put all blocks' `i++;` into ARG_INNER(). Well I was wrong, because the code was written the original way for a reason, namely that we still need `i` to point to the -playx/y/rx/ry/gc/music argv so we can re-compare which argument led us into this code block.
2020-06-22 03:37:44 +02:00
i++;
De-duplicate and add safety checks to CLI args, fix brace style The command-line argument parsing code has a lot of copy-paste. This copy-paste would get even worse if I added safety checks to make sure you couldn't index argv out-of-bounds by having an argument like `-renderer` without having anything after it, i.e. you'd be doing the command `./VVVVVV -renderer`. Previously, only the playtest arguments (apart from the recently-added `playassets`) had this safety check, but the message it printed whenever the safety check failed was always "-playing option requires one argument" regardless of whatever argument actually failed to be parsed. So I fixed it so that all arguments actually output the correct corresponding failed argument instead. Also, `strcmp(argv[i], <name>) == 0` is really kind of noisy, even if you understand what it does perfectly well. So I refactored it with a bunch of macros. ARG() just does the strcmp() char* comparison, and ARG_INNER() does the safety check and returns 1, along with printing a message, if the safety check fails.
2020-06-22 01:15:28 +02:00
})
}
else if (ARG("-playassets"))
{
ARG_INNER({
Fix -playx/y/rx/ry/gc/music looking at wrong argument In my previous PR, I wrongly assumed that I could just replace the `i` handling code of those options with an `i++;` at the beginning, and thus I could put all blocks' `i++;` into ARG_INNER(). Well I was wrong, because the code was written the original way for a reason, namely that we still need `i` to point to the -playx/y/rx/ry/gc/music argv so we can re-compare which argument led us into this code block.
2020-06-22 03:37:44 +02:00
i++;
Properly camel-case FILESYSTEM_[un]mountassets() They are now camel-cased to be consistent with the rest of the filesystem functions.
2021-04-03 21:48:47 +02:00
// Even if this is a directory, FILESYSTEM_mountAssets() expects '.vvvvvv' on the end
Add -playassets command-line option This is used if you're loading a level file from STDIN. The game needs to know the actual level assets directory you're referring to, since when it gets the level from STDIN, it doesn't know the actual filename of the level. Fixes #309.
2020-06-22 00:56:31 +02:00
playassets = "levels/" + std::string(argv[i]) + ".vvvvvv";
De-duplicate and add safety checks to CLI args, fix brace style The command-line argument parsing code has a lot of copy-paste. This copy-paste would get even worse if I added safety checks to make sure you couldn't index argv out-of-bounds by having an argument like `-renderer` without having anything after it, i.e. you'd be doing the command `./VVVVVV -renderer`. Previously, only the playtest arguments (apart from the recently-added `playassets`) had this safety check, but the message it printed whenever the safety check failed was always "-playing option requires one argument" regardless of whatever argument actually failed to be parsed. So I fixed it so that all arguments actually output the correct corresponding failed argument instead. Also, `strcmp(argv[i], <name>) == 0` is really kind of noisy, even if you understand what it does perfectly well. So I refactored it with a bunch of macros. ARG() just does the strcmp() char* comparison, and ARG_INNER() does the safety check and returns 1, along with printing a message, if the safety check fails.
2020-06-22 01:15:28 +02:00
})
Implement command-line playtesting (#163)
2020-04-09 21:03:24 +02:00
}
Allow disabling output/fine-tuning output -nooutput disables output completely (both STDOUT and STDERR). -noinfo disables INFO lines. -nowarn disables WARN lines. -noerror disables ERROR lines.
2021-09-01 22:41:06 +02:00
else if (ARG("-nooutput"))
{
vlog_toggle_output(0);
}
Add command-line options to force-enable/disable color `-forcecolor` will force color to be on. `-nocolor` will force color to be off. And just because I'm a nice person, I've also added British versions of those flags. As a treat.
2021-09-01 22:28:51 +02:00
else if (ARG("-forcecolor") || ARG("-forcecolour"))
{
vlog_toggle_color(1);
}
else if (ARG("-nocolor") || ARG("-nocolour"))
{
vlog_toggle_color(0);
}
Add debug logs These are disabled by default, because they're noisy. To enable them, pass -debug.
2021-09-01 23:11:23 +02:00
else if (ARG("-debug"))
{
vlog_toggle_debug(1);
}
Allow disabling output/fine-tuning output -nooutput disables output completely (both STDOUT and STDERR). -noinfo disables INFO lines. -nowarn disables WARN lines. -noerror disables ERROR lines.
2021-09-01 22:41:06 +02:00
else if (ARG("-noinfo"))
{
vlog_toggle_info(0);
}
else if (ARG("-nowarn"))
{
vlog_toggle_warn(0);
}
else if (ARG("-noerror"))
{
vlog_toggle_error(0);
}
Add localization "foundation" (many code changes) This commit adds most of the code changes necessary for making the game translatable, but does not yet "unhardcode" nearly all of the strings (except in a few cases where it was hard to separate added loc::gettexts from foundational code changes, or all the localization- related menus which were also added by this commit.) This commit is part of rewritten history of the localization branch. The original (unsquashed) commit history can be found here: https://github.com/Dav999-v/VVVVVV/tree/localization-orig
2022-12-30 22:57:24 +01:00
else if (ARG("-translator"))
{
loc::show_translator_menu = true;
}
Add `-console` option on Windows This adds the `-console` command-line option (for Win32 only) so the game can spawn an attached console window which will contain all console output. This is to make it easier for people to debug on Windows systems. Otherwise, the only way to get console output would be to either compile the application as a console app (i.e. switch the subsystem to console) - which is undesirable for regular users as this makes it so a console is always spawned even when unwanted - or launch the game with shell arguments that make it so output is redirected to a file. As a result, color checking support is factored out of vlog_init() into its own function, even though we don't support colors on Windows.
2022-11-15 04:34:48 +01:00
#ifdef _WIN32
else if (ARG("-console"))
{
open_console = true;
}
#endif
Seed with frame counter instead of `SDL_GetTicks` Using SDL_GetTicks() to seed the Gravitron RNG caused many reproducibility issues while syncing https://tasvideos.org/7575S . To fix this, add a frame counter, which is a number that is incremented every frame and never resets, and use it instead. If someone needs to switch back to SDL_GetTicks() for old TASes, then provide the -seed-use-sdl-getticks command-line option for them.
2022-11-14 23:10:24 +01:00
else if (ARG("-seed-use-sdl-getticks"))
{
seed_use_sdl_getticks = true;
}
De-duplicate and add safety checks to CLI args, fix brace style The command-line argument parsing code has a lot of copy-paste. This copy-paste would get even worse if I added safety checks to make sure you couldn't index argv out-of-bounds by having an argument like `-renderer` without having anything after it, i.e. you'd be doing the command `./VVVVVV -renderer`. Previously, only the playtest arguments (apart from the recently-added `playassets`) had this safety check, but the message it printed whenever the safety check failed was always "-playing option requires one argument" regardless of whatever argument actually failed to be parsed. So I fixed it so that all arguments actually output the correct corresponding failed argument instead. Also, `strcmp(argv[i], <name>) == 0` is really kind of noisy, even if you understand what it does perfectly well. So I refactored it with a bunch of macros. ARG() just does the strcmp() char* comparison, and ARG_INNER() does the safety check and returns 1, along with printing a message, if the safety check fails.
2020-06-22 01:15:28 +02:00
#undef ARG_INNER
Fix undeffing ARG_IS instead of ARG Whoops. Noticed this earlier when I was merging upstream back into VCE, and interestingly enough, it doesn't look like cppcheck warns about undeffing a non-existent define.
2020-07-16 03:27:54 +02:00
#undef ARG
Print error and return if given invalid command-line arg This is helpful to know if the user either spelled an arg wrong, or spelled it right but nothing is happening.
2020-08-03 06:30:08 +02:00
else
{
Replace all print calls with vlog calls This is pretty straight-forward to do.
2021-02-24 00:21:29 +01:00
vlog_error("Error: invalid option: %s", argv[i]);
Clean up all program close paths to use VVV_exit() Wow, there are a lot of these. All of these exit paths now use VVV_exit() instead, which attempts to save unlock.vvv and settings.vvv, and also frees all resources so Valgrind is happy. This is a good thing, because previously unlock.vvv/settings.vvv wouldn't be written to if we decided to bail for a given reason.
2021-02-16 03:53:17 +01:00
VVV_exit(1);
Print error and return if given invalid command-line arg This is helpful to know if the user either spelled an arg wrong, or spelled it right but nothing is happening.
2020-08-03 06:30:08 +02:00
}
Add -assets option to specify data.zip (#139) This is useful for distributions, which may not want to put data.zip in the same directory as the binary. This can't be distribution-specific due to the license ("Altered source/binary versions must be plainly marked as such, and must not be misrepresented as being the original software.").
2020-02-03 00:28:26 +01:00
}
Add localization "foundation" (many code changes) This commit adds most of the code changes necessary for making the game translatable, but does not yet "unhardcode" nearly all of the strings (except in a few cases where it was hard to separate added loc::gettexts from foundational code changes, or all the localization- related menus which were also added by this commit.) This commit is part of rewritten history of the localization branch. The original (unsquashed) commit history can be found here: https://github.com/Dav999-v/VVVVVV/tree/localization-orig
2022-12-30 22:57:24 +01:00
#if defined(ALWAYS_SHOW_TRANSLATOR_MENU)
loc::show_translator_menu = true;
#endif
Add `-console` option on Windows This adds the `-console` command-line option (for Win32 only) so the game can spawn an attached console window which will contain all console output. This is to make it easier for people to debug on Windows systems. Otherwise, the only way to get console output would be to either compile the application as a console app (i.e. switch the subsystem to console) - which is undesirable for regular users as this makes it so a console is always spawned even when unwanted - or launch the game with shell arguments that make it so output is redirected to a file. As a result, color checking support is factored out of vlog_init() into its own function, even though we don't support colors on Windows.
2022-11-15 04:34:48 +01:00
#ifdef _WIN32
if (open_console)
{
vlog_open_console();
}
#endif
Add localization "foundation" (many code changes) This commit adds most of the code changes necessary for making the game translatable, but does not yet "unhardcode" nearly all of the strings (except in a few cases where it was hard to separate added loc::gettexts from foundational code changes, or all the localization- related menus which were also added by this commit.) This commit is part of rewritten history of the localization branch. The original (unsquashed) commit history can be found here: https://github.com/Dav999-v/VVVVVV/tree/localization-orig
2022-12-30 22:57:24 +01:00
if(!FILESYSTEM_init(argv[0], baseDir, assetsPath, langDir, fontsDir))
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Replace all print calls with vlog calls This is pretty straight-forward to do.
2021-02-24 00:21:29 +01:00
vlog_error("Unable to initialize filesystem!");
Clean up all program close paths to use VVV_exit() Wow, there are a lot of these. All of these exit paths now use VVV_exit() instead, which attempts to save unlock.vvv and settings.vvv, and also frees all resources so Valgrind is happy. This is a good thing, because previously unlock.vvv/settings.vvv wouldn't be written to if we decided to bail for a given reason.
2021-02-16 03:53:17 +01:00
VVV_exit(1);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
SDL_Init after FILESYSTEM_init, for gamecontrollerdb.txt
2020-02-19 18:44:36 +01:00
SDL_Init(
SDL_INIT_VIDEO |
SDL_INIT_AUDIO |
SDL_INIT_JOYSTICK |
SDL_INIT_GAMECONTROLLER
);
Axe manual state trackers and use SDL_IsTextInputActive() After looking at pull request #446, I got a bit annoyed that we have TWO variables, key.textentrymode and ed.textentry, that we rolled ourselves to track the state of something SDL already provides us a function to easily query: SDL_IsTextInputActive(). We don't need to have either of these two variables, and we shouldn't. So that's what I do in this patch. Both variables have been axed in favor of using this function, and I just made a wrapper out of it, named key.textentry(). For bonus points, this gets rid of the ugly NO_CUSTOM_LEVELS and NO_EDITOR ifdef in main.cpp, since text entry is enabled when entering the script list and disabled when exiting it. This makes the code there easier to read, too. Furthermore, apparently key.textentrymode was initialized to *true* instead of false... for whatever reason. But that's gone now, too. Now, you'd think there wouldn't be any downside to using SDL_IsTextInputActive(). After all, it's a function that SDL itself provides, right? Wrong. For whatever reason, it seems like text input is active *from the start of the program*, meaning that what would happen is I would go into the editor, and find that I can't move around nor place tiles nor anything else. Then I would press Esc, and then suddenly become able to do those things I wanted to do before. I have no idea why the above happens, but all I can do is to just insert an SDL_StopTextInput() immediately after the SDL_Init() in main.cpp. Of course, I have to surround it with an SDL_IsTextInputActive() check to make sure I don't do anything extraneous by stopping input when it's already stopped.
2020-08-13 08:43:25 +02:00
if (SDL_IsTextInputActive() == SDL_TRUE)
{
SDL_StopTextInput();
}
SDL_Init after FILESYSTEM_init, for gamecontrollerdb.txt
2020-02-19 18:44:36 +01:00
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
NETWORK_init();
Replace all print calls with vlog calls This is pretty straight-forward to do.
2021-02-24 00:21:29 +01:00
vlog_info("\t\t");
vlog_info("\t\t");
vlog_info("\t\t VVVVVV");
vlog_info("\t\t");
vlog_info("\t\t");
vlog_info("\t\t 8888888888888888 ");
vlog_info("\t\t88888888888888888888");
vlog_info("\t\t888888 8888 88");
vlog_info("\t\t888888 8888 88");
vlog_info("\t\t88888888888888888888");
vlog_info("\t\t88888888888888888888");
vlog_info("\t\t888888 88");
vlog_info("\t\t88888888 8888");
vlog_info("\t\t 8888888888888888 ");
vlog_info("\t\t 88888888 ");
vlog_info("\t\t 8888888888888888 ");
vlog_info("\t\t88888888888888888888");
vlog_info("\t\t88888888888888888888");
vlog_info("\t\t88888888888888888888");
vlog_info("\t\t8888 88888888 8888");
vlog_info("\t\t8888 88888888 8888");
vlog_info("\t\t 888888888888 ");
vlog_info("\t\t 8888 8888 ");
vlog_info("\t\t 888888 888888 ");
vlog_info("\t\t 888888 888888 ");
vlog_info("\t\t 888888 888888 ");
vlog_info("\t\t");
vlog_info("\t\t");
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
Move from surfaces to the SDL render system Ever since VVVVVV was initially ported to C++ in 2.0, it has used surfaces from SDL. The downside is, that's all software rendering. This commit moves most things off of surfaces, and all into GPU, by using textures and SDL_Renderer. Pixel-perfect collision has been kept by keeping a copy of sprites as surfaces. There's plans for pixel-perfect collision to use masks instead of reading pixel data directly, but that's out of scope for this commit. - `graphics.reloadresources()` is now called later in `main`, because textures cannot be created without a renderer. - This commit also removes a bunch of surface functions which are no longer needed. - This also recaches target textures in certain places for d3d9. - graphics.images was converted to a fixed-size array. - fillbox and fillboxabs use SDL_RenderDrawRect instead of drawing an outline using four filled rectangles - Update my name in the credits
2023-01-07 19:28:07 +01:00
// Set up screen
Allow using help/graphics/music/game/key/map/obj everywhere This commit makes `help`, `graphics`, `music`, `game`, `key`, `map`, and `obj` essentially static global objects that can be used everywhere. This is useful in case we ever need to add a new function in the future, so we don't have to bother with passing a new argument in which means we have to pass a new argument in to the function that calls that function which means having to pass a new argument into the function that calls THAT function, etc. which is a real headache when working on fan mods of the source code. Note that this changes NONE of the existing function signatures, it merely just makes those variables accessible everywhere in the same way `script` and `ed` are. Also note that some classes had to be initialized after the filesystem was initialized, but C++ would keep initializing them before the filesystem got initialized, because I *had* to put them at the top of `main.cpp`, or else they wouldn't be global variables. The only way to work around this was to use entityclass's initialization style (which I'm pretty sure entityclass of all things doesn't need to be initialized this way), where you actually initialize the class in an `init()` function, and so then you do `graphics.init()` after the filesystem initialization, AFTER doing `Graphics graphics` up at the top. I've had to do this for `graphics` (but only because its child GraphicsResources `grphx` needs to be initialized this way), `music`, and `game`. I don't think this will affect anything. Other than that, `help`, `key`, and `map` are still using the C++-intended method of having ClassName::ClassName() functions.
2020-01-29 08:35:03 +01:00
graphics.init();
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
Allow using help/graphics/music/game/key/map/obj everywhere This commit makes `help`, `graphics`, `music`, `game`, `key`, `map`, and `obj` essentially static global objects that can be used everywhere. This is useful in case we ever need to add a new function in the future, so we don't have to bother with passing a new argument in which means we have to pass a new argument in to the function that calls that function which means having to pass a new argument into the function that calls THAT function, etc. which is a real headache when working on fan mods of the source code. Note that this changes NONE of the existing function signatures, it merely just makes those variables accessible everywhere in the same way `script` and `ed` are. Also note that some classes had to be initialized after the filesystem was initialized, but C++ would keep initializing them before the filesystem got initialized, because I *had* to put them at the top of `main.cpp`, or else they wouldn't be global variables. The only way to work around this was to use entityclass's initialization style (which I'm pretty sure entityclass of all things doesn't need to be initialized this way), where you actually initialize the class in an `init()` function, and so then you do `graphics.init()` after the filesystem initialization, AFTER doing `Graphics graphics` up at the top. I've had to do this for `graphics` (but only because its child GraphicsResources `grphx` needs to be initialized this way), `music`, and `game`. I don't think this will affect anything. Other than that, `help`, `key`, and `map` are still using the C++-intended method of having ClassName::ClassName() functions.
2020-01-29 08:35:03 +01:00
game.init();
Seed with frame counter instead of `SDL_GetTicks` Using SDL_GetTicks() to seed the Gravitron RNG caused many reproducibility issues while syncing https://tasvideos.org/7575S . To fix this, add a frame counter, which is a number that is incremented every frame and never resets, and use it instead. If someone needs to switch back to SDL_GetTicks() for old TASes, then provide the -seed-use-sdl-getticks command-line option for them.
2022-11-14 23:10:24 +01:00
game.seed_use_sdl_getticks = seed_use_sdl_getticks;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
Refactor startup to load config before calling Screen::init
2020-07-08 20:30:57 +02:00
game.gamestate = PRELOADER;
game.menustart = false;
Move title screen color initialization to main() This fixes a bug where if you completed a custom level during command-line playtesting, when returning to the title screen, the background would be red and the text would be white. This is because playtesting skips over the code path of pressing ACTION to start the game and advance to the title screen, and the code path of that ACTION press specifically initializes the title screen colors to cyan. This is also caused by the fact that completing a custom level doesn't call map.nexttowercolour(), but my guess is that the intent there was that the player would select a custom level, complete it, and return to the title screen on the same screen with the same colors, so I decided not to add a map.nexttowercolour() there. Instead, I've moved the cyan color initialization to main(), so that it is always executed no matter what, and doesn't require you to take a specific code path to do it.
2021-01-06 02:18:00 +01:00
// Initialize title screen to cyan
graphics.titlebg.colstate = 10;
map.nexttowercolour();
Refactor startup to load config before calling Screen::init
2020-07-08 20:30:57 +02:00
map.ypos = (700-29) * 8;
Fix two places with map.oldypos not being assigned These places didn't assign map.oldypos when they assigned map.ypos. This could have only resulted in visual glitches, but it's good to be consistent and proactively fix these.
2021-04-23 05:27:45 +02:00
map.oldypos = map.ypos;
Consolidate tower BG bypos and bscroll assignments Tower backgrounds have a bypos and bscroll. bypos is just the y-position of the background, and bscroll is the amount of pixels to scroll the background by on each frame, which is used to scroll it (if it's not being redrawn) and for linear interpolation. For the tower background (and not the title background), bypos is map.ypos / 2, and bscroll is (map.ypos - map.oldypos) / 2. However, usually bscroll gets assigned at the same time bypos is incremented or decremented, so you never see that calculation explicitly - except in the previous commit, where I worked out the calculation because the change in y-position isn't a known constant. Having to do all these calculations every time introduces the possibility of errors where you forget to do it, or you do it wrongly. But that's not even the worst; you could cause a linear interpolation glitch if you decide to overwrite bscroll without taking into account map.oldypos and map.ypos. So that's why I'm adding a function that automatically updates the tower background, using the values of map.oldypos and map.ypos, that is used every time map.ypos is assigned. That way, we have to write less code, you can be sure that there's no place where we forget to do the calculations (or at least it will be glaringly obvious) or we do it wrongly, and it plays nicely with linear interpolation. This also replaces every instance where the manual calculations are done with the new function.
2021-04-23 03:47:07 +02:00
map.setbgobjlerp(graphics.towerbg);
map.setbgobjlerp(graphics.titlebg);
Refactor startup to load config before calling Screen::init
2020-07-08 20:30:57 +02:00
Remove duplicate screen configuration variables There were some duplicate Screen configuration variables that were on Game, when there didn't need to be. - game.fullScreenEffect_badSignal is a duplicate of graphics.screenbuffer->badSignalEffect - game.fullscreen is a duplicate of !graphics.screenbuffer->isWindowed - game.stretchMode is a duplicate of graphics.screenbuffer->stretchMode - game.useLinearFilter is a duplicate of graphics.screenbuffer->isFiltered These duplicate variables have been removed now. I put indentation when handling the ScreenSettings struct in main() so the local doesn't live for the entirety of main() (which is the entirety of the program).
2020-11-13 01:45:51 +01:00
{
// Prioritize unlock.vvv first (2.2 and below),
// but settings have been migrated to settings.vvv (2.3 and up)
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
struct ScreenSettings screen_settings;
Explicitly zero declared `struct ScreenSettings`s Performance cost is negligible and well worth being safe in case there are more members added in the future but we forget to initialize them.
2021-12-25 09:22:22 +01:00
SDL_zero(screen_settings);
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
ScreenSettings_default(&screen_settings);
Remove duplicate screen configuration variables There were some duplicate Screen configuration variables that were on Game, when there didn't need to be. - game.fullScreenEffect_badSignal is a duplicate of graphics.screenbuffer->badSignalEffect - game.fullscreen is a duplicate of !graphics.screenbuffer->isWindowed - game.stretchMode is a duplicate of graphics.screenbuffer->stretchMode - game.useLinearFilter is a duplicate of graphics.screenbuffer->isFiltered These duplicate variables have been removed now. I put indentation when handling the ScreenSettings struct in main() so the local doesn't live for the entirety of main() (which is the entirety of the program).
2020-11-13 01:45:51 +01:00
game.loadstats(&screen_settings);
game.loadsettings(&screen_settings);
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
gameScreen.init(&screen_settings);
Remove duplicate screen configuration variables There were some duplicate Screen configuration variables that were on Game, when there didn't need to be. - game.fullScreenEffect_badSignal is a duplicate of graphics.screenbuffer->badSignalEffect - game.fullscreen is a duplicate of !graphics.screenbuffer->isWindowed - game.stretchMode is a duplicate of graphics.screenbuffer->stretchMode - game.useLinearFilter is a duplicate of graphics.screenbuffer->isFiltered These duplicate variables have been removed now. I put indentation when handling the ScreenSettings struct in main() so the local doesn't live for the entirety of main() (which is the entirety of the program).
2020-11-13 01:45:51 +01:00
}
Refactor startup to load config before calling Screen::init
2020-07-08 20:30:57 +02:00
Start rewrite of font system This is still a work in progress, but the existing font system has been removed and replaced by a new one, in Font.cpp. Design goals of the new font system include supporting colored button glyphs, different fonts for different languages, and larger fonts than 8x8 for Chinese, Japanese and Korean, while being able to support their 30000+ characters without hiccups, slowdowns or high memory usage. And to have more flexibility with fonts in general. Plus, Graphics.cpp was long enough as-is, so it's good to have a dedicated file for font storage. The old font system worked with a std::vector<SDL_Surface*> to store 8x8 surfaces for each character, and a std::map<int,int> to store mappings between codepoints and vector indexes. The new system has a per-font collection of pages for every block of 0x1000 (4096) codepoints, that may be allocated as needed. A glyph on a page contains the index of the glyph in the image (giving its coordinates), the advance (how much the cursor should advance, so the width of that glyph) and some flags which would be at least whether the glyph exists and whether it is colored. Most of the *new* features aren't implemented yet; it's currently hardcoded to the regular 8x8 font.png, but it should be functionally equivalent to the previous behavior. The only thing that doesn't really work yet is level-specific font.png, but that'll be supported again soon enough. This commit also adds fontmeta (xml) support. Since the fonts folder is mounted at graphics/, there are two main options for recognizing non-font.png fonts: the font files have to be prefixed with font (or font_) or some special file extension is involved to signal what files are fonts. I always had a font.xml in mind (so font_cn.xml, font_ja.xml, etc) but if there's ever gonna be a need for further xml files inside the graphics folder, we have a problem. So I named them .fontmeta instead. A .fontmeta file looks somewhat like this: <?xml version="1.0" encoding="UTF-8"?> <font_metadata> <width>12</width> <height>12</height> <white_teeth>1</white_teeth> <chars> <range start="0x20" end="0x7E"/> <range start="0x80" end="0x80"/> <range start="0xA0" end="0xDF"/> <range start="0x250" end="0x2A8"/> <range start="0x2AD" end="0x2AD"/> <range start="0x2C7" end="0x2C7"/> <range start="0x2C9" end="0x2CB"/> ... </chars> <special> <range start="0x00" end="0x1F" advance="6"/> <range start="0x61" end="0x66" color="1"/> <range start="0x63" end="0x63" color="0"/> </special> </font_metadata> The <chars> tag can be used to specify characters instead of in a .txt. The original idea was to just always use the existing .txt system for specifying the font charset, and only use the XML for the other stuff that the .txt doesn't cover. However, it's probably better to keep it simple if possible - having to only have a .png and a .fontmeta seems simpler than having the data spread out over three files. And a major advantage: Chinese fonts can have about 30000 characters! It's more efficient to be able to have a tag saying "now there's 20902 characters starting at U+4E00" than to include them all in a text file and having to UTF-8 decode every single one of them. If a font.txt exists, it takes priority over the <chars> tag, and in that case, there's no reason to include the <chars> tag in the XML. But font.txt has to be in the same directory as font.png, otherwise it is rejected. Same for font.fontmeta. If neither font.txt nor <chars> exist, then the font is seen as a 2.2-and-below-style ASCII font. In <special>: advance is the number of pixels the cursor advances after drawing the character (so the width of the character, without affecting the grid in the source image), color is whether the character should have its original colors retained when printed (for button glyphs). As for <white_teeth>: The renderer PR has replaced draw-time whitening of sprites/etc (using BlitSurfaceColoured) by load-time whitening of entire images (using LoadImage with TEX_WHITE as an argument). This means we have a problem: fonts have always had their glyphs whitened at printing time, and since I'm adding support for colored button glyphs, I changed it so glyphs would sometimes not be whitened. But if we can't whiten at print time, then we'd need to whiten at load time, and if we whiten the entire font, any colored glyphs will get destroyed too. If you whiten the image selectively, well, we need more code to target specific squares in the image, and it's kind of a waste when you need to whiten 30000 12x12 Chinese characters when you're only going to need a handful, but you don't know which ones. The solution: Whitening fonts is useless if all the non-colored glyphs are already white, so we don't need to do it anyway! However, any existing fonts that have non-white glyphs (and I know of at least one level like that) will still need to be whitened. So there is now a font property <white_teeth> that can be specified in the fontmeta, which indicates that the font is already pre-whitened. If not specified, traditional whitening behavior will be used, and the font cannot use colored glyphs.
2023-01-02 05:14:53 +01:00
font::load_main();
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
// This loads music too...
if (!graphics.reloadresources())
{
/* Something wrong with the default assets? We can't use them to
* display the error message, and we have to bail. */
SDL_ShowSimpleMessageBox(
SDL_MESSAGEBOX_ERROR,
graphics.error_title,
graphics.error,
NULL
);
VVV_exit(1);
}
Add localization "foundation" (many code changes) This commit adds most of the code changes necessary for making the game translatable, but does not yet "unhardcode" nearly all of the strings (except in a few cases where it was hard to separate added loc::gettexts from foundational code changes, or all the localization- related menus which were also added by this commit.) This commit is part of rewritten history of the localization branch. The original (unsquashed) commit history can be found here: https://github.com/Dav999-v/VVVVVV/tree/localization-orig
2022-12-30 22:57:24 +01:00
loc::loadtext(false);
loc::loadlanguagelist();
game.createmenu(Menu::mainmenu);
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.create_buffers();
Add VSync graphics option, off by default This is if you want delta-timesteps to go as quickly as possible. Also it seems like on Windows this only has an effect in exclusive fullscreen mode.
2020-05-04 22:19:47 +02:00
Add an accessibility option to toggle the fake loading screen (#63)
2020-01-13 02:45:44 +01:00
if (game.skipfakeload)
game.gamestate = TITLEMODE;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
if (game.slowdown == 0) game.slowdown = 30;
Add localization "foundation" (many code changes) This commit adds most of the code changes necessary for making the game translatable, but does not yet "unhardcode" nearly all of the strings (except in a few cases where it was hard to separate added loc::gettexts from foundational code changes, or all the localization- related menus which were also added by this commit.) This commit is part of rewritten history of the localization branch. The original (unsquashed) commit history can be found here: https://github.com/Dav999-v/VVVVVV/tree/localization-orig
2022-12-30 22:57:24 +01:00
if (!loc::lang_set)
{
game.gamestate = TITLEMODE;
game.menustart = true;
game.createmenu(Menu::language);
game.currentmenuoption = loc::languagelist_curlang;
}
Fix mixed indentation in main.cpp Also fix the indentation of preprocessor statements.
2020-04-02 23:43:50 +02:00
//Check to see if you've already unlocked some achievements here from before the update
if (game.swnbestrank > 0){
Fix #380 Achievements could be unlocked in custom levels/make and play, so this adds the wrapper function `game.unlockAchievement` which calls `NETWORK_unlockAchievement` if `map.custommode` is false. Also, this function and `Game::unlocknum` have both been `ifdef`ed to be empty if MAKEANDPLAY is defined.
2020-08-01 21:49:07 +02:00
if(game.swnbestrank >= 1) game.unlockAchievement("vvvvvvsupgrav5");
if(game.swnbestrank >= 2) game.unlockAchievement("vvvvvvsupgrav10");
if(game.swnbestrank >= 3) game.unlockAchievement("vvvvvvsupgrav15");
if(game.swnbestrank >= 4) game.unlockAchievement("vvvvvvsupgrav20");
if(game.swnbestrank >= 5) game.unlockAchievement("vvvvvvsupgrav30");
if(game.swnbestrank >= 6) game.unlockAchievement("vvvvvvsupgrav60");
Fix mixed indentation in main.cpp Also fix the indentation of preprocessor statements.
2020-04-02 23:43:50 +02:00
}
Fix #380 Achievements could be unlocked in custom levels/make and play, so this adds the wrapper function `game.unlockAchievement` which calls `NETWORK_unlockAchievement` if `map.custommode` is false. Also, this function and `Game::unlocknum` have both been `ifdef`ed to be empty if MAKEANDPLAY is defined.
2020-08-01 21:49:07 +02:00
if(game.unlock[5]) game.unlockAchievement("vvvvvvgamecomplete");
if(game.unlock[19]) game.unlockAchievement("vvvvvvgamecompleteflip");
if(game.unlock[20]) game.unlockAchievement("vvvvvvmaster");
Fix mixed indentation in main.cpp Also fix the indentation of preprocessor statements.
2020-04-02 23:43:50 +02:00
if (game.bestgamedeaths > -1) {
if (game.bestgamedeaths <= 500) {
Fix #380 Achievements could be unlocked in custom levels/make and play, so this adds the wrapper function `game.unlockAchievement` which calls `NETWORK_unlockAchievement` if `map.custommode` is false. Also, this function and `Game::unlocknum` have both been `ifdef`ed to be empty if MAKEANDPLAY is defined.
2020-08-01 21:49:07 +02:00
game.unlockAchievement("vvvvvvcomplete500");
Fix mixed indentation in main.cpp Also fix the indentation of preprocessor statements.
2020-04-02 23:43:50 +02:00
}
if (game.bestgamedeaths <= 250) {
Fix #380 Achievements could be unlocked in custom levels/make and play, so this adds the wrapper function `game.unlockAchievement` which calls `NETWORK_unlockAchievement` if `map.custommode` is false. Also, this function and `Game::unlocknum` have both been `ifdef`ed to be empty if MAKEANDPLAY is defined.
2020-08-01 21:49:07 +02:00
game.unlockAchievement("vvvvvvcomplete250");
Fix mixed indentation in main.cpp Also fix the indentation of preprocessor statements.
2020-04-02 23:43:50 +02:00
}
if (game.bestgamedeaths <= 100) {
Fix #380 Achievements could be unlocked in custom levels/make and play, so this adds the wrapper function `game.unlockAchievement` which calls `NETWORK_unlockAchievement` if `map.custommode` is false. Also, this function and `Game::unlocknum` have both been `ifdef`ed to be empty if MAKEANDPLAY is defined.
2020-08-01 21:49:07 +02:00
game.unlockAchievement("vvvvvvcomplete100");
Fix mixed indentation in main.cpp Also fix the indentation of preprocessor statements.
2020-04-02 23:43:50 +02:00
}
if (game.bestgamedeaths <= 50) {
Fix #380 Achievements could be unlocked in custom levels/make and play, so this adds the wrapper function `game.unlockAchievement` which calls `NETWORK_unlockAchievement` if `map.custommode` is false. Also, this function and `Game::unlocknum` have both been `ifdef`ed to be empty if MAKEANDPLAY is defined.
2020-08-01 21:49:07 +02:00
game.unlockAchievement("vvvvvvcomplete50");
Fix mixed indentation in main.cpp Also fix the indentation of preprocessor statements.
2020-04-02 23:43:50 +02:00
}
}
Fix #380 Achievements could be unlocked in custom levels/make and play, so this adds the wrapper function `game.unlockAchievement` which calls `NETWORK_unlockAchievement` if `map.custommode` is false. Also, this function and `Game::unlocknum` have both been `ifdef`ed to be empty if MAKEANDPLAY is defined.
2020-08-01 21:49:07 +02:00
if(game.bestrank[0]>=3) game.unlockAchievement("vvvvvvtimetrial_station1_fixed");
if(game.bestrank[1]>=3) game.unlockAchievement("vvvvvvtimetrial_lab_fixed");
if(game.bestrank[2]>=3) game.unlockAchievement("vvvvvvtimetrial_tower_fixed");
if(game.bestrank[3]>=3) game.unlockAchievement("vvvvvvtimetrial_station2_fixed");
if(game.bestrank[4]>=3) game.unlockAchievement("vvvvvvtimetrial_warp_fixed");
if(game.bestrank[5]>=3) game.unlockAchievement("vvvvvvtimetrial_final_fixed");
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
obj.init();
Fix NO_CUSTOM_LEVELS builds breaking after command-line playtesting
2020-04-16 01:51:58 +02:00
#if !defined(NO_CUSTOM_LEVELS)
Implement command-line playtesting (#163)
2020-04-09 21:03:24 +02:00
if (startinplaytest) {
game.levelpage = 0;
game.playcustomlevel = 0;
Add -playassets command-line option This is used if you're loading a level file from STDIN. The game needs to know the actual level assets directory you're referring to, since when it gets the level from STDIN, it doesn't know the actual filename of the level. Fixes #309.
2020-06-22 00:56:31 +02:00
game.playassets = playassets;
Fixed the title screen showing up when going to graphics options while playtesting.
2020-08-13 14:59:14 +02:00
game.menustart = true;
Implement command-line playtesting (#163)
2020-04-09 21:03:24 +02:00
LevelMetaData meta;
Add support for start position via level XML for CLI playtesting As already described in cc61194bed324e9fbf51847915357d613a94ff47, as well as Ved's commits from the last almost two weeks, starting VVVVVV from Ved for playtesting could be made a lot faster by "preloading" the game - letting it do all its asset loading in the background without creating a window - and then waiting until the level is passed in via stdin. There's only one problem left with this approach: VVVVVV currently expects the starting position to be passed via command line arguments, which isn't known yet at the time we'd like to start VVVVVV. Therefore, this commit allows passing the starting position via the level XML, instead of via arguments. The extra XML looks like this, and is added next to the <Data> tag: <Playtest> <playx>214</playx> <playy>112</playy> <playrx>100</playrx> <playry>100</playry> <playgc>0</playgc> <playmusic>4</playmusic> </Playtest> This is handled similarly to how the equivalent arguments are handled: when the level metadata is loaded for CLI playtesting, we also try to find this tag, and if it exists, it sets the same variables that the arguments would have otherwise set.
2022-06-19 22:41:48 +02:00
CliPlaytestArgs pt_args;
if (cl.getLevelMetaDataAndPlaytestArgs(playtestname, meta, &pt_args)) {
Move all editor-specific attributes to a new editorclass This is a pretty hefty commit! But essentially, I made a new editorclass object, and moved all functions and variables that only get used in the in-game level editor to that class. This cleanly demarcates which things are in the editor and which things are just general custom level stuff. Then I fixed up all the callers. I also fixed up some NO_CUSTOM_LEVELS and NO_EDITOR ifdefs, too, in several places.
2021-02-21 00:40:11 +01:00
cl.ListOfMetaData.clear();
cl.ListOfMetaData.push_back(meta);
Implement command-line playtesting (#163)
2020-04-09 21:03:24 +02:00
} else {
Move all editor-specific attributes to a new editorclass This is a pretty hefty commit! But essentially, I made a new editorclass object, and moved all functions and variables that only get used in the in-game level editor to that class. This cleanly demarcates which things are in the editor and which things are just general custom level stuff. Then I fixed up all the callers. I also fixed up some NO_CUSTOM_LEVELS and NO_EDITOR ifdefs, too, in several places.
2021-02-21 00:40:11 +01:00
cl.loadZips();
Add support for start position via level XML for CLI playtesting As already described in cc61194bed324e9fbf51847915357d613a94ff47, as well as Ved's commits from the last almost two weeks, starting VVVVVV from Ved for playtesting could be made a lot faster by "preloading" the game - letting it do all its asset loading in the background without creating a window - and then waiting until the level is passed in via stdin. There's only one problem left with this approach: VVVVVV currently expects the starting position to be passed via command line arguments, which isn't known yet at the time we'd like to start VVVVVV. Therefore, this commit allows passing the starting position via the level XML, instead of via arguments. The extra XML looks like this, and is added next to the <Data> tag: <Playtest> <playx>214</playx> <playy>112</playy> <playrx>100</playrx> <playry>100</playry> <playgc>0</playgc> <playmusic>4</playmusic> </Playtest> This is handled similarly to how the equivalent arguments are handled: when the level metadata is loaded for CLI playtesting, we also try to find this tag, and if it exists, it sets the same variables that the arguments would have otherwise set.
2022-06-19 22:41:48 +02:00
if (cl.getLevelMetaDataAndPlaytestArgs(playtestname, meta, &pt_args)) {
Move all editor-specific attributes to a new editorclass This is a pretty hefty commit! But essentially, I made a new editorclass object, and moved all functions and variables that only get used in the in-game level editor to that class. This cleanly demarcates which things are in the editor and which things are just general custom level stuff. Then I fixed up all the callers. I also fixed up some NO_CUSTOM_LEVELS and NO_EDITOR ifdefs, too, in several places.
2021-02-21 00:40:11 +01:00
cl.ListOfMetaData.clear();
cl.ListOfMetaData.push_back(meta);
Fixed some custom asset bugs, added .zip level loading Main game would retain custom level assets, now fixed. Also, custom fonts load properly. Finally, levels can be stored as a zip and placed in the levels folder, with the .vvvvvv file at the root of the zip and custom asset folders (graphics, sounds etc) also at the root.
2020-06-03 20:05:09 +02:00
} else {
Replace all print calls with vlog calls This is pretty straight-forward to do.
2021-02-24 00:21:29 +01:00
vlog_error("Level not found");
Clean up all program close paths to use VVV_exit() Wow, there are a lot of these. All of these exit paths now use VVV_exit() instead, which attempts to save unlock.vvv and settings.vvv, and also frees all resources so Valgrind is happy. This is a good thing, because previously unlock.vvv/settings.vvv wouldn't be written to if we decided to bail for a given reason.
2021-02-16 03:53:17 +01:00
VVV_exit(1);
Fixed some custom asset bugs, added .zip level loading Main game would retain custom level assets, now fixed. Also, custom fonts load properly. Finally, levels can be stored as a zip and placed in the levels folder, with the .vvvvvv file at the root of the zip and custom asset folders (graphics, sounds etc) also at the root.
2020-06-03 20:05:09 +02:00
}
Implement command-line playtesting (#163)
2020-04-09 21:03:24 +02:00
}
Add support for start position via level XML for CLI playtesting As already described in cc61194bed324e9fbf51847915357d613a94ff47, as well as Ved's commits from the last almost two weeks, starting VVVVVV from Ved for playtesting could be made a lot faster by "preloading" the game - letting it do all its asset loading in the background without creating a window - and then waiting until the level is passed in via stdin. There's only one problem left with this approach: VVVVVV currently expects the starting position to be passed via command line arguments, which isn't known yet at the time we'd like to start VVVVVV. Therefore, this commit allows passing the starting position via the level XML, instead of via arguments. The extra XML looks like this, and is added next to the <Data> tag: <Playtest> <playx>214</playx> <playy>112</playy> <playrx>100</playrx> <playry>100</playry> <playgc>0</playgc> <playmusic>4</playmusic> </Playtest> This is handled similarly to how the equivalent arguments are handled: when the level metadata is loaded for CLI playtesting, we also try to find this tag, and if it exists, it sets the same variables that the arguments would have otherwise set.
2022-06-19 22:41:48 +02:00
if (pt_args.valid)
{
savefileplaytest = true;
savex = pt_args.x;
savey = pt_args.y;
saverx = pt_args.rx;
savery = pt_args.ry;
savegc = pt_args.gc;
savemusic = pt_args.music;
}
Implement command-line playtesting (#163)
2020-04-09 21:03:24 +02:00
game.loadcustomlevelstats();
Move all editor-specific attributes to a new editorclass This is a pretty hefty commit! But essentially, I made a new editorclass object, and moved all functions and variables that only get used in the in-game level editor to that class. This cleanly demarcates which things are in the editor and which things are just general custom level stuff. Then I fixed up all the callers. I also fixed up some NO_CUSTOM_LEVELS and NO_EDITOR ifdefs, too, in several places.
2021-02-21 00:40:11 +01:00
game.customleveltitle=cl.ListOfMetaData[game.playcustomlevel].title;
game.customlevelfilename=cl.ListOfMetaData[game.playcustomlevel].filename;
Implement command-line playtesting (#163)
2020-04-09 21:03:24 +02:00
if (savefileplaytest) {
game.playx = savex;
game.playy = savey;
game.playrx = saverx;
game.playry = savery;
game.playgc = savegc;
Fix -playmusic command line option not working There's a bug where playtesting from Ved doesn't properly play the music of the level, due to no fault with Ved. This was because the music was being faded out by scriptclass::startgamemode() case 23 after main() called music.play(). To fix this, just call music.play() when all the other variables are being set in Game::customloadquick().
2020-07-11 20:55:26 +02:00
game.playmusic = savemusic;
Implement command-line playtesting (#163)
2020-04-09 21:03:24 +02:00
game.cliplaytest = true;
Refactor scriptclass::startgamemode This overhauls scriptclass::gamemode massively. The first change is that it now uses an enum, and enforces using that enum via using its type instead of an int. This is because whenever you're reading any calls to startgamemode, you have no idea what magic number actually corresponds to what unless you read startgamemode itself. And when you do read it, not every case is commented adequately, so you'd have to do more work to figure out what each case is. With the enum, it's obvious and self-evident, and that also removes the need for all the comments in the function too. Some math is still done on mode variables (to simplify time trial code), but it's okay, we can just cast between int and the enum as needed. The second is that common code is now de-duplicated. There was a lot of code that every case does, such as calling hardreset, setting Flip Mode, resetting the player, calling gotoroom and so on. Now some code may be duplicated between cases, so I've tried to group up similar cases where possible (most notable example is grouping up the main game and No Death Mode cases together). But some code still might be duplicated in the end. Which is okay - I could've tried to de-duplicate it further but that just results in logic relevant to a specific case that's located far from the actual case itself. It's much better to leave things like setting fademode or loading scripts in the case itself. This also fixes a bug since 2.3 where playing No Death Mode (and never opening and closing the options menu) and beating it would also give you the Flip Mode trophy, since turning on the flag to invalidate Flip Mode in startgamemode only happened for the main game cases and in previous versions the game relied upon this flag being set when using a teleporter for some reason (which I removed in 2.3). Now instead of specifying it per case, I just do a !map.custommode check instead so it covers every single case at once.
2022-12-29 23:01:36 +01:00
script.startgamemode(Start_CUSTOM_QUICKSAVE);
Implement command-line playtesting (#163)
2020-04-09 21:03:24 +02:00
} else {
Refactor scriptclass::startgamemode This overhauls scriptclass::gamemode massively. The first change is that it now uses an enum, and enforces using that enum via using its type instead of an int. This is because whenever you're reading any calls to startgamemode, you have no idea what magic number actually corresponds to what unless you read startgamemode itself. And when you do read it, not every case is commented adequately, so you'd have to do more work to figure out what each case is. With the enum, it's obvious and self-evident, and that also removes the need for all the comments in the function too. Some math is still done on mode variables (to simplify time trial code), but it's okay, we can just cast between int and the enum as needed. The second is that common code is now de-duplicated. There was a lot of code that every case does, such as calling hardreset, setting Flip Mode, resetting the player, calling gotoroom and so on. Now some code may be duplicated between cases, so I've tried to group up similar cases where possible (most notable example is grouping up the main game and No Death Mode cases together). But some code still might be duplicated in the end. Which is okay - I could've tried to de-duplicate it further but that just results in logic relevant to a specific case that's located far from the actual case itself. It's much better to leave things like setting fademode or loading scripts in the case itself. This also fixes a bug since 2.3 where playing No Death Mode (and never opening and closing the options menu) and beating it would also give you the Flip Mode trophy, since turning on the flag to invalidate Flip Mode in startgamemode only happened for the main game cases and in previous versions the game relied upon this flag being set when using a teleporter for some reason (which I removed in 2.3). Now instead of specifying it per case, I just do a !map.custommode check instead so it covers every single case at once.
2022-12-29 23:01:36 +01:00
script.startgamemode(Start_CUSTOM);
Implement command-line playtesting (#163)
2020-04-09 21:03:24 +02:00
}
Enumify all fade modes This removes the magic numbers previously used for controlling the fade mode, which are really not readable at all unless you already know what they mean. 0: FADE_NONE 1: FADE_FULLY_BLACK 2: FADE_START_FADEOUT 3: FADE_FADING_OUT 4: FADE_START_FADEIN 5: FADE_FADING_IN There is also the macro FADEMODE_IS_FADING, which indicates when the intention is to only check if the game is fading right now, which wasn't clearly conveyed previously. I also took the opportunity to clean up the style of any lines I touched. This included rewriting if-else chains into case-switches, turning one-liner if-then statements into proper blocks, fixing up comments, and even commenting the `fademode == FADE_NONE` on the tower spike checks (which, it was previously undocumented why that check was there, but I think I know why it's there). As for type safety, we already get some by transforming the variable types into the enum. Assignment is prohibited without a cast. But, apparently, comparison is perfectly legal and won't even give so much as a warning. To work around this and make absolutely sure I made all existing comparisons now use the enum, I temporarily changed it to be an `enum class`, which is a C++11 feature that makes it so all comparisons are illegal. Unfortunately, it scopes them in a namespace with the same name as a class, so I had to temporarily define macros to make sure my existing code worked. I also had to temporarily up the standard in CMakeLists.txt to get it to compile. But after all that was done, I found the rest of the places where a comparison to an integer was used, and fixed them.
2022-04-25 09:57:47 +02:00
graphics.fademode = FADE_NONE;
Implement command-line playtesting (#163)
2020-04-09 21:03:24 +02:00
}
Fix NO_CUSTOM_LEVELS builds breaking after command-line playtesting
2020-04-16 01:51:58 +02:00
#endif
Implement command-line playtesting (#163)
2020-04-09 21:03:24 +02:00
Move `SDL_ShowWindow` to after assets are loaded This is a minor optimization to streamline the experience of Ved playtesting. Previously, the user would have to wait for all the assets to load when launching playtesting (most of the time, I suspect, is taken up by loading music from a vvvvvvmusic blob). With this optimization, however, the game can be launched in the background and its assets can be loaded, while it blocks on STDIN input. During this time, the user in Ved will be choosing where to start playtesting. After Ved provides STDIN input, then the window will be created and appears instantaneously. This also fixes a related issue in which providing an invalid playtesting level name would result in a brief window flash that gets instantly destroyed. With this, if the level is invalid then no window is ever shown at all.
2022-06-02 01:42:22 +02:00
/* Only create the window after we have loaded all the assets. */
SDL_ShowWindow(gameScreen.m_window);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
key.isActive = true;
Generalize game loop order and fix it to what it was in 2.2 Okay, so the reason why all render functions were moved to the end of the frame in #220 is because it's simpler to call two fixed functions and then a delta function instead of one fixed function, then a delta function, and then another fixed function. This is because fixed functions need special handling inside deltaloop(), and you can't simply duplicate this handling after calling a delta function. Oh, and to make matters worse, it's not always fixed-delta-fixed, sometimes (like in MAPMODE and TELEPORTERMODE) it's delta-fixed-fixed, so we'd need to handle that somehow too. The solution here is to generalize the game loop and factor out each function, instead of hardcoding it. Instead of having hardcoded case-switches directly in the loop, I made a function that returns an array of functions for a given gamestate, along with the number of functions, then the game loop processes it accordingly. In fixedloop(), it iterates over the array and executes each function until it reaches a delta function, at which point it stops. And when it reaches the end of the array, it goes back to the start of the array. But anyway, if it gets to a delta function, it'll stop the loop and finish fixedloop(). Then deltaloop() will call the delta function. And then on the next frame, the function index will be incremented again, so fixedloop() will call the fixed functions again. Actually, the previous game loop was actually made up of one big loop, with a gamestate function loop nested inside it, flanked with code that ran at the start and end of the "big loop". This would be easy to handle with one loop (just include the beginning and end functions with the gamestate functions in the array), except that the gamestate functions could suddenly be swapped out with unfocused functions (the ones that run when you unfocus the window) at any time (well, on frame boundaries, since key.isActive only got checked once, guarding the entire "inner loop" - and I made sure that changing key.isActive wouldn't immediately apply, just like the previous game loop order) - so I had to add yet another layer of indirection, where the gamestate functions could immediately be swapped out with the unfocused functions (while still running the beginning and end code, because that was how the previous loop order worked, after all). This also fixes a regression that the game loop that #220 introduced had, where if the fixed functions switched the gamestate, the game would prematurely start rendering the gamestate function of the new gamestate in the deltaframes, which was a source of some deltaframe glitches. But fixing this is likely to just as well cause deltaframe glitches, so it'd be better to fix this along with fixing the loop order, and only have one round of QA to do in the end, instead of doing one round after each change separately. Fixes #464... but this isn't the end of the patchset. There are bugs that need to be fixed, and kludges that need to be reverted.
2020-11-07 01:08:22 +01:00
gamestate_funcs = get_gamestate_funcs(game.gamestate, &num_gamestate_funcs);
loop_assign_active_funcs();
Use Emscripten's main loop On Emscripten, SDL_Delay is implemented as a busy loop. In addition, everything happens on a single thread. This effectively means that you have to let Emscripten manage the main loop, since if you do it yourself the browser will just be frozen.
2021-03-31 21:06:26 +02:00
#ifdef __EMSCRIPTEN__
emscripten_set_main_loop(emscriptenloop, 0, 0);
#else
Call VVV_exit() when SDL_QUIT is received This fixes a regression introduced by #535 where a quit signal (e.g. Ctrl-C) sent to the window while the game was in unfocus pause wouldn't close the game. One problem was that key.quitProgram would only be checked when control flow switched back to the outer loop in main(), which would only happen when the loop order state machine switched to a delta function. As the unfocused func table didn't have any delta functions, this means key.quitProgram would never be checked. So a naïve solution to this would just be to add a no-op delta func entry to the unfocused func table. However, we then run into a separate issue where a delta function at the end of a func list never reassigns the active funcs, causing the game to be stuck in the unfocus pause forever. Active func reassignment only happens after fixed funcs. So then a naïve solution after that would be to simply add a no-op fixed func entry after that. And indeed, that would fix the whole issue. However, I want to do things the right way. And this does not seem like the right way. Even putting aside the separate last-func-being-delta issue, it mandates that every func list needs a delta function. Which seems quite unnecessary to me. Another solution I considered was copy-pasting the key.quitProgram check to the inner loops, or adding some sort of signal propagation to the inner loops - implemented by copy-pasting checks after each loop - so we didn't need to copy-paste key.quitProgram... but that seems really messy, too. So, I realized that we could throw away key.quitProgram, and simply call VVV_exit() directly when we receive an SDL_QUIT event. This fixes the issue, this removes an unnecessary middleman variable, and it's pretty cleanly and simply the right thing to do.
2021-04-02 00:24:14 +02:00
while (true)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Switch over to using `SDL_GetTicks64()` SDL_GetTicks64() is a function that got added in SDL 2.0.18, which is just an SDL_GetTicks() without a value that wraps every ~49 days, instead wrapping after the sun explodes and kills us all. Oh sorry, didn't mean to get existential. For now, put this behind an SDL_VERSION_ATLEAST guard, which will be removed when SDL 2.0.18 officially releases and we can update to it.
2021-10-26 03:16:47 +02:00
f_time = SDL_GetTicks64();
Optimize 30-mode FPS loop to use SDL_Delay() This patch optimizes the loop used to limit the framerate in 30-FPS-only mode so that it uses SDL_Delay() instead of an accumulator. This means that the game will take up less CPU power in 30-FPS-only mode. This also means that the game loop code has been simplified, so there's only two while-loops, and only two places where game.over30mode is checked, thus leading to easier-to-understand logic. Using an accumulator here would essentially mean busywaiting until the 34 millisecond timer was up. (The following is just what leo60228 told me.) Busywaiting is bad because it's inefficient. The operating system assumes that if you're busywaiting, you're performing a complex calculation and handles your process accordingly. And this is why sleeping was invented, so you could busywait without taking up unnecessary CPU time.
2020-07-14 06:17:20 +02:00
Switch over to using `SDL_GetTicks64()` SDL_GetTicks64() is a function that got added in SDL 2.0.18, which is just an SDL_GetTicks() without a value that wraps every ~49 days, instead wrapping after the sun explodes and kills us all. Oh sorry, didn't mean to get existential. For now, put this behind an SDL_VERSION_ATLEAST guard, which will be removed when SDL 2.0.18 officially releases and we can update to it.
2021-10-26 03:16:47 +02:00
const Uint64 f_timetaken = f_time - f_timePrev;
Optimize 30-mode FPS loop to use SDL_Delay() This patch optimizes the loop used to limit the framerate in 30-FPS-only mode so that it uses SDL_Delay() instead of an accumulator. This means that the game will take up less CPU power in 30-FPS-only mode. This also means that the game loop code has been simplified, so there's only two while-loops, and only two places where game.over30mode is checked, thus leading to easier-to-understand logic. Using an accumulator here would essentially mean busywaiting until the 34 millisecond timer was up. (The following is just what leo60228 told me.) Busywaiting is bad because it's inefficient. The operating system assumes that if you're busywaiting, you're performing a complex calculation and handles your process accordingly. And this is why sleeping was invented, so you could busywait without taking up unnecessary CPU time.
2020-07-14 06:17:20 +02:00
if (!game.over30mode && f_timetaken < 34)
Add being able to toggle over/fixed-30-FPS, off by default There is now an option in "graphic options" named "toggle fps", which toggles whether the game visually runs at 1000/34 FPS or over 1000/34 FPS. It is off by default. I've had to put the entire game loop in yet another set of braces, I'll indent it next commit.
2020-05-04 21:52:57 +02:00
{
Switch over to using `SDL_GetTicks64()` SDL_GetTicks64() is a function that got added in SDL 2.0.18, which is just an SDL_GetTicks() without a value that wraps every ~49 days, instead wrapping after the sun explodes and kills us all. Oh sorry, didn't mean to get existential. For now, put this behind an SDL_VERSION_ATLEAST guard, which will be removed when SDL 2.0.18 officially releases and we can update to it.
2021-10-26 03:16:47 +02:00
const volatile Uint64 f_delay = 34 - f_timetaken;
SDL_Delay((Uint32) f_delay);
f_time = SDL_GetTicks64();
Add being able to toggle over/fixed-30-FPS, off by default There is now an option in "graphic options" named "toggle fps", which toggles whether the game visually runs at 1000/34 FPS or over 1000/34 FPS. It is off by default. I've had to put the entire game loop in yet another set of braces, I'll indent it next commit.
2020-05-04 21:52:57 +02:00
}
Optimize 30-mode FPS loop to use SDL_Delay() This patch optimizes the loop used to limit the framerate in 30-FPS-only mode so that it uses SDL_Delay() instead of an accumulator. This means that the game will take up less CPU power in 30-FPS-only mode. This also means that the game loop code has been simplified, so there's only two while-loops, and only two places where game.over30mode is checked, thus leading to easier-to-understand logic. Using an accumulator here would essentially mean busywaiting until the 34 millisecond timer was up. (The following is just what leo60228 told me.) Busywaiting is bad because it's inefficient. The operating system assumes that if you're busywaiting, you're performing a complex calculation and handles your process accordingly. And this is why sleeping was invented, so you could busywait without taking up unnecessary CPU time.
2020-07-14 06:17:20 +02:00
f_timePrev = f_time;
timePrev = time_;
Switch over to using `SDL_GetTicks64()` SDL_GetTicks64() is a function that got added in SDL 2.0.18, which is just an SDL_GetTicks() without a value that wraps every ~49 days, instead wrapping after the sun explodes and kills us all. Oh sorry, didn't mean to get existential. For now, put this behind an SDL_VERSION_ATLEAST guard, which will be removed when SDL 2.0.18 officially releases and we can update to it.
2021-10-26 03:16:47 +02:00
time_ = SDL_GetTicks64();
Optimize 30-mode FPS loop to use SDL_Delay() This patch optimizes the loop used to limit the framerate in 30-FPS-only mode so that it uses SDL_Delay() instead of an accumulator. This means that the game will take up less CPU power in 30-FPS-only mode. This also means that the game loop code has been simplified, so there's only two while-loops, and only two places where game.over30mode is checked, thus leading to easier-to-understand logic. Using an accumulator here would essentially mean busywaiting until the 34 millisecond timer was up. (The following is just what leo60228 told me.) Busywaiting is bad because it's inefficient. The operating system assumes that if you're busywaiting, you're performing a complex calculation and handles your process accordingly. And this is why sleeping was invented, so you could busywait without taking up unnecessary CPU time.
2020-07-14 06:17:20 +02:00
deltaloop();
Put the main game loop inside its own function Makes main() less of one giant blob of code.
2020-06-14 20:45:36 +02:00
}
Move cleanup code to separate function I will need to re-use this code, so it's best that it not be copy-pasted.
2021-02-16 02:52:41 +01:00
cleanup();
Use Emscripten's main loop On Emscripten, SDL_Delay is implemented as a busy loop. In addition, everything happens on a single thread. This effectively means that you have to let Emscripten manage the main loop, since if you do it yourself the browser will just be frozen.
2021-03-31 21:06:26 +02:00
#endif
Move cleanup code to separate function I will need to re-use this code, so it's best that it not be copy-pasted.
2021-02-16 02:52:41 +01:00
return 0;
}
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
static void cleanup(void)
Move cleanup code to separate function I will need to re-use this code, so it's best that it not be copy-pasted.
2021-02-16 02:52:41 +01:00
{
Clean up all leftover resources in cleanup() If there's a resource that doesn't otherwise need to be cleaned up and is still alive upon program shutdown, then it should go in cleanup(). This cleans up Screen, GraphicsResources, Graphics buffers, Graphics tiles, and musicclass audio upon program shutdown. Even we technically don't NEED to clean these resources up ourselves (the kernel is going to get rid of all of it anyway, else it'd be a security problem), I'm doing this because otherwise Valgrind will complain about these, and then it'd be difficult to see which memory leaks are real and which are just "well this isn't really a leak but you haven't freed this thing when the process exited, and that's technically what a memory leak is". These are all resources whose cleanup functions can be safely called even if they haven't initialized anything yet.
2021-02-16 03:43:35 +01:00
/* Order matters! */
`cleanup`: Don't `savestatsandsettings` if filesystem not init This isn't necessary, but it does silence these annoying logs if you pass an invalid argument or don't have data.zip: [ERROR] Could not get window size: Invalid renderer [WARN] Stats not loaded! Not writing unlock.vvv. [ERROR] Could not get window size: Invalid renderer [WARN] Settings not loaded! Not writing settings.vvv. To do this, I've added FILESYSTEM_isInit().
2022-03-14 18:45:19 +01:00
if (FILESYSTEM_isInit()) /* not necessary but silences logs */
{
game.savestatsandsettings();
}
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
Clean up all leftover resources in cleanup() If there's a resource that doesn't otherwise need to be cleaned up and is still alive upon program shutdown, then it should go in cleanup(). This cleans up Screen, GraphicsResources, Graphics buffers, Graphics tiles, and musicclass audio upon program shutdown. Even we technically don't NEED to clean these resources up ourselves (the kernel is going to get rid of all of it anyway, else it'd be a security problem), I'm doing this because otherwise Valgrind will complain about these, and then it'd be difficult to see which memory leaks are real and which are just "well this isn't really a leak but you haven't freed this thing when the process exited, and that's technically what a memory leak is". These are all resources whose cleanup functions can be safely called even if they haven't initialized anything yet.
2021-02-16 03:43:35 +01:00
graphics.grphx.destroy();
graphics.destroy_buffers();
graphics.destroy();
Start rewrite of font system This is still a work in progress, but the existing font system has been removed and replaced by a new one, in Font.cpp. Design goals of the new font system include supporting colored button glyphs, different fonts for different languages, and larger fonts than 8x8 for Chinese, Japanese and Korean, while being able to support their 30000+ characters without hiccups, slowdowns or high memory usage. And to have more flexibility with fonts in general. Plus, Graphics.cpp was long enough as-is, so it's good to have a dedicated file for font storage. The old font system worked with a std::vector<SDL_Surface*> to store 8x8 surfaces for each character, and a std::map<int,int> to store mappings between codepoints and vector indexes. The new system has a per-font collection of pages for every block of 0x1000 (4096) codepoints, that may be allocated as needed. A glyph on a page contains the index of the glyph in the image (giving its coordinates), the advance (how much the cursor should advance, so the width of that glyph) and some flags which would be at least whether the glyph exists and whether it is colored. Most of the *new* features aren't implemented yet; it's currently hardcoded to the regular 8x8 font.png, but it should be functionally equivalent to the previous behavior. The only thing that doesn't really work yet is level-specific font.png, but that'll be supported again soon enough. This commit also adds fontmeta (xml) support. Since the fonts folder is mounted at graphics/, there are two main options for recognizing non-font.png fonts: the font files have to be prefixed with font (or font_) or some special file extension is involved to signal what files are fonts. I always had a font.xml in mind (so font_cn.xml, font_ja.xml, etc) but if there's ever gonna be a need for further xml files inside the graphics folder, we have a problem. So I named them .fontmeta instead. A .fontmeta file looks somewhat like this: <?xml version="1.0" encoding="UTF-8"?> <font_metadata> <width>12</width> <height>12</height> <white_teeth>1</white_teeth> <chars> <range start="0x20" end="0x7E"/> <range start="0x80" end="0x80"/> <range start="0xA0" end="0xDF"/> <range start="0x250" end="0x2A8"/> <range start="0x2AD" end="0x2AD"/> <range start="0x2C7" end="0x2C7"/> <range start="0x2C9" end="0x2CB"/> ... </chars> <special> <range start="0x00" end="0x1F" advance="6"/> <range start="0x61" end="0x66" color="1"/> <range start="0x63" end="0x63" color="0"/> </special> </font_metadata> The <chars> tag can be used to specify characters instead of in a .txt. The original idea was to just always use the existing .txt system for specifying the font charset, and only use the XML for the other stuff that the .txt doesn't cover. However, it's probably better to keep it simple if possible - having to only have a .png and a .fontmeta seems simpler than having the data spread out over three files. And a major advantage: Chinese fonts can have about 30000 characters! It's more efficient to be able to have a tag saying "now there's 20902 characters starting at U+4E00" than to include them all in a text file and having to UTF-8 decode every single one of them. If a font.txt exists, it takes priority over the <chars> tag, and in that case, there's no reason to include the <chars> tag in the XML. But font.txt has to be in the same directory as font.png, otherwise it is rejected. Same for font.fontmeta. If neither font.txt nor <chars> exist, then the font is seen as a 2.2-and-below-style ASCII font. In <special>: advance is the number of pixels the cursor advances after drawing the character (so the width of the character, without affecting the grid in the source image), color is whether the character should have its original colors retained when printed (for button glyphs). As for <white_teeth>: The renderer PR has replaced draw-time whitening of sprites/etc (using BlitSurfaceColoured) by load-time whitening of entire images (using LoadImage with TEX_WHITE as an argument). This means we have a problem: fonts have always had their glyphs whitened at printing time, and since I'm adding support for colored button glyphs, I changed it so glyphs would sometimes not be whitened. But if we can't whiten at print time, then we'd need to whiten at load time, and if we whiten the entire font, any colored glyphs will get destroyed too. If you whiten the image selectively, well, we need more code to target specific squares in the image, and it's kind of a waste when you need to whiten 30000 12x12 Chinese characters when you're only going to need a handful, but you don't know which ones. The solution: Whitening fonts is useless if all the non-colored glyphs are already white, so we don't need to do it anyway! However, any existing fonts that have non-white glyphs (and I know of at least one level like that) will still need to be whitened. So there is now a font property <white_teeth> that can be specified in the fontmeta, which indicates that the font is already pre-whitened. If not specified, traditional whitening behavior will be used, and the font cannot use colored glyphs.
2023-01-02 05:14:53 +01:00
font::destroy();
Destroy `gameScreen` after all other graphics are destroyed This is because destroying the renderer causes use-after-frees since the renderer destroys all textures when it gets destroyed. This fixes a Valgrind error where an invalid read occurs because the font textures get destroyed again after the renderer is destroyed.
2023-03-04 01:46:15 +01:00
gameScreen.destroy();
Clean up all leftover resources in cleanup() If there's a resource that doesn't otherwise need to be cleaned up and is still alive upon program shutdown, then it should go in cleanup(). This cleans up Screen, GraphicsResources, Graphics buffers, Graphics tiles, and musicclass audio upon program shutdown. Even we technically don't NEED to clean these resources up ourselves (the kernel is going to get rid of all of it anyway, else it'd be a security problem), I'm doing this because otherwise Valgrind will complain about these, and then it'd be difficult to see which memory leaks are real and which are just "well this isn't really a leak but you haven't freed this thing when the process exited, and that's technically what a memory leak is". These are all resources whose cleanup functions can be safely called even if they haven't initialized anything yet.
2021-02-16 03:43:35 +01:00
music.destroy();
Make room names own their own memory This makes it so room names are no longer pointers to someone else's memory, and instead to set them you use `mapclass::setroomname`. If the string is short enough to fit in a static, no-alloc buffer, then it gets copied there. Otherwise, a new heap allocation is made that duplicates the string, and the new pointer is used instead. This makes it possible for room names to contain arbitrary data whose origin is temporary (e.g. from a script command that could be added in the future).
2022-12-01 07:35:42 +01:00
map.destroy();
Put the main game loop inside its own function Makes main() less of one giant blob of code.
2020-06-14 20:45:36 +02:00
NETWORK_shutdown();
Add localization "foundation" (many code changes) This commit adds most of the code changes necessary for making the game translatable, but does not yet "unhardcode" nearly all of the strings (except in a few cases where it was hard to separate added loc::gettexts from foundational code changes, or all the localization- related menus which were also added by this commit.) This commit is part of rewritten history of the localization branch. The original (unsquashed) commit history can be found here: https://github.com/Dav999-v/VVVVVV/tree/localization-orig
2022-12-30 22:57:24 +01:00
loc::resettext(true);
Put the main game loop inside its own function Makes main() less of one giant blob of code.
2020-06-14 20:45:36 +02:00
SDL_Quit();
FILESYSTEM_deinit();
}
Use `SDL_NORETURN` I misread SDL's code and thought that SDL's `begin_code.h` was internal only to SDL. It turns out you get it when you include basically any header, such as `SDL_stdinc.h`. So use it directly instead of copying it for our own.
2021-09-27 19:32:23 +02:00
SDL_NORETURN void VVV_exit(const int exit_code)
Add VVV_exit() This is just a function that calls the cleanup() in main.cpp, as well as calls exit(). I would have liked to use SDL_ExitProcess() here, because that function has ifdefs for different runtime environments. But alas, it's an internal function and isn't exported. Ah well; exit() seems to be fine anyway.
2021-02-16 03:47:24 +01:00
{
cleanup();
exit(exit_code);
}
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
static void inline deltaloop(void)
Move delta loop to its own function Makes the code less of a giant blob, again.
2020-06-14 20:53:41 +02:00
{
Unindent deltaloop() Doing it in the same commit makes the diffs too noisy...
2020-06-14 20:55:19 +02:00
//timestep limit to 30
const float rawdeltatime = static_cast<float>(time_ - timePrev);
accumulator += rawdeltatime;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
Factor timestep calculation out to Game function This is so we can grab the game's timestep anywhere else in the codebase without copy-pasting it.
2021-04-02 20:50:30 +02:00
Uint32 timesteplimit = game.get_timestep();
Unindent deltaloop() Doing it in the same commit makes the diffs too noisy...
2020-06-14 20:55:19 +02:00
while (accumulator >= timesteplimit)
{
Fix funcs not being reassigned if delta func is last func in list One of the solutions to the quit signal unfocus pause regression is to add a no-op delta func to the unfocused func table. However, this results in the game being stuck in unfocus pause forever, because when it reaches the end of a list on a delta func, it won't reassign the active functions - only when the end of a list is a fixed func will it do so. A workaround is to then add a no-op fixed func afterwards, but that's inelegant. The solution in the end to the quit signal regression is to not bother with adding a delta func, so the game as of right now actually never has a delta func at the end of a list, and probably never will - but this is one piece of technical debt I don't want to leave laying around. In case we're ever going to put a delta function at the end of a list, I've made it so that delta functions will now reassign the list of active funcs if they happen to be at the end of the func list.
2021-04-02 00:25:07 +02:00
enum IndexCode index_code = increment_func_index();
if (index_code == Index_end)
{
loop_assign_active_funcs();
}
Generalize game loop order and fix it to what it was in 2.2 Okay, so the reason why all render functions were moved to the end of the frame in #220 is because it's simpler to call two fixed functions and then a delta function instead of one fixed function, then a delta function, and then another fixed function. This is because fixed functions need special handling inside deltaloop(), and you can't simply duplicate this handling after calling a delta function. Oh, and to make matters worse, it's not always fixed-delta-fixed, sometimes (like in MAPMODE and TELEPORTERMODE) it's delta-fixed-fixed, so we'd need to handle that somehow too. The solution here is to generalize the game loop and factor out each function, instead of hardcoding it. Instead of having hardcoded case-switches directly in the loop, I made a function that returns an array of functions for a given gamestate, along with the number of functions, then the game loop processes it accordingly. In fixedloop(), it iterates over the array and executes each function until it reaches a delta function, at which point it stops. And when it reaches the end of the array, it goes back to the start of the array. But anyway, if it gets to a delta function, it'll stop the loop and finish fixedloop(). Then deltaloop() will call the delta function. And then on the next frame, the function index will be incremented again, so fixedloop() will call the fixed functions again. Actually, the previous game loop was actually made up of one big loop, with a gamestate function loop nested inside it, flanked with code that ran at the start and end of the "big loop". This would be easy to handle with one loop (just include the beginning and end functions with the gamestate functions in the array), except that the gamestate functions could suddenly be swapped out with unfocused functions (the ones that run when you unfocus the window) at any time (well, on frame boundaries, since key.isActive only got checked once, guarding the entire "inner loop" - and I made sure that changing key.isActive wouldn't immediately apply, just like the previous game loop order) - so I had to add yet another layer of indirection, where the gamestate functions could immediately be swapped out with the unfocused functions (while still running the beginning and end code, because that was how the previous loop order worked, after all). This also fixes a regression that the game loop that #220 introduced had, where if the fixed functions switched the gamestate, the game would prematurely start rendering the gamestate function of the new gamestate in the deltaframes, which was a source of some deltaframe glitches. But fixing this is likely to just as well cause deltaframe glitches, so it'd be better to fix this along with fixing the loop order, and only have one round of QA to do in the end, instead of doing one round after each change separately. Fixes #464... but this isn't the end of the patchset. There are bugs that need to be fixed, and kludges that need to be reverted.
2020-11-07 01:08:22 +01:00
Use SDL_fmodf() instead of libc fmodf() Always good to use the SDL stdlib where possible.
2020-11-07 00:11:24 +01:00
accumulator = SDL_fmodf(accumulator, timesteplimit);
Unindent deltaloop() Doing it in the same commit makes the diffs too noisy...
2020-06-14 20:55:19 +02:00
Fix filter/screenshake/flash update order In 2.2, at render time, the game rendered screenshakes and flashes if their timers were above 0, and then decremented them afterwards. The game would also update the analogue filter right before rendering it, too. In 2.3, this was changed so the flash and screenshake timers were unified, and also done at the end of the frame - right before rendering happened. This resulted in 1-frame flashes and screenshakes not rendering at all. The other changes in this patchset don't fix this either. The analogue filter was also in the wrong order, but that is less of an issue than flashes and screenshakes. So, what I've done is made the flash and screenshake timers update right before the loop switches over to rendering, and only decrements them when we switch back to fixed functions (after rendering). The analogue filter is also updated right before rendering as well. This restores 1-frame flashes and screenshakes, as well as restores the correct order of analogue filter updates.
2021-03-18 01:53:17 +01:00
/* We are done rendering. */
graphics.renderfixedpost();
Move fixed loop to its own function To improve code readability because otherwise the code would be one giant blob.
2020-06-14 20:57:33 +02:00
fixedloop();
}
const float alpha = game.over30mode ? static_cast<float>(accumulator) / timesteplimit : 1.0f;
graphics.alpha = alpha;
Generalize game loop order and fix it to what it was in 2.2 Okay, so the reason why all render functions were moved to the end of the frame in #220 is because it's simpler to call two fixed functions and then a delta function instead of one fixed function, then a delta function, and then another fixed function. This is because fixed functions need special handling inside deltaloop(), and you can't simply duplicate this handling after calling a delta function. Oh, and to make matters worse, it's not always fixed-delta-fixed, sometimes (like in MAPMODE and TELEPORTERMODE) it's delta-fixed-fixed, so we'd need to handle that somehow too. The solution here is to generalize the game loop and factor out each function, instead of hardcoding it. Instead of having hardcoded case-switches directly in the loop, I made a function that returns an array of functions for a given gamestate, along with the number of functions, then the game loop processes it accordingly. In fixedloop(), it iterates over the array and executes each function until it reaches a delta function, at which point it stops. And when it reaches the end of the array, it goes back to the start of the array. But anyway, if it gets to a delta function, it'll stop the loop and finish fixedloop(). Then deltaloop() will call the delta function. And then on the next frame, the function index will be incremented again, so fixedloop() will call the fixed functions again. Actually, the previous game loop was actually made up of one big loop, with a gamestate function loop nested inside it, flanked with code that ran at the start and end of the "big loop". This would be easy to handle with one loop (just include the beginning and end functions with the gamestate functions in the array), except that the gamestate functions could suddenly be swapped out with unfocused functions (the ones that run when you unfocus the window) at any time (well, on frame boundaries, since key.isActive only got checked once, guarding the entire "inner loop" - and I made sure that changing key.isActive wouldn't immediately apply, just like the previous game loop order) - so I had to add yet another layer of indirection, where the gamestate functions could immediately be swapped out with the unfocused functions (while still running the beginning and end code, because that was how the previous loop order worked, after all). This also fixes a regression that the game loop that #220 introduced had, where if the fixed functions switched the gamestate, the game would prematurely start rendering the gamestate function of the new gamestate in the deltaframes, which was a source of some deltaframe glitches. But fixing this is likely to just as well cause deltaframe glitches, so it'd be better to fix this along with fixing the loop order, and only have one round of QA to do in the end, instead of doing one round after each change separately. Fixes #464... but this isn't the end of the patchset. There are bugs that need to be fixed, and kludges that need to be reverted.
2020-11-07 01:08:22 +01:00
if (active_func_index == NULL
|| *active_func_index == -1
|| active_funcs == NULL)
Move fixed loop to its own function To improve code readability because otherwise the code would be one giant blob.
2020-06-14 20:57:33 +02:00
{
Generalize game loop order and fix it to what it was in 2.2 Okay, so the reason why all render functions were moved to the end of the frame in #220 is because it's simpler to call two fixed functions and then a delta function instead of one fixed function, then a delta function, and then another fixed function. This is because fixed functions need special handling inside deltaloop(), and you can't simply duplicate this handling after calling a delta function. Oh, and to make matters worse, it's not always fixed-delta-fixed, sometimes (like in MAPMODE and TELEPORTERMODE) it's delta-fixed-fixed, so we'd need to handle that somehow too. The solution here is to generalize the game loop and factor out each function, instead of hardcoding it. Instead of having hardcoded case-switches directly in the loop, I made a function that returns an array of functions for a given gamestate, along with the number of functions, then the game loop processes it accordingly. In fixedloop(), it iterates over the array and executes each function until it reaches a delta function, at which point it stops. And when it reaches the end of the array, it goes back to the start of the array. But anyway, if it gets to a delta function, it'll stop the loop and finish fixedloop(). Then deltaloop() will call the delta function. And then on the next frame, the function index will be incremented again, so fixedloop() will call the fixed functions again. Actually, the previous game loop was actually made up of one big loop, with a gamestate function loop nested inside it, flanked with code that ran at the start and end of the "big loop". This would be easy to handle with one loop (just include the beginning and end functions with the gamestate functions in the array), except that the gamestate functions could suddenly be swapped out with unfocused functions (the ones that run when you unfocus the window) at any time (well, on frame boundaries, since key.isActive only got checked once, guarding the entire "inner loop" - and I made sure that changing key.isActive wouldn't immediately apply, just like the previous game loop order) - so I had to add yet another layer of indirection, where the gamestate functions could immediately be swapped out with the unfocused functions (while still running the beginning and end code, because that was how the previous loop order worked, after all). This also fixes a regression that the game loop that #220 introduced had, where if the fixed functions switched the gamestate, the game would prematurely start rendering the gamestate function of the new gamestate in the deltaframes, which was a source of some deltaframe glitches. But fixing this is likely to just as well cause deltaframe glitches, so it'd be better to fix this along with fixing the loop order, and only have one round of QA to do in the end, instead of doing one round after each change separately. Fixes #464... but this isn't the end of the patchset. There are bugs that need to be fixed, and kludges that need to be reverted.
2020-11-07 01:08:22 +01:00
/* Somehow the first deltatime has been too small and things haven't
* initialized. We'll just no-op for now.
*/
}
else
{
const struct ImplFunc* implfunc = &(*active_funcs)[*active_func_index];
if (implfunc->type == Func_delta && implfunc->func != NULL)
Move fixed loop to its own function To improve code readability because otherwise the code would be one giant blob.
2020-06-14 20:57:33 +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
graphics.clear();
graphics.set_render_target(graphics.gameTexture);
Generalize game loop order and fix it to what it was in 2.2 Okay, so the reason why all render functions were moved to the end of the frame in #220 is because it's simpler to call two fixed functions and then a delta function instead of one fixed function, then a delta function, and then another fixed function. This is because fixed functions need special handling inside deltaloop(), and you can't simply duplicate this handling after calling a delta function. Oh, and to make matters worse, it's not always fixed-delta-fixed, sometimes (like in MAPMODE and TELEPORTERMODE) it's delta-fixed-fixed, so we'd need to handle that somehow too. The solution here is to generalize the game loop and factor out each function, instead of hardcoding it. Instead of having hardcoded case-switches directly in the loop, I made a function that returns an array of functions for a given gamestate, along with the number of functions, then the game loop processes it accordingly. In fixedloop(), it iterates over the array and executes each function until it reaches a delta function, at which point it stops. And when it reaches the end of the array, it goes back to the start of the array. But anyway, if it gets to a delta function, it'll stop the loop and finish fixedloop(). Then deltaloop() will call the delta function. And then on the next frame, the function index will be incremented again, so fixedloop() will call the fixed functions again. Actually, the previous game loop was actually made up of one big loop, with a gamestate function loop nested inside it, flanked with code that ran at the start and end of the "big loop". This would be easy to handle with one loop (just include the beginning and end functions with the gamestate functions in the array), except that the gamestate functions could suddenly be swapped out with unfocused functions (the ones that run when you unfocus the window) at any time (well, on frame boundaries, since key.isActive only got checked once, guarding the entire "inner loop" - and I made sure that changing key.isActive wouldn't immediately apply, just like the previous game loop order) - so I had to add yet another layer of indirection, where the gamestate functions could immediately be swapped out with the unfocused functions (while still running the beginning and end code, because that was how the previous loop order worked, after all). This also fixes a regression that the game loop that #220 introduced had, where if the fixed functions switched the gamestate, the game would prematurely start rendering the gamestate function of the new gamestate in the deltaframes, which was a source of some deltaframe glitches. But fixing this is likely to just as well cause deltaframe glitches, so it'd be better to fix this along with fixing the loop order, and only have one round of QA to do in the end, instead of doing one round after each change separately. Fixes #464... but this isn't the end of the patchset. There are bugs that need to be fixed, and kludges that need to be reverted.
2020-11-07 01:08:22 +01:00
implfunc->func();
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
gameScreen.RenderPresent();
Move fixed loop to its own function To improve code readability because otherwise the code would be one giant blob.
2020-06-14 20:57:33 +02:00
}
}
}
Generalize game loop order and fix it to what it was in 2.2 Okay, so the reason why all render functions were moved to the end of the frame in #220 is because it's simpler to call two fixed functions and then a delta function instead of one fixed function, then a delta function, and then another fixed function. This is because fixed functions need special handling inside deltaloop(), and you can't simply duplicate this handling after calling a delta function. Oh, and to make matters worse, it's not always fixed-delta-fixed, sometimes (like in MAPMODE and TELEPORTERMODE) it's delta-fixed-fixed, so we'd need to handle that somehow too. The solution here is to generalize the game loop and factor out each function, instead of hardcoding it. Instead of having hardcoded case-switches directly in the loop, I made a function that returns an array of functions for a given gamestate, along with the number of functions, then the game loop processes it accordingly. In fixedloop(), it iterates over the array and executes each function until it reaches a delta function, at which point it stops. And when it reaches the end of the array, it goes back to the start of the array. But anyway, if it gets to a delta function, it'll stop the loop and finish fixedloop(). Then deltaloop() will call the delta function. And then on the next frame, the function index will be incremented again, so fixedloop() will call the fixed functions again. Actually, the previous game loop was actually made up of one big loop, with a gamestate function loop nested inside it, flanked with code that ran at the start and end of the "big loop". This would be easy to handle with one loop (just include the beginning and end functions with the gamestate functions in the array), except that the gamestate functions could suddenly be swapped out with unfocused functions (the ones that run when you unfocus the window) at any time (well, on frame boundaries, since key.isActive only got checked once, guarding the entire "inner loop" - and I made sure that changing key.isActive wouldn't immediately apply, just like the previous game loop order) - so I had to add yet another layer of indirection, where the gamestate functions could immediately be swapped out with the unfocused functions (while still running the beginning and end code, because that was how the previous loop order worked, after all). This also fixes a regression that the game loop that #220 introduced had, where if the fixed functions switched the gamestate, the game would prematurely start rendering the gamestate function of the new gamestate in the deltaframes, which was a source of some deltaframe glitches. But fixing this is likely to just as well cause deltaframe glitches, so it'd be better to fix this along with fixing the loop order, and only have one round of QA to do in the end, instead of doing one round after each change separately. Fixes #464... but this isn't the end of the patchset. There are bugs that need to be fixed, and kludges that need to be reverted.
2020-11-07 01:08:22 +01:00
static enum LoopCode loop_begin(void)
Move fixed loop to its own function To improve code readability because otherwise the code would be one giant blob.
2020-06-14 20:57:33 +02:00
{
Add option to re-enable 1-frame input delay This is an option for speedrunners whose muscle memory is precisely trained and used to the 1-frame input delay that existed in 2.2 and below. It is located in Game Options -> Advanced Options, and is off by default. To re-add the 1-frame input delay, we simply move the key.Poll() to the start of the frame, instead of before an input function gets ran - undoing what #535 did. There is a frame ordering-sensitive issue here, where toggling game.inputdelay at the wrong time could cause double-polling. However, we only toggle it in an input function, which regardless is always guaranteed to be ran after key.Poll() (it either happened at the start of the frame or just before the input function got ran), so this is not an issue. But, in case we ever need to toggle this variable in the future, we can just use the defer callbacks system to defer the toggle to the end of the frame - also added by #535. Added at the request of Habeechee on the VVVVVV speedrunning Discord server.
2021-04-02 00:39:56 +02:00
if (game.inputdelay)
{
key.Poll();
}
Move infocus and network updates to fixedloop() Updating them every delta frame is way too fast.
2020-06-14 20:58:27 +02:00
// Update network per frame.
NETWORK_update();
Generalize game loop order and fix it to what it was in 2.2 Okay, so the reason why all render functions were moved to the end of the frame in #220 is because it's simpler to call two fixed functions and then a delta function instead of one fixed function, then a delta function, and then another fixed function. This is because fixed functions need special handling inside deltaloop(), and you can't simply duplicate this handling after calling a delta function. Oh, and to make matters worse, it's not always fixed-delta-fixed, sometimes (like in MAPMODE and TELEPORTERMODE) it's delta-fixed-fixed, so we'd need to handle that somehow too. The solution here is to generalize the game loop and factor out each function, instead of hardcoding it. Instead of having hardcoded case-switches directly in the loop, I made a function that returns an array of functions for a given gamestate, along with the number of functions, then the game loop processes it accordingly. In fixedloop(), it iterates over the array and executes each function until it reaches a delta function, at which point it stops. And when it reaches the end of the array, it goes back to the start of the array. But anyway, if it gets to a delta function, it'll stop the loop and finish fixedloop(). Then deltaloop() will call the delta function. And then on the next frame, the function index will be incremented again, so fixedloop() will call the fixed functions again. Actually, the previous game loop was actually made up of one big loop, with a gamestate function loop nested inside it, flanked with code that ran at the start and end of the "big loop". This would be easy to handle with one loop (just include the beginning and end functions with the gamestate functions in the array), except that the gamestate functions could suddenly be swapped out with unfocused functions (the ones that run when you unfocus the window) at any time (well, on frame boundaries, since key.isActive only got checked once, guarding the entire "inner loop" - and I made sure that changing key.isActive wouldn't immediately apply, just like the previous game loop order) - so I had to add yet another layer of indirection, where the gamestate functions could immediately be swapped out with the unfocused functions (while still running the beginning and end code, because that was how the previous loop order worked, after all). This also fixes a regression that the game loop that #220 introduced had, where if the fixed functions switched the gamestate, the game would prematurely start rendering the gamestate function of the new gamestate in the deltaframes, which was a source of some deltaframe glitches. But fixing this is likely to just as well cause deltaframe glitches, so it'd be better to fix this along with fixing the loop order, and only have one round of QA to do in the end, instead of doing one round after each change separately. Fixes #464... but this isn't the end of the patchset. There are bugs that need to be fixed, and kludges that need to be reverted.
2020-11-07 01:08:22 +01:00
return Loop_continue;
}
static void unfocused_run(void)
{
Unindent unfocused_run() and focused_begin() from previous commit As always, indentation changes are applied in a separate commit to minimize diff noise.
2021-01-16 20:40:26 +01:00
if (!game.blackout)
{
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.fill_rect(0, 0, 0);
Fix oversight with unfocus pause screen in Flip Mode Flip Mode flips all the unfocus pause screen text upside-down, to make it read in reverse order. This looks kind of strange to me, and I don't think it was intended. So I'm flipping the text again so it's the right way up in Flip Mode.
2021-03-19 23:58:52 +01:00
#define FLIP(YPOS) graphics.flipmode ? 232 - YPOS : YPOS
Migrate more prints and graphics.len calls to font:: I especially focused on graphics.len and the print calls around them, because graphics.len calls appear a bit less often, might be overlooked when migrating print calls (thus possibly using different fonts by accident) and are often used for some kind of right-alignment or centering which can be changed into PR_RIGHT or PR_CEN with a different X anyway. Notably, I also added a new function to generate these kinds of sliders: ....[]............ Different languages means that the slider for analogue stick sensitivity needs to be longer to fit possibly long words for Low/Medium/High, and then different font sizes means that the longer slider won't fit onscreen in a language that needs a 12-wide font. So slider_get() can take a "target width", which dynamically changes the number of characters depending on the width of them in the interface font. I kinda forgot that I could force the 8x8 font instead of adapting the characters in the slider to the font, and other ideas (like using different characters or a more graphical progress bar) have been brought up on Discord, so this might all change again sooner or later.
2023-01-16 21:29:50 +01:00
/* The pause screen can also appear on the language screen, where highlighting
* a language changes the used language metadata but not the loaded strings... */
Fix pause screen font on language screen with other language selected If you for example have your VVVVVV set to English, have the option for Chinese selected, and then the window loses focus, the English pause screen would show up in the Chinese font. This is now fixed.
2023-01-15 05:26:15 +01:00
uint32_t flags = PR_CEN | PR_BOR | PR_FONT_IDX(loc::langmeta.font_idx);
font::print(flags | PR_CJK_HIGH, -1, FLIP(110), loc::gettext("Game paused"), 196 - help.glow, 255 - help.glow, 196 - help.glow);
font::print(flags | PR_CJK_LOW, -1, FLIP(120), loc::gettext("[click to resume]"), 196 - help.glow, 255 - help.glow, 196 - help.glow);
font::print(flags | PR_CJK_HIGH, -1, FLIP(220), loc::gettext("Press M to mute in game"), 164 - help.glow, 196 - help.glow, 164 - help.glow);
font::print(flags, -1, FLIP(230), loc::gettext("Press N to mute music only"), 164 - help.glow, 196 - help.glow, 164 - help.glow);
Fix oversight with unfocus pause screen in Flip Mode Flip Mode flips all the unfocus pause screen text upside-down, to make it read in reverse order. This looks kind of strange to me, and I don't think it was intended. So I'm flipping the text again so it's the right way up in Flip Mode.
2021-03-19 23:58:52 +01:00
#undef FLIP
Unindent unfocused_run() and focused_begin() from previous commit As always, indentation changes are applied in a separate commit to minimize diff noise.
2021-01-16 20:40:26 +01:00
}
graphics.render();
//We are minimised, so lets put a bit of a delay to save CPU
Use Emscripten's main loop On Emscripten, SDL_Delay is implemented as a busy loop. In addition, everything happens on a single thread. This effectively means that you have to let Emscripten manage the main loop, since if you do it yourself the browser will just be frozen.
2021-03-31 21:06:26 +02:00
#ifndef __EMSCRIPTEN__
Unindent unfocused_run() and focused_begin() from previous commit As always, indentation changes are applied in a separate commit to minimize diff noise.
2021-01-16 20:40:26 +01:00
SDL_Delay(100);
Use Emscripten's main loop On Emscripten, SDL_Delay is implemented as a busy loop. In addition, everything happens on a single thread. This effectively means that you have to let Emscripten manage the main loop, since if you do it yourself the browser will just be frozen.
2021-03-31 21:06:26 +02:00
#endif
Generalize game loop order and fix it to what it was in 2.2 Okay, so the reason why all render functions were moved to the end of the frame in #220 is because it's simpler to call two fixed functions and then a delta function instead of one fixed function, then a delta function, and then another fixed function. This is because fixed functions need special handling inside deltaloop(), and you can't simply duplicate this handling after calling a delta function. Oh, and to make matters worse, it's not always fixed-delta-fixed, sometimes (like in MAPMODE and TELEPORTERMODE) it's delta-fixed-fixed, so we'd need to handle that somehow too. The solution here is to generalize the game loop and factor out each function, instead of hardcoding it. Instead of having hardcoded case-switches directly in the loop, I made a function that returns an array of functions for a given gamestate, along with the number of functions, then the game loop processes it accordingly. In fixedloop(), it iterates over the array and executes each function until it reaches a delta function, at which point it stops. And when it reaches the end of the array, it goes back to the start of the array. But anyway, if it gets to a delta function, it'll stop the loop and finish fixedloop(). Then deltaloop() will call the delta function. And then on the next frame, the function index will be incremented again, so fixedloop() will call the fixed functions again. Actually, the previous game loop was actually made up of one big loop, with a gamestate function loop nested inside it, flanked with code that ran at the start and end of the "big loop". This would be easy to handle with one loop (just include the beginning and end functions with the gamestate functions in the array), except that the gamestate functions could suddenly be swapped out with unfocused functions (the ones that run when you unfocus the window) at any time (well, on frame boundaries, since key.isActive only got checked once, guarding the entire "inner loop" - and I made sure that changing key.isActive wouldn't immediately apply, just like the previous game loop order) - so I had to add yet another layer of indirection, where the gamestate functions could immediately be swapped out with the unfocused functions (while still running the beginning and end code, because that was how the previous loop order worked, after all). This also fixes a regression that the game loop that #220 introduced had, where if the fixed functions switched the gamestate, the game would prematurely start rendering the gamestate function of the new gamestate in the deltaframes, which was a source of some deltaframe glitches. But fixing this is likely to just as well cause deltaframe glitches, so it'd be better to fix this along with fixing the loop order, and only have one round of QA to do in the end, instead of doing one round after each change separately. Fixes #464... but this isn't the end of the patchset. There are bugs that need to be fixed, and kludges that need to be reverted.
2020-11-07 01:08:22 +01:00
}
static void focused_begin(void)
{
Fix cycling title BG more than once per frame This can happen if you select an option in a menu that (A) returns to the previous menu and (B) saves settings. If the settings save fails, this will create another menu on the same frame that cycles the tower BG after it's already been cycled for that frame. Examples are the slowdown and glitchrunner menus. I could fix this by creating a new function that copy-pastes all of Game::savestatsandsettings_menu() except for the map.nexttowercolour() at the end. But that's copy-pasting code. Instead what I've done is added a variable to signal if the color has already been cycled this frame, so we don't cycle it again. This also covers cases of possible double-cycling in the future as well.
2021-08-06 01:38:06 +02:00
map.nexttowercolour_set = false;
Generalize game loop order and fix it to what it was in 2.2 Okay, so the reason why all render functions were moved to the end of the frame in #220 is because it's simpler to call two fixed functions and then a delta function instead of one fixed function, then a delta function, and then another fixed function. This is because fixed functions need special handling inside deltaloop(), and you can't simply duplicate this handling after calling a delta function. Oh, and to make matters worse, it's not always fixed-delta-fixed, sometimes (like in MAPMODE and TELEPORTERMODE) it's delta-fixed-fixed, so we'd need to handle that somehow too. The solution here is to generalize the game loop and factor out each function, instead of hardcoding it. Instead of having hardcoded case-switches directly in the loop, I made a function that returns an array of functions for a given gamestate, along with the number of functions, then the game loop processes it accordingly. In fixedloop(), it iterates over the array and executes each function until it reaches a delta function, at which point it stops. And when it reaches the end of the array, it goes back to the start of the array. But anyway, if it gets to a delta function, it'll stop the loop and finish fixedloop(). Then deltaloop() will call the delta function. And then on the next frame, the function index will be incremented again, so fixedloop() will call the fixed functions again. Actually, the previous game loop was actually made up of one big loop, with a gamestate function loop nested inside it, flanked with code that ran at the start and end of the "big loop". This would be easy to handle with one loop (just include the beginning and end functions with the gamestate functions in the array), except that the gamestate functions could suddenly be swapped out with unfocused functions (the ones that run when you unfocus the window) at any time (well, on frame boundaries, since key.isActive only got checked once, guarding the entire "inner loop" - and I made sure that changing key.isActive wouldn't immediately apply, just like the previous game loop order) - so I had to add yet another layer of indirection, where the gamestate functions could immediately be swapped out with the unfocused functions (while still running the beginning and end code, because that was how the previous loop order worked, after all). This also fixes a regression that the game loop that #220 introduced had, where if the fixed functions switched the gamestate, the game would prematurely start rendering the gamestate function of the new gamestate in the deltaframes, which was a source of some deltaframe glitches. But fixing this is likely to just as well cause deltaframe glitches, so it'd be better to fix this along with fixing the loop order, and only have one round of QA to do in the end, instead of doing one round after each change separately. Fixes #464... but this isn't the end of the patchset. There are bugs that need to be fixed, and kludges that need to be reverted.
2020-11-07 01:08:22 +01:00
}
Unindent deltaloop() Doing it in the same commit makes the diffs too noisy...
2020-06-14 20:55:19 +02:00
Generalize game loop order and fix it to what it was in 2.2 Okay, so the reason why all render functions were moved to the end of the frame in #220 is because it's simpler to call two fixed functions and then a delta function instead of one fixed function, then a delta function, and then another fixed function. This is because fixed functions need special handling inside deltaloop(), and you can't simply duplicate this handling after calling a delta function. Oh, and to make matters worse, it's not always fixed-delta-fixed, sometimes (like in MAPMODE and TELEPORTERMODE) it's delta-fixed-fixed, so we'd need to handle that somehow too. The solution here is to generalize the game loop and factor out each function, instead of hardcoding it. Instead of having hardcoded case-switches directly in the loop, I made a function that returns an array of functions for a given gamestate, along with the number of functions, then the game loop processes it accordingly. In fixedloop(), it iterates over the array and executes each function until it reaches a delta function, at which point it stops. And when it reaches the end of the array, it goes back to the start of the array. But anyway, if it gets to a delta function, it'll stop the loop and finish fixedloop(). Then deltaloop() will call the delta function. And then on the next frame, the function index will be incremented again, so fixedloop() will call the fixed functions again. Actually, the previous game loop was actually made up of one big loop, with a gamestate function loop nested inside it, flanked with code that ran at the start and end of the "big loop". This would be easy to handle with one loop (just include the beginning and end functions with the gamestate functions in the array), except that the gamestate functions could suddenly be swapped out with unfocused functions (the ones that run when you unfocus the window) at any time (well, on frame boundaries, since key.isActive only got checked once, guarding the entire "inner loop" - and I made sure that changing key.isActive wouldn't immediately apply, just like the previous game loop order) - so I had to add yet another layer of indirection, where the gamestate functions could immediately be swapped out with the unfocused functions (while still running the beginning and end code, because that was how the previous loop order worked, after all). This also fixes a regression that the game loop that #220 introduced had, where if the fixed functions switched the gamestate, the game would prematurely start rendering the gamestate function of the new gamestate in the deltaframes, which was a source of some deltaframe glitches. But fixing this is likely to just as well cause deltaframe glitches, so it'd be better to fix this along with fixing the loop order, and only have one round of QA to do in the end, instead of doing one round after each change separately. Fixes #464... but this isn't the end of the patchset. There are bugs that need to be fixed, and kludges that need to be reverted.
2020-11-07 01:08:22 +01:00
static void focused_end(void)
{
Don't process music, fades, or timer when unfocused This fixes being able to make music fully fade in (or out) by unfocusing the game, or making the fade bars fully fade in (or out) by unfocusing the game, or racking up the timer while the game is unfocused.
2021-04-13 23:42:45 +02:00
game.gameclock();
music.processmusic();
graphics.processfade();
Generalize game loop order and fix it to what it was in 2.2 Okay, so the reason why all render functions were moved to the end of the frame in #220 is because it's simpler to call two fixed functions and then a delta function instead of one fixed function, then a delta function, and then another fixed function. This is because fixed functions need special handling inside deltaloop(), and you can't simply duplicate this handling after calling a delta function. Oh, and to make matters worse, it's not always fixed-delta-fixed, sometimes (like in MAPMODE and TELEPORTERMODE) it's delta-fixed-fixed, so we'd need to handle that somehow too. The solution here is to generalize the game loop and factor out each function, instead of hardcoding it. Instead of having hardcoded case-switches directly in the loop, I made a function that returns an array of functions for a given gamestate, along with the number of functions, then the game loop processes it accordingly. In fixedloop(), it iterates over the array and executes each function until it reaches a delta function, at which point it stops. And when it reaches the end of the array, it goes back to the start of the array. But anyway, if it gets to a delta function, it'll stop the loop and finish fixedloop(). Then deltaloop() will call the delta function. And then on the next frame, the function index will be incremented again, so fixedloop() will call the fixed functions again. Actually, the previous game loop was actually made up of one big loop, with a gamestate function loop nested inside it, flanked with code that ran at the start and end of the "big loop". This would be easy to handle with one loop (just include the beginning and end functions with the gamestate functions in the array), except that the gamestate functions could suddenly be swapped out with unfocused functions (the ones that run when you unfocus the window) at any time (well, on frame boundaries, since key.isActive only got checked once, guarding the entire "inner loop" - and I made sure that changing key.isActive wouldn't immediately apply, just like the previous game loop order) - so I had to add yet another layer of indirection, where the gamestate functions could immediately be swapped out with the unfocused functions (while still running the beginning and end code, because that was how the previous loop order worked, after all). This also fixes a regression that the game loop that #220 introduced had, where if the fixed functions switched the gamestate, the game would prematurely start rendering the gamestate function of the new gamestate in the deltaframes, which was a source of some deltaframe glitches. But fixing this is likely to just as well cause deltaframe glitches, so it'd be better to fix this along with fixing the loop order, and only have one round of QA to do in the end, instead of doing one round after each change separately. Fixes #464... but this isn't the end of the patchset. There are bugs that need to be fixed, and kludges that need to be reverted.
2020-11-07 01:08:22 +01:00
}
Unindent deltaloop() Doing it in the same commit makes the diffs too noisy...
2020-06-14 20:55:19 +02:00
Generalize game loop order and fix it to what it was in 2.2 Okay, so the reason why all render functions were moved to the end of the frame in #220 is because it's simpler to call two fixed functions and then a delta function instead of one fixed function, then a delta function, and then another fixed function. This is because fixed functions need special handling inside deltaloop(), and you can't simply duplicate this handling after calling a delta function. Oh, and to make matters worse, it's not always fixed-delta-fixed, sometimes (like in MAPMODE and TELEPORTERMODE) it's delta-fixed-fixed, so we'd need to handle that somehow too. The solution here is to generalize the game loop and factor out each function, instead of hardcoding it. Instead of having hardcoded case-switches directly in the loop, I made a function that returns an array of functions for a given gamestate, along with the number of functions, then the game loop processes it accordingly. In fixedloop(), it iterates over the array and executes each function until it reaches a delta function, at which point it stops. And when it reaches the end of the array, it goes back to the start of the array. But anyway, if it gets to a delta function, it'll stop the loop and finish fixedloop(). Then deltaloop() will call the delta function. And then on the next frame, the function index will be incremented again, so fixedloop() will call the fixed functions again. Actually, the previous game loop was actually made up of one big loop, with a gamestate function loop nested inside it, flanked with code that ran at the start and end of the "big loop". This would be easy to handle with one loop (just include the beginning and end functions with the gamestate functions in the array), except that the gamestate functions could suddenly be swapped out with unfocused functions (the ones that run when you unfocus the window) at any time (well, on frame boundaries, since key.isActive only got checked once, guarding the entire "inner loop" - and I made sure that changing key.isActive wouldn't immediately apply, just like the previous game loop order) - so I had to add yet another layer of indirection, where the gamestate functions could immediately be swapped out with the unfocused functions (while still running the beginning and end code, because that was how the previous loop order worked, after all). This also fixes a regression that the game loop that #220 introduced had, where if the fixed functions switched the gamestate, the game would prematurely start rendering the gamestate function of the new gamestate in the deltaframes, which was a source of some deltaframe glitches. But fixing this is likely to just as well cause deltaframe glitches, so it'd be better to fix this along with fixing the loop order, and only have one round of QA to do in the end, instead of doing one round after each change separately. Fixes #464... but this isn't the end of the patchset. There are bugs that need to be fixed, and kludges that need to be reverted.
2020-11-07 01:08:22 +01:00
static enum LoopCode loop_end(void)
{
Seed with frame counter instead of `SDL_GetTicks` Using SDL_GetTicks() to seed the Gravitron RNG caused many reproducibility issues while syncing https://tasvideos.org/7575S . To fix this, add a frame counter, which is a number that is incremented every frame and never resets, and use it instead. If someone needs to switch back to SDL_GetTicks() for old TASes, then provide the -seed-use-sdl-getticks command-line option for them.
2022-11-14 23:10:24 +01:00
++game.framecounter;
Unindent fixedloop() If I did it in the previous commit, it would've been too noisy.
2020-06-14 20:57:57 +02:00
//We did editorinput, now it's safe to turn this off
key.linealreadyemptykludge = false;
Unindent gameloop() You know the drill, diffs are too impatient to properly illustrate an indentation change without adding a bunch of noise.
2020-06-14 20:49:23 +02:00
Unindent fixedloop() If I did it in the previous commit, it would've been too noisy.
2020-06-14 20:57:57 +02:00
//Mute button
Axe manual state trackers and use SDL_IsTextInputActive() After looking at pull request #446, I got a bit annoyed that we have TWO variables, key.textentrymode and ed.textentry, that we rolled ourselves to track the state of something SDL already provides us a function to easily query: SDL_IsTextInputActive(). We don't need to have either of these two variables, and we shouldn't. So that's what I do in this patch. Both variables have been axed in favor of using this function, and I just made a wrapper out of it, named key.textentry(). For bonus points, this gets rid of the ugly NO_CUSTOM_LEVELS and NO_EDITOR ifdef in main.cpp, since text entry is enabled when entering the script list and disabled when exiting it. This makes the code there easier to read, too. Furthermore, apparently key.textentrymode was initialized to *true* instead of false... for whatever reason. But that's gone now, too. Now, you'd think there wouldn't be any downside to using SDL_IsTextInputActive(). After all, it's a function that SDL itself provides, right? Wrong. For whatever reason, it seems like text input is active *from the start of the program*, meaning that what would happen is I would go into the editor, and find that I can't move around nor place tiles nor anything else. Then I would press Esc, and then suddenly become able to do those things I wanted to do before. I have no idea why the above happens, but all I can do is to just insert an SDL_StopTextInput() immediately after the SDL_Init() in main.cpp. Of course, I have to surround it with an SDL_IsTextInputActive() check to make sure I don't do anything extraneous by stopping input when it's already stopped.
2020-08-13 08:43:25 +02:00
if (key.isDown(KEYBOARD_m) && game.mutebutton<=0 && !key.textentry())
Unindent fixedloop() If I did it in the previous commit, it would've been too noisy.
2020-06-14 20:57:57 +02:00
{
game.mutebutton = 8;
if (game.muted)
Unindent deltaloop() Doing it in the same commit makes the diffs too noisy...
2020-06-14 20:55:19 +02:00
{
Unindent fixedloop() If I did it in the previous commit, it would've been too noisy.
2020-06-14 20:57:57 +02:00
game.muted = false;
Unindent deltaloop() Doing it in the same commit makes the diffs too noisy...
2020-06-14 20:55:19 +02:00
}
Unindent fixedloop() If I did it in the previous commit, it would've been too noisy.
2020-06-14 20:57:57 +02:00
else
Unindent deltaloop() Doing it in the same commit makes the diffs too noisy...
2020-06-14 20:55:19 +02:00
{
Unindent fixedloop() If I did it in the previous commit, it would've been too noisy.
2020-06-14 20:57:57 +02:00
game.muted = true;
Unindent deltaloop() Doing it in the same commit makes the diffs too noisy...
2020-06-14 20:55:19 +02:00
}
Unindent fixedloop() If I did it in the previous commit, it would've been too noisy.
2020-06-14 20:57:57 +02:00
}
if(game.mutebutton>0)
{
game.mutebutton--;
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
Axe manual state trackers and use SDL_IsTextInputActive() After looking at pull request #446, I got a bit annoyed that we have TWO variables, key.textentrymode and ed.textentry, that we rolled ourselves to track the state of something SDL already provides us a function to easily query: SDL_IsTextInputActive(). We don't need to have either of these two variables, and we shouldn't. So that's what I do in this patch. Both variables have been axed in favor of using this function, and I just made a wrapper out of it, named key.textentry(). For bonus points, this gets rid of the ugly NO_CUSTOM_LEVELS and NO_EDITOR ifdef in main.cpp, since text entry is enabled when entering the script list and disabled when exiting it. This makes the code there easier to read, too. Furthermore, apparently key.textentrymode was initialized to *true* instead of false... for whatever reason. But that's gone now, too. Now, you'd think there wouldn't be any downside to using SDL_IsTextInputActive(). After all, it's a function that SDL itself provides, right? Wrong. For whatever reason, it seems like text input is active *from the start of the program*, meaning that what would happen is I would go into the editor, and find that I can't move around nor place tiles nor anything else. Then I would press Esc, and then suddenly become able to do those things I wanted to do before. I have no idea why the above happens, but all I can do is to just insert an SDL_StopTextInput() immediately after the SDL_Init() in main.cpp. Of course, I have to surround it with an SDL_IsTextInputActive() check to make sure I don't do anything extraneous by stopping input when it's already stopped.
2020-08-13 08:43:25 +02:00
if (key.isDown(KEYBOARD_n) && game.musicmutebutton <= 0 && !key.textentry())
Unindent fixedloop() If I did it in the previous commit, it would've been too noisy.
2020-06-14 20:57:57 +02:00
{
game.musicmutebutton = 8;
game.musicmuted = !game.musicmuted;
}
if (game.musicmutebutton > 0)
{
game.musicmutebutton--;
}
Indent timestep loop Ok, NOW indent it. I didn't indent it previously because the diffs are annoying to read if there's an indent that doesn't otherwise change anything (and even now it's pretty annoying to read).
2020-04-28 23:44:53 +02:00
Move the mute logic to musicclass. This moves the last of the SDL_mixer calls to Music.cpp.
2021-12-26 14:48:23 +01:00
music.updatemutestate();
Move render functions to outer deltatime loop Ok, and this is where the fun starts. In an ideal world, this would be the end of this patch. However, of course, there are many, MANY places in the game that update fixed-timestep timers DIRECTLY inside the render function, which is not ideal because it means those timers go super fast. I'll have to fix those later.
2020-04-29 00:02:37 +02:00
Unindent fixedloop() If I did it in the previous commit, it would've been too noisy.
2020-06-14 20:57:57 +02:00
if (key.resetWindow)
{
key.resetWindow = false;
gameScreen.ResizeScreen(-1, -1);
}
Unindent gameloop() You know the drill, diffs are too impatient to properly illustrate an indentation change without adding a bunch of noise.
2020-06-14 20:49:23 +02:00
Generalize game loop order and fix it to what it was in 2.2 Okay, so the reason why all render functions were moved to the end of the frame in #220 is because it's simpler to call two fixed functions and then a delta function instead of one fixed function, then a delta function, and then another fixed function. This is because fixed functions need special handling inside deltaloop(), and you can't simply duplicate this handling after calling a delta function. Oh, and to make matters worse, it's not always fixed-delta-fixed, sometimes (like in MAPMODE and TELEPORTERMODE) it's delta-fixed-fixed, so we'd need to handle that somehow too. The solution here is to generalize the game loop and factor out each function, instead of hardcoding it. Instead of having hardcoded case-switches directly in the loop, I made a function that returns an array of functions for a given gamestate, along with the number of functions, then the game loop processes it accordingly. In fixedloop(), it iterates over the array and executes each function until it reaches a delta function, at which point it stops. And when it reaches the end of the array, it goes back to the start of the array. But anyway, if it gets to a delta function, it'll stop the loop and finish fixedloop(). Then deltaloop() will call the delta function. And then on the next frame, the function index will be incremented again, so fixedloop() will call the fixed functions again. Actually, the previous game loop was actually made up of one big loop, with a gamestate function loop nested inside it, flanked with code that ran at the start and end of the "big loop". This would be easy to handle with one loop (just include the beginning and end functions with the gamestate functions in the array), except that the gamestate functions could suddenly be swapped out with unfocused functions (the ones that run when you unfocus the window) at any time (well, on frame boundaries, since key.isActive only got checked once, guarding the entire "inner loop" - and I made sure that changing key.isActive wouldn't immediately apply, just like the previous game loop order) - so I had to add yet another layer of indirection, where the gamestate functions could immediately be swapped out with the unfocused functions (while still running the beginning and end code, because that was how the previous loop order worked, after all). This also fixes a regression that the game loop that #220 introduced had, where if the fixed functions switched the gamestate, the game would prematurely start rendering the gamestate function of the new gamestate in the deltaframes, which was a source of some deltaframe glitches. But fixing this is likely to just as well cause deltaframe glitches, so it'd be better to fix this along with fixing the loop order, and only have one round of QA to do in the end, instead of doing one round after each change separately. Fixes #464... but this isn't the end of the patchset. There are bugs that need to be fixed, and kludges that need to be reverted.
2020-11-07 01:08:22 +01:00
return Loop_continue;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
Reference in a new issue Copy permalink