Quote:
When Pattern table data $fdxx is read, so when it's drawn.
I figured as much, but wasn't sure. Thanx
Quote:
Thanx for all your contribution
No problem
Quote:
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.
Oh, so you want to scroll while the text iis displayed (like CT). Yeah, it would be much easier to have the text box full screen width (like Lagrange Point, although I believe you want it to be more like Crystalis (without the graphic glitches) right?), unlike FF1s text box. Yeah, you could make it work. So you want to sub it in 1 scanline per frame or something (like FF1 does)?
You'll have to swap NameTable B into PPU space via $5105 in VBLANK and then write to it and then swap back. Then use an IRQ at the appropriate line to start the text box rendering. Now MMC5 IRQs trigger at the beginning of the scanline # in $5203, which leaves you with at best 8 pixels offscreen (factoring in the random delay
(DMC sample loading or the CPU is currently finishing an instruction) in the IRQ actually being triggered in the CPU as opposed to the MMC5 triggering the IRQ). That's if you have PPU leftmost 8-pixel clipping on.
Now even with the full 8 pixels offscreen (which would be rare to even have that much), that wouldn't give you anytime to modify anything (giving you 2 2/3 CPU cycles to work with) before onscreen pixels. So, you'll prolly have to make the IRQ trigger the scanline before the textbox and then wait for 86 CPU cycles (might get away with 85, but it depends on the situation). You can then use ~30 cpu cycles (HBLANK + beginning of the next line 8-pixels, also there will the random IRQ delay) to modify the registers that you need (which should be enough time with self modifying code).
If you need more time, you could just use timed code and (once the IRQ triggers) wait for 59 cycles (more if the values you need arn't in $00xx, zero page) and then LD- X, A, and Y with their values and by the time that's done you'll be in HBLANK and it'll be safe to write to the MMC5 regs.
Quote:
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.
You could do that too. I doubt anyone will complain, but I myself think that the game scrolling while the text box is onscreen (like CT) would be cool. I guess it's not impossible for the text box to have a width less than the whole screen + playfield scrolls regular, but generally it would be too hard + not worth it + no one would care.
Switching away from NESASM might be good. Although it's not such a bad assembler (it does have a few perks when dealing strictly with NES programming), it's got a few annoyyances. Is SnowBro's assembler pretty good?
Quote:
Yeah, you're *very* right. From my wiewpoint, FF3j is for sure the better game ever released on the Famicom.
Of course, I was amazed by FF3j, it was truly a masterpiece for the NES. There's supposed to be a redone FF3j for the Nintendo DS, that should be interesting.
Quote:
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).
Yeah, 1 byte would be faster (no need for a bit checking routine) + it would allow the player to interact more with the background (granted you code it too). 256 different collisions is a bit much, but it still doesn't take up that much memory if your using metatiles (240 bytes is nothing with an extra 8K onboard RAM).
Yeah a different reference for the collision depending on the map (overworld or in town/dungeon) would be interesting. Like how you can't swim in water in FF3j overworld, but can in towns and dungeons (is that what you mean?).
What do you mean you don't know how to code something like "if hero steps on certain tile then event occurs." If you already can detect what tile the hero is going to step onto then just use the value when he actually steps onto the tile + you can use the another index for what dungeon + what screen he's on to trigger something like that also
Quote:
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.
Yeah, JB's collision detection wasn't too complex (can walk on, can't walk on, enter house, maybe more, the battle system had more). It was still a fun enough game though.
You should prolly decide the more important aspects of the game first and then decide this. Using, item/weapons on fieldscreen might be cool if you can incorporate it well. Heh, walk on lava and melt.
Quote:
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.
Yeah, I get what you mean. Using a "Z index" would probably be pretty cool, it'd make the game more interesting. Mother (J), doesn't have an overworld map and thus it's random battle occur whether your within a certain area on the map or not, I thought that was pretty interesting.
2 software map layers? I know you mean having 2 maps of the same area in ram (with different data), but I don't exactly understand what you'd use them for. I understand what your getting at, but not how you'd use it.
Quote:
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 looked at how it messed with the palette under certain conditions and it did things oddly, although I believe it was for having more sprites with different colors on the screen at once.
Quote:
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.
I don't think it'd hurt to load monsters once the random battle occurs (based upon the type of tile your standing on). You could turn the screen off and have plenty of time to mess with whatever you want. If you took 2/60 seconds to load everything for the battle I'd be suprised. I guess the only reason you'd pre load everything, would be to try and hurry to update everything in 1 VBLANK and instantly go to the battle screen (with no blank screen at all). Other than that there'd be no reason (even if you took a whole frame with the screen off it'd be only a little noticable). So why do you need to pre load everything? Theres nothing wrong with it, I'm just wondering why.
Writing a new palette while detecting the oncoming area would defintely be a good idea though.
Quote:
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).
I didn't mean don't decompress it into SRAM. You should defintly compresss it and use the onboard SRAM to store it. I just meant that the more you compress the data the longer it'll take to decompress it into SRAM and thus make the game spend more time decompressing it than doing anything else (although you'd have more memory). I just meant you don't have to compress it so much like you were originally doing with the background collision detection.
Quote:
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
Yeah, 256KBs for prg and chr rom is probably enough, that was just a suggestion if you ever found you needed more CHR data (or data in general as you could easily store other data in the CHR-ROM chip (SMB does something like that I think)). Using either 256KB or 512 KBs of PRG ROM, I guess depends on how big your game's gonna get.
Quote:
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.
Your right, Just Breed's scrolling routine will defintly work on real hardware, but that doesn't mean you can't try to make a better one. You probably don't have to worry about $5800, because the Koei games never used it and I think they scroll sometimes (although it's rare), and they use ExGrafix mode. You could easily just copy the "$5800" code if your worried about that. Just Breed's scrolling looked horrible on the rightmost column of the screen when you scrolled left.