Game Frame Rate and wait type.
9 posts
• Page 1 of 1
Game Frame Rate and wait type.
Hi,
as we know most game are either 30 fps or 60fps on console and this translate to their internal fire mechanism/limit.
so to make it short a lot of game firing mechanic use a multiple of 1000/60 (16,66667ms)
for example if you need to make a rapid fire for a gun A with 133,3333 ms fire interval you would usually code something like:
now since the value (50+84 = 134) isn't an exact match of 133,333ms but a rounded value to ceil integer it may drift over time for weapons with very large magazine.
say i have 100 round in mag and play at 30fps :
if i'm 0,66667ms off each round , after 75 bullet i am 50ms off and albeit minimal this can cause fire hiccup for the remainder of the mag..
my question to JKBR is could you implement something like a precision wait (call it wait_p) but with an exact value of 1000/60ms (or 16,67ms, as the T2 response time is 50µs this should be possible) ?
wait_p(m) ; // wait m time 1000/60 ms ?
this would allow perfect timing with no frame drift of anything up to 60fps.
the previous code would become :
maybe i'm over thinking this because game sync is hard to achieve but this would be useful anyway as in most game console
wait time are tied to frames.
as we know most game are either 30 fps or 60fps on console and this translate to their internal fire mechanism/limit.
so to make it short a lot of game firing mechanic use a multiple of 1000/60 (16,66667ms)
for example if you need to make a rapid fire for a gun A with 133,3333 ms fire interval you would usually code something like:
- Code: Select all
combo RPM450 {
set_val(PS4_R2, 100);
wait(50);
set_val(PS4_R2, 0);
wait(84);
set_val(PS4_R2, 0);
}
now since the value (50+84 = 134) isn't an exact match of 133,333ms but a rounded value to ceil integer it may drift over time for weapons with very large magazine.
say i have 100 round in mag and play at 30fps :
if i'm 0,66667ms off each round , after 75 bullet i am 50ms off and albeit minimal this can cause fire hiccup for the remainder of the mag..
my question to JKBR is could you implement something like a precision wait (call it wait_p) but with an exact value of 1000/60ms (or 16,67ms, as the T2 response time is 50µs this should be possible) ?
wait_p(m) ; // wait m time 1000/60 ms ?
this would allow perfect timing with no frame drift of anything up to 60fps.
the previous code would become :
- Code: Select all
combo RPM450 {
set_val(PS4_R2, 100);
wait_p(2); // wait 2 frames@60fps = 33,33ms
set_val(PS4_R2, 0);
wait_p(6); // wait 6 frames@60fps = 100ms
set_val(PS4_R2, 0);
}
maybe i'm over thinking this because game sync is hard to achieve but this would be useful anyway as in most game console
wait time are tied to frames.
-
paname - Sergeant Major of the Army
- Posts: 204
- Joined: Wed Jan 07, 2015 3:02 pm
Re: Game Frame Rate and wait type.
paname wrote:my question to JKBR is could you implement something like a precision wait (call it wait_p) but with an exact value of 1000/60ms (or 16,67ms, as the T2 response time is 50µs this should be possible) ?
Definitively the hardware is capable to handle time resolution below 1ms. The best approach for that would be an uswait() "micro-second wait", to keep the value on the integer domain.
However, it is possible compensate the drift with the current implementation, something like this (based in your code).
- Code: Select all
#include <ps4.gph>
fix32 drift;
uint32 rtime;
main {
if(get_val(PS4_R2)) {
if(event_active(PS4_R2)) {
drift = 0.0;
rtime = 84;
}
combo_run(RPM450);
}
}
combo RPM450 {
set_val(PS4_R2, 100);
wait(50);
set_val(PS4_R2, 0);
wait(rtime);
set_val(PS4_R2, 0);
// Drift Correction
drift += 0.666667;
if(drift >= 1.0) {
drift -= 1.0;
rtime = 83;
} else rtime = 84;
}
Here we are incrementing the variable "drift " with the know drift for that combo, when this value reaches 1.0 or more, the next time the combo run it subtracts 1ms from the last wait, compensating the drift.
ConsoleTuner Support Team
-
J2Kbr - General of the Army
- Posts: 20323
- Joined: Tue Mar 18, 2014 1:39 pm
Re: Game Frame Rate and wait type.
nice trick for the drift correction i will try and use it until you have time to implement a uswait() function
many thanks
many thanks
-
paname - Sergeant Major of the Army
- Posts: 204
- Joined: Wed Jan 07, 2015 3:02 pm
Re: Game Frame Rate and wait type.
J2Kbr wrote:paname wrote:my question to JKBR is could you implement something like a precision wait (call it wait_p) but with an exact value of 1000/60ms (or 16,67ms, as the T2 response time is 50µs this should be possible) ?
Definitively the hardware is capable to handle time resolution below 1ms. The best approach for that would be an uswait() "micro-second wait", to keep the value on the integer domain.
However, it is possible compensate the drift with the current implementation, something like this (based in your code).
- Code: Select all
#include <ps4.gph>
fix32 drift;
uint32 rtime;
main {
if(get_val(PS4_R2)) {
if(event_active(PS4_R2)) {
drift = 0.0;
rtime = 84;
}
combo_run(RPM450);
}
}
combo RPM450 {
set_val(PS4_R2, 100);
wait(50);
set_val(PS4_R2, 0);
wait(rtime);
set_val(PS4_R2, 0);
// Drift Correction
drift += 0.666667;
if(drift >= 1.0) {
drift -= 1.0;
rtime = 83;
} else rtime = 84;
}
Here we are incrementing the variable "drift " with the know drift for that combo, when this value reaches 1.0 or more, the next time the combo run it subtracts 1ms from the last wait, compensating the drift.
Is this Script for Titan one or TitanTwo
-
teddy18 - Lieutenant
- Posts: 346
- Joined: Sun Jul 19, 2015 4:18 pm
Re: Game Frame Rate and wait type.
@teddy18 - for the Titan Two. But it is possible do something similar for the Titan One, if you want me to do, please request on the Titan One script forum, so we don't mix the code for one on the section of other. thanks.
ConsoleTuner Support Team
-
J2Kbr - General of the Army
- Posts: 20323
- Joined: Tue Mar 18, 2014 1:39 pm
Re: Game Frame Rate and wait type.
2 questions.
1. has the uswait() function been implimented yet? i dont see it listed here: https://www.consoletuner.com/wiki/index ... t2:set_val
2. I am a new to scripting but every time i see these rapid fire scripts i see 2 waits
wait(50);
set_val(PS4_R2, 0);
wait(84);
set_val(PS4_R2, 0);
Why not just have 1 wait at 134? What is the second wait archiving?
I am slowly figuring scripting out with all your help thanks!
1. has the uswait() function been implimented yet? i dont see it listed here: https://www.consoletuner.com/wiki/index ... t2:set_val
2. I am a new to scripting but every time i see these rapid fire scripts i see 2 waits
wait(50);
set_val(PS4_R2, 0);
wait(84);
set_val(PS4_R2, 0);
Why not just have 1 wait at 134? What is the second wait archiving?
I am slowly figuring scripting out with all your help thanks!
-
shogun6x - First Sergeant
- Posts: 53
- Joined: Thu Aug 04, 2016 9:44 pm
Re: Game Frame Rate and wait type.
The first wait is the hold time and the second wait is the release time, 134 would only hold the button.
Console tuner since my 1st controller.
Scripting, a game in the game.
Believe or dare, It's Titanic!
Scripting, a game in the game.
Believe or dare, It's Titanic!
-
Prototype - Major General
- Posts: 3251
- Joined: Sun Dec 16, 2012 1:43 pm
Re: Game Frame Rate and wait type.
prototype wrote:The first wait is the hold time and the second wait is the release time, 134 would only hold the button.
Cool thanks.
-
shogun6x - First Sergeant
- Posts: 53
- Joined: Thu Aug 04, 2016 9:44 pm
Re: Game Frame Rate and wait type.
J2Kbr wrote:@teddy18 - for the Titan Two. But it is possible do something similar for the Titan One, if you want me to do, please request on the Titan One script forum, so we don't mix the code for one on the section of other. thanks.
do it for titan one
-
ohkarmahd - Corporal
- Posts: 4
- Joined: Mon Jan 09, 2017 10:03 pm
9 posts
• Page 1 of 1
Return to GPC2 Script Programming
Who is online
Users browsing this forum: No registered users and 81 guests