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

Transition code is not a drawable and doesn't support frameskips #1094

Closed
Ghabry opened this Issue Feb 3, 2017 · 0 comments

Comments

Projects
None yet
3 participants
@Ghabry
Copy link
Member

Ghabry commented Feb 3, 2017

Noticable on slow systems like the 3DS where transitions take significantly longer then elsewhere, due to the way they are implemented.
They are a hardcoded part of Graphics::Draw instead of being a Drawable.

@Ghabry Ghabry added this to the 0.6.0 milestone Feb 3, 2017

Albeleon added a commit to Albeleon/Player that referenced this issue Jun 4, 2018

Transition change:
Note: This commit is done to the PR of the Transition Implementations left (TransitionRandomBlocksDown/Up, TransitionZoomIn/Out, TransitionMosaicIn/Out and TransitionWaveIn/Out), but it changes its its scope greatly.

---------

This Update fixes EasyRPG#1094 by turning Transition into a Drawable and separating Logic from Drawing. It makes the following changes:

    - It separates the functions related with Transitions in Graphics.h/cpp to its own files as Transition.h/cpp.
    - It turns Transition in a Drawable, as an attribute of Graphics that other files can access via Graphics::GetTransition(). It's a global drawable, it has an Update where the logic frames are updated (instead of in the Drawing function), and the TransitionUpdate is now the override Draw. It also adds in Drawable the DrawableType::TypeTransition, whose priority comes below Overlay but above Frame.
    - It changes every reference from other files from Graphics::Transition to Transition::Init to initiate the right transition. Same with the TransitionTypes.
    - It changes quite a few names to make it more consistent:
        · Graphics::DrawFrame -> Graphics::Draw
        · Graphics::Transition -> Transition::Init
        · Graphics::TransitionUpdate -> Transition::Update and Transition::Draw

    - It separates Local and Global drawing of Drawables, and when the screen is erased because a transition (easily checkable by Transition::IsErased()) it prints GlobalDraw, so the overlays should be printed when the screen is erased.
    - The function Graphics::SnapToBitmap, LocalDraw and GlobalDraw have an input argument (priority), which means it will print every Drawable that is equal or below it. If the input is not filled, it uses TransitionType::TransitionMaximum, which means it prints all of them.
    - Also, when a transition is summoned and takes a frozen screen, it makes sure it only prints the drawables below Transition.

    - Now, Update and Draw are completely independent. Graphics::Update only updates logic (except FPS), and when it's time to draw, Player::Update uses Graphics::Draw. Graphics::Update updates the FPS and Transition, and it's always summoned in the logic Update regardless of whether the Scene need updating or not. It's also inside the speed_modifier, so fast_forward affects these Updates.

IMPORTANT: Now that the transition frames are tied to Update logic instead of when they're drawn in the graphics, that means they are affected by lags. This keeps the FPS correct but graphically it can get laggy if the functions have a lot of delay factor. Some functions that have been checked to be really slow and cause lag are Game_System::BgmPlay, Game_System::BgmStop or Player::SetupPlayerSpawn. Which means there will be some lags when starting a new game when there's music, or when loading a file.

Albeleon added a commit to Albeleon/Player that referenced this issue Jun 4, 2018

Transition change:
Note: This commit is done to the PR of the Transition Implementations left (TransitionRandomBlocksDown/Up, TransitionZoomIn/Out, TransitionMosaicIn/Out and TransitionWaveIn/Out), but it changes its its scope greatly.

---------

This Update fixes EasyRPG#1094 by turning Transition into a Drawable and separating Logic from Drawing. It makes the following changes:

    - It separates the functions related with Transitions in Graphics.h/cpp to its own files as Transition.h/cpp.
    - It turns Transition in a Drawable, as an attribute of Graphics that other files can access via Graphics::GetTransition(). It's a global drawable, it has an Update where the logic frames are updated (instead of in the Drawing function), and the TransitionUpdate is now the override Draw. It also adds in Drawable the DrawableType::TypeTransition, whose priority comes below Overlay but above Frame.
    - It changes every reference from other files from Graphics::Transition to Transition::Init to initiate the right transition. Same with the TransitionTypes.
    - It changes quite a few names to make it more consistent:
        · Graphics::DrawFrame -> Graphics::Draw
        · Graphics::Transition -> Transition::Init
        · Graphics::TransitionUpdate -> Transition::Update and Transition::Draw

    - It separates Local and Global drawing of Drawables, and when the screen is erased because a transition (easily checkable by Transition::IsErased()) it prints GlobalDraw, so the overlays should be printed when the screen is erased.
    - The function Graphics::SnapToBitmap, LocalDraw and GlobalDraw have an input argument (priority), which means it will print every Drawable that is equal or below it. If the input is not filled, it uses TransitionType::TransitionMaximum, which means it prints all of them.
    - Also, when a transition is summoned and takes a frozen screen, it makes sure it only prints the drawables below Transition.

    - Now, Update and Draw are completely independent. Graphics::Update only updates logic (except FPS), and when it's time to draw, Player::Update uses Graphics::Draw. Graphics::Update updates the FPS and Transition, and it's always summoned in the logic Update regardless of whether the Scene need updating or not. It's also inside the speed_modifier, so fast_forward affects these Updates.

IMPORTANT: Now that the transition frames are tied to Update logic instead of when they're drawn in the graphics, that means they are affected by lags. This keeps the FPS correct but graphically it can get laggy if the functions have a lot of delay factor. Some functions that have been checked to be really slow and cause lag are Game_System::BgmPlay, Game_System::BgmStop or Player::SetupPlayerSpawn. Which means there will be some lags when starting a new game when there's music, or when loading a file.

Albeleon added a commit to Albeleon/Player that referenced this issue Jun 4, 2018

Transition change:
Note: This commit is done to the PR of the Transition Implementations left (TransitionRandomBlocksDown/Up, TransitionZoomIn/Out, TransitionMosaicIn/Out and TransitionWaveIn/Out), but it changes its its scope greatly.

---------

This Update fixes EasyRPG#1094 by turning Transition into a Drawable and separating Logic from Drawing. It makes the following changes:

    - It separates the functions related with Transitions in Graphics.h/cpp to its own files as Transition.h/cpp.
    - It turns Transition in a Drawable, as an attribute of Graphics that other files can access via Graphics::GetTransition(). It's a global drawable, it has an Update where the logic frames are updated (instead of in the Drawing function), and the TransitionUpdate is now the override Draw. It also adds in Drawable the DrawableType::TypeTransition, whose priority comes below Overlay but above Frame.
    - It changes every reference from other files from Graphics::Transition to Transition::Init to initiate the right transition. Same with the TransitionTypes.
    - It changes quite a few names to make it more consistent:
        · Graphics::DrawFrame -> Graphics::Draw
        · Graphics::Transition -> Transition::Init
        · Graphics::TransitionUpdate -> Transition::Update and Transition::Draw

    - It separates Local and Global drawing of Drawables, and when the screen is erased because a transition (easily checkable by Transition::IsErased()) it prints GlobalDraw, so the overlays should be printed when the screen is erased.
    - The function Graphics::SnapToBitmap, LocalDraw and GlobalDraw have an input argument (priority), which means it will print every Drawable that is equal or below it. If the input is not filled, it uses TransitionType::TransitionMaximum, which means it prints all of them.
    - Also, when a transition is summoned and takes a frozen screen, it makes sure it only prints the drawables below Transition.

    - Now, Update and Draw are completely independent. Graphics::Update only updates logic (except FPS), and when it's time to draw, Player::Update uses Graphics::Draw. Graphics::Update updates the FPS and Transition, and it's always summoned in the logic Update regardless of whether the Scene need updating or not. It's also inside the speed_modifier, so fast_forward affects these Updates.

IMPORTANT: Now that the transition frames are tied to Update logic instead of when they're drawn in the graphics, that means they are affected by lags. This keeps the FPS correct but graphically it can get laggy if the functions have a lot of delay factor. Some functions that have been checked to be really slow and cause lag are Game_System::BgmPlay, Game_System::BgmStop or Player::SetupPlayerSpawn. Which means there will be some lags when starting a new game when there's music, or when loading a file.

Albeleon added a commit to Albeleon/Player that referenced this issue Jun 4, 2018

Transition change:
Note: This commit is done to the PR of the Transition Implementations left (TransitionRandomBlocksDown/Up, TransitionZoomIn/Out, TransitionMosaicIn/Out and TransitionWaveIn/Out), but it changes its its scope greatly.

---------

This Update fixes EasyRPG#1094 by turning Transition into a Drawable and separating Logic from Drawing. It makes the following changes:

    - It separates the functions related with Transitions in Graphics.h/cpp to its own files as Transition.h/cpp.
    - It turns Transition in a Drawable, as an attribute of Graphics that other files can access via Graphics::GetTransition(). It's a global drawable, it has an Update where the logic frames are updated (instead of in the Drawing function), and the TransitionUpdate is now the override Draw. It also adds in Drawable the DrawableType::TypeTransition, whose priority comes below Overlay but above Frame.
    - It changes every reference from other files from Graphics::Transition to Transition::Init to initiate the right transition. Same with the TransitionTypes.
    - It changes quite a few names to make it more consistent:
        · Graphics::DrawFrame -> Graphics::Draw
        · Graphics::Transition -> Transition::Init
        · Graphics::TransitionUpdate -> Transition::Update and Transition::Draw

    - It separates Local and Global drawing of Drawables, and when the screen is erased because a transition (easily checkable by Transition::IsErased()) it prints GlobalDraw, so the overlays should be printed when the screen is erased.
    - The function Graphics::SnapToBitmap, LocalDraw and GlobalDraw have an input argument (priority), which means it will print every Drawable that is equal or below it. If the input is not filled, it uses TransitionType::TransitionMaximum, which means it prints all of them.
    - Also, when a transition is summoned and takes a frozen screen, it makes sure it only prints the drawables below Transition.

    - Now, Update and Draw are completely independent. Graphics::Update only updates logic (except FPS), and when it's time to draw, Player::Update uses Graphics::Draw. Graphics::Update updates the FPS and Transition, and it's always summoned in the logic Update regardless of whether the Scene need updating or not. It's also inside the speed_modifier, so fast_forward affects these Updates.

IMPORTANT: Now that the transition frames are tied to Update logic instead of when they're drawn in the graphics, that means they are affected by lags. This keeps the FPS correct but graphically it can get laggy if the functions have a lot of delay factor. Some functions that have been checked to be really slow and cause lag are Game_System::BgmPlay, Game_System::BgmStop or Player::SetupPlayerSpawn. Which means there will be some lags when starting a new game when there's music, or when loading a file.

Albeleon added a commit to Albeleon/Player that referenced this issue Jun 4, 2018

Transition change:
Note: This commit is done to the PR of the Transition Implementations left (TransitionRandomBlocksDown/Up, TransitionZoomIn/Out, TransitionMosaicIn/Out and TransitionWaveIn/Out), but it changes its its scope greatly.

---------

This Update fixes EasyRPG#1094 by turning Transition into a Drawable and separating Logic from Drawing. It makes the following changes:

    - It separates the functions related with Transitions in Graphics.h/cpp to its own files as Transition.h/cpp.
    - It turns Transition in a Drawable, as an attribute of Graphics that other files can access via Graphics::GetTransition(). It's a global drawable, it has an Update where the logic frames are updated (instead of in the Drawing function), and the TransitionUpdate is now the override Draw. It also adds in Drawable the DrawableType::TypeTransition, whose priority comes below Overlay but above Frame.
    - It changes every reference from other files from Graphics::Transition to Transition::Init to initiate the right transition. Same with the TransitionTypes.
    - It changes quite a few names to make it more consistent:
        · Graphics::DrawFrame -> Graphics::Draw
        · Graphics::Transition -> Transition::Init
        · Graphics::TransitionUpdate -> Transition::Update and Transition::Draw

    - It separates Local and Global drawing of Drawables, and when the screen is erased because a transition (easily checkable by Transition::IsErased()) it prints GlobalDraw, so the overlays should be printed when the screen is erased.
    - The function Graphics::SnapToBitmap, LocalDraw and GlobalDraw have an input argument (priority), which means it will print every Drawable that is equal or below it. If the input is not filled, it uses TransitionType::TransitionMaximum, which means it prints all of them.
    - Also, when a transition is summoned and takes a frozen screen, it makes sure it only prints the drawables below Transition.

    - Now, Update and Draw are completely independent. Graphics::Update only updates logic (except FPS), and when it's time to draw, Player::Update uses Graphics::Draw. Graphics::Update updates the FPS and Transition, and it's always summoned in the logic Update regardless of whether the Scene need updating or not. It's also inside the speed_modifier, so fast_forward affects these Updates.

IMPORTANT: Now that the transition frames are tied to Update logic instead of when they're drawn in the graphics, that means they are affected by lags. This keeps the FPS correct but graphically it can get laggy if the functions have a lot of delay factor. Some functions that have been checked to be really slow and cause lag are Game_System::BgmPlay, Game_System::BgmStop or Player::SetupPlayerSpawn. Which means there will be some lags when starting a new game when there's music, or when loading a file.

Albeleon added a commit to Albeleon/Player that referenced this issue Jun 4, 2018

Transition change:
Note: This commit is done to the PR of the Transition Implementations left (TransitionRandomBlocksDown/Up, TransitionZoomIn/Out, TransitionMosaicIn/Out and TransitionWaveIn/Out), but it changes its its scope greatly.

---------

This Update fixes EasyRPG#1094 by turning Transition into a Drawable and separating Logic from Drawing. It makes the following changes:

    - It separates the functions related with Transitions in Graphics.h/cpp to its own files as Transition.h/cpp.
    - It turns Transition in a Drawable, as an attribute of Graphics that other files can access via Graphics::GetTransition(). It's a global drawable, it has an Update where the logic frames are updated (instead of in the Drawing function), and the TransitionUpdate is now the override Draw. It also adds in Drawable the DrawableType::TypeTransition, whose priority comes below Overlay but above Frame.
    - It changes every reference from other files from Graphics::Transition to Transition::Init to initiate the right transition. Same with the TransitionTypes.
    - It changes quite a few names to make it more consistent:
        · Graphics::DrawFrame -> Graphics::Draw
        · Graphics::Transition -> Transition::Init
        · Graphics::TransitionUpdate -> Transition::Update and Transition::Draw

    - It separates Local and Global drawing of Drawables, and when the screen is erased because a transition (easily checkable by Transition::IsErased()) it prints GlobalDraw, so the overlays should be printed when the screen is erased.
    - The function Graphics::SnapToBitmap, LocalDraw and GlobalDraw have an input argument (priority), which means it will print every Drawable that is equal or below it. If the input is not filled, it uses TransitionType::TransitionMaximum, which means it prints all of them.
    - Also, when a transition is summoned and takes a frozen screen, it makes sure it only prints the drawables below Transition.

    - Now, Update and Draw are completely independent. Graphics::Update only updates logic (except FPS), and when it's time to draw, Player::Update uses Graphics::Draw. Graphics::Update updates the FPS and Transition, and it's always summoned in the logic Update regardless of whether the Scene need updating or not. It's also inside the speed_modifier, so fast_forward affects these Updates.

IMPORTANT: Now that the transition frames are tied to Update logic instead of when they're drawn in the graphics, that means they are affected by lags. This keeps the FPS correct but graphically it can get laggy if the functions have a lot of delay factor. Some functions that have been checked to be really slow and cause lag are Game_System::BgmPlay, Game_System::BgmStop or Player::SetupPlayerSpawn. Which means there will be some lags when starting a new game when there's music, or when loading a file.

Albeleon added a commit to Albeleon/Player that referenced this issue Jun 4, 2018

Transition change:
Note: This commit is done to the PR of the Transition Implementations left (TransitionRandomBlocksDown/Up, TransitionZoomIn/Out, TransitionMosaicIn/Out and TransitionWaveIn/Out), but it changes its its scope greatly.

---------

This Update fixes EasyRPG#1094 by turning Transition into a Drawable and separating Logic from Drawing. It makes the following changes:

    - It separates the functions related with Transitions in Graphics.h/cpp to its own files as Transition.h/cpp.
    - It turns Transition in a Drawable, as an attribute of Graphics that other files can access via Graphics::GetTransition(). It's a global drawable, it has an Update where the logic frames are updated (instead of in the Drawing function), and the TransitionUpdate is now the override Draw. It also adds in Drawable the DrawableType::TypeTransition, whose priority comes below Overlay but above Frame.
    - It changes every reference from other files from Graphics::Transition to Transition::Init to initiate the right transition. Same with the TransitionTypes.
    - It changes quite a few names to make it more consistent:
        · Graphics::DrawFrame -> Graphics::Draw
        · Graphics::Transition -> Transition::Init
        · Graphics::TransitionUpdate -> Transition::Update and Transition::Draw

    - It separates Local and Global drawing of Drawables, and when the screen is erased because a transition (easily checkable by Transition::IsErased()) it prints GlobalDraw, so the overlays should be printed when the screen is erased.
    - The function Graphics::SnapToBitmap, LocalDraw and GlobalDraw have an input argument (priority), which means it will print every Drawable that is equal or below it. If the input is not filled, it uses TransitionType::TransitionMaximum, which means it prints all of them.
    - Also, when a transition is summoned and takes a frozen screen, it makes sure it only prints the drawables below Transition.

    - Now, Update and Draw are completely independent. Graphics::Update only updates logic (except FPS), and when it's time to draw, Player::Update uses Graphics::Draw. Graphics::Update updates the FPS and Transition, and it's always summoned in the logic Update regardless of whether the Scene need updating or not. It's also inside the speed_modifier, so fast_forward affects these Updates.

IMPORTANT: Now that the transition frames are tied to Update logic instead of when they're drawn in the graphics, that means they are affected by lags. This keeps the FPS correct but graphically it can get laggy if the functions have a lot of delay factor. Some functions that have been checked to be really slow and cause lag are Game_System::BgmPlay, Game_System::BgmStop or Player::SetupPlayerSpawn. Which means there will be some lags when starting a new game when there's music, or when loading a file.

Albeleon added a commit to Albeleon/Player that referenced this issue Jun 4, 2018

Transition change:
Note: This commit is done to the PR of the Transition Implementations left (TransitionRandomBlocksDown/Up, TransitionZoomIn/Out, TransitionMosaicIn/Out and TransitionWaveIn/Out), but it changes its its scope greatly.

---------

This Update fixes EasyRPG#1094 by turning Transition into a Drawable and separating Logic from Drawing. It makes the following changes:

    - It separates the functions related with Transitions in Graphics.h/cpp to its own files as Transition.h/cpp.
    - It turns Transition in a Drawable, as an attribute of Graphics that other files can access via Graphics::GetTransition(). It's a global drawable, it has an Update where the logic frames are updated (instead of in the Drawing function), and the TransitionUpdate is now the override Draw. It also adds in Drawable the DrawableType::TypeTransition, whose priority comes below Overlay but above Frame.
    - It changes every reference from other files from Graphics::Transition to Transition::Init to initiate the right transition. Same with the TransitionTypes.
    - It changes quite a few names to make it more consistent:
        · Graphics::DrawFrame -> Graphics::Draw
        · Graphics::Transition -> Transition::Init
        · Graphics::TransitionUpdate -> Transition::Update and Transition::Draw

    - It separates Local and Global drawing of Drawables, and when the screen is erased because a transition (easily checkable by Transition::IsErased()) it prints GlobalDraw, so the overlays should be printed when the screen is erased.
    - The function Graphics::SnapToBitmap, LocalDraw and GlobalDraw have an input argument (priority), which means it will print every Drawable that is equal or below it. If the input is not filled, it uses TransitionType::TransitionMaximum, which means it prints all of them.
    - Also, when a transition is summoned and takes a frozen screen, it makes sure it only prints the drawables below Transition.

    - Now, Update and Draw are completely independent. Graphics::Update only updates logic (except FPS), and when it's time to draw, Player::Update uses Graphics::Draw. Graphics::Update updates the FPS and Transition, and it's always summoned in the logic Update regardless of whether the Scene need updating or not. It's also inside the speed_modifier, so fast_forward affects these Updates.

IMPORTANT: Now that the transition frames are tied to Update logic instead of when they're drawn in the graphics, that means they are affected by lags. This keeps the FPS correct but graphically it can get laggy if the functions have a lot of delay factor. Some functions that have been checked to be really slow and cause lag are Game_System::BgmPlay, Game_System::BgmStop or Player::SetupPlayerSpawn. Which means there will be some lags when starting a new game when there's music, or when loading a file.

Albeleon added a commit to Albeleon/Player that referenced this issue Jun 5, 2018

Transition change:
Note: This commit is done to the PR of the Transition Implementations left (TransitionRandomBlocksDown/Up, TransitionZoomIn/Out, TransitionMosaicIn/Out and TransitionWaveIn/Out), but it changes its its scope greatly.

---------

This Update fixes EasyRPG#1094 by turning Transition into a Drawable and separating Logic from Drawing. It makes the following changes:

    - It separates the functions related with Transitions in Graphics.h/cpp to its own files as Transition.h/cpp.
    - It turns Transition in a Drawable, as an attribute of Graphics that other files can access via Graphics::GetTransition(). It's a global drawable, it has an Update where the logic frames are updated (instead of in the Drawing function), and the TransitionUpdate is now the override Draw. It also adds in Drawable the DrawableType::TypeTransition, whose priority comes below Overlay but above Frame.
    - It changes every reference from other files from Graphics::Transition to Transition::Init to initiate the right transition. Same with the TransitionTypes.
    - It changes quite a few names to make it more consistent:
        · Graphics::DrawFrame -> Graphics::Draw
        · Graphics::Transition -> Transition::Init
        · Graphics::TransitionUpdate -> Transition::Update and Transition::Draw

    - It separates Local and Global drawing of Drawables, and when the screen is erased because a transition (easily checkable by Transition::IsErased()) it prints GlobalDraw, so the overlays should be printed when the screen is erased.
    - The function Graphics::SnapToBitmap, LocalDraw and GlobalDraw have an input argument (priority), which means it will print every Drawable that is equal or below it. If the input is not filled, it uses TransitionType::TransitionMaximum, which means it prints all of them.
    - Also, when a transition is summoned and takes a frozen screen, it makes sure it only prints the drawables below Transition.

    - Now, Update and Draw are completely independent. Graphics::Update only updates logic (except FPS), and when it's time to draw, Player::Update uses Graphics::Draw. Graphics::Update updates the FPS and Transition, and it's always summoned in the logic Update regardless of whether the Scene need updating or not. It's also inside the speed_modifier, so fast_forward affects these Updates.

IMPORTANT: Now that the transition frames are tied to Update logic instead of when they're drawn in the graphics, that means they are affected by lags. This keeps the FPS correct but graphically it can get laggy if the functions have a lot of delay factor. Some functions that have been checked to be really slow and cause lag are Game_System::BgmPlay, Game_System::BgmStop or Player::SetupPlayerSpawn. Which means there will be some lags when starting a new game when there's music, or when loading a file.

@Ghabry Ghabry modified the milestones: 0.6.0, 0.5.4 Jun 18, 2018

Albeleon added a commit to Albeleon/Player that referenced this issue Jun 24, 2018

Transition change:
Note: This commit is done to the PR of the Transition Implementations left (TransitionRandomBlocksDown/Up, TransitionZoomIn/Out, TransitionMosaicIn/Out and TransitionWaveIn/Out), but it changes its its scope greatly.

---------

This Update fixes EasyRPG#1094 by turning Transition into a Drawable and separating Logic from Drawing. It makes the following changes:

    - It separates the functions related with Transitions in Graphics.h/cpp to its own files as Transition.h/cpp.
    - It turns Transition in a Drawable, as an attribute of Graphics that other files can access via Graphics::GetTransition(). It's a global drawable, it has an Update where the logic frames are updated (instead of in the Drawing function), and the TransitionUpdate is now the override Draw. It also adds in Drawable the DrawableType::TypeTransition, whose priority comes below Overlay but above Frame.
    - It changes every reference from other files from Graphics::Transition to Transition::Init to initiate the right transition. Same with the TransitionTypes.
    - It changes quite a few names to make it more consistent:
        · Graphics::DrawFrame -> Graphics::Draw
        · Graphics::Transition -> Transition::Init
        · Graphics::TransitionUpdate -> Transition::Update and Transition::Draw

    - It separates Local and Global drawing of Drawables, and when the screen is erased because a transition (easily checkable by Transition::IsErased()) it prints GlobalDraw, so the overlays should be printed when the screen is erased.
    - The function Graphics::SnapToBitmap, LocalDraw and GlobalDraw have an input argument (priority), which means it will print every Drawable that is equal or below it. If the input is not filled, it uses TransitionType::TransitionMaximum, which means it prints all of them.
    - Also, when a transition is summoned and takes a frozen screen, it makes sure it only prints the drawables below Transition.
    - Graphics::IsTransitionActive now checks if Transition exists before checking if it's active. This is done since, when they Graphics are resetted when they are eliminated, this function is still called one more time.

    - Now, Update and Draw are completely independent. Graphics::Update only updates logic (except FPS), and when it's time to draw, Player::Update uses Graphics::Draw. Graphics::Update updates the FPS and Transition, and it's always summoned in the logic Update regardless of whether the Scene need updating or not. It's also inside the speed_modifier, so fast_forward affects these Updates.

IMPORTANT: Now that the transition frames are tied to Update logic instead of when they're drawn in the graphics, that means they are affected by lags. This keeps the FPS correct but graphically it can get laggy if the functions have a lot of delay factor. Some functions that have been checked to be really slow and cause lag are Game_System::BgmPlay, Game_System::BgmStop or Player::SetupPlayerSpawn. Which means there will be some lags when starting a new game when there's music, or when loading a file.

Format fixes and Checking in Graphics::UpdateSceneCallback whether Transition is nullptr before checking if it's active, so it doesn't give an error when closing the application after Graphics::Quit

Albeleon added a commit to Albeleon/Player that referenced this issue Jun 24, 2018

"Turn Transition to a Drawable; Implement missing transitions (Random…
…BlockUp/Down, WaveIn/Out, ZoomIn/Out, MosaicIn/Out)

This Update fixes EasyRPG#1094 by turning Transition into a Drawable and separating Logic from Drawing. It makes the following changes:

    - It separates the functions related with Transitions in Graphics.h/cpp to its own files as Transition.h/cpp.
    - It turns Transition in a Drawable, as an attribute of Graphics that other files can access via Graphics::GetTransition(). It's a global drawable, it has an Update where the logic frames are updated (instead of in the Drawing function), and the TransitionUpdate is now the override Draw. It also adds in Drawable the DrawableType::TypeTransition, whose priority comes below Overlay but above Frame.
    - It changes every reference from other files from Graphics::Transition to Transition::Init to initiate the right transition. Same with the TransitionTypes.
    - It changes quite a few names to make it more consistent:
        · Graphics::DrawFrame -> Graphics::Draw
        · Graphics::Transition -> Transition::Init
        · Graphics::TransitionUpdate -> Transition::Update and Transition::Draw

    - It separates Local and Global drawing of Drawables, and when the screen is erased because a transition (easily checkable by Transition::IsErased()) it prints GlobalDraw, so the overlays should be printed when the screen is erased.
    - The function Graphics::SnapToBitmap, LocalDraw and GlobalDraw have an input argument (priority), which means it will print every Drawable that is equal or below it. If the input is not filled, it uses TransitionType::TransitionMaximum, which means it prints all of them.
    - Also, when a transition is summoned and takes a frozen screen, it makes sure it only prints the drawables below Transition.
    - Graphics::IsTransitionPending now checks if Transition exists before checking if it's active. This is done since, when they Graphics are reseted when they are eliminated, this function is still called one more time.

    - Now, Update and Draw are completely independent. Graphics::Update only updates logic (except FPS), and when it's time to draw, Player::Update uses Graphics::Draw. Graphics::Update updates the FPS and Transition, and it's always summoned in the logic Update regardless of whether the Scene need updating or not. It's also inside the speed_modifier, so fast_forward affects these Updates.

IMPORTANT: Now that the transition frames are tied to Update logic instead of when they're drawn in the graphics, that means they are affected by lags. This keeps the FPS correct but graphically it can get laggy if the functions have a lot of delay factor. Some functions that have been checked to be really slow and cause lag are Game_System::BgmPlay, Game_System::BgmStop or Player::SetupPlayerSpawn. Which means there will be some lags when starting a new game when there's music, or when loading a file.

Also, Transitions RandomBlocksUp/Down, ZoomIn/Out, MosaicIn/Out and WaveIn/Out have been implemented:
 - RandomBlocksUp/Down work like RandomBlocks but with a different order.
 - ZoomIn/Out uses StretchBlit in Draw(), saving beforehand the character's screen position where to zoom. The zoom isn't direct, it only starts zooming right directly on the character when they are in the 75% inner screen, so a few changes were made to be as similar as RPG_RT.
 - MosaicIn/Out uses FillRect after taking each pixel. When mosaic_size = 2, 3 or 4, it's the most heavy performance wise (320 / size * 240 / size), but the bigger the mosaic_size is, the less time it takes. Also, the pixel and position it takes is modified a little to not create confusing chaos or intuitive order.
 - WaveInOut uses WaverBlit with the right parameters to imitate RPG_RT's transition.

Albeleon added a commit to Albeleon/Player that referenced this issue Jun 29, 2018

"Turn Transition to a Drawable; Implement missing transitions (Random…
…BlockUp/Down, WaveIn/Out, ZoomIn/Out, MosaicIn/Out)

This Update fixes EasyRPG#1094 by turning Transition into a Drawable and separating Logic from Drawing. It makes the following changes:

    - It separates the functions related with Transitions in Graphics.h/cpp to its own files as Transition.h/cpp.
    - It turns Transition in a Drawable, as an attribute of Graphics that other files can access via Graphics::GetTransition(). It's a global drawable, it has an Update where the logic frames are updated (instead of in the Drawing function), and the TransitionUpdate is now the override Draw. It also adds in Drawable the DrawableType::TypeTransition, whose priority comes below Overlay but above Frame.
    - It changes every reference from other files from Graphics::Transition to Transition::Init to initiate the right transition. Same with the TransitionTypes.
    - It changes quite a few names to make it more consistent:
        · Graphics::DrawFrame -> Graphics::Draw
        · Graphics::Transition -> Transition::Init
        · Graphics::TransitionUpdate -> Transition::Update and Transition::Draw

    - It separates Local and Global drawing of Drawables, and when the screen is erased because a transition (easily checkable by Transition::IsErased()) it prints GlobalDraw, so the overlays should be printed when the screen is erased.
    - The function Graphics::SnapToBitmap, LocalDraw and GlobalDraw have an input argument (priority), which means it will print every Drawable that is equal or below it. If the input is not filled, it uses TransitionType::TransitionMaximum, which means it prints all of them.
    - Also, when a transition is summoned and takes a frozen screen, it makes sure it only prints the drawables below Transition.
    - Graphics::IsTransitionPending now checks if Transition exists before checking if it's active. This is done since, when they Graphics are reseted when they are eliminated, this function is still called one more time.

    - Now, Update and Draw are completely independent. Graphics::Update only updates logic (except FPS), and when it's time to draw, Player::Update uses Graphics::Draw. Graphics::Update updates the FPS and Transition, and it's always summoned in the logic Update regardless of whether the Scene need updating or not. It's also inside the speed_modifier, so fast_forward affects these Updates.

IMPORTANT: Now that the transition frames are tied to Update logic instead of when they're drawn in the graphics, that means they are affected by lags. This keeps the FPS correct but graphically it can get laggy if the functions have a lot of delay factor. Some functions that have been checked to be really slow and cause lag are Game_System::BgmPlay, Game_System::BgmStop or Player::SetupPlayerSpawn. Which means there will be some lags when starting a new game when there's music, or when loading a file.

Also, Transitions RandomBlocksUp/Down, ZoomIn/Out, MosaicIn/Out and WaveIn/Out have been implemented:
 - RandomBlocksUp/Down work like RandomBlocks but with a different order.
 - ZoomIn/Out uses StretchBlit in Draw(), saving beforehand the character's screen position where to zoom. The zoom isn't direct, it only starts zooming right directly on the character when they are in the 75% inner screen, so a few changes were made to be as similar as RPG_RT.
 - MosaicIn/Out uses FillRect after taking each pixel. When mosaic_size = 2, 3 or 4, it's the most heavy performance wise (320 / size * 240 / size), but the bigger the mosaic_size is, the less time it takes. Also, the pixel and position it takes is modified a little to not create confusing chaos or intuitive order.
 - WaveInOut uses WaverBlit with the right parameters to imitate RPG_RT's transition.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.