No offense, but the patch does indeed look a bit random (more like trial&error than knowledge).
Mind commenting on how you got there, kiesel-stein?
Patch is nice, i have 8-10 fps boost in Hyrule field, but this patch also have sideeffect in Metroid games, buggy spriteeffect textures
so... anybody care to upload a build for other to test? thanks in advance
I was planning on uploading a build but I've been busy. I would rather say wait until a proper fix is implemented as this causes some weird issues.
@Kiesel, are you still here? We would like to know how you came to this conclusion and what your experience with emulation and coding is.
Would be nice if more developers reviewed this and commented, would seem this issue and thread is receiving little attention from developers except for the few that already commented.
well less work more speed
even no
if (((u32*)&bpmem)[bp.address] != bp.newvalue && (bp.address < BPMEM_TEV_COLOR_ENV || bp.address > BPMEM_TEV_ALPHA_ENV+32))
and comment
//FlushPipeline();
the mulator still work (but with glichy graphics)
why don't you use switch/case for all the function that not use like BPMEM_TEV_COLOR_ENV, BPMEM_TEV_ALPHA_ENV+32, etc
or use
if (((u32*)&bpmem)[bp.address] != bp.newvalue && ((bp.address & 0xF0) < BPMEM_TEV_COLOR_ENV || (bp.address & 0xF0) > BPMEM_TEV_ALPHA_ENV+32))
this also look random to me too
well if you still here please comment
I have a question for Kiesel which puzzles me, perhaps he may be able to answer it.
After getting the tears of light for the second time and clearing the Twilight, Hyrule Field SouthWest is running at a full solid 30 FPS. Once I visited Hyrule Field North, my FPS also decreased by 10 - 15 FPS in Hyrule Field SouthWest which was previously running at 30 FPS.
What is the reason for this? There is no different geometry than before as indicated by running the game in wireframe mode and using free look so I am curious as to what triggered this. Even though your patch helped somewhat, my bet still lies on CPU/GPU sync issues, threading issues or another bug involving the Fifo.
(04-27-2010, 03:59 AM)spellforce Wrote: [ -> ]well less work more speed
even no
if (((u32*)&bpmem)[bp.address] != bp.newvalue && (bp.address < BPMEM_TEV_COLOR_ENV || bp.address > BPMEM_TEV_ALPHA_ENV+32))
and comment
//FlushPipeline();
the mulator still work (but with glichy graphics)
why don't you use switch/case for all the function that not use like BPMEM_TEV_COLOR_ENV, BPMEM_TEV_ALPHA_ENV+32, etc
or use
if (((u32*)&bpmem)[bp.address] != bp.newvalue && ((bp.address & 0xF0) < BPMEM_TEV_COLOR_ENV || (bp.address & 0xF0) > BPMEM_TEV_ALPHA_ENV+32))
this also look random to me too
well if you still here please comment
I'm going to try experimenting with the code you and Kiesel posted, will inform everyone of the results.
I've fixed the texture issues with the patch, however no speed increases. The texture issues were an easy fix, you just forgot a value when making the alterations. Btw I meant I fixed the issue with the patch Kiesel posted.
This should fix the texture issues, should also work for Kiesel's patch as well:
Code:
if (((u32*)&bpmem)[bp.address] != bp.newvalue && ((bp.address & 0xF0) < BPMEM_TEV_COLOR_ENV+32 || (bp.address & 0xF0) > BPMEM_TEV_ALPHA_ENV+32))
Notice that I added a +32 after BPMEM_TEV_COLOR_ENV so the code looks like the above sample. It's still a bit random, but better than before.
Gah, never mind for now as adding that +32 seems to have made it just as slow as without the patch.
I'm using the latest SVN version (5413) and these latest builds seem to be more stable than 2.0 (Which crashes after a few minutes sometimes).
Hyrule field still sucks, but at least the map is now somewhat visible and not a garbled mess.
This question is totally n00b.
How do I apply these patches that are supposed to speed things up, or are they added to the SVN automatically with each new commit?
well if you see the code near the end of file
case BPMEM_TEV_COLOR_ENV: // Texture Environment 1
case BPMEM_TEV_ALPHA_ENV:
case BPMEM_TEV_COLOR_ENV+2: // Texture Environment 2
...
...
case BPMEM_TEV_COLOR_ENV+32: // Texture Environment 16
case BPMEM_TEV_ALPHA_ENV+32:
means maybe he want to cut this out ,not flush it to pipeline
though there is no code for this 'case' in this file but I'm don't know about FlushPipeline(); maybe it will have code for this 'case' at that
and these will may result create some missing /glichy texture
in the other word he cut off some work to gain more speed (cut few to gain more)
If flushing to the pipeline is as costly as he mentioned, perhaps a way should be sought to speed this process up without sacrificing graphics or textures. Unfortunately I wouldn't know how to do this since I am not a coder or an emu-dev despite my experimentation with the code.