Hey There,
Thanks for the powerusage info. Very handy to have around... I guess
I'll stick with 300GHz then... :) Personally I didn't know if there
would be any difference between 600kHz and 300kHz so I went with the
600kHz option. However, I just don't think 32kHz is possible.
Especially not if I want to implement sound as well.
And like Soeren says, the only thing I actually DO is use the
display. Remember it's a shoot'em up... Things flying around all over
which means that apart from some minor calculations and reading the
keys, all the routines I call use the display.
I'll just make it in 300kHz for now, and when it's done I'll see if
it's still playable in 32kHz. If it is, I can always rip out the wait
routines and see how things go...
Kay, thanx,
Tobias Keizer...
--- In vmu-dev@egroups.com, Brian Chapman <bchapman@s...> wrote:
> At 10/30/00 01:26 PM , Tobias_Keizer@y... wrote:
> > Anyways, I've got part of the game running now... I've got my
> > scrolling 'sky' and 'floor' (don't think too much of it) and
finally
> > my ship that moves around freely in this world... Now, question
time
> > again... I am currently working in the 600MHz mode for extra
speed.
> ^^^^^^
> Yikes, surly you meant Kilo-Hz not MHz ;-)
>
>
> > I've read though, that this uses more battery power than the
subclock
> > mode. The question is, how much?!?
> >
> > As of now the game is still hella-fast, but then I've got no
enemy
> > routines and no (and thats the real bitch) sprite collision
> > detection. Then another this is, if I want to add SFX or Music,
as
> > far as I know I won't be able to change clock-speed without the
sound
> > routine making strange-glass-breaking noises.
> >
> > So anyways, the question... Is it okay to make a game that runs
in
> > 600MHz in the entire game, or would this use up way too much
battery
> > power? Apart from that, is there anyone that thinks all the above
can
> > be done (including sound) in subclock mode?
>
> Here is a quote from a document I saved off the net. I forget the
original
> URL. (My appologies to the author):
>
> :::: BEGIN QUOTE :::::::::::::::::::::::::::::::::
> Sören measured the power consumption at different speeds.
>
> watch: 0.25mA sleep watch: 0.1mA
> getkeys 6MHz: 8.6mA sleep 6MHz: 3.0mA
> getkeys 3MHz: 5.4mA sleep 3MHz: 1.65mA
> getkeys 600Khz: 2.9mA sleep 600Khz game: 0.55mA
> getkeys 300Khz: 2.4mA sleep 300Khz game: 0.35mA
> getkeys 32kHz: 0.65mA sleep 32kHz game: 0.15mA
> getkeys 16kHz: 0.65mA sleep 16kHz game: 0.15mA
>
> As you can see, the 600kHz mode requires 4.5 times the power of the
32kHz
> mode. However, since it will run 18 times the instructions of the
slower
> speed, it is more power efficient. The batteries don't last very
long as
> it is, so you can't afford to waste power.
> :::: END QUOTE :::::::::::::::::::::::::::::::::::
>
> I think the best thing is to stay in Subclock Mode (~32khz) and
only go
> into RC Mode (~600khz) when you absolutely need too. Perhaps when
you have
> a certain algo that really needs to be done quickly (and LCD access
> ofcourse).
>
> I'm still working on this myself so I'm mostly speculating here.