Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow using 'help', 'graphics', 'music', 'game', 'key', 'map', and 'obj' everywhere #129

Merged

Conversation

InfoTeddy
Copy link
Collaborator

Changes:

  • Allow using help, graphics, music, game, key, map, and obj everywhere

    This PR 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, or else the game would segfault. 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.

Legal Stuff:

By submitting this pull request, I confirm that...

  • My changes may be used in a future commercial release of VVVVVV (for
    example, a 2.3 update on Steam for Windows/macOS/Linux)
  • I will be credited in a CONTRIBUTORS file for all of said releases, but
    will NOT be compensated for these changes

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.
@TerryCavanagh
Copy link
Owner

Huh! Yeah, this seems like a useful change, and a good first step towards eventually stabilising this jenga tower of a game (i.e. removing the reference passing stuff from virtually every function in the game).

I can't think of any reason this might cause a problem - any thoughts, @flibitijibibo?

@flibitijibibo
Copy link
Collaborator

None I can think of - may be worth checking the Win64 issue after this, it might fix that as a side effect.

@flibitijibibo flibitijibibo merged commit 5a316d6 into TerryCavanagh:master Jan 29, 2020
@InfoTeddy InfoTeddy deleted the code-quality-improvements branch January 29, 2020 23:19
@InfoTeddy InfoTeddy mentioned this pull request Jun 12, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants