(07-20-2010, 06:09 PM)fircrestsk8 Wrote: [ -> ]I'm actually talking about the minimap, the one that is in grayscale when using EFB Copy to Texture! Basically the first thing done each frame is that a very small gray circle (16pixels X 16 pixels) is drawn over and over again (by setting it as the active texture and flushing loads and loads of vertices) in order to shape the current minimap (actually, this only shapes the background of the map). Once this is complete, the EFB is copied to some location in memory and cleared. Then the rest of the frame begins drawing, and at some point later, the map is drawn back to the frame as a texture in its proper place. Right after this things like the location indicator, etc. are drawn to the map.
At least in the GC version, the location indicator is drawn at the same time as the rest of the minimap, not added later. This can be seen in the attached snapshots of the efb just before clearing. The colors are probably added later using a palette. There is the possibility of the game copying the frame out and in again just after targ2317, but i doubt that.
It's weird that the patch only fixes this one game, the patch doesn't affect speed at all with any other game.
Be advised that svn6060 broke the patch when he moved the check box to the game properties.
(08-06-2010, 07:13 AM)obscured Wrote: [ -> ]Be advised that svn6060 broke the patch when he moved the check box to the game properties.
You are correct, there is likely an issue with the option such as with the checkbox state in the game configuration not enabling the hack in bpstructs.cpp.
I think I found the issue, compiling and going to test in a few.
Well that wasn't the problem..
Just Committed a fix for the hack, it now works from the game properties menu (Wish i woulda thought of that...)
Hmmm... I'm not familiar with Gecko code at all, anybody know where i might find some info on it?
Good to see you back kiesel, unfortunately the thread isnt letting me get to your EFB images yet
That would, however, explain why the mini map is being drawn every frame (since the location arrow might change at any time).
Something that I remembered again, I believe nodchip mentioned something about frame buffer textures earlier in this thread, but not much else was mentioned or discussed about that. Is there any idea why only ZTP suffers from this issue and other games don't, it there something that isn't implemented or implemented correctly that is causing this or are pipeline flushes expensive and there is no other way to get around this issue without using a hack?
Can someone else confirm/test that the newest svn builds have taken a 10-15% speed decrease for hyrule field and the patch? I tested 6142.
(08-29-2010, 01:18 PM)obscured Wrote: [ -> ]Can someone else confirm/test that the newest svn builds have taken a 10-15% speed decrease for hyrule field and the patch? I tested 6142.
yes thats right. on older revisions i have permanently 30 fps
on 6136 i have 22-26, but still playable at 80% of speed.
(08-29-2010, 06:33 PM)sNk Wrote: [ -> ]yes thats right. on older revisions i have permanently 30 fps
Older as in which revisions?
r5000 - r5500, but on those the maps are not working correctly...
on 5800+ the maps are working with copy efb to ram. with copy efb to texture there is no big speed improovement and the maps are not working.