Sprite tiles are flippable. Can we flip the background tiles as well?
I think for the SNES and GBC it's different, but the NES's attribute table only keeps track of color information. So yeah, the answer is sadly no. You'll have to think a bit outside the box if you want to display reversed graphics.
Sega Master System is the exact opposite, you can flip the background tiles, but you can't flip the sprites.
Wow I didn't know that. That's crazy. Seems to me like flipping sprites is far more useful than flipping BG tiles. Wonder why they did that. Although I think the SMS used an off the shelf type VDP chip which would explain something like that.
MottZilla wrote:
Wow I didn't know that. That's crazy. Seems to me like flipping sprites is far more useful than flipping BG tiles. Wonder why they did that. Although I think the SMS used an off the shelf type VDP chip which would explain something like that.
Phantasy Star 1 had a really cool first-person dungeon engine that I read somewhere was made possible by the BG tile flipping.
Based on what I saw in a quick YouTube video of a dungeon, it could use the same tiles to represent all four quadrants of the player's view.
Dwedit wrote:
Sega Master System is the exact opposite, you can flip the background tiles, but you can't flip the sprites.
Yeah, this is very stupid. In 90% of the games sprites are required to face left and right, while background tile flipping just saves some extra space. SMS games sure have a hard time because of this. I believe the GG version of the VDP allowed for sprite flipping though.
MottZilla wrote:
Although I think the SMS used an off the shelf type VDP chip
It didn't, its VDP was *based on* an off the shelf VDP chip (the same one used on the MSX, ColecoVision and many others) which couldn't flip sprites. I believe it didn't flip background tiles either.
tepples wrote:
Based on what I saw in a quick YouTube video of a dungeon, it could use the same tiles to represent all four quadrants of the player's view.
Using the Meka emulator you can disable vertical and/or horizontal tile flipping in the tile map viewer, so you can easily see what's mirrored and what's not.
You can also easily see which tiles have high priority (above the sprites) or low priority (under the sprite). Yeah, this is another thing the SMS has that's kind of the opposite of what the NES does: the background tiles have priority bits, not the sprites (this is why in Sonic games sometimes the HUD is hidden by background tiles).
Interesting, I guess the GBC also have the ability to flip BG tiles and have background priority which is an extra to what the NES can do.
Note that if you have CHR-RAM it's always possible to flip tiles in software. I know it still wastes VRAM, but at least it doesn't waste ROM.
I'm pretty sure that the GG can't flip sprites either, otherwise I would have noticed that when I was messing around with SMSAdvance.
Dwedit wrote:
I'm pretty sure that the GG can't flip sprites either
I was told it could by people on some forum that worked with the SMS/GG (don't remember which forum), but I never looked into it. I assumed it was one of the improvements made on the VDP, like going from 64 colors to 4096, but wasn't used much so that games were still mostly compatible with both systems.
You know, many GG games do not take advantage of the fact that a large part of the tile map is hidden (to make scrolling easier, for example), they update the tile map as if a screen the size of the SMS one was visible, in order to make the game easy to port to the SMS I presume. So I though they avoided using the hardware flipping for the same reason, but I really don't know if the GG actually has it or not.
Bregalad wrote:
Note that if you have CHR-RAM it's always possible to flip tiles in software. I know it still wastes VRAM, but at least it doesn't waste ROM.
I've seen SMS games doing that with sprites. When copying the tiles from ROM to VRAM, a 256-byte long table was used to flip every byte during the copy for horizontal flipping. Also, I believe they read the tiles upside down (bottom row first) for vertical flipping.
Hi all,
I started a development making the assumption that I could flip x/y all tiles, even the background ones.
I feel sorry now that I realise the attribute table does not allow this
As I guess there's no mapper providing specific facilities in order to just flip the background tiles with a good granularity I guess that my options are only those two:
a) doing it software side with some RAM then upload them in the ppu
My problem with this one is that I have more than 100 tiles to switch so I would have to upload those flipped version at mid-frame and I remember reading that there's not enough cpu cycle to copy as many data during so few scanlines, even a full vblank would not enough if I understood properly.
b) use normal bank switching with a mapper.
If it's my only option, could someone advise me what mapper would allow to switch half of the pattern table at mid-frame ?
Is the MMC1 enough for that purpose ?
Am I still supposed to use Sprite 0 to detect when I should do the switch or is there some builtin MMC facility to trigger an IRQ when the PPU is drawing a particular scanline ?
Thanks for your help !
SMS and GG are identical as far as sprites go, only differences being palette size and viewport size and even then those are actually appiled extrenally. The VDP always outputs full res digital pixel info, palette and size are applied externally depending on SMS/GG mode pin status.
Now why there's no sprite flipping and such on sprites it has to do with VRAM access. Y coords are all within single set of 64 bytes, and each VRAM access fetches 2 coords for evaluation. X coord and start tile are in their own 128 bytes, but those use up all the 16 bits of single transfer, there's no room for an additional fetch and interleaving another attrib into Y coords probably halves sprite count or such (which I think wouldn't be a problem, you rarely get a lot of sprties on screen and you can mux them anyway).
And on the NES, it's the other way around: you can flip sprites but not background tiles. You can flip sprites because the OAM is on a separate bus, but you can't flip background because there isn't enough space in the attribute table to store a flip attribute.
AMIGrAve: Could you attach a mock-up of the picture that you're trying to display on the NES?
tepples wrote:
there isn't enough space in the attribute table to store a flip attribute.
Well, there is 32 unused bits interleaved with the last row. Could have stored a flip bit per column there.
tepples wrote:
AMIGrAve: Could you attach a mock-up of the picture that you're trying to display on the NES?
Sure, it will be a perspective grid that will looks a bit like this:
Yes, mappers would allow splitting that into top and bottom halves and serving each from a separate bank of CHR ROM.
tepples wrote:
Yes, mappers would allow splitting that into top and bottom halves and serving each from a separate bank of CHR ROM.
Thanks!
And for triggering the event at mid frame in order to do the bank switching, is it preferable to use the sprite 0 or do you advise a particular mapper that allows to trigger an IRQ or something at a given scanline ?
If you'll already be using a mapper with decent CHR bankswitching, better use one that also has scanline IRQs. To split the screen with sprite 0 you need to wait for the hit in a loop, which wastes CPU time. IRQs on the other hand can interrupt the program when the desired scanline is reached, regardless of what it's doing, and after the split the program resumes as if nothing had happened.
tokumaru wrote:
If you'll already be using a mapper with decent CHR bankswitching, better use one that also has scanline IRQs. To split the screen with sprite 0 you need to wait for the hit in a loop, which wastes CPU time. IRQs on the other hand can interrupt the program when the desired scanline is reached, regardless of what it's doing, and after the split the program resumes as if nothing had happened.
Thanks!
I just found the
list of mappers with support for scanline IRQs maintained by rainwarrior on the nesdev wiki. Cool!
I just maintained the category page itself a little. I should not be credited for maintaining the list, a lot of other people did the real work on that one.
The MMC3 is probably the best choice in this case. It has reasonably fine CHR bankswitching (2KB for one pattern table and 1KB for the other) and a decent scanline counter. It's also very common and there are implementations of it for homebrew games. The only downside is that since the scanline counter functions by counting pattern table accesses, you can't use sprite tiles from both pattern tables when in 8x16 mode, because that confuses the counter. Sprites must come from one pattern table, and backgrounds from the other.
tokumaru wrote:
It's also very common and there are implementations of it for homebrew games.
I'm not sure if I understand, do you mean that are chips available that do the job of a MMC3 without the need of grabbing these chips out of other carts?
Yes.
INL has all new hardware for many mappers, including the MMC3.