It is currently Mon Oct 23, 2017 11:08 pm

All times are UTC - 7 hours





Post new topic Reply to topic  [ 35 posts ]  Go to page 1, 2, 3  Next
Author Message
PostPosted: Thu Dec 16, 2004 2:05 pm 
Online
User avatar

Joined: Fri Nov 12, 2004 2:49 pm
Posts: 7235
Location: Chexbres, VD, Switzerland
Which mirroiting mode shall I choose to have a single bi-directionnal scrolling screen ? What are the strong points and the weak points of Horizontal / Vertical mirroiting ?

_________________
Life is complex: it has both real and imaginary components.


Top
 Profile  
 
 Post subject: Single Mirroring :-)
PostPosted: Thu Dec 16, 2004 2:40 pm 
Your using MMC5 hardware right? If your using the MMC5 graphic expansions (ExGrafix mode), it'd prolly be best for you to use Single Screen mirroring.

ExGrafix mode expands the graphics of both Nametable A and B I believe (so tile 1 of the both tables would be exactly the same high byte but different lower byte + it would have the exact same attribute), thus unless you can think of a certain way to use your graphics wisely, you should use 1-screen mirroring (making your game a lot more flexible and less restricted).

Think about it: Scrolling up and down would be absolutely no problem. The MMC5 ExGrafix allows 8x8 attribute so even they wouldn't be a problem. You can't see the top and bottom 8 pixels of the screen (NTSC) so scrolling up and down would be smooth with no graphicc glitches.

Horizontal mirroring would probably be pointless then. I guess you could possibly do vertical mirroring, which I believe Just Breed uses, but essentially it would have to act just like 1-screen mirroring (Just Breed works like that for some reason). I studied Just Breed for awhile, but I'm not sure I remember correctly how it did it's scrolling so I think it's best you check it's scrolling method out if you want to :-)

Some ideas if you don't want single screen mirroring:

-only Nametable A (the lower 8-bits of Exgrafix) to have 0-127, and only have Nametable B (the lower 8-bits of Exgrafix) have the tile #s 128-256. And then design the CHR data in your game to compensate this. This would effectively allow the 2 NES nametables to have different tilesets, but the same attributes.

-I guess you don't have to even use Exgrafix mode, I mean the MMC5 has a lot of other benefits besides that Exgrfix mode (but I reccommend you use it).


Top
  
 
 Post subject: Re: Single Mirroring :-)
PostPosted: Thu Dec 16, 2004 6:46 pm 
Offline

Joined: Mon Nov 22, 2004 3:24 pm
Posts: 162
Location: Sweden
I must say I agree with J2. There's really no reason do use anything other than single screen mirroring if you use ExGrafix.

edit: I just realized something.. 1 kB of ExGrapix memory simply isn't enough to cover two nametables, or?

I've been thinking about the same problem myself, but for a less advanced mapper. Since I'm writing (read: hacking around with some tech-demos that'll never turn into a complete game) a Megaman parody I only need pure horizontal or pure vertical scrolling is needed, never both simultaneously.
An early test of the scrolling system seem to indicate that this can be done without color-clashes and without sacraficing many additional cycles. The only problems I can foresee is that switching between horizontal and vertical mirroring when the viewport isn't aligned on a nametable would be next to impossible to handle seamlessly, and also split screen in vertical mode would become messy (i.e. require additional raster splits).
Neighter of these seems to be used in Megaman (well.. the early games had split screen). Yet Capcom chose to use horizontal mirroring, why?

And another thing. What's the optimum size of meta-tiles? I realize that 2x2 seems to be the de-facto standard but 4x4 reduces the size of internal tables and makes it a lot easier to deal with the attribute cells.

Sorry for hijacking your thread Bregalad.


Top
 Profile  
 
 Post subject:
PostPosted: Fri Dec 17, 2004 10:32 am 
Online
User avatar

Joined: Fri Nov 12, 2004 2:49 pm
Posts: 7235
Location: Chexbres, VD, Switzerland
I asked this question both for my MMC5 game and for curiousity.
On a standard mapper, what are the advantages of every mode of mirroiting ?
Right, with MMC5, ExGrafix data will be aplicated to every name table, but I really can't see why single screen mirroiting would "make my game a lot more flexible and less restricted".
About MetaTile, I think to use standard 2x2 size. Every metatiles will be 8 bytes data, 4 bytes to write to the name table and 4 for exgrafix. But I'm planning to compress map data as possible, to simply have more places in the games.

_________________
Life is complex: it has both real and imaginary components.


Top
 Profile  
 
 Post subject: Re: Single Mirroring :-)
PostPosted: Fri Dec 17, 2004 11:01 am 
doynax wrote:
Neighter of these seems to be used in Megaman (well.. the early games had split screen). Yet Capcom chose to use horizontal mirroring, why?


The only Megaman with hardwired mirroring is the original (which uses an UNROM board) and it uses vertical mirroring. The other games in the series all have mapper-controlled mirroring. I haven't checked but I suspect they use vertical mirroring everywhere, except perhaps in some boss battles. Remember that none of the NES Megaman games has any smooth vertical scrolling sequences--vertical scrolling is always in screen-sized chunks.

Also, the only Megaman game with a split screen is Megaman 3. The first two games draw the weapon-select window right on top of the BG (like the subscreen in Zelda 2) and the last three switch to a completely separate screen.


Top
  
 
 Post subject:
PostPosted: Fri Dec 17, 2004 11:19 am 
Wait, I spoke too soon. The later Megaman games must use horizontal mirroring in regular gameplay--because of the subscreen in MM3, and in the later games for split screen gimmicks (e.g. the "crushing ceiling" sequence which SMB3 popularized)

The MM games from MM3 onward all clip the leftmost 8-pixel column via bits 2 and 1 of $2001, and have tile and palette artifacts at the rightmost edge of the screen--the two unmistakable signs that a game is doing horizontal scrolling with horizontal mirroring.


Top
  
 
 Post subject:
PostPosted: Fri Dec 17, 2004 1:17 pm 
Online
User avatar

Joined: Fri Nov 12, 2004 2:49 pm
Posts: 7235
Location: Chexbres, VD, Switzerland
Megaman 1 and 2 uses vertical mirroiting, but 3-6 uses horizontal mirroiting while scrooling horizontaly and vertical mirroiting while scrooling vertically. So the segond nametable is always empty, exepet for MM3's menu.

_________________
Life is complex: it has both real and imaginary components.


Top
 Profile  
 
 Post subject:
PostPosted: Sat Dec 18, 2004 3:30 am 
Quote:
I asked this question both for my MMC5 game and for curiousity.
On a standard mapper, what are the advantages of every mode of mirroiting ?


Well, If you have horizontal mirroring then it's easier to code the game to vertically scroll as there is graphic data that you can write to that is out of the boundaries of what the NES s currently displaying (vertically). While with vertical mirroring it's easier to code the game to horizontally scroll as there is graphic data that you can write to that is out of the boundaries of what the NES s currently displaying (horizontally). So really the benefit is what way you want to scroll cleanly and easily. Note: In vertical mirroring it sort of looks better to scroll all 4 ways seeing as the top and bottom 8 pixels arn't displayed (making it easy to scroll up in down cleanly), and you don't have to use the background clipping on the left 8-pixels of the screen (which really isn't that big of a deal, but it does look somewhat better, FF3j scrolling does this)

Single screen mirroring is pretty useful I think. You can scroll all 4 ways with just one nametable and have the other nametable unnaffected (in which you can put data in that and switch it in if you need to, many games used it for status bars). Scrolling up and downs fine (since bottom and top 8 pixels arn't displayed) and you can scroll horizontally cleanly *enough* if you use the background 8-pixel clipping of the leftmost pixels.

4-screen mirroring is useful if...I guess if you have some kind of level format the exactly fits 64x60 tiles and you don't want to mess around with nametable ram while scrolling then 4-screen mirroring would be useful. Or if you needed 4 way scrolling easily and cleanly.

So,

Horizontal Mirroring: If the game scrolls vertically.

Vertical Mirroring: If the game scrolls horizontally.

1-screen mirroring: If you need to scroll 4 ways and leave the other nametable untouched as the game scrolls (as with other mirroring modes, if you scrolled all 4 ways in would defintly eventually scroll over the other nametable and thus the other nametable would need to change it's data to keep scrolling the map)

4-screen mirroring: An easy way to scroll all 4-ways cleanly and non hackingly (I can't seem to think of any other benefits...).

Quote:
Right, with MMC5, ExGrafix data will be aplicated to every name table, but I really can't see why single screen mirroiting would "make my game a lot more flexible and less restricted".


What I meant was you wouldn't need to come up with a hacky way to use horizontal or vertical mirroring with ExGrafix mode. It would allow you to scroll 4 ways intedpendently of the contents of other nametables.

Quote:
About MetaTile, I think to use standard 2x2 size. Every metatiles will be 8 bytes data, 4 bytes to write to the name table and 4 for exgrafix. But I'm planning to compress map data as possible, to simply have more places in the games.


So the same size as regular sized NES Attributes. Your metatiles will probably have the same 4-colors in them right? So, if your going to compress it like that, what's the point of using ExGrafix mode (besides having 16,384 tiles to choose from) or will your meta-tiles have different attributes in them? The MMC5 allows for a lot of data so you'll probably not need to worry too much. 1 MB of PRG rom and 1 MB of CHR-ROM should be plenty for your game. You could do simple RLE compression of your nametable and get away with it (depending on how big you plan to make your game).


Top
  
 
 Post subject:
PostPosted: Sat Dec 18, 2004 5:05 am 
Offline

Joined: Mon Nov 22, 2004 3:24 pm
Posts: 162
Location: Sweden
Guest wrote:
Wait, I spoke too soon. The later Megaman games must use horizontal mirroring in regular gameplay--because of the subscreen in MM3, and in the later games for split screen gimmicks (e.g. the "crushing ceiling" sequence which SMB3 popularized)

The MM games from MM3 onward all clip the leftmost 8-pixel column via bits 2 and 1 of $2001, and have tile and palette artifacts at the rightmost edge of the screen--the two unmistakable signs that a game is doing horizontal scrolling with horizontal mirroring.

I knew I had to have missed something..
Still, maybe it's a bad idea to let the other 98% of the game suffer because of a few special cases. The nametable handling is fairly separate from just about everything else so it shouldn't be too hard to write a horizontally mirrored system to handle such effects.

J2 wrote:
So the same size as regular sized NES Attributes. Your metatiles will probably have the same 4-colors in them right? So, if your going to compress it like that, what's the point of using ExGrafix mode (besides having 16,384 tiles to choose from) or will your meta-tiles have different attributes in them? The MMC5 allows for a lot of data so you'll probably not need to worry too much. 1 MB of PRG rom and 1 MB of CHR-ROM should be plenty for your game. You could do simple RLE compression of your nametable and get away with it (depending on how big you plan to make your game).

Heh, I think you're confusing me with Bregalad (why do I keep pronouncing that as "Bergladad" in my head?). I'm going to use a discrete logic mappery myself. It's my own fault for hijacking the thread I guess..

The big disadvantage of 4x4 metatiles as I see it is that I'd have to write something equivalent of a "slope system", simply because 4x4 boolean collision detection isn't accurate enough.
My main consern with switching to the smaller size is that I'd have to waste a lot more memory on collision tables, which are pretty much required if I'm going to do any kind of compression. Since I'm thinking of keeping track of the game state half a nametable out of the screen or so (in each direction) I'd waste about a quarter of the RAM on the collision table alone, hopefully I won't need anything else that big though.


Top
 Profile  
 
 Post subject:
PostPosted: Sat Dec 18, 2004 9:18 am 
Online
User avatar

Joined: Fri Nov 12, 2004 2:49 pm
Posts: 7235
Location: Chexbres, VD, Switzerland
So (in a non-ExGrafix environnement) Vertical mirroiting is fine, but your scrooling routine must be quick and structurated while scrooling vertically like FF3, right ?
And I guess Horizontal mirroiting would have some gliches while scrooling horizontally, but it's the only way to have a permanent status bar while scrooling vertically, like Double Dragon and Cronicles of the Rydia War.
For my MMC5 game, I'm planning to use 2x2 metatiles with 2 bytes per tiles, the low one for name table and the high one for the exgrafix table, so this would be 14 bit of adress and 2 bits of color for each tile. The reason for using 2x2 is the collison thing, but I'm in trouble about it. It would be 1 bit per metatile, or may more. Any way of compression is welcome (I'm not going to have 1MB of PRG, at least 512kb cause I'm not sure of the accuracy of this, and the CHR thing can't go above 256kb with ExGrafix mode).
If I could, I'd like to copy and change a bit Just Breed's scooling code.
One cool thing would like to change the BG palette wile scrooling to have more colors in one big map, but not all at the same time (Double Dragon does this).
Also, I noted how the talking aera is done in FF1. It writes the window just in the opposite name table, then invert the $2000.0 bit midframe to switch the used name table. A similar thing will be used later in FF6, CT, etc... I'm gonna to have an effect like this in my game.

_________________
Life is complex: it has both real and imaginary components.


Top
 Profile  
 
 Post subject:
PostPosted: Sat Dec 18, 2004 10:24 am 
Offline

Joined: Mon Sep 27, 2004 2:57 pm
Posts: 1248
On my experience, if you want 4-way scrolling, it depends on your needs.

If you want a statusbar, you can you either mirroring, but vertical mirroring with a statusbar is a little bit tricky, because you'd need to use the irq to split the status bar out of where it would normally appear in the middle of the level, and then split again, to put the statusbar at the bottom. (Krusty's Fun House does this) The advantages of this is that you don't have the ugly looking crap on the left and right sides of the screen, and you can leave the 8-pixel clipping turned off.

Horizontal mirroring is probably more preferred because it's a little easier and probably routines are quicker, because you'd only need to split the screen once: leave the tiles and attributes that make up the status bar at the bottom of the lower-most nametable, and just "emulate" single-nametable mirroring by writing everything twice, once to each nametable, but make sure to add a check in the routine to make sure the statusbar tiles don't get overwritten. This is what I'm doing for JQ, and I've seen a bunch of other games do this, or something similar.


Top
 Profile  
 
PostPosted: Sat Dec 18, 2004 5:09 pm 
Quote:
So (in a non-ExGrafix environnement) Vertical mirroiting is fine, but your scrooling routine must be quick and structurated while scrooling vertically like FF3, right ?


Yes, I believe you understand that correctly. In vertical mirroring there is no "off the screen" tiles vertically (aside from the 8 pixels bottom and top, which the NTSC fortunately cuts off, and because of this, clean vertical scrolling is possible if you make it quick and precise in proportion to the scrolling, you can make it scroll vertically with absolutly no graphic glitches (lke FF3j does)).


Quote:
And I guess Horizontal mirroiting would have some gliches while scrooling horizontally, but it's the only way to have a permanent status bar while scrooling vertically, like Double Dragon and Cronicles of the Rydia War.


It is possible to have almost no graphical glitches if you use the 8-pixel background clipping. SMB3 uses this for example (many many games also do). Now it has some graphical glitches when scrolling horizontally (if you scroll left look at the right most 4 pixels of the screen and picture data for the left of the screen will appear, if you scroll left 2 pixels that were once on the left part of the screen appear on the right), also since attributes are 16x16, it has graphical color glitches (MMC5 ExGrafix mode you don't have to worry about that). Although the little graphic glitches on the rightmost ~4 pixels don't show up in some TVs (mine for instance), as some TVs cut off some (I guess around 5) of the rightmost vertical lines.

It is possible to have vertical mirroring and a permantant status bar it's just a lot harder to do and although it looks better many developers figured it wasn't worth it. You see there'll be a status bar at the end of the nametable in games like Krusties Fun House, so if you scrolled down naturally the statusbar would scroll up, but then that would be worthless. So it needs to use MMC3 IRQs to then get rid of the status bar where it normally would be because of scrolling and switch it with level grapphics and then near the bottom of the screen use another IRQ to switch the status bar in. It works nicely, but is a whole mess of work to execute.

Quote:
For my MMC5 game, I'm planning to use 2x2 metatiles with 2 bytes per tiles, the low one for name table and the high one for the exgrafix table, so this would be 14 bit of adress and 2 bits of color for each tile. The reason for using 2x2 is the collison thing, but I'm in trouble about it. It would be 1 bit per metatile, or may more.


That seems alright, but your collision detection should probably be a little more complex if it's going to be an RPG. 1 bit for each 16x16 metatile would sort of get boring eventually. Look at FF3j for instances, that game is probably the most interesting conventional RPG I've ever played on the NES (aside from Lagrange Point, but unfortunately I can't read Japanese). It has awsome beatifully detailed backgrounds, but also allows you to do many things with the background (like go though it and such). If your going to make an MMC5 rpg, you should at least try to put some more depths in it to keep it interesting, but that's only my opinion.

I mean you really don't have to go with super compressed everything. The 16x16 metatiles cut the rom storage of nametable by half (that's good), but collision mostly deals with RAM. The MMC5 has plenty of RAM (depending on the board) so you shouldn't have to worry about only using 1 bit per 16x16 tile. Let's see a 16x15 screen (each tile being 16x16) with 1 bit per tile collision means you would only need 30 bytes for collision detection. Even with an EKROM board that hardly anything. You could have a full byte per tile witha 16x15 screen and still only use up 240 bytes (which is still hardly anything if you use any board besides ELROM).



Quote:
Any way of compression is welcome (I'm not going to have 1MB of PRG, at least 512kb cause I'm not sure of the accuracy of this, and the CHR thing can't go above 256kb with ExGrafix mode).
If I could, I'd like to copy and change a bit Just Breed's scooling code.


I believe you wanted to try to get your game similar to Just Breed right? You said something in another post about wanting to updat the ExRAM fully every frame right? One thing, Compression usually = Slower. If your going to do compression your going to have to draw the line somewhere between speed and memory :-)

It's true that 1MB of data for each CHR and PRG is not proven, but 512KB for each PRG and CHR ROM was used in the MMC5 game Metal Slader Glory, so at least that much is surely possible. It's true that ExGrafix background (as far as we know) cannot go past 256KBs, but such a limit is not existant with sprite graphics (unless you use 1KB bankswitching, any other bankswitchings fine). You could have 512 KBs of data with the first 256KBs for ExGrafix mode and the second 256KBs for sprites (either 8x16 or 8x8) and other data (if you needed to squeeze more nametable data or something you could do that as I don't think you'll need a full 256 KBs jst for sprites :-)

I guess it's possible to do "use" Just Breed's scrolling routine, but you'd have to figure out all lot about the ROM itself and either try to rip it out or recreate it. I don't see why you simply couldn't make your own scrolling method...possibly even supperior to Just Breed's (it had unneccessary graphic glitches on the rightmost 8 pixels when scrolling horizontally IIRC). Try coding some simple scrolling + updating nametable techniques and you should be able to code something better than Just Breed's eventually.

Quote:
One cool thing would like to change the BG palette wile scrooling to have more colors in one big map, but not all at the same time (Double Dragon does this).


Actually that'd be pretty cool, but you'd have to be careful. I believe Just Breed does this with some of it's sprites IIRC.

Quote:
Also, I noted how the talking aera is done in FF1. It writes the window just in the opposite name table, then invert the $2000.0 bit midframe to switch the used name table. A similar thing will be used later in FF6, CT, etc... I'm gonna to have an effect like this in my game.


That's possible, but with ExGrafix mode, it wouldn't be entirely possible (not like FF1s where Nametable A and B were completely independant of each other, in ExGrafix mode Nametable A and B are only independent in the case of the lower 8 bits and that's it).

Theres many ways too do something like text displaying. I believe the best way to do is simply writing on the screen like FF3j does, it looks the best and works just fine (in ExGrafix mode this is entirely possible).

Some text display methods:

1)Lagrange Point: Use IRQ at bottom part of screen to switch from 1-screen mirroring nametable A to 1-screen mirroring nametable B plus it switches background tiles from graphics to text. this is useful if you don't want text taking up a whole mess of the background pattern table, but still having a whole mess of text characters to choose from. I'm not sure exactly how the storing of the text characters went, but I believe it had somethink to do with an unused 1KB of sprite CHR-RAM was bankswitched in when the IRQ was triggered (since LP had 8KBs of CHR-RAM 4KBs of Sprite CHR and 4KBs of Background CHR). This was useful for LP to be able to display more graphics and have lpenty of text graphics at the same time, but MMC5 ExGrafix mode has no problem with this because it can display 16384 tiles on the same screen anywhere it wants. You could do this if you wanted to though. Just have an IRQ triggered near the bottom of the screen. You would just write bytes into nametable B during VBLANK and then when the IRQ is hit turn ExGrafix mode off, switch to single screen mirroring table B, and bankswitch to the proper bank of CHR that contains text. (Note: That is only one way to do something like that, you could be more creative and leave ExGrafix mode on use an IRQ to turn on split mode fullscreen and write the bottom of EXRAM with the text data and have split modes bank contantly set to the CHR bank od text). So basically this is remotely useful if you wanted to store text in the 2nd 256KB area (which ExGrafix can't reach), and display it on screen with ExGrafix, but generally you wouldn't need to do this unless you were pressing for more graphic space for some reason.

2)FF3j anf FF2j: Simply write to an area of nameable RAM with the text data in VBLANK. This is probably best suited for Exgrafix mode since there won't be any sacrifices to the background graphics seeing as you'll need to store the the text somewhere in the CHR and ExGrafix mode can access the first 256KBs. FF3 and 2j had to make sacrifices and stored the text data within the second pattern table almost always (aside from the world map where text wasn't displayed), but using ExGrafix mode there will be no sacrifices since it can access so many tiles. This method seems popular for RPGs because it looks clean (as does method 3 and 4).

3)FF1: Storing it in nametable B and then switching nametable display via $2000. Not entirely impossible, but not entirely suited for ExGrafix mode. Useful if you wanted to easily phase it in at a scanline level (like FF1 does). OK, a way to accomplish this would be too...In VBLANK write the low bits of the text and then switch it in the VBLANK after you write the high bytes. Actually that might not work like you want too. I guess one way too do it would be to use IRQs + timed code (leaving slack for the marigin of error) to switch things around in the middle of a scanline to achieve the effect (it would work only a little different from method 4, if you really need to achieve this ask me and I'll explain it more).

4)Fire Emblem Gaiden: This game has the text box borders already in the graphic area, but not the text characters. So it puts most of the border of the text box and when it reaches a certain point (with timed code) it switches CHR from graphics to text in the middle of the scanline and back at the. I really didn't study it much so I could be wrong about this, but that's the way it looked to me. This method makes it very clean looking just like FF3j, but doesn't suffer from losing 1/4th of the pattern table to text data so that the graphics suffer. With MMC5 ExGrafix mode, this is also unneccessary, just do it the way FF3j does it and you'll be fine since ExGrafix compensates making so that there is practically no loss (unless you wanted to use the LP method (above)).

5)Use split mode. Granted it would look very odd and be very unique it is quite possible. Just write to the EXRAM of text you'll be displaying and then put it on screen (making sure to switch the split mode bank to a CHR bank with the text graphics).


So:

Raw Nametable writing: Useful as it looks clean and is easy to use with no graphic glitches.

Midscanline changes: Useful as it looks clean (if done right) and gives you more tiles to choose from when drawing regular background with almost no graphic glitches (if done right, and giving it slack for marigin of error that will almost defintly occur).

Change at a certain scanline: Doesn't look as clean, but it's easier to do than midscanline changes + it gives almost the same benefits.


Top
  
 
PostPosted: Sat Dec 18, 2004 5:44 pm 
Offline
User avatar

Joined: Sun Sep 19, 2004 10:59 pm
Posts: 1390
J2 wrote:
4)Fire Emblem Gaiden: This game has the text box borders already in the graphic area, but not the text characters. So it puts most of the border of the text box and when it reaches a certain point (with timed code) it switches CHR from graphics to text in the middle of the scanline.


Not quite. Fire Emblem [Gaiden] uses the MMC4, which supports CHR switching the same as the MMC2 - when the PPU fetches tile 0xFD it switches to one bank, and when it fetches tile 0xFE it switches to another bank. Thus, the text boxes simply have one tile on the left side and another tile on the right side, allowing it to use around 500 different background tiles on one screen without having to use any special timed code. Note that this works for both background AND sprites, just as with the MMC2.

_________________
Quietust, QMT Productions
P.S. If you don't get this note, let me know and I'll write you another.


Top
 Profile  
 
 Post subject:
PostPosted: Sat Dec 18, 2004 6:46 pm 
Quote:
Not quite. Fire Emblem [Gaiden] uses the MMC4, which supports CHR switching the same as the MMC2 - when the PPU fetches tile 0xFD it switches to one bank, and when it fetches tile 0xFE it switches to another bank. Thus, the text boxes simply have one tile on the left side and another tile on the right side, allowing it to use around 500 different background tiles on one screen without having to use any special timed code. Note that this works for both background AND sprites, just as with the MMC2.


Ahhh, yes your right. I was looking over some RPG games hoping to find some new text rendering methods to suggest and I started playing FE: Gaiden. I had completely forgotten the game was an MMC4. Looking at the game, it seemed it switched banks in the middle of the scanline and the switched back near the end to have the text box in the middle of the screen with the graphic outside of it. Since I'd forgotten that it was an MMC4, I immediatly assumed that it was using IRQs + timed code (or pure timed code with sprite 0,but since I was thinking it was an MMC3 I thought it had a scanline IRQ generator) as that would be the only way to get that working cleanly (since I was thinking in terms of MMC3 at the time). Hmm, that's a pretty cool way to display text, so thx for correcting me :-)

I don't know much about the MMC4. When exactly does the bank switch? Is it switched when the tile is drawn or fetched? For example tile $FD. If it is the 3rd tile to be drawn on a scanline wouldn't it be fetched at the beginning of the scanline (I believe that's how the PPU accessing goes...)? And if it is would it change the bank when it is fetched (at the beginning of the scanline) or when it's drawn (the 3rd tile).

Well, I know some games do something like change the CHR bank midscanline for text boxes, which are not MMC2/4. I believe Marble Madness is one, and I believe Mother (J) does something of the sort to display english characters + japanese characters on the screen at the same time.


Top
  
 
 Post subject:
PostPosted: Sun Dec 19, 2004 1:13 am 
Online
User avatar

Joined: Fri Nov 12, 2004 2:49 pm
Posts: 7235
Location: Chexbres, VD, Switzerland
J2 wrote:
I don't know much about the MMC4. When exactly does the bank switch? Is it switched when the tile is drawn or fetched?

When Pattern table data $fdxx is read, so when it's drawn.
Thanx for all your contribution :wink:
I guess I'll use FF1 drawing method. I'll do a IRQ or something, then turn off ExGrafix mode (attribute table shall be full of $FFs), turn off sprites via $2001, then change nametable displayed via $2000 or $5104, and may set up a new scrooling via $2005, $2006, $2006, $2005. At the end of the window part, the exact opposite should be done (ie. recalculate map's scrooliong, re-set normal name table, turn on sprites and turn ex-grafix mode on). This can look a bit complex, but it's the only way to can scroll while having a windows text on the screen, like Chrono Trigger does (this will work only whith 1-screen mirroiting). So, while cloosing the window, I don't have to re-write a huge part of the name table and ex-grafix table, data won't be erased.
May the standard method (FF2, FF3, JB, DW, etc...) would also be fine if I want a window smaller than the whole width of the screen. I'll take a decision later about this, I'm now programming the menu sub-screen, and I've already to redo my code with new SnowBro's assembler, scince it's now using NESAsm, and it's not usefull. Unfortunately, SnowBro's assembler is too much complex, I hope I'll got it easily.
Quote:
Look at FF3j for instances, that game is probably the most interesting conventional RPG I've ever played on the NES (aside from Lagrange Point, but unfortunately I can't read Japanese). It has awsome beatifully detailed backgrounds, but also allows you to do many things with the background (like go though it and such). If your going to make an MMC5 rpg, you should at least try to put some more depths in it to keep it interesting, but that's only my opinion.

Yeah, you're *very* right. From my wiewpoint, FF3j is for sure the better game ever released on the Famicom.
So, I can do 1byte per metatile to code this in a simpler way. So every metatile would have pointer to 9bytes data, and the actual reference would be different for every kind of map. One header byte that tells the collison thing, etc..., then 4 words for the 4 tiles to write to NameTable data. (this is similar to the SNES SPC's BRR samples compression, heh)
So in the header byte, one bit tells if it's walkable at Z index 0, oneother tells the same with Z index 1 (ff3 does something like that sometimes), two bit would say if the hero is above or behind the BG for two different Z index, and I reserve one whole nybble for a later usage (stuff like special events if the hero walk on this metatiles, but I don't know how to code something like this. Also to have special battles on special places like FF1 behind chests would be fine).
So this is already better than Just Breed. I may add lava that'll reduce party's HP like FF1, or may the hero will be able to jump over obstacles, or use weapon/items on fieldscreen. I'll decide this later.
Also, have different kinds of map would be a cool thing. For example, the overwold map is very large, and you'll be able to walk, go on ship, air ship, flying dragon, etc... But there will be only one Z index. In a town, map will be smaller, you can just walk, but there will be mode Z index. In a cave/dungeon/moutain/etc..., there also will be battles and enigmas that won't happen in a village.
You give me a lot of ideas. I could have two software map layers, I belive castlevania 1&3 does this.
Quote:
Actually that'd be pretty cool, but you'd have to be careful. I believe Just Breed does this with some of it's sprites IIRC.

Just Breed sprite's mazing system is very special. The palette is calculated every frame after drawing sprites. I don't know exactly how it works, but I guess every sprite thing has a palette on it, and the programm automatically assign a palette number on it (I don't know how explain this stuff)
I've a great idea to change the BG palette while scrooling. In the huge overworld map, monsters can vary. So the map has different "regions" with it's own partial palette, and monsters type and frequency of battle.
For example, I've got a desert to the south, a forest in the middle and snow moutains to the north. I'm in the fortest, and all forest monsters are loaded. While walking south, the scrooling programm will "detect" the comming desert, write a yellow palette in a place that the forest don't use and load desert monster while the player is walking in desert aera. If the player get back to north, the scrooling programm wil detect the comming moutains, overwrite the yellow palette with a blue/white one, and then load snow monsters while walking on snow aeras.
Quote:
I believe you wanted to try to get your game similar to Just Breed right? You said something in another post about wanting to updat the ExRAM fully every frame right? One thing, Compression usually = Slower. If your going to do compression your going to have to draw the line somewhere between speed and memory

Heh, the map will be decompressed into SRAM like *every* RPG as far I know. So that would just be slower while loading the map, isn't it ? Just the overwold map will be larger, then may I wont compress it and read it direcly from ROM aera.
The segond advantage to load the map in SRAM is to be flexible. For example, tresaurure chests have different graphics when they are closed or oppened, and additionally the event isn't the same while pressing A next to them. The oppened chest will reder a "empty" message, but the closed one will write, for example "Found : Potion" and increase your potions counter, then turn it into a opened chest. I'm not sure if I'll draw chests as sprites (easier to code) or bg (more usefull graphically).
Quote:
It's true that 1MB of data for each CHR and PRG is not proven, but 512KB for each PRG and CHR ROM was used in the MMC5 game Metal Slader Glory, so at least that much is surely possible. It's true that ExGrafix background (as far as we know) cannot go past 256KBs, but such a limit is not existant with sprite graphics (unless you use 1KB bankswitching, any other bankswitchings fine). You could have 512 KBs of data with the first 256KBs for ExGrafix mode and the second 256KBs for sprites (either 8x16 or 8x8) and other data (if you needed to squeeze more nametable data or something you could do that as I don't think you'll need a full 256 KBs jst for sprites

I use 1kb sprites swapping. This would be more flexible while fignting, 1kb per playable character+4kb for monsters and animation. I'll also drawn character&monster graphics in BG while they're not moving, though. But battle will come after map scrooling in my plannig, so I don't worry about that yet. 256kb is enough anyways. I prefer limit sprites to have greather BG (let's say 33% of sprites and 66% of BG graphics in 256kb would be enough).
I firstly was planning to have only 256kb of PRG rom divided into 32 8kb banks with the following structure :
Bank 0-7 -> Map graphics (+map code)
Bank 8-15 -> Dialog box data (+text code)
Bank 16-23 -> Music data
Bank 24-25 -> Monster+Battle data (+battle code)
Bank 26-28 -> Sound effects
Bank 29 -> Sound code
Bank 30 -> Menu code+single subroutine code
Bank 31 -> Main code

I could need mode, but I don't know how I'll be able to full 512kb of PRG rom. Let me guess how the 64 8kb banks would be organized.
Bank 0-15 -> Map graphics
Bank 16-23 -> Dialogue box data
Bank 24-27 -> Monster data
Bank 28 -> Battle SFX data
Bank 29-31 -> Sound effects datad
Bank 32-40 -> Music data
Bank 41 -> Menu/battle data
Bank 42 - 58 -> I've to found additonal stuff to put in there
Bank 60 -> Battle code
Bank 61 -> Sound code
Bank 62 -> Menu code+single subroutine code
Bank 63 -> Main code
Quote:
I guess it's possible to do "use" Just Breed's scrolling routine, but you'd have to figure out all lot about the ROM itself and either try to rip it out or recreate it. I don't see why you simply couldn't make your own scrolling method...possibly even supperior to Just Breed's (it had unneccessary graphic glitches on the rightmost 8 pixels when scrolling horizontally IIRC). Try coding some simple scrolling + updating nametable techniques and you should be able to code something better than Just Breed's eventually.

Yeah, but I'm sure that Just Breed scrooling code would work on a real hardware. If I do my own thing, I'm note sure it will. MMC5 is complex and Just Breed has insinifiants writes to $5800. May my scrooling code could bug beacause I don't write to this register or somthing like this.
I'm already ripping Just Breed sound code for my game, and it's great (but too much complex sometimes). It's not far to use the whole NES ram ($3c0-$6bf !!) to have 9 independant software channels.

_________________
Life is complex: it has both real and imaginary components.


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

All times are UTC - 7 hours


Who is online

Users browsing this forum: Bing [Bot] and 3 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