Page 1 of 1

Fixes for videoGL if someone wants to start before I do

Posted: Sat May 05, 2012 6:44 am
by Discostew
Having read over the thread involving the port of Doom64 to the DS, I've come to the conclusion that some changes need to be made to the videoGL portion of libnds. I would go into the work of it myself since I made the current allocation method, but I am stuck with finishing up projects and finals for school for the next few weeks, so unless people don't mind waiting before I can start on these, I'll post my ideas and let someone tackle them if they wish.

As it is right now, when allocating a new texture, the current system checks the state of each relevant VRAM bank to see if it is properly set for textures (or texture palettes). This is all good, except this can cause rendering problems if such allocation checks are being done while the rendering engine is active. Say you want to put a texture into bank_C but not into bank_A or bank_B. The current method requires that bank A/B not be set to textures for this to work. This conflicts with the rendering engine if any textures are being referenced in either of those banks while buffering. The current setup uses the states for deciding if the bank is "locked" or not. My idea is to take that "lock" attribute, and separate it from the states, but use both the lock attribute and the current bank state for deciding where to allocate. Would require additional functions, but would not necessarily be required if the VRAM banks aren't being changed to anything else.

The other involves the actual copying of data into the VRAM banks via glTex2DImage. Right now, it makes a copy of the current main bank states, then sets them all to LCD mode so that copying can be done. This also conflicts with the rendering engine if that is active. My idea is to have it figure out which banks will actually have data copied to them, and only set those banks to LCD mode. Conflicts with the rendering engine will still happen if the same bank having data copied to it is being referenced by the rendering engine, but that is something we can't get around.

Re: Fixes for videoGL if someone wants to start before I do

Posted: Fri May 11, 2012 7:33 am
by Discostew
Had a little time to work on this today. Patch already submitted.