mpo/VVVVVV
1
0
Fork 0
mirror of https://github.com/TerryCavanagh/VVVVVV.git synced 2024-11-18 00:49:42 +01:00
Code Issues Releases Wiki Activity
VVVVVV/desktop_version/src/Ent.h

57 lines
972 B
C
Raw Normal View History

Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
#ifndef ENT_H
#define ENT_H
Fix, for in-GAMEMODE sprites, their colors updating too fast Okay, so the problem here is that Graphics::setcol() is called right before a sprite is drawn in a render function, but render functions are done in deltatime, meaning that the color of a sprite keeps being recalculated every time. This only affects sprites that use fRandom() (the other thing that can dynamically determine a color is help.glow, but that's only updated in the fixed-timestep loop), but is especially noticeable for sprites that flash wildly, like the teleporter, trinket, and elephant. To fix this, we need to make the color be recalculated only in the fixed-timestep loop. However, this means that we MUST store the color of the sprite SOMEWHERE for the delta-timesteps to render it, otherwise the color calculation will just be lost or something. So each entity now has a new attribute, `realcol`, which is the actual raw color used to render the sprite in render functions. This is not to be confused with their `colour` attribute, which is more akin to a color "ID" of sorts, but which isn't an actual color. At the end of gamelogic(), as well as when an entity is first created, the `colour` is given to Graphics::setcol() and then `realcol` gets set to the actual color. Then when it comes time to render the entity, `realcol` gets used instead. Gravitron squares are a somewhat tricky case where there's technically TWO colors for it - one is the actual sprite itself and the other is the indicator. However, usually the indicator and the square aren't both onscreen at the same time, so we can simply switch the realcol between the two as needed. However, we can't use this system for the sprite colors used on the title and map screen, so we'll have to do something else for those.
2020-05-01 02:34:37 +02:00
#include "Graphics.h"
Move entityclass::setenemyroom() to entclass::setenemyroom() This moves the setenemyroom() function onto the entity object itself, so I can more easily change all 'entities[k].' to 'entity.' in entityclass::createentity() later. Additionally, I've had to move the rn() macro from Entity.h to Ent.h, or else entclass::setenemyroom() won't know what it is.
2020-04-03 21:43:06 +02:00
#define rn( rx, ry) ((rx) + ((ry) * 100))
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
class entclass
{
public:
entclass();
bool outside();
Move entityclass::setenemy() to entclass::setenemy() This moves the setenemy() function onto the entity object itself, instead of having to give the indice of the entity in obj.entities. This makes the code more object-oriented so later I can simply change all 'entities[k]' to 'entity.' in entityclass::createentity().
2020-04-03 21:29:57 +02:00
void setenemy(int t);
Move entityclass::setenemyroom() to entclass::setenemyroom() This moves the setenemyroom() function onto the entity object itself, so I can more easily change all 'entities[k].' to 'entity.' in entityclass::createentity() later. Additionally, I've had to move the rn() macro from Entity.h to Ent.h, or else entclass::setenemyroom() won't know what it is.
2020-04-03 21:43:06 +02:00
void setenemyroom(int rx, int ry);
Move entityclass::settreadmillcolour() to entclass::settreadmillcolour() This moves settreadmillcolour() onto the entity object, so I can invoke it independent of an indice in obj.entities.
2020-04-03 21:47:38 +02:00
void settreadmillcolour(int rx, int ry);
Fix, for in-GAMEMODE sprites, their colors updating too fast Okay, so the problem here is that Graphics::setcol() is called right before a sprite is drawn in a render function, but render functions are done in deltatime, meaning that the color of a sprite keeps being recalculated every time. This only affects sprites that use fRandom() (the other thing that can dynamically determine a color is help.glow, but that's only updated in the fixed-timestep loop), but is especially noticeable for sprites that flash wildly, like the teleporter, trinket, and elephant. To fix this, we need to make the color be recalculated only in the fixed-timestep loop. However, this means that we MUST store the color of the sprite SOMEWHERE for the delta-timesteps to render it, otherwise the color calculation will just be lost or something. So each entity now has a new attribute, `realcol`, which is the actual raw color used to render the sprite in render functions. This is not to be confused with their `colour` attribute, which is more akin to a color "ID" of sorts, but which isn't an actual color. At the end of gamelogic(), as well as when an entity is first created, the `colour` is given to Graphics::setcol() and then `realcol` gets set to the actual color. Then when it comes time to render the entity, `realcol` gets used instead. Gravitron squares are a somewhat tricky case where there's technically TWO colors for it - one is the actual sprite itself and the other is the indicator. However, usually the indicator and the square aren't both onscreen at the same time, so we can simply switch the realcol between the two as needed. However, we can't use this system for the sprite colors used on the title and map screen, so we'll have to do something else for those.
2020-05-01 02:34:37 +02:00
void updatecolour();
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
public:
//Fundamentals
Refactor entities and linecrosskludge to not use the 'active' system This removes the variables obj.nentity and obj.nlinecrosskludge, as well as removing the 'active' attribute from the entity class object. Now every entity you access is guaranteed to be real and you don't have to check the 'active' variable. The biggest part of this is changing createentity() to modify a newly-created entity object and push it back instead of already modifying an indice in obj.entities. As well, removing an entity now uses the new obj.removeentity() function and removeentity_iter() macro.
2020-04-03 22:50:16 +02:00
bool invis;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
int type, size, tile, rule;
int state, statedelay;
int behave, animate;
float para;
int life, colour;
//Position and velocity
int oldxp, oldyp;
float ax, ay, vx, vy;
int cx, cy, w, h;
float newxp, newyp;
bool isplatform;
int x1,y1,x2,y2;
//Collision Rules
int onentity;
bool harmful;
int onwall, onxwall, onywall;
//Platforming specific
bool jumping;
bool gravity;
int onground, onroof;
int jumpframe;
//Animation
int framedelay, drawframe, walkingframe, dir, actionframe;
int yp;int xp;
Fix, for in-GAMEMODE sprites, their colors updating too fast Okay, so the problem here is that Graphics::setcol() is called right before a sprite is drawn in a render function, but render functions are done in deltatime, meaning that the color of a sprite keeps being recalculated every time. This only affects sprites that use fRandom() (the other thing that can dynamically determine a color is help.glow, but that's only updated in the fixed-timestep loop), but is especially noticeable for sprites that flash wildly, like the teleporter, trinket, and elephant. To fix this, we need to make the color be recalculated only in the fixed-timestep loop. However, this means that we MUST store the color of the sprite SOMEWHERE for the delta-timesteps to render it, otherwise the color calculation will just be lost or something. So each entity now has a new attribute, `realcol`, which is the actual raw color used to render the sprite in render functions. This is not to be confused with their `colour` attribute, which is more akin to a color "ID" of sorts, but which isn't an actual color. At the end of gamelogic(), as well as when an entity is first created, the `colour` is given to Graphics::setcol() and then `realcol` gets set to the actual color. Then when it comes time to render the entity, `realcol` gets used instead. Gravitron squares are a somewhat tricky case where there's technically TWO colors for it - one is the actual sprite itself and the other is the indicator. However, usually the indicator and the square aren't both onscreen at the same time, so we can simply switch the realcol between the two as needed. However, we can't use this system for the sprite colors used on the title and map screen, so we'll have to do something else for those.
2020-05-01 02:34:37 +02:00
Uint32 realcol;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
};
#endif /* ENT_H */
Reference in a new issue Copy permalink