It is currently Tue Nov 21, 2017 8:58 am

All times are UTC - 7 hours



Forum rules


Related:



Post new topic Reply to topic  [ 21 posts ]  Go to page Previous  1, 2
Author Message
PostPosted: Sun Sep 17, 2017 11:41 am 
Offline
User avatar

Joined: Tue Sep 12, 2017 4:16 pm
Posts: 7
Yeah you're right.

I got a second sprite to display by changing Spritebuff2 (aka $0600) from #$54 to #$50. So instead of it being equal to #%01010100, it's now #%01010000. I guess I forgot how binary worked for a minute which is why I couldn't figure out what exactly was going on with this part. I expected that changing it to %#00010100 would work for some reason.

Following what HihiDanni just said sort of bumped me in the right direction causing me to realize this, and now I have a second sprite on the screen without glitches. I only needed that one DMA transfer section for it to work just like being told.

Now it's the same sprite as my first, not the different one that I'm trying to get to display, but I'll probably figure it out within the next day or so. It has to do with telling it somewhere the correct VRAM address which I likely overlooked and did wrong, so time to study some more snes code on the wiki.

EDIT: Yeah I don't know. Can someone point me in the right direction as to change what displays as the second sprite? Right now It's only showing my first one for both sprites. I am trying to get my second sprite at VRAM $9000, $0800 to show instead.

I'm just using that LoadBlockToVRAM code. Not sure why it's not linked to my 2nd sprite already the same way the DMA transfer code did it but I haven't been able to find out how to change it. I could get it so that some of that ONE working sprite's 16 tiles are used for another sprite and then tell it to use for example the 4th tile row only for sprite 2 using the 3rd byte of the low table but then I'm reducing the possible usable tiles for that 1st sprite just because there's no possible way to just load another different file for my 2nd sprite. I just don't see why using a different image file for a different sprite which is at a different VRAM address, allowing more versatile graphics, has to be such a nearly impossible task.


Top
 Profile  
 
PostPosted: Sun Sep 17, 2017 5:26 pm 
Offline
User avatar

Joined: Thu Dec 25, 2014 10:26 pm
Posts: 309
Location: Canada
If it's displaying a copy of the first sprite there's only two ways that should happen - either your data in VRAM has another copy of the first sprite, or else your OAM data is pointing to the wrong sprite. In the main OAM table where each sprite has 4 bytes, the third byte should be set to select which sprite in the allocated region of VRAM to display, that's my guess where your problem is, it's probably still set to zero.
Code:
Byte 0:    xxxx xxxx    x: X coordinate
Byte 1:    yyyy yyyy    y: Y coordinate
Byte 2:    cccc cccc    c: Starting tile #
Byte 3:    vhoo pppc    v: vertical flip  h: horizontal flip  o: priority bits  p: palette #


Top
 Profile  
 
PostPosted: Mon Sep 18, 2017 6:02 pm 
Offline
User avatar

Joined: Tue Sep 12, 2017 4:16 pm
Posts: 7
Are you sure? Byte 3, or the one that is in the cccc cccc format, points to which tile of the sprite to use from my understanding of it. If I start changing values of the 3rd byte, it just cycles through tiles. I mean I didn't just type in every value from 0 - 255 but it's like, in increments of #$40, just add + #$40 to get to the next row of tiles. For example, 00 shows the first row of my first sprite, #$40 shows the 2nd row, #$80 is responsible for the 3rd row and #$C0 is the 4th row in my 4x4 sprite tile that got made with pcx2snes.
To get to the next column, just add #$04. For example, setting byte 3 to #$44 sets it to row 2, column 2, whereas #$40 is row 2 column, 1 and #$48 is row 2 column 3. Since my sprite is only 4x4, setting it to something like #$50 just makes it sort of glitch but #$4C is fine.

None of these options show me the 2nd sprite that I'm trying to display which is stored in the VRAM at $9000 and is $0800 in size.

What is it that I'm missing?


Top
 Profile  
 
PostPosted: Tue Sep 19, 2017 4:06 pm 
Offline
User avatar

Joined: Mon Jan 23, 2006 7:47 am
Posts: 75
You could load the ROM into SNES9x 1.42 (or ZSNES) and make a savestate that you load into vSNES. From there you can see the status of the system - and even change it via the hex editor.


Top
 Profile  
 
PostPosted: Fri Sep 22, 2017 9:09 am 
Offline
User avatar

Joined: Tue Sep 12, 2017 4:16 pm
Posts: 7
I sort of got it to work by just putting a crap ton of sprites on one single tilemap and loading that ONE sprite tilemap into VRAM. Then and only then will it let me use those using byte 3 of the low table. It works OK except I can't have more sprites than will fit in one rom bank.
I think I read somewhere that if the other tilemaps start after like $6000 or $8000 or something they won't show up which is my problem right now. Even though I'm using a massive amount of sprites in one file that's like $3800 in length, it starts at $6000 and I can still use every tile in that map. Whenever I get around to doing that, I'll put another sprite into a different bank starting at $0000, keeping the one I have in a different one and if it works I'll post about it here.


Top
 Profile  
 
PostPosted: Sat Sep 23, 2017 6:40 am 
Offline
User avatar

Joined: Mon Jan 23, 2006 7:47 am
Posts: 75
Sounds like a lot of guesswork.

Ditch any framework files you're using (they often only help if you already know what they're doing with the hardware), read regs.txt again and write a new test ROM from scratch.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 21 posts ]  Go to page Previous  1, 2

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 7 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group