TEXIMAGE_PARAM and PLTT_BASE effect previous polygon
When issuing a TEXIMAGE_PARAM and/or PLTT_BASE command between BEGIN_VTXS and END_VTXS, they can effect the previous polygon. For example when doing
- TEXIMAGE_PARAM (1)
- PLTT_BASE (1)
- BEGIN_VTXS (quads)
- TEXCOORD
- VTX_16
- TEXCOORD
- VTX_16
- TEXCOORD
- VTX_16
- TEXCOORD
- VTX_16
- TEXIMAGE_PARAM (2)
- PLTT_BASE (2)
- TEXCOORD
- VTX_16
- TEXCOORD
- VTX_16
- TEXCOORD
- VTX_16
- TEXCOORD
- VTX_16
- END_VTXS
Then both the first and the second quad will have the texture and palette specified by TEXIMAGE_PARAM (2) and PLTT_BASE (2). When no vertices are issued after TEXIMAGE_PARAM (2) and PLTT_BASE (2), it doesn't change the texture and the initial settings (1) will be used. When enough cycles are added before TEXIMAGE_PARAM (2), for example by inserting a MTX_SCALE, then the first quad is already done processing and won't be effected.
I modified a libnds example to show the behavior. Melonds shows one untextured and one textured quad, while real hw has both quads textured.
TexImageParamBug.nds.zip
TexImageParamBug_src.zip
Edit: I did some more testing, and clipping also effects the timing. Within a tristrip I found that using MTX_SCALE is not good enough when clipping (the texture then switches if the vertex is clipped or so), in that case MTX_TRANS seems to work though.
struggling to reproduce this on a new3dsxl, even with the provided rom. this might be our first genuine revisional difference in the gpu not even just fixed with the gx rev bit, it seems to just be outright fixed...? can anyone else test this on differing ds models?
false alarm: can reproduce; just not when run via twilight menu for some reason? very strange.
Could it be related to scfg settings somehow?
It seems to be, SCFG_EXT9 bit1 set makes it look like in melonDS.
Ah okay. That makes sense, because that's the revision bit for the geometry engine. Then I guess it behaves as it should.
twilight menu doesn't set the scfg bit though and my test rom that does: vtx10, vtx10, vtx10, vtx10, texparam, swap. doesn't seem to reproduce it even under circumstances that work in this rom i'll try to look further into this