So far I haven't focused that much on the Watchdog, it's not something of permanent effects which should be worked that hard.
I haven't tried to make any changes to the fps counters at all, I don't really know the right way to do it, besides, there's still work to do from the devs with the video things and i don't want to do something that will probably not work in future revisions.
Right now i'm trying understand a little how Jit and Interpreter work.
I'm not going anywhere near the PPC yet.
____
Question to devs, what is to be done in order to make a fully working debug release?
(07-29-2009, 01:07 PM)CacoFFF Wrote: [ -> ]it's not something of permanent effects which should be worked that hard.
Soo is there any way on turning the patch off when its alreadyy included in the build ? think that will give a better FPS. Or leaving it on 60 is like turning it off? ? But anyway for me sometimes it does give me like a 9-10 FPS Boost.... every extra FPS counts for me
60 is like turning it off.
when people talk about fps=speed in this thread they probably have not read the last 2-3 pages... its sad
if more fps would mean that the game runs faster, we could easily implement a method for the watchdog to automaticly choose the best value.
but thats not the case : i get most fps in every game with very low watchdog, but most games still run worse than before.
Quote:Any Updates on your progress?
maybe not possible at the moment.
means : i dont know anything that clearly states that the game runs faster then before.
If you do : tell me.
i could write that auto-update for rev 34xx but as i dont know if we ever come back to the old framebuffer its not worth the work.
(07-29-2009, 05:24 PM)Iulius Wrote: [ -> ]i get most fps in every game with very low watchdog, but most games still run worse than before.
Both are true with me, but anyway in the games ive tested i dont get quite smooth graphics in other words, choppy with this "boost" with WatchDog.
Odd isnt it ?
Or you can blame my graphics card for this ?
yes its the card.
the slower your video card is, the lower the watchdog should be, apart from those frameskip-games like SSBB.
the reason is : its not worth looking rapidly if the gpu has done its work when its slow as hell as it is unlikely that the card is finished.
but its very useful if the gpu is very fast, as the cpu can work on faster that way.
example : you wait for an email.
if a mail comes every hour on average, it wont be usefull to check every 5 minutes as you could use the time better.
but if a new mail comes every minute, its bad to check only every 5 minutes cause you waisted 4 minutes for nothing.
thats the reason why a fixed watchdog is never the best way.
unless you dont care for any email at all (frameskip games).
That sucks, also, emulated gpu receives load from video card AND an extra core, so it only takes one of the two to slow down the whole emulated gpu.
Optimising the vertex loaders will help making the emulated gpu faster, but as long as there are slow video cards around, the watchdog won't die.
==
Makes me think, those Phenom users + AMD overclocking tool on 7xx chipset motherboards.
If they oveclock only Core 1 (lock threads off, without touching Core 2,3,4 freq), they could speed up emulated gpu (provided they have a good video card) without increasing heat that much.
After all, the OS will leave the most demanding thread to the highest clocked core (useful for switching cores when passing from a very-low poly area to a high poly area).
Just one of the many ideas that come to my mind.
(07-30-2009, 12:13 PM)CacoFFF Wrote: [ -> ]That sucks, also, emulated gpu receives load from video card AND an extra core, so it only takes one of the two to slow down the whole emulated gpu.
Optimising the vertex loaders will help making the emulated gpu faster, but as long as there are slow video cards around, the watchdog won't die.
==
Makes me think, those Phenom users + AMD overclocking tool on 7xx chipset motherboards.
If they oveclock only Core 1 (lock threads off, without touching Core 2,3,4 freq), they could speed up emulated gpu (provided they have a good video card) without increasing heat that much.
After all, the OS will leave the most demanding thread to the highest clocked core (useful for switching cores when passing from a very-low poly area to a high poly area).
Just one of the many ideas that come to my mind.
CacoFFF do you know if the OGL plugin uses BSP trees to sepparate static objects from dynamic objects for later do an space partioning and reduce the the polies being processed, thus making rendering faster.
I've been asking this question, but no one has answered it and I'm too lazy to look at the ogl source code. It was the solution Quake makers used to render 10,000 polies (at that time) without having slowdowns.
Lol, the speedincrease in Zelda:TP with 5 is awesome. Even if it breaks the FPS-Counter and plays the music (maybe, I'm not really sure how the music sounds in fullspeed) a bit to fast, I get nearly + 10-15 FPS for example in Hyrulefields. Even if the FPS-Counter always shows 59-60, it really feels like 60 at some parts. Maybe you should add this at front page.
(07-31-2009, 01:17 AM)BlinkHawk Wrote: [ -> ] (07-30-2009, 12:13 PM)CacoFFF Wrote: [ -> ]That sucks, also, emulated gpu receives load from video card AND an extra core, so it only takes one of the two to slow down the whole emulated gpu.
Optimising the vertex loaders will help making the emulated gpu faster, but as long as there are slow video cards around, the watchdog won't die.
==
Makes me think, those Phenom users + AMD overclocking tool on 7xx chipset motherboards.
If they oveclock only Core 1 (lock threads off, without touching Core 2,3,4 freq), they could speed up emulated gpu (provided they have a good video card) without increasing heat that much.
After all, the OS will leave the most demanding thread to the highest clocked core (useful for switching cores when passing from a very-low poly area to a high poly area).
Just one of the many ideas that come to my mind.
CacoFFF do you know if the OGL plugin uses BSP trees to sepparate static objects from dynamic objects for later do an space partioning and reduce the the polies being processed, thus making rendering faster.
I've been asking this question, but no one has answered it and I'm too lazy to look at the ogl source code. It was the solution Quake makers used to render 10,000 polies (at that time) without having slowdowns.
I don't really know that, i should take a deeper look at the plugin.
I'm guessing the emulator is translating all the poly info instead of reading it like native PC games do, I bet that's where said (by devs) optimization is needed.
Also, updated main post.