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

Restructure the processor handling to use a variant object #149

Merged
merged 40 commits into from
Jan 8, 2024

Conversation

edo9300
Copy link
Owner

@edo9300 edo9300 commented Sep 24, 2023

Rewrite the whole process function of the processor to use instead tag dispatching on variant objects.
Each single processor message got rewritten as a struct, inheriting from a base templated Process struct, containing only the required data for that process, rather than using the generic structure that ended up needing to spam bitwise operations to pack as many arguments in a byte as possible. This makes things easier to follow and streamlines the addition of new processes:

  • Define its struct with the parameters it expects by also providing a constructor
    • If the process requires an answer, inherit it from Process<true>, if it requires no answer, inherit it from Process<false>
  • Add such struct to the processors variant type
  • Declare and implement its corresponding bool process(Processors::NewProcess& arg); function

…ocessors

Updated ExecuteCost, ExecuteOperation, ExecuteTarget, PhaseEvent, PointEvent, QuickEffect, IdleCommand and partially BattleCommand
ChangePos, SendTo, SpSummonStep, MonsterSet, FlipSummon, Equip, TrapMonsterAdjust, SelfDestroy, ControlAdjust, SwapControl, GetControl, RemoveOverlay and PayLPCost
…and ocgapi

Also split the SelfDestroy processor into appropriate subprocesses to keep it clear
So that it's consistent with the c api
Now all the processes use a common structure, except 4 remaining special cases
@edo9300 edo9300 added this to the API v11 milestone Sep 24, 2023
…ptions disabled for mac os

Attempt to work around std::visit's availability only on mac os 10.14+ if built with exceptions
it wasn't properly handling cancelations
Actually properly use an optional to handle the only instance of processor_unit used standalone (processor::reserved)
Helps reducing symbol names to ease debugging
It was only used in the handling of Processors::BattleCommand, properly put the values it was used for in the processor struct
@edo9300 edo9300 force-pushed the processor-variant branch 2 times, most recently from 0aa14b4 to 665a658 Compare January 5, 2024 11:34
@edo9300 edo9300 force-pushed the master branch 3 times, most recently from 45e4132 to 7982ca1 Compare January 5, 2024 12:15
@edo9300 edo9300 force-pushed the processor-variant branch 2 times, most recently from 92ab087 to 70b8f13 Compare January 5, 2024 14:54
This base class, uncopyable holds both the current processor step value and sets the tag to check if the processor needs an answer, cleanung up the implementation of Processors::NeedsAnswer
Rather than having half of them taking it as unsigned, and the other as signed int16
Bite the extra memory size for each processor, but avoid allocating containers seaparately from the single processors
Enabled by default only when doing debug builds, under visual studio, the processor_unit is then declared as variant of variants, with a maximum of 30 elements each, so that visual studio can display it in the debugger
@edo9300 edo9300 marked this pull request as ready for review January 8, 2024 19:35
@edo9300 edo9300 merged commit e97a1c2 into master Jan 8, 2024
28 checks passed
@edo9300 edo9300 deleted the processor-variant branch January 8, 2024 19:47
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.

1 participant