Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Question about generating 32x32 sprites for the PCE #48

Open
zanto1 opened this issue Apr 19, 2024 · 3 comments
Open

Question about generating 32x32 sprites for the PCE #48

zanto1 opened this issue Apr 19, 2024 · 3 comments

Comments

@zanto1
Copy link

zanto1 commented Apr 19, 2024

I'm trying out this tool to convert a 32x32 png file to a sprite I can load into my PCE game. The problem is that I'm getting the result on the right when the image on the right is the correct one (ignore the palette difference between the two images)

image

This is the command I'm running. What am I doing wrong?
.\superfamiconv.exe -i 04.png -t 04-conv.bin -p 04.palette -M pce_sprite -v

@jbrandwood
Copy link

Just dropping in to add an unwanted comment ...

Are you sure that you're obeying the HuC6270 VDC's limit on sprite placement in VRAM, because that result sure looks a lot like what you get when you misalign sprites in VRAM!

The VDC sees contiguous VRAM as a bunch of 32x64 sprites (on 512 word boundaries), and you MUST align any sprites larger than 16x16 within those areas; so a 32x32 sprite must be loaded on a 256 word boundary (i.e. VRAM $xx00).

This gets super confusing when you are using 16x32 sprites because the top and bottom halves are seperated in memory!

This is because the VDC builds sprites larger than 16x16 by flipping VRAM address bits directly rather than adding an offset from a base location (which the Genesis and SNES do IIRC).

@est77
Copy link

est77 commented Apr 19, 2024

I think that there is a bug when generating PCE sprites. They are horizontally flipped iirc.
I found this diff in a Superfamiconv fork (I cannot seem to find which one) that seems to fix the issue for me (I didn't test it a lot).

diff --git a/src/Mode.h b/src/Mode.h
index 9d46454..bbe1616 100644
--- a/src/Mode.h
+++ b/src/Mode.h
@@ -748,7 +748,18 @@ inline byte_vec_t pack_native_tile(const index_vec_t& data, Mode mode, unsigned
 
   } else if (mode == Mode::pce_sprite) {
     for (unsigned p = 0; p < 4; ++p) {
-      auto plane = make_1bit_planes(data, p, false);
+      // PCE sprite data was previously generated incorrectly, it seems.
+      // Firstly, the call to make_1bit_planes here should specify 'reverse=true'.
+      // Second, sprite data is stored as 16-bit words in low/high order, meaning the byte pairs should
+      // be swapped here in order to be correct.
+      auto plane = make_1bit_planes(data, p, true);
+      int datalength = plane.size();
+      for (int i = 0; i < datalength-1; i += 2)
+      {
+        auto tmp = plane[i];
+        plane[i] = plane[i+1];
+        plane[i+1] = tmp;
+      }
       nd.insert(nd.end(), plane.begin(), plane.end());
     }
   }

@Optiroc
Copy link
Owner

Optiroc commented Apr 21, 2024

I’m not familiar with PCE internals personally, so I’m happy to receive any fixes pertaining to the PCE code paths. I will have a closer look at the diff above.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants