Hi PCSX2 forum,
I am currently developing a GS plugin which is going well, however, in developing this plugin I have come across some circumstances regarding GIF packets that are difficult to resolve. Ideally, a person familier with the GS will be able to advise me.
I'll give an example. Here's some logging output of a GIF packet from FFX.
As you can see, it follows the typical structure of a GIF packet, that is, it contains a GIFTAG with it's EOP flag set, therefor, after the GIFTAG and its data has been read the packet logically should be dropped and any remaining data discarded. Making this assumption, my GS plugin has come far and many games and demo's are playable, however, there is a problem. The size (passed from the PCSX2 through the GSgifTransfer functions) of the GIF packet does not add up and there is actually one extra GIFFTAG in this particular packet, which actually tells the GS that IMAGE data is coming next and how much, so it's very important. Here's is the packet with the EOP ignored and only going by the size.
So, my question is. Should I just ignore the EOP and read all data in the packet according the size, effectively making the EOP redundant, or is there some sort of comprimise? If I do ignore the EOP (in FFX for example), I get visual artifacts that shouldn't be there and random crashes, although, menu's that wern't rendering before show up.
Thanks for any advise and sorry for the convoluted nature of this question.
I am currently developing a GS plugin which is going well, however, in developing this plugin I have come across some circumstances regarding GIF packets that are difficult to resolve. Ideally, a person familier with the GS will be able to advise me.
I'll give an example. Here's some logging output of a GIF packet from FFX.
Code:
GIF packet: path=3, size=3
GIFtag: nloop=0x1, eop=0x1, pre=0x0, prim=0x0, flg=0x0, nreg=0x1
A+D (BITBLTBUF): 0x0000000000000050_00013ff400000000
GIF Packet end
As you can see, it follows the typical structure of a GIF packet, that is, it contains a GIFTAG with it's EOP flag set, therefor, after the GIFTAG and its data has been read the packet logically should be dropped and any remaining data discarded. Making this assumption, my GS plugin has come far and many games and demo's are playable, however, there is a problem. The size (passed from the PCSX2 through the GSgifTransfer functions) of the GIF packet does not add up and there is actually one extra GIFFTAG in this particular packet, which actually tells the GS that IMAGE data is coming next and how much, so it's very important. Here's is the packet with the EOP ignored and only going by the size.
Code:
GIF packet: path=3, size=3
GIFtag: nloop=0x1, eop=0x1, pre=0x0, prim=0x0, flg=0x0, nreg=0x1
A+D (BITBLTBUF): 0x0000000000000050_00013ff400000000
GIFtag: nloop=0x40, eop=0x1, pre=0x0, prim=0x0, flg=0x2, nreg=0x0
GIF Packet end
So, my question is. Should I just ignore the EOP and read all data in the packet according the size, effectively making the EOP redundant, or is there some sort of comprimise? If I do ignore the EOP (in FFX for example), I get visual artifacts that shouldn't be there and random crashes, although, menu's that wern't rendering before show up.
Thanks for any advise and sorry for the convoluted nature of this question.