(01-15-2011, 07:49 AM)Jack Frost Wrote: [ -> ]James: Those two games seem to (want to) decode them differently.
This is what Dolphin makes of it (resulting in garbled graphics): http://i51.tinypic.com/ip85rp.png
This is was the image should be (extracted the file and stuffed it into the GX sample from OGC): http://i56.tinypic.com/sqgzgx.png
Looks like a job for me! I'll put it at the end of my queue.

No hurries, Issue 2197 has been around for ages; that thing being broken for almost twice as long (infact, never worked correctly to begin with).
I was looking into what OGC might do differently there, but I kinda got stuck due to lack of holidays, lack of matching patterns to identify the GX calls with and lack of...erm...motivation after christmas

(01-15-2011, 07:55 AM)Jack Frost Wrote: [ -> ]No hurries, Issue 2197 has been around for ages; that thing being broken for almost twice as long (infact, never worked correctly to begin with).
I was looking into what OGC might do differently there, but I kinda got stuck due to lack of holidays, lack of matching patterns to identify the GX calls with and lack of...erm...motivation after christmas 
I hear that!

Motivation is hard to come by these days. I'm betting it's something like the I4/I8 textures have subtypes similar to how the C4/C8 textures do. Would need to do some testing to confirm that theory. I'm sure you could do that while I'm busy over here

Unless you had more important things to do of course...

Sure, if you tell me what you'd want me to do. I'm not that familiar with all the graphics stuff, so don't expect me to write some fancy rendering stuff to do....things. Pretty much everything else tho

(01-15-2011, 08:09 AM)Jack Frost Wrote: [ -> ]Sure, if you tell me what you'd want me to do. I'm not that familiar with all the graphics stuff, so don't expect me to write some fancy rendering stuff to do....things. Pretty much everything else tho 
Basically a simple battery of tests while playing Harvest Moon to figure out the I4/I8 texture thing. Hit a breakpoint in the decoder implementation and see if there are any significant variables that might be used to drive a decision to switch between different decoder implementations, like how the C4/C8 decoders do their thing. The C4/C8 decoders are sensitive to the 'tlutfmt' value, so that'd be an excellent place to start testing.
Also, I don't have Harvest Moon so I can't really do it myself.

I'd guess its not a decoder issue; just copied the (working) implementation from tplx over and got the same (garbled) result. Looks like something else is breaking this thing...
Hello James!
I was asking myself how big the texture sets of several games are... cause we have plenty of space on todays gfx. Maybe its possible to load all textures on game startup onto gfx memory. Then you wouldn't have to bother with loading it when its requested
But what to do for the indexed colors with 14bit

Store all combinations in memory? Better not.
But today we have shaders and a palette shader is at least very simple and coded in around 20lines.
I had no luck in testing my palette shader with dolphin, but that's because of the lack of input formats and I'm too stupid to change the decoding of CI formats in dolphin

I have no luck in doing so... the upper 2/3 give just weird values (cannot be divided by 17??) while the lower 1/3 seems to be correct.
The palette access is also there as far as I can see, so every texture entry needs just one more attribute with the decoded palette texture.
A benefit of this approach, the textures wouldn't have to be reloaded when the tlut address changes

Instead you push a shader on the pipeline

The texture cache would be superfluous or at least it would just reflect the textures loaded on the graphics card.
(01-17-2011, 06:22 AM)Metzelmaennchen Wrote: [ -> ]Hello James!
I was asking myself how big the texture sets of several games are... cause we have plenty of space on todays gfx. Maybe its possible to load all textures on game startup onto gfx memory. Then you wouldn't have to bother with loading it when its requested 
Nope, not possible...
(Leaving the explanation to someone else, don't feel like doing that right now)
(01-17-2011, 06:33 AM)NeoBrain Wrote: [ -> ] (01-17-2011, 06:22 AM)Metzelmaennchen Wrote: [ -> ]Hello James!
I was asking myself how big the texture sets of several games are... cause we have plenty of space on todays gfx. Maybe its possible to load all textures on game startup onto gfx memory. Then you wouldn't have to bother with loading it when its requested 
Nope, not possible...
(Leaving the explanation to someone else, don't feel like doing that right now)
I think I can tackle that one. The biggest problem is we don't know ahead of time where textures are in the ROM to preload them. Then, how do we uniquely identify textures to look up in the preloaded cache when they are presented to the renderer? Furthermore, who's to say a texture address, if used as the unique identifier, is not subject to its contents being changed? I can assure you that during movie playback, for instance, a few textures are allocated and used in a pipelining fashion for frames of the movie to be decoded onto. This obviously implies we cannot cache all textures ahead-of-time, even if we somehow knew where they all were. Textures may also be generated by the PowerPC CPU, in theory.