1
0
Fork 0
mirror of https://github.com/TerryCavanagh/VVVVVV.git synced 2024-11-05 18:59:41 +01:00
Commit graph

13 commits

Author SHA1 Message Date
Misa
35d9bcce05 Remove global args from mapclass
This commit removes the global args being passed around from the
function args on the mapclass object, as well as updating all callers in
other files to not have those args. Furthermore, 'dwgfx' has been
renamed to 'graphics' in Map.cpp.
2020-04-03 10:40:50 -04:00
Misa
cac1a9e3ab Remove global args from entityclass
This commit removes all global args from functions on the entityclass
object, and updates the callers of those functions in other files
accordingly (most significantly, the game level files Finalclass.cpp,
Labclass.cpp, Otherlevel.cpp, Spacestation2.cpp, WarpClass.cpp, due to
them using createentity()), as well as renaming all instances of 'dwgfx'
in Entity.cpp to 'graphics'.
2020-04-03 10:40:50 -04:00
Misa
8d44d9387b Refactor edentities to not use separate length-trackers
This turns the array 'edentity' into a proper vector, and removes the need to
use a separate length-tracking variable and manually keep track of the actual
amount of edentities in the level by using the long-winded
'EditorData::GetInstance().numedentities'. This manual tracking was more
error-prone and much less maintainable.

editorclass::naddedentity() has been removed due to now functionally being the
same as editorclass::addedentity() (there's no more
'EditorData::GetInstance().numedentities' to not increment) and for also being
unused in the first place.

editorclass::copyedentity() has been removed because it was only used to shift
the rest of the edentities up manually, but now that we let C++ do all the
hard work it's no longer necessary.
2020-03-01 15:47:01 -05:00
Misa
a4d7fc017c Refactor roomtext to not use ad-hoc objects / separate length trackers
This refactors the roomtext code to (1) not use ad-hoc objects and (2)
not use a separate length-tracking variable to keep track of the actual
amount of roomtext in a room.

What I mean by ad-hoc object is, instead of formally creating a
fully-fledged struct or class and storing one vector containing that
object, this game instead hacks together an object by storing each
attribute of an object in different vectors.

In the case of roomtext, instead of making a Roomtext object that has
attributes 'x', 'y', and 'text', the 'text' attribute of each is stored
in the vector 'roomtext', the 'x' attribute of each is stored in the
vector 'roomtextx', and the 'y' attribute of each is stored in the
vector 'roomtexty'. It's only an object in the sense that you can grab
the attributes of each roomtext by using the same index across all three
vectors.

This makes it somewhat annoying to maintain and deal with, like when I
wanted add sub-tile positions to roomtext in VVVVVV: Community Edition.
Instead of being able to add attributes to an already-existing
formalized Roomtext object, I would instead have to add two more
vectors, which is inelegant. Or I could refactor the whole system, which
is what I decided to do instead.

Furthermore, this removes the separate length-tracking variable
'roomtextnumlines', which makes the code much more easy to maintain and
deal with, as the amount of roomtext is naturally tracked by C++ instead
of us having to keep track of the actual amount of roomtext manually.
2020-02-29 23:02:52 -05:00
Matt Penny
1b00d12600 Add option to allow custom levels when the editor is disabled 2020-02-09 23:31:44 -05:00
Matt Penny
7d35c5ce4e Add option to compile without the level editor 2020-02-09 23:31:44 -05:00
Fredrik Ljungdahl
1062113f73 Make tiles in tower mode behave consistently with tower tileset elsewhere
Previously, in tower mode, being inside walls would just kill you, unlike
being inside walls outside tower mode, which was somewhat confusing.

Also, spikes behaved differently with regards to invincibility, being
unsolid in towers but solid outside them.

This does not change the behaviour of the "edge" spikes in towers.
2020-02-05 22:08:48 +01:00
Info Teddy
1e460721bb Fix hardcoded (19,8) all-sides warp happening in custom levels
(19,8) is hardcoded to warp on all-sides no matter what. This is fine,
except for the fact that it was doing this in custom levels, too, even
despite the fact that the warp background and color would be overridden
anyway. The only workaround was to add a warp line to the room in custom
levels. I've added a check for custommode so that this won't happen.
2020-02-02 08:43:28 -05:00
Info Teddy
47ebbf15ab Don't redraw H/V warp BG if gotorooming to same room in customs
This has two benefits:
 (1) The game uses less resources when it is asked to gotoroom to the
     same room because it is no longer redrawing the warp background
     every single frame, which is very wasteful.
 (2) The warp background no longer freezes or flickers if the player is
     standing inside a gotoroom script box (which calls gotoroom every
     frame or every other frame, because every time the gotoroom happens
     the script box gets reloaded).
2020-01-27 14:46:11 -08:00
Fredrik Ljungdahl
3697487f47 Fix minor issue with respawning into a tower
When the game enter towermode, it adjusts player amd camera x/y depending
on what screen the player entered it from (The Tower) or the loadlevel
mode ("minitowers"; Panic Room and The Final Challenge). This code didn't
account for respawning to checkpoints. This is unlikely to matter in most
circumstances, but can cause problems in some corner cases, or with R abuse.
This could cause a player to die, respawn outside camera edges and then
immediately die again due to the edge spikes, repositioning the camera
properly. Invincibility would cause further issues, but that's Invincibility
Mode for you -- if this was the only problem I wouldn't bother.

I added a check that repositions the tower camera appropriately if a player
enter a tower as part of the respawn process.
2020-01-25 23:30:29 -05:00
Info Teddy
921e288ebe Correct Warp Zone's area name from "Warpzone" to "Warp Zone"
This is the name that gets displayed in your save file.
2020-01-15 20:29:30 -05:00
Info Teddy
b8e611a3bf Destroy duplicate player entities during gotoroom
The game makes sure that the player entity is never destroyed, but in
doing so, it doesn't destroy any duplicate player entities that might
have been created via strange means e.g. a custom level doing a
createentity with t=0.

Duplicate player entities are, in a sense, not the "real" player entity.
For one, they can take damage and die, but when they do they'll still be
stuck inside the hazard, which can result in a softlock. For another,
their position isn't updated when going between rooms. It's better to
just destroy them when we can.
2020-01-13 18:18:44 -05:00
Ethan Lee
f7c0321b71 Hello WWWWWWorld! 2020-01-08 10:37:50 -05:00