More lua additions

[johnbaumann]

No description provided.

[ghost]

👇 Click on the image for a new way to code review

Legend

[codecov]

Codecov Report

Attention: 1 lines in your changes are missing coverage. Please review.

Comparison is base (a879d9e) 9.77% compared to head (8b77052) 9.78%.

Files	Patch %	Lines
src/core/pcsxlua.cc	50.00%	1 Missing ⚠️

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #1559   +/-   ##
=======================================
  Coverage    9.77%    9.78%           
=======================================
  Files         441      441           
  Lines      130414   130425   +11     
=======================================
+ Hits        12748    12758   +10     
- Misses     117666   117667    +1     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[nicolasnoble]

So, I'm in a bit of a pickle here. The cdrom refactoring branch has a change there to make the cycle counter 64 bits. Changing this later would be an API breaking change, but I'm still not ready to merge the cd refactoring one. Might be worth doing a last push to finish it.

[johnbaumann]

So, I'm in a bit of a pickle here. The cdrom refactoring branch has a change there to make the cycle counter 64 bits. Changing this later would be an API breaking change, but I'm still not ready to merge the cd refactoring one. Might be worth doing a last push to finish it.

Would it simplify things if I were to do either/both of the following: Pre-empt the change to the cycle counter and simply change the return type of getCPUCycles() to uint64_t, or, assuming the change is relatively small, piggy back the 64-bit cycle counter change into this PR?

[nicolasnoble]

So the problem with changing the return type is that the behavior will still be different after the switch: right now, with a 32 bits counter, it'll roll over every ~2 minutes, whereas with a 64 bits counter, it'd never roll over (or rather, will take a few millennias).

And the problem with cherry-picking the change from the cd-rom branch is that the it's a savestate breaking change, and that'd be too many breaking changes in a row, which I'd like to avoid.

[johnbaumann]

So the problem with changing the return type is that the behavior will still be different after the switch: right now, with a 32 bits counter, it'll roll over every ~2 minutes, whereas with a 64 bits counter, it'd never roll over (or rather, will take a few millennias).

And the problem with cherry-picking the change from the cd-rom branch is that the it's a savestate breaking change, and that'd be too many breaking changes in a row, which I'd like to avoid.

I'm ok with putting this pr on ice.