-
Notifications
You must be signed in to change notification settings - Fork 24
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
Comments
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). |
I think that there is a bug when generating PCE sprites. They are horizontally flipped iirc.
|
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. |
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)
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
The text was updated successfully, but these errors were encountered: