GP2X Devs Please Underclock Your Apps

[A_SN]

They have disappeared before due to 'crap' posted in these forums...

That's right, and we talked about it in #gp2xdev, it's because well, there's loads of crap on this forum, anyways you can still find them in #gp2xdev, that's where the devs are at, there's hardly any drama in there and hardly anyone considering developers as semi-gods or saints or gurus unlike you guys.

By the way gruntfuggly, I know of some dev who mentionned your name in the people who made him want to stay away from these forums, actually you're on his list of people to positron to death, or something of this kind.

Oh and it sounds like now people want to apologize for their behavior in this topic, fine, but I won't, because I always said the right thing, I've always been righteous in my actions, therefore I have nothing to apologize about, and even if I did, I wouldn't because arrogant frenchmen like me are exempted from apologies anyways.

Plus I'm a dev, so fear my wrath, or something, bitches!

PS : Oh yeah, seems like some older devs stopped releasing anything because when you release an original homebrew game you don't receive the respect, critique or admiration you're ought to expect, so if you like homebrew games this much (I don't by the way), let the devs know.

 

[A_SN]

Anyways, I'm getting some stats. Done with the battery tester app with fully loaded Uniross 2100 mah batteries, here at 120 MHz and 200 MHz

STATISTICS:
Clock Speed: 120 Mhz
Running Time: 3:05:00
Average FPS: 47.84

Current charge: 5%
Initial internal charge: 985
Current internal charge: 669

STATISTICS:
Clock Speed: 200 Mhz
Running Time: 2:05:00
Average FPS: 81.51

Current charge: 80%
Initial internal charge: 971
Current internal charge: 763

With the same batteries, 3 hours at 120 MHz, 2 hours at 200 MHz. And that's with display on and CPU used to the fullest. On this example when the frequency is increased by 67%, up time is increased by 50%. I think it proves the necessity of having developpers to make their own underclocking scripts

 

[Gruntfuggly]

By the way gruntfuggly, I know of some dev who mentionned your name in the people who made him want to stay away from these forums, actually you're on his list of people to positron to death, or something of this kind.

Are you serious? Please tell me who your are referring to - PM me if you'd rather not make it public!

As far as I know this is the first time I had *ever* rubbed somebody (you) up the wrong way in these forums!

Plus I'm a dev, so fear my wrath, or something, bitches!

Fuck me, surely it hasn't come to this...

 

[ryosaeba]

I understand your request, I'm not offended and I'm not flamin you here but my opinion remains the same.
The apps shouldn't underclock on their own.

Having a command line parameter to avoid that is a workaround to the side-effect I exposed before but here's what'll happen...

A casual user (that usually doesn't know that he should add --dontoverclock to params) adds a link in gmenu2x or writes a script (copying from examples on the board) and notices that the app is not affected at all and you'll see tons of them coming to the board complaining like "YOUR APPZ SUKZ!!!11eleven!!" or more moderately like "I found a bug in your app....", "this script doesn't work..." etc...

I think that using a script to underclock or gmenu2x is easy enough.

 

[DaveN]

Here is a table of minimim clock speeds

Picodrive: 220mhz :huh:

 

[PokeParadox]

It needs updating. That was BEFORE the dual core version was released

 

[Micket]

...
I think that using a script to underclock or gmenu2x is easy enough.

Scripts are indeed optimal for this purpose in most cases, but with OldPlay for example (or other mediaplayers) one can need a varying frequency.
Restarting it in other to play nsf instead of an mp3 isn't really a reasonable option, so letting it change internally is the best sullotion.

 

[BradN]

Maybe a good guideline is... if your program supports clock speed changing internally, make sure it doesn't suck or limit you more than if you were to just make a script. Something like oldplay with variable frequencies is a Good Thing (tm), but it would never hurt to have an option to shut off the internal stuff, for whatever reason (maybe a new hardware revision will have a different oscillator setup, etc).

 

[A_SN]

I understand your request, I'm not offended and I'm not flamin you here but my opinion remains the same.
The apps shouldn't underclock on their own.

Having a command line parameter to avoid that is a workaround to the side-effect I exposed before but here's what'll happen...

A casual user (that usually doesn't know that he should add --dontoverclock to params) adds a link in gmenu2x or writes a script (copying from examples on the board) and notices that the app is not affected at all and you'll see tons of them coming to the board complaining like "YOUR APPZ SUKZ!!!11eleven!!" or more moderately like "I found a bug in your app....", "this script doesn't work..." etc...

I think that using a script to underclock or gmenu2x is easy enough.

I later mentionned that indeed devs should write a script instead of put it in their code, but that THEY should do it and release it with their app.

Here is a table of minimim clock speeds

Picodrive: 220mhz :huh:

Yeah, way not to rely on users to decide what minimum clock speeds to use and rather let the devs deal with it.

...
I think that using a script to underclock or gmenu2x is easy enough.

Scripts are indeed optimal for this purpose in most cases, but with OldPlay for example (or other mediaplayers) one can need a varying frequency.
Restarting it in other to play nsf instead of an mp3 isn't really a reasonable option, so letting it change internally is the best sullotion.

Agreed with that, in such cases the app should determine by itselves what frequency is needed in a particular case. And in some cases, it can be wise to change the clock to something high punctually during for example some loading, writing, computing and then switch back to the wanted low frequency (I'm planning on using that actually)

I think it's best to have to developer of that app to choose what to do and how to do it, saying that an app shouldn't do it and let users use scripts for this is like asking the developer not to make other choices about his app like the button layout.

Maybe a good guideline is... if your program supports clock speed changing internally, make sure it doesn't suck or limit you more than if you were to just make a script. Something like oldplay with variable frequencies is a Good Thing (tm), but it would never hurt to have an option to shut off the internal stuff, for whatever reason (maybe a new hardware revision will have a different oscillator setup, etc).

Combine the use of documented arguments and developer created scripts to launch the app with the proper arguments by default or something of this kind and there you got it..

 

[Shikaku]

because I always said the right thing, I've always been righteous in my actions, therefore I have nothing to apologize about, and even if I did, I wouldn't because arrogant frenchmen like me are exempted from apologies anyways.

This is how wars start you know... B)

 

[Alex.]

"I have been accused of wrong doing. But we will not let those accusations deter us. We WILL annex Poland by Spring, and out stock will go HIGH!"

:rolleyes:

- Alex

 

[inksmithy]

Right now this might sound like a noob developer putting his nose in where he isn't qualified, but how hard would it be for some contributing soul to write a script which could be configured by the dev for his particular game and stick it on the wiki?

To me that sounds like a perfect example of a) using the wiki and /B) nicely standardised code.

Not that I'm suggesting that everybody needs to write code the same way.

If its a fairly simple script which can be referred to in the readme of the file and run, then why not stick it on the wiki and let the dev set it to his own preferences?

 

[Goity]

Have a bath you smelly frenchman!

 

[A_SN]

Have a bath you smelly frenchman!

Shove your umbrella up your arse, you bloody jelly-eating tea-sipping crap-eating british fag!