Union Vs. Pointer Arithmetics BS

We have a problem and that is the use of unions vs. pointer arithmetics for some struct accesses, because either capcom thought it was a good idea to do all that crap or they are some kind of compiler optimization that we don't know of.

This issue should be addressed ASAP as it will clutter up the decompiled code badly without knowledge of the original coding practices they used.

    REG_IE = struct0->unk50;
    REG_DISPSTAT = struct0->unk52;
    REG_DISPCNT = struct0->unk4A;
    // if not done via arithmetic this would require tons of unions
    (*(vu32 *)REG_ADDR_BG0CNT) = *((u32*) struct0+0);
    (*(vu32 *)REG_ADDR_BG0HOFS) = *((u32*) struct0+2);
    (*(vu32 *)REG_ADDR_BG1HOFS) = *((u32*) struct0+3);
    (*(vu32 *)REG_ADDR_BG2CNT) = *((u32*) struct0+1);
    (*(vu32 *)REG_ADDR_BG2HOFS) = *((u32*) struct0+4);
    (*(vu32 *)REG_ADDR_BG3HOFS) = *((u32*) struct0+5);
    (*(vu32 *)REG_ADDR_BG2PA) = *((u32*) struct0+6);
    (*(vu32 *)REG_ADDR_BG2PC) = *((u32*) struct0+7);
    REG_BG2X = *((u32*) struct0+8);
    REG_BG2Y = *((u32*) struct0+9);
    (*(vu32 *)REG_ADDR_BG3PA) = *((u32*) struct0+10);
    (*(vu32 *)REG_ADDR_BG3PC) = *((u32*) struct0+11);
    REG_BG3X = *((u32*) struct0+12);
    REG_BG3Y = *((u32*) struct0+13);
    (*(vu32 *)REG_ADDR_WIN0H) = *((u32*) struct0+14);
    (*(vu32 *)REG_ADDR_WIN0V) = *((u32*) struct0+15);
    (*(vu32 *)REG_ADDR_WININ) = *((u32*) struct0+16);
    (*(vu32 *)REG_ADDR_MOSAIC) = *((u32*) struct0+17);
    REG_BLDCNT = struct0->unk48;
    REG_BLDALPHA = struct0->unk4C;
    REG_BLDY = struct0->unk4E;

Here is an example of using pointer arithmetics for matching code and as you can clearly see it looks horrifying.

seeing how

pwaa1/src/main.c

Line 249 in 4db1ee1

DataCopy32(&REG_BG0CNT, &ioRegsp->lcd_bg0cnt);

fixes this ill close this for now