I've been playing with my Archos 43, and found a cool way to almost double the speed of 2D graphics and somewhat increase 3D graphics speed (as measured with AnTuTu), and probably decrease memory usage, at the expense of display quality.
Just switch the device into 16-bit display mode.
Code:
su
fbset -fb /dev/graphics/fb0 -g 480 854 480 854 16 -n ; killall zygote
One could set this up on boot, but I haven't figured out how to run any scripts before zygote starts using Chulri's rw root.
To switch back to 32-bit, just do a normal reboot, or:
Code:
su
fbset -fb /dev/graphics/fb0 -g 480 854 480 854 32 -n ; killall zygote
---------- Post added at 05:38 AM ---------- Previous post was at 05:18 AM ----------
Alas, 16-bit breaks the Archos video player and Youtube. On the other hand, Netflix works fine.
HI,
what is the difference with chainfire 3D?
As far as I know, ChainFire3D switches texture bit depth, but still leaves the bit depth of the screen as a whole unchanged. In particular, setting to 16-bit textures in CF3D may help with some 3D apps, but will have no effect on 2D performance. Setting to 16-bit mode in the above way almost doubles 2D performance, at the expense of quality and complete loss of Youtube/Archos Video. One should be able to combine the 16-bit setting above with CF3D.
Of course, if you've got a different device, you'll need different resolution numbers. You can find out your numbers with:
Code:
su
fbset -fb /dev/graphics/fb0
Further investigation: the fbset command doesn't require root on Gen8 if executed in adb, so you can do this on a non-rooted device.
I did some more benchmarks. In these, the performance gain is more moderate, probably because I was previously comparing to a system that was configured less well in other ways.
There is still a 38% performance gain for 2D applications with CF3D off.
Some AnTuTu benchmarks on the A43:
32-bit display, CF3D off:
2D: 344
3D: 718
32-bit display, CF3D set to reduce textures to 16-bit:
2D: 378
3D: 726
32-bit display, CF3D set to unroll textures to 32-bit:
2D: 432
3D: 712
16-bit display, CF3D off:
2D: 478 (average of two tests)
3D: 711
16-bit display, CF3D set to reduce textures to 16-bit:
2D: 408
3D: 756
16-bit display, CF3D set to unroll textures to 32-bit:
2D: 426
3D: 716
I can not confirm any positive affect of the 16bit setting on my A70s. The scripts seem to work, the system reboots and the fbset reports 16 bit as expected. But the 2D benchmark staid the same around 275 in Antutu for both 16 and 32 bit settings. Worse: my system needed a cold reset to get archos video back working.
old_pocket said:
I can not confirm any positive affect of the 16bit setting on my A70s. The scripts seem to work, the system reboots and the fbset reports 16 bit as expected. But the 2D benchmark staid the same around 275 in Antutu for both 16 and 32 bit settings. Worse: my system needed a cold reset to get archos video back working.
Click to expand...
Click to collapse
Oh, well.
I wonder, by the way, why your 2D benchmark is so much lower on your A70 than on my A43. Is your max CPU speed set to 1ghz?
I used uruk 1.6b1 with 1200/300 setting via setcpu. I tried different constant settings to see if there would be a dependency:
I got more or less constant 275 for frequencies from 1200 to 800, 365 for 600 MHz and 300 for 300 MHz. Very strange.
I'm also seeing the CPU speed as not mattering much. I just got 353 with 300MHz and 419 with 1000MHz.
What is your debug.sf.hw setting? You can do:
Code:
getprop | grep debug.sf.hw
to check.
Normally, I have it set to debug.sf.hw=1.
If I set debug.sf.hw=0, I get a maximum of 200 on AnTuTu 2D, and the value seems to vary more with CPU speed. I am guessing that with hardware acceleration enabled, it's the GPU speed and memory bus speed that matter, not the CPU speed.
I'm also using this script to optimize memory management. I haven't tested enough to see if it makes a difference.
Good idea. I tried out your grep. As you might have expected: nothing, means that =1 is active by default. Tried out =0 by editing build.prop resulting in around 100 values. No real improvement...
I tried something different, booted stock 2.4.19 Archos Android and here you go: values around and above 400. In comparison you can see that it is a lot faster.
Maybe this is caused by the increased clock rate / "fluidity" of the new Archos firmware. Hopefully sauron will get his pad back soon. This seems to be a good chance to get even better performance on uruk.
old_pocket said:
Good idea. I tried out your grep. As you might have expected: nothing, means that =1 is active by default. Tried out =0 by editing build.prop resulting in around 100 values. No real improvement...
I tried something different, booted stock 2.4.19 Archos Android and here you go: values around and above 400. In comparison you can see that it is a lot faster.
Maybe this is caused by the increased clock rate / "fluidity" of the new Archos firmware. Hopefully sauron will get his pad back soon. This seems to be a good chance to get even better performance on uruk.
Click to expand...
Click to collapse
Have you tried the Sibere kernels that are based on the 2.4.19 source but with uruk additions?
I just now tried Sibere_OCUV_SB from: http://forum.xda-developers.com/showpost.php?p=17443339&postcount=2069
No problem with the undervolting, but something in his newer kernels seems to render my USB port useless, like the one I tried a few weeks before. On the other hand no positive effect with this on the 2D benchmark, around 275 as before. I remember a conversation between sauron and sibere speculating that Archos modification was not in the kernel but in the firmware.
old_pocket said:
I just now tried Sibere_OCUV_SB from: http://forum.xda-developers.com/showpost.php?p=17443339&postcount=2069
No problem with the undervolting, but something in his newer kernels seems to render my USB port useless, like the one I tried a few weeks before. On the other hand no positive effect with this on the 2D benchmark, around 275 as before. I remember a conversation between sauron and sibere speculating that Archos modification was not in the kernel but in the firmware.
Click to expand...
Click to collapse
I wouldn't be surprised if some of the changes were in the libraries, especially libsurfaceflinger, libskiahw and libskia. You could try pulling in new versions of these libraries.
Related
Update: Resolved to my satisfaction: http://forum.xda-developers.com/showpost.php?p=14323192&postcount=8
The egl.cfg we've been using:
Code:
1 1 android
0 1 POWERVR_SGX530_121
is functionally equivalent to removing the software renderer:
Code:
0 1 POWERVR_SGX530_121
Original post:
......................................................................................
So, we've been running /system/lib/egl/egl.cfg set as:
Code:
1 1 android
0 1 POWERVR_SGX530_121
This tweaked egl.cfg essentially disables hardware rendering and substitutes software rendering. The default setting is
Code:
0 0 android
0 1 POWERVR_SGX530_121
We do this because this was reported to be much, much faster by just about everyone and I will admit to also experiencing this improvement. However, I've recently run 2.1 and honestly it really puts our 2.2 to shame. Additionally it's never made any sense that the software renderer would outperform hardware acceleration. It makes more sense that there's something wrong with our graphics libraries and that's why software rendering wins. Or we were mistaken in believing things were faster.
In my work-in-progress ROM, I've updated graphics libraries (for other reasons) and then I tried disabling the tweak and performance seems much improved and much closer to what I see in 2.1 (FYI, for some reason I had to wipe dalvik-cache after making the change or boot got stuck, but that could be unrelated).
So, the question is: are the updated graphics libraries the reason it works or was changing egl.cfg a mistake?
Can some adventurous souls try going back to the defaults and report whether they really think the software render really is faster? Please post which ROM you are testing on. If switching egl.cfg back to defaults makes things worse, we can then try whether updating the graphics libraries to the versions I'm testing helps.
RusMod,usyng egl.cfg as soft renderer.
In next version i will try to move egl.cfg to default from 2.1 and will ask people - how it feeling.
For results will post here.
btw, afaik defy uses same video accel?
p.s. http://xt720.fjfalcon.ru/Mods/rusmodv1.14.zip
RusMod users haven't noticed much problem(all usyng fastboot kernel)
But in quadrant when going test with2 planets - scores shows like in 2.1.
I wondered how long it would take for this to come back up. I think that the difference between hardware and software based encoding on our phone is more of a question of "What else is being affected?"
Obviously, there isn't too dramatic of a difference in the overall performance or people would have been screaming about it way back when we made this change. I am more concerned about the possibility of other things, such as battery life or video performance being affected by these settings. Is it possible that other things are being hit? Who knows. I always knew that this change was merely cosmetic, a way to boost quadrant scores.
Mioze7Ae, I switched mine back and have been tinkering with it since. I have not noticed a significant difference. It actually seemed a bit choppier. If you have a test build with new libs, I would be willing to try it out for a while and see if I can break it.
I forgot to add:
I'm running galaxyXTv4. I didn't like the way epicsteelblue looked.
reverendkjr said:
Mioze7Ae, I switched mine back and have been tinkering with it since. I have not noticed a significant difference. It actually seemed a bit choppier. If you have a test build with new libs, I would be willing to try it out for a while and see if I can break it.
Click to expand...
Click to collapse
I also notice it is slightly choppier sometimes but on the other hand the software rendering to me feels sluggish and the hardware rendering feels more responsive. For example scrolling: open something with a long list and throw the list up and down. The software rendering seems to slow this down and lag a bit, but the hardware rendered flows faster and seems to stay underneath my finger. The 3D program list in ADW Launcher is noticeably faster and smoother.
Anyway, as you wish here's the work-in-progress.
http://www.multiupload.com/HYUZG4E3BZ
It's a larger rework of Dexter's 1.3. It's based on an analysis I'm doing where I compare which files change and which files remain identical between Motorola's XT720 2.1, Motoroi 2.1 and 2.2, and Milestone 2.1 and 2.2 releases in order to make predictions about which versions of these files should be on Milestone XT720 2.2. It's a full ROM that applies as an update instead of a nandroid image. I switched the 2nd-init hijack to the simpler bin/sh_hijack.sh+etc/rootfs one that is used on Milestone instead of the mot_boot_mode+lw+lw2+ramdisk.tar method. Not included are the init.d scripts--so the governors, overclocking, ext partition, swap, moving dalvik-cache to /cache are "do it yourself" for now. I'm porting the CM6 scripts to implement that, but they're not ready.
How is the battery life doing Mioze7Ae? And thanks for fixing, will try this weekend when im free. =)
khankuan said:
How is the battery life doing Mioze7Ae? And thanks for fixing, will try this weekend when im free. =)
Click to expand...
Click to collapse
Honestly, I haven't had that ROM running long enough to have an opinion about its battery life. It's quickly evolving and I keep flashing back to an earlier version that's about half-way between bugfix-3 and this version for my everyday use. There's still a lot I need to do with this ROM before I'm ready to "move in" and dogfood it. Anyway it's my feeling that disabling the egl.cfg tweek improves performance on this ROM.
In the mean time, if changing the egl.cfg back actually makes things worse on current ROMs, we can see about testing just these specific libraries in those ROMs. There's just so many of them. I'll see if I can make a library patch for galaxyXTv4 for reverendkjr to test.
Which one do you run?
Hi been useing the rus.mod and it has without error something could not say before very good build.
Sent from my XT720 using XDA Premium App
I think I've figured this out
Ok, here's the scoop: contrary to what I thought, xav's hacked egl.cfg actually disables the software renderer all together. In testing with Quadrant Advance I get identical (best) performance from either of these two egl.cfg's:
Code:
1 1 android
0 1 POWERVR_SGX530_121
and (my recommendation):
Code:
0 1 POWERVR_SGX530_121
More info
The documentation header for egl.cfg says:
Code:
#
# One line per configuration, of the form:
#
# D I TAG
#
# D: display (0: default)
# I: implementation (0: software, 1: hardware)
# TAG: a unique tag
#
# The library name loaded by EGL is constructed as (in that order):
#
# /system/lib/egl/libGLES_$TAG.so
# /system/lib/egl/lib{EGL|GLESv1_CM|GLESv2}_$TAG.so
#
Now, what had me confused in the past is I couldn't make heads or tails of what "D: display (0: default)" means. Somehow when re-reading that today had the obvious revelation that it's referring to "display number" and 0 is the display number of the primary screen (the default screen) the same way that X11 in Unix refers to displays. So:
Code:
1 1 android
means "use the android software renderer as a hardware renderer on the second display" (we don't have a second display and I don't think it can mean the TV or HDMI out, either because Motorola never defined any renderers for a second device). In fact, you can just delete or comment out the entire 0 0 android line and get the same results.
From testing, a tale-tale sign of the software renderer being used is that messed up moon. Hardware rendering doesn't have the messed up moon.
Motorola's default enables both:
Code:
0 0 android
0 1 POWERVR_SGX530_121
It turns out that even making the software renderer available is bad for 3D performance.
So why does having the software renderer around cause trouble? Speculation: I thought OpenGL is supposed to figure out the best way to render things, so why is it getting this wrong? My guess is the software renderer must provide APIs that are preferred compared to what the hardware interface provides so applications or the GL library negotiates to use the software API rather than a less desirable hardware-accelerated library or perhaps they can't tell the difference. Or perhaps Quadrant is a piece of junk. That's my guess anyway.
Here's a bunch of testing I did (default kernel frequencies/voltages):
Code:
egl.cfg: 0 0 android
0 1 POWERVR_SGX530_121
# Has the messed up moon
Tot CPU Mem I/O 2D 3D
------+----+---+---+---+----
1: 573 954 813 630 194 273
2: 590 989 841 648 195 276
3: 627 1029 981 654 195 277
4: 597 1008 842 663 195 275
5: 601 1025 847 662 194 277
egl.cfg: 1 1 android
0 1 POWERVR_SGX530_121
# No messed up moon
Tot CPU Mem I/O 2D 3D
------+----+---+---+---+----
1: 612 925 820 601 194 521
2: 590 935 842 459 195 519
3: 654 949 977 626 196 524
4: 642 1009 822 656 195 527
5: 643 998 854 645 194 524
egl.cfg: 0 1 android
0 0 POWERVR_SGX530_121
# Noticably awful--feels like a Macintosh 512k
# Quadrant warns about using software rendering
# Has the messed up moon
Tot CPU Mem I/O 2D 3D
------+----+---+---+---+----
1: 465 803 730 562 79 151
2: 477 735 784 635 80 152
3: 487 773 791 638 80 153
4: 472 750 757 622 80 153
5: 468 785 773 552 80 152
egl.cfg: 0 0 POWERVR_SGX530_121
# No messed up moon
Tot CPU Mem I/O 2D 3D
------+----+---+---+---+----
1: 613 860 860 626 193 524
2: 635 963 836 658 194 522
3: 641 1014 807 661 196 526
4: 654 989 912 653 194 522
5: 674 1026 977 648 194 525
egl.cfg: 0 1 POWERVR_SGX530_121
# No messed up moon
Tot CPU Mem I/O 2D 3D
------+----+---+---+---+----
1: 609 919 960 452 193 519
2: 601 946 716 620 195 528
3: 664 999 960 647 195 521
4: 627 1014 751 651 194 527
5: 642 1008 820 661 192 529
egl.cfg: 0 1 POWERVR_SGX530_121
0 0 android
# Has the messed up moon
Tot CPU Mem I/O 2D 3D
------+----+---+---+---+----
1: 575 917 872 626 189 269
2: 595 967 890 651 193 273
3: 597 978 901 634 194 277
4: 577 1006 845 571 192 272
5: 591 982 834 665 195 278
I flashed dexter's 1.3, then I installed your update. I'll run it for a while and get back to you on my results. A couple of items though. First, the camera apk doesnt work. I tried deleting and reinstalling, but it will not. Also, Milestone Overclock refuses to load. I am wondering if you have experienced anything along these lines yet.
reverendkjr said:
I flashed dexter's 1.3, then I installed your update. I'll run it for a while and get back to you on my results. A couple of items though. First, the camera apk doesnt work. I tried deleting and reinstalling, but it will not. Also, Milestone Overclock refuses to load. I am wondering if you have experienced anything along these lines yet.
Click to expand...
Click to collapse
Yeah, none of that works yet. It's probably not worth playing with extensively yet. I've only just started getting into the libraries. When it's closer to usable I'll post another.
I changed my egl to
0 1 POWERVR_SGX530_121
completely removed the android line. I was surprised to see that was even possible. I also managed to get the Milestone Overclock v. 1.4.1 to run on this and OC to 1ghz. I was thinking about trying
1 1 android
0 0 POWERVR_SGX530_121
since it doesn't look like that was tried yet. I'll do that later. I have been running the all day and do believe there is a level of "snappiness" that the other versions do not have.
reverendkjr said:
I changed my egl to
0 1 POWERVR_SGX530_121
completely removed the android line. I was surprised to see that was even possible. I also managed to get the Milestone Overclock v. 1.4.1 to run on this and OC to 1ghz. I was thinking about trying
1 1 android
0 0 POWERVR_SGX530_121
since it doesn't look like that was tried yet. I'll do that later. I have been running the all day and do believe there is a level of "snappiness" that the other versions do not have.
Click to expand...
Click to collapse
Not much of a difference. I went back to
0 1 POWERVR_SGX530_121.
$aur0n said:
It would be good to start another topic for overclocking (with values that works, perhaps scores) - anyone willing to gather this data?
With this it will be easier for people to setup their values...
Click to expand...
Click to collapse
Please post your results by using overclocking under UrukDroid here. For benchmark results please use Quadrant Standard Edition. You can download it for free on Android Market. And don't forget to say if you think your configuration is stable.
A70it
Board Version: A70S-V6
Uruk:
1.6RC4
settings:
max_vsel=65
max_rate=1100000
I think the results may be different because the fabrication of the CPU's is also a reason.
stable: yes
tested: browsing, games like Angry Birds, Dungeon Hunter....
Quadrant Score: 1706-1460
UrukDroid:
1.6RC4
settings:
max_vsel=60
max_rate=1100000
stable:yes
tested apps : games (angry birds , NFS , air attack , dragon fly , racingmoto ) , browsing , music , videos
quadrant Score:1581-1162
Uruk:
1.6RC4
settings:
max_vsel=60
max_rate=1050000
stable:yes
tested apps : games (My Country)
A101IT
Board Version: A101IT-V6
Uruk:
1.6RC4
settings:
max_vsel=60
max_rate=1050000
stable:yes
tested apps: games (angry birds, flick soccer, homerun battle, 3d bowling, basketball shoot)
quadrant score: 1465
i always fail to overclock. whats the forum thread to a successful overclock on archos gen8. i use setcpu it only remains on 1000, urukdroid 1.6rc4
thx
You first need to configure the kernel module, as SetCpu is only there for switching the maximum down from what the tables are saying.
@All:
Please also state Model ( A101,A70S,A70H,A43,A28) and if possible boardversion.
rc4
archos 70 it
I use text editor to change the values to 65 and 1100000 but the editor won't let me save the changes
You need one that has Root when editing.
fzelle said:
You need one that has Root when editing.
Click to expand...
Click to collapse
Yes, one like Root Explorer
A70it
Board Version: A70S-V6
Uruk:
1.6RC4
settings:
max_vsel=67
max_rate=1100000
stable: yes or almost (see below)
tested: browsing, games like Angry Birds, YouTube, Market....
Quadrant Score: not tested
Remarks: [email protected] did not seem stable: FC's, strange behaviour. So I bumped the volts a notch. This seems stable, but not yet entirely sure. It may need just a bit more, 68, 69 or even 70...
For understanding more, I did the calc how much volts the different vsels really yield (based on $auron's formula )
vsel
60 = 1,35V (default for 1Ghz)
65 = 1,4125V
67 = 1,4375V
70 = 1,475V
---------- Post added at 11:41 AM ---------- Previous post was at 11:40 AM ----------
rapunzel11 said:
Yes, one like Root Explorer
Click to expand...
Click to collapse
Well I have some strange issues with that too. Before updating to RC4 it would always be ok to use FileExpert in root mode to edit the file. But now, that leads to error when saving, ie no rights.
I have to go into FileManager or what the other thing is called (also root capable), rename the cpugovernor to cpugovernor.txt, edit it, then I can save. Then rename it, (re)start CPUGovernor: then the settings DO take succesfully.
Archos 70it.
I have tried 1.6rc4 both with 1.6b1 kernelocuv and with 1.6rc4 at 60& 1100000.
Both were stable and fast. I may prefer the first one.
Are there any advantages- disadvantages to either of them?
arie_i said:
Archos 70it.
I have tried 1.6rc4 both with 1.6b1 kernelocuv and with 1.6rc4 at 60& 1100000.
Both were stable and fast. I may prefer the first one.
Are there any advantages- disadvantages to either of them?
Click to expand...
Click to collapse
Well yes - second on is better You can do ALL what was done in OCUV (just rewrite cpu table) in RC5+ - but you may disable it with few clicks and test configuration that suits you best.
ps. I've added link to this thread in manual for overclocking.
ps2. Free "root capable" file explorer is FileExpert (default file manager since UrukDroid 1.5) - you just need to enable this feature in it's configuration menu.
@$aur0n
I have installed UrukDroid 1.6.4 and wanted to overclock the Archos 101 with the help of you manual.
My current cpugovernor stats output:
Code:
Uruk-CPUGovernor statistics:
Current governor: interactive
Overclock module: Enabled
Current max vsel: 66
Current max rate: 1000000
CPU Max: 1000000
CPU Min: 300000
Available frequencies: 1000000 800000 600000 300000
CPU statistics (tick spend in every frequency range):
1 GHz had 17458 ticks (8.18%)
800 MHz had 20275 ticks (9.50%)
600 MHz had 31112 ticks (14.58%)
300 MHz had 144634 ticks (67.75%)
Then I try to manualy set the vsel and rate with:
Code:
echo 66 > /proc/overclock/max_vsel
echo 1000000 > /proc/overclock/max_rate
and whatever numbers I set, the Archos reboots instantly. I even tried setting max_rate to 900000 and it also rebooted!?
What am I doing wrong?
Thanks
Edit:
I did the rest in your manual and set the right memory addresses... damn, I thought these are automatically set - it seems they could be. Now lets try to set the real max
Edit2:
OC = 1.1Ghz ; Max_vsel=68 == Enough for me.
I have just installed Urukdroid 1.6 on my Gen8 A101T.
Sorry to be a bit thick, but how to I know test how much it can be overclocked?
hi all,
this is setting of mine at my Aria CM 7.1.0
CPU Tuner
On Battery, Screen Locked, Call in:
Freq: 245-600MHz
Governor: Conservative(Thresholds up:95 down:50)
On Power:
Freq: 245-845MHz
Governor: OnDemand(Thresholds up:50)
No Services Switch
CyangeMod Setting (setting>cyangenmod setting>performance)
VM Heap Size
48M
Disable Surface dithering
i feel after that battery usage feel a little bit better.
set VM heap size to max 48M, it let application run smoothly but less CPU usage. because phone like Aria CPU is low end so i think max VM heap size can share process work with CPU. after this setting my Aria RAM always around 30-40MB free. (i have 230 apps total, 2 game app only, 200MB App2ext4, dalvik-cache size 140MB, internal storage always lower than 33MB)
CPU set to conservative up95 down 50, is make cpu not rise up freq too early, and go down in resasonable value, in conservative mode cpu go down faster to save battery.
anyone like to try this setting to see is it good or bad?or make this more improve.
i very much love my Aria, small size, great out look, but sadly its not good in spec, but i still work to make it good and keep as long as i can.
btw, sorry for my poor english.
Interesting
Does disable surface dithering can make perfomance better?
Increase Internal Memory
Why dont you extend the internal memory by partition external memory and then use s2e, ungaze other apps or script or just by hack?
Hi guys,
So, it is possible to "use" 4k on a full hd tv. This is done via ADB by entering the following lines:
adb shell wm size 3840x2160
adb shell wm density 640
(the second is just twice the density of stock, 320, otherwise everything will be 4 times smaller)
Now this is FAR from perfect.
Some things don't scale well, like the android load screen and the recent apps screenshots.
But more importantly, this seems to impact performance a lot. And I would guess it impacts it more so than native 4k.
Does anybody have an idea what causes this performance drop? (However 4k video is smooth, even at 60hz)
I must assume that normally some settings would adjust automatically when you use a native 4k screen, so that performance is optimized. Does anyone have an idea as to what settings are involved?
Setting the CPU governor to performance helps some. But it seems to be more like a memory issue, where maybe the memory is at lower clock speeds? Or the cache is lower?
I'm rooted.
And as to why I did this, well it looks better and you can select 4k in youtube for example.
this rom/combo is great for gaming call of duty mobile on the Nexus 6
--------------------------------------------------------------------------------------------------------------------------------------------------------
Resurrection Remix 8.6.4 https://sourceforge.net/projects/resurrectionremix-ten/files/shamu/
open_gapps-arm-10.0-nano-20220125 https://opengapps.org/
Magisk 23 https://github.com/topjohnwu/Magisk/releases
-----------------------------------------------------------------------------------------------
NFSInjector X8 Armageddon https://anonfiles.com/t8m9U4D3xa/NFS_INJECTOR-X8-Armageddon-1311_041255_zip
Game Speed v4 https://anonfiles.com/b5laU0Dbx5/GameSpeed_V4_zip
Empty Thermals https://anonfiles.com/n6l4UbDfx1/EmptyThermals_Module_zip
ROG Phone 5 v6 https://anonfiles.com/F9l8UfDexa/ROG_Phone_5_v6_zip
Advanced Charging Controller
--------------------------------------------------------------------------------------------------------------------------------------------
NFS Manager v1.5 https://anonfiles.com/H6k8U2Dfx9/NFS_Manager-v1.5_Release_apk
(optiona, NFS Mode Gaming, CPU governor Performance, I/O scheduler CFQ)
Gamers-GLTool-Pro-1_3 https://anonfiles.com/T0lbU4Daxb/Gamers-GLTool-Pro-1_3p_apk
(options, Resolution 768x480, shadow disabled, msaa disable, texture low, gpu api opengl, gpu optimise enable, the rest leave default)
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
i Restrict most of the apps list too from using the battery which seems to help alot and disable animation scales in dev options.
-----------------------------------------------------------
sensitivity i use for Battleroyale
distance accel 130
Realistic scope option
third person/standard sens 100
ads/red dot sens 130 for both camera/firing sense
FOV Range 1st oerson 90
FOV Range 3rd person 80
FOV FPP 75
----------------------------------------------------------
if anybody can improve on this please let me know, but i get minimal lag/fps drops and play consistent BR games