Closed jpd002 closed 8 years ago
Hmm. I definitely feel like it'd be nicer to specify the regs in a different way on the tag - ideally more typesafe. But it's tricky, since you're building a structure which will have nloop rows.
It might make sense for it to have methods which "build" the active tag, and have a method to init a new tag. I'm not sure though, been busy lately so haven't thought about this properly yet.
An idea, some of which I'm not liking:
// GIFtag(u16 nloop, DataFormat fmt, bool last, RegDesc r0 = REG_INVALID, RegDesc r1 = REG_INVALID, ... RegDesc r15 = REG_INVALID);
packet.GIFtag(1, GIF::FMT_PACKED, true, GIF::REG_AD);
packet.SetPrim(GS::PRIM_LINE);
It needs a way to add raw data too, so we can test other bits of the tag. But yeah, I think AD makes sense just taking a 64 bit value. Though, I think ideally they can be quick funcs under GS::
rather than defines, like u64 SIGNAL(u32 id, u32 msk) { return (u64)id | ((u64)idmsk << 32); }
.
packet.PackedAD(GS::REG_SIGNAL, GS::SIGNAL(1234, 5768));
Hmm. It'd be awesome if it were somehow typesafe, but there are a ton of registers, so that seems like a pain. Could be something like GS::RegData SIGNAL(u32 id, u32 msk) { return RegData(GS::REG_SIGNAL, (u64)id | ((u64)idmsk << 32)); }
and then packet.PackedAD(GS::SIGNAL(1234, 5678));
. That seems cleanest but likely not worth the hassle, and would still want the alternative of a reg and data to add raw.
-[Unknown]
Thanks for your comments. Following your input, I've made some changes to the branch:
Tag
class in the GIF
namespace with setters for the tag's fields. The data is kept in an union to allow easy access to the fields or to the raw data (if we want to fiddle with the unused bits).PackedPacket
which is a sub-class of Packet
which has functions that generates writes to GS registers in the way this format allows. A RegListPacket
and ImagePacket
could be added later.Emit
function of Packet
public to allow writing arbitrary data in the packet.Well, tell me what you think! There's surely a way to make this even better.
Cool. I think this is a pretty good starting point, we may find ways to make it better as we work with it more but the important thing is that I think tests written this way will be clear enough for someone to read and have an idea what's being tested.
To be fair, some of the CPU tests are maybe not beautiful (RRI_, etc.) but it's at least pretty clear what's being tested.
Thanks.
-[Unknown]
As discussed in #31, this is a first shot of what GIF packet construction could look like.
Not quite sure about the register value generation in
gsregs.h
that uses defines. The alternative was to use functions, but I was thinking that might be a bit heavy.Anyways, I'm open to all your suggestions, so, just tell me what you think!