Interpreting EOP's in GIF packets
#1
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.

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.



Reply

Sponsored links

#2
WEll, i am not sure about what plugin your're making. But you can ask Gabest(GSdx maker) or ZeroFrog(ZeroGS Maker) or even the ZZOgl maker.
[Image: recodersignature2.png]
Reply
#3
ideally your GS plugin should be ignoring gif packet EOP's, it should just be concentrating on reading GS primitives. the EOP's are something pcsx2's core uses to handle gif path arbitration (and it tell's VU1's xgkick instruction when to stop reading the gif-packet from vu1 memory).

however pcsx2's gif code needs rewriting so its possible you currently might need to do some other hacky stuff to get it working.
i don't know what pcsx2's current code wants you to do; you might wanna take a look at gsdx and see what its doing.

there used to be 3 different giftransfer callbacks for the different paths (which was obviously wrong). i think now we're only using the gstransfer2 callback, but i haven't looked at the code in a while.

basically what pcsx2 should be doing is managing the reordering of gif packets, and sending the gs plugin gs primitives in such a way where it doesn't need to care about EOP's or the different gif paths.
Check out my blog: Trashcan of Code
Reply
#4
(06-19-2011, 12:10 PM)cottonvibes Wrote: ideally your GS plugin should be ignoring gif packet EOP's, it should just be concentrating on reading GS primitives. the EOP's are something pcsx2's core uses to handle gif path arbitration (and it tell's VU1's xgkick instruction when to stop reading the gif-packet from vu1 memory).

however pcsx2's gif code needs rewriting so its possible you currently might need to do some other hacky stuff to get it working.
i don't know what pcsx2's current code wants you to do; you might wanna take a look at gsdx and see what its doing.

there used to be 3 different giftransfer callbacks for the different paths (which was obviously wrong). i think now we're only using the gstransfer2 callback, but i haven't looked at the code in a while.

basically what pcsx2 should be doing is managing the reordering of gif packets, and sending the gs plugin gs primitives in such a way where it doesn't need to care about EOP's or the different gif paths.

Thanks for clearing that up for me, I'll take a closer look at other plugins source and the PCSX2's source and see what they are doing.

Reply
#5
(06-19-2011, 12:08 PM)recoder Wrote: WEll, i am not sure about what plugin your're making. But you can ask Gabest(GSdx maker) or ZeroFrog(ZeroGS Maker) or even the ZZOgl maker.

It's just a (currently quite primitive) plugin for the graphical functionality of the PCSX2 which I'm writing for the learning experience and for fun. You're probably right, I should contact a plugin author directly but cottonvibes has basically cleared things up for me, for now atleast.
Reply
#6
It is possible that pcsx2 could be sending you multiple packets at once due to the mtgs buffer, but we make sure the gs plugin only gets the data as far as the eop giftag and associated data. So yeah, as cotton said, just process the tags for the length of data you've received, it should be correct Smile
[Image: ref-sig-anim.gif]

Reply
#7
Does PCSX2 use PSEmu plug-in source code?
Reply
#8
(06-21-2011, 05:02 PM)Default Wrote: Does PCSX2 use PSEmu plug-in source code?

Not the source code directly, if you mean the method created by PSEmu as the standard interfacing type, then yes, as do most (if not all) modern plugin based emulators.

[Image: ref-sig-anim.gif]

Reply
#9
the psemu plugin design has its drawbacks because it forces plugin authors to re-implement emulation specific stuff, when a plugin ideally should be 'dumb' and only output graphics/sound/handle input w/o doing real emulation.
this way plugin authors don't have to duplicate emulation code, and it prevents emulation bugs and makes future big-changes to emulation easier since only the core needs to be modified.

some of us have been talking about converting pcsx2 to use dumb-plugins in the future; although obviously its going to be a challenge (especially for the GS plugin).
the biggest pain for the other plugins are the UI and setting changes that need to be changed between pcsx2 and the plugins.
Check out my blog: Trashcan of Code
Reply
#10
(06-21-2011, 09:06 PM)cottonvibes Wrote: the psemu plugin design has its drawbacks because it forces plugin authors to re-implement emulation specific stuff, when a plugin ideally should be 'dumb' and only output graphics/sound/handle input w/o doing real emulation.
this way plugin authors don't have to duplicate emulation code, and it prevents emulation bugs and makes future big-changes to emulation easier since only the core needs to be modified.

some of us have been talking about converting pcsx2 to use dumb-plugins in the future; although obviously its going to be a challenge (especially for the GS plugin).
the biggest pain for the other plugins are the UI and setting changes that need to be changed between pcsx2 and the plugins.

So, PCSX2 plugins use more processing power and memory than 'dumb' plugins?
Reply




Users browsing this thread: 1 Guest(s)