Page 2 of 2

Posted: Tue Jul 17, 2012 4:27 am
by Jsolo
It seems sprites disappearing on the left side is a bug in the library, at least judging from the documentation.

oamSet takes x coordinates in range 0..255, but their actual range is -255..255. The most significant (sign) bit lies in the upper 32 bytes of OAM.
(Note that -256 doesn't work correctly in hardware and therefore shouldn't be used).

Code would be something similar to this (note: not "optimized", also: C99/C++)

Code: Select all

void oamSetXY_fixed(unsigned int id, unsigned int x, unsigned char y) {
    const OAM_HI_TABLE_START = 128*4;

    // Set low byte of x position and y position:
    unsigned char x_lo = (unsigned char)x;
    oamSetXY(id,x,y);

    // Note that id isn't the OAM id, but a direct index into OAM shadow memory;
    // the result is that id/4 is the actual oam index, which is required for determining 
    // the OAM high table position.
    unsigned char oam_id = (unsigned char)(id >> 2);

    // Set highest bit of x position: Either at bit 0,2,4,6 depending on oam id,
    // as 4 oam entries are merged into one byte of the OAM high table.
    int bit_shift = 2*(oam_id % 4);
    int in_byte_position = 1 << bit_shift;
    int oam_high_table_pos = OAM_HI_TABLE_START + oam_id / 4;
    oamMemory[oam_high_table_pos] &= ~in_byte_position; // Clear current high bit of x
    oamMemory[oam_high_table_pos] |= (x>>8)<<bit_shift; // Fill in new high bit of x
}
Objects disappearing in the top 8 pixels may be a sign of you putting all unused objects with invisible gfx there; unused sprites should be moved to some huge negative x value (EXCEPT -256).

In fact, after looking at the oamInit code, it is another bug in the library: It sets the x position of every entry to (you probably guessed it) -256.
Since I'm already writing so much, I'll explain the curious behavior, too: If I recall correctly, sprites with x=-256 aren't displayed (as their x position is far too small), but due to a bug in the PPU they are considered on screen! They each take up a sprite slot, which has a hardware-based hard limit of 32, i.e. no more than 32 8x8 sprite tiles can be displayed per line. Since all sprites you didn't set to x=-255 are considered on the first 8 lines for sprite display, your sprite gets dropped. Manually setting all sprite positions to x=-255 should fix this.

Please excuse any errors, my last clash with the SNES was several years ago ;)

Posted: Tue Jul 17, 2012 7:40 am
by thefox
I was skimming through the documentation and noticed a small error in the "Day 2 - Output / Input" page (http://www.portabledev.com/wiki/doku.ph ... toutput_en)

At the bottom of the page it says:
... or if (pad0 & (KEY_A | KEY_X)) to know if button A and button X are pressed.
But that condition will actually check if either one of the buttons is pressed (or both).

Posted: Sun Jul 22, 2012 10:58 pm
by alekmaul
thefox wrote: At the bottom of the page it says:
... or if (pad0 & (KEY_A | KEY_X)) to know if button A and button X are pressed.
But that condition will actually check if either one of the buttons is pressed (or both).
You're right, fixed this day.

Posted: Sun Jul 22, 2012 11:12 pm
by alekmaul
Jsolo wrote: (Note that -256 doesn't work correctly in hardware and therefore shouldn't be used).
OK, didn't know about that.
Jsolo wrote: Objects disappearing in the top 8 pixels may be a sign of you putting all unused objects with invisible gfx there; unused sprites should be moved to some huge negative x value (EXCEPT -256).

In fact, after looking at the oamInit code, it is another bug in the library: It sets the x position of every entry to (you probably guessed it) -256.
Since I'm already writing so much, I'll explain the curious behavior, too: If I recall correctly, sprites with x=-256 aren't displayed (as their x position is far too small), but due to a bug in the PPU they are considered on screen! They each take up a sprite slot, which has a hardware-based hard limit of 32, i.e. no more than 32 8x8 sprite tiles can be displayed per line. Since all sprites you didn't set to x=-255 are considered on the first 8 lines for sprite display, your sprite gets dropped. Manually setting all sprite positions to x=-255 should fix this.
ago ;)
OK, will fix that in next release.
I think I will add another function like oamSetXYEx instead of rewriting the actual one to avoid speed problem.

Posted: Mon Jul 23, 2012 6:09 am
by juef
Thank you, Jsolo, thefox and alekmaul! :)

Re:

Posted: Fri Aug 31, 2012 2:15 pm
by cdoty
juef wrote:I'm having fun with this! :D
Couldn't agree more. I used it in Ludum Dare (http://www.ludumdare.com/) #24 last weekend. Ludum Dare is a 48 hour game dev competition.
I have developed software for the SNES (started back in '93 if I remember right), but had never used PVSnesLib before. It was a nice departure for having to write everything myself, and I didn't write one line of 65816 asm code.

Here's my Bacon, Lettuce, and Tomato vertical shooter, from the competition:
Image
BLT for the SNES
Now for a question, is the source for gfx2snes available?

Re: Re:

Posted: Sat Sep 01, 2012 6:24 am
by alekmaul
cdoty wrote:
Now for a question, is the source for gfx2snes available?
Everything is available here : http://code.google.com/p/pvsneslib/
You've got gfx2snes, smconv and snestools source codes.
If you made some changes on them, please tell me, I will add your changes to the next version of the lib :)

Re: Re:

Posted: Tue Sep 04, 2012 3:40 pm
by cdoty
alekmaul wrote:Everything is available here : http://code.google.com/p/pvsneslib/
You've got gfx2snes, smconv and snestools source codes.
If you made some changes on them, please tell me, I will add your changes to the next version of the lib :)
Thanks, I'm "looking to steal trade secrets". :)

I am looking to port this to other game systems (like the Genesis,) as the multi palette tile and map creation would be very useful on those systems.

The Gfx2Snes tool is missing the lzss.c file (unless it's somewhere else in the project, I couldn't find it). It's not a bit deal, as I just #ifdef'd out the lzsspacked related code.

Re: PVSnesLib for Snes 20th birthday :D !

Posted: Mon Jun 24, 2013 5:43 am
by alekmaul
Hi,
I updated PVSneslib with lot's of things.
Also, I added the missing lzss.c file, even if it is useless currently, I don't decompress BG in the lib...

At least, new game on the way with the lib : http://youtu.be/oVZBEesZZgw

Re: PVSnesLib for Snes 20th birthday :D !

Posted: Wed Jun 26, 2013 3:52 am
by juef
Great, thanks! :D Are the binaries available?