It is currently Sun Oct 22, 2017 7:43 pm

All times are UTC - 7 hours





Post new topic Reply to topic  [ 35 posts ]  Go to page Previous  1, 2, 3  Next
Author Message
 Post subject:
PostPosted: Sun Dec 19, 2004 3:22 am 
Offline
User avatar

Joined: Fri Nov 12, 2004 2:49 pm
Posts: 7234
Location: Chexbres, VD, Switzerland
I've just traced the code of Hanjuku Hero while opening a menu window, and I noted it reads the VRAM attribute tables, then change it to set the good window attribute (this could cover a half of one byte, for example) then re write it to the VRAM while writing window tiles.

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


Top
 Profile  
 
 Post subject:
PostPosted: Thu Dec 23, 2004 2:09 am 
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 :wink:


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.


Top
  
 
 Post subject:
PostPosted: Thu Dec 23, 2004 1:47 pm 
Offline
User avatar

Joined: Fri Nov 12, 2004 2:49 pm
Posts: 7234
Location: Chexbres, VD, Switzerland
Quote:
You'll have to swap NameTable B into PPU space via $5105 in VBLANK and then write to it and then swap back.

I don't see exaclty what do you mean here.
I think I'll do different kind of text boxes and use an apropriate one.
Quote:
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?

Yeah, it seems good exept for instruction like lda [$xx],Y that will bugs in the eventual rom if you don't set two different variables for the word $xx.
So the automatic-ram assigment is pretty bad beacause :
1-When debugging your game you'll be lost if you don't know wich RAM adress is wich variable in your code
2-You can't mix up user defined and linker defined-variables, beacause the liker could use a memory already used by you, exept it you don't declare this part of ram.
3-You can't know witch data would be in SRAM and not, so your saved things could be assigned out of SRAM and that would be a shame.
Also, anonnymous macros didn't work at all in my current experiences.
Quote:
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.

Nah, the original one, as far played with a emulator, is really better. Scince Square released games like Kingdom Earths and fusionned themselves with Enix, I think I won't buy anything for Square anymore. They were an exellent game company, but now they aren't. They does this just for money. Also, why don't they release a Just Breed remake on the DS, GBA, PS2 or something ? This won't make enough money of course.
Quote:
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.

I guess one background map that won't really a map shall be loaded to draw landscapes etc... So if the "normal" map has a metatlise such as blank, unused and unwalkable, an "automatic landscape" would be written to the name table rather than blank tiles. So, this would be usefull to have optimal data in moutains and tower-like stuff. This would not be used at all in a village, in a cave or on the overworld, but another stuff will "replace" it.
Quote:
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.

This is primilary a good idea, but not very usefull on fieldscreen. I guess I'll use something like that in battles to store animation data in a easier way. It'll just have color gliches if 5 sprites palettes are loaded at the same time, but it's not worse than 8 sprites-cycling.
Quote:
So why do you need to pre load everything? Theres nothing wrong with it, I'm just wondering why.

Errr.... I firstly have to design my battle system. I just noted in my mind that palette and monsters regions *could* be similar.
Quote:
Writing a new palette while detecting the oncoming area would defintely be a good idea though.

Yes, but that won't be that simple to code. You have to don't use a palette at lease in a 32*28 tile region (of course in pracice more space is needed), and this would be hard to do both vertically and horizontally.
Quote:
I just meant you don't have to compress it so much like you were originally doing with the background collision detection.

To have more time while changing map region is totally insinifient, scince the screen will be turned off, so I've not to worry about time.
I guess a LZSS compression on data already compressed by RLE would be the thing.
Quote:
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.

I don't know how to read other data on a CHRROM chip....
I'll take the 256k/512k decision later.
Quote:
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.

I guess I'll first watch how all the hardware part of Just Breed's scrooling code works, and them rewrite one similar with hardware registers, but softwarely different to increase chances to get something working. I guess someone should try to update the whole JustBreed gane on a devcard and replaces writes to $5800 for nops to see wat happens. I'll do this when I'll be able to found one of thoose damed Koei games to destroy them and make a devcard.

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


Top
 Profile  
 
 Post subject:
PostPosted: Fri Dec 24, 2004 2:39 am 
Quote:
I don't see exaclty what do you mean here.
I think I'll do different kind of text boxes and use an apropriate one.


I meant you can't normally write to the other nametable unless it's swapped in via $5105. Yeah, try to make it look good (and make it easy to read).


Quote:
Nah, the original one, as far played with a emulator, is really better. Scince Square released games like Kingdom Earths and fusionned themselves with Enix, I think I won't buy anything for Square anymore. They were an exellent game company, but now they aren't. They does this just for money. Also, why don't they release a Just Breed remake on the DS, GBA, PS2 or something ? This won't make enough money of course.


Well, it's the exact same game just with better graphics + some cool new scenes. You mean they released "Kingdom HEARTS." Squaresoft released that game and I think it's pretty good. It's actually a real fun game even though it has Disney characters. I think it's an intresting combination that was actually done well.

As for Square Enix making bad games (as opposed to Squaresoft), I think it's sorta true. At first I think they tried to live off both the companies repuations and starting to make some horrible games thinking they'd sell (Elemental Saga...). Maybe since they fused it gave them more money to blow so they tried different kind of games to see how they'd sell. I personally think the games will get much better. FF1 and 2 remakes for the playstation was actually pretty amazing :-)


Quote:
I guess one background map that won't really a map shall be loaded to draw landscapes etc... So if the "normal" map has a metatlise such as blank, unused and unwalkable, an "automatic landscape" would be written to the name table rather than blank tiles. So, this would be usefull to have optimal data in moutains and tower-like stuff. This would not be used at all in a village, in a cave or on the overworld, but another stuff will "replace" it.


I think I understand what you mean. That might not be a bad idea, you should try it.

Quote:
This is primilary a good idea, but not very usefull on fieldscreen. I guess I'll use something like that in battles to store animation data in a easier way. It'll just have color gliches if 5 sprites palettes are loaded at the same time, but it's not worse than 8 sprites-cycling.


Overlapping sprites with different attributes allows for many different colors to be in 1 area (12 at most, 13 if counting transparency, and 16 if you count the background colors behind transparency). So you could have an 16x32 "sprite" in the middle of the screen and it could consist of 16 different colors. That'd be a cool demo :-)


Quote:
Yes, but that won't be that simple to code. You have to don't use a palette at lease in a 32*28 tile region (of course in pracice more space is needed), and this would be hard to do both vertically and horizontally.


Wouldn't be simple, but prolly be needed.

Quote:
To have more time while changing map region is totally insinifient, scince the screen will be turned off, so I've not to worry about time.
I guess a LZSS compression on data already compressed by RLE would be the thing.


Yeah, speed is only important when you wanna do things in real time.

Quote:
I don't know how to read other data on a CHRROM chip....
I'll take the 256k/512k decision later.


Just set the bank number of a certain area of PPU space to the CHR-ROM bank you need. And then something like:
LDA #$00
STA $2006
STA $2006 ;set PPU address to $0000 (the first bank of CHR)
;switched via $5120

LDA $2007 ;junk read.....fill buffer
LDA $2007 ;this will store the first byte of ROM * whatever bank is in

Quote:
I guess I'll first watch how all the hardware part of Just Breed's scrooling code works, and them rewrite one similar with hardware registers, but softwarely different to increase chances to get something working. I guess someone should try to update the whole JustBreed gane on a devcard and replaces writes to $5800 for nops to see wat happens. I'll do this when I'll be able to found one of thoose damed Koei games to destroy them and make a devcard.


Really I don't they do anything. That's the only game that writes to them and even though they are unemulated, emulators run the whole game just fine. So don't worry about $5800 and just write any normal scroll routine and I'm sure someone has an MMC5 devcart to test it on :-)


Top
  
 
 Post subject:
PostPosted: Fri Dec 24, 2004 2:42 am 
Quote:
I don't see exaclty what do you mean here.
I think I'll do different kind of text boxes and use an apropriate one.


I meant you can't normally write to the other nametable unless it's swapped in via $5105. Yeah, try to make it look good (and make it easy to read).


Quote:
Nah, the original one, as far played with a emulator, is really better. Scince Square released games like Kingdom Earths and fusionned themselves with Enix, I think I won't buy anything for Square anymore. They were an exellent game company, but now they aren't. They does this just for money. Also, why don't they release a Just Breed remake on the DS, GBA, PS2 or something ? This won't make enough money of course.


Well, it's the exact same game just with better graphics + some cool new scenes. You mean they released "Kingdom HEARTS." Squaresoft released that game and I think it's pretty good. It's actually a real fun game even though it has Disney characters. I think it's an intresting combination that was actually done well.

As for Square Enix making bad games (as opposed to Squaresoft), I think it's sorta true. At first I think they tried to live off both the companies repuations and starting to make some horrible games thinking they'd sell (Elemental Saga...). Maybe since they fused it gave them more money to blow so they tried different kind of games to see how they'd sell. I personally think the games will get much better. FF1 and 2 remakes for the playstation was actually pretty amazing :-)


Quote:
I guess one background map that won't really a map shall be loaded to draw landscapes etc... So if the "normal" map has a metatlise such as blank, unused and unwalkable, an "automatic landscape" would be written to the name table rather than blank tiles. So, this would be usefull to have optimal data in moutains and tower-like stuff. This would not be used at all in a village, in a cave or on the overworld, but another stuff will "replace" it.


I think I understand what you mean. That might not be a bad idea, you should try it.

Quote:
This is primilary a good idea, but not very usefull on fieldscreen. I guess I'll use something like that in battles to store animation data in a easier way. It'll just have color gliches if 5 sprites palettes are loaded at the same time, but it's not worse than 8 sprites-cycling.


Overlapping sprites with different attributes allows for many different colors to be in 1 area (12 at most, 13 if counting transparency, and 16 if you count the background colors behind transparency). So you could have an 16x32 "sprite" in the middle of the screen and it could consist of 16 different colors. That'd be a cool demo :-)


Quote:
Yes, but that won't be that simple to code. You have to don't use a palette at lease in a 32*28 tile region (of course in pracice more space is needed), and this would be hard to do both vertically and horizontally.


Wouldn't be simple, but prolly be needed.

Quote:
To have more time while changing map region is totally insinifient, scince the screen will be turned off, so I've not to worry about time.
I guess a LZSS compression on data already compressed by RLE would be the thing.


Yeah, speed is only important when you wanna do things in real time.

Quote:
I don't know how to read other data on a CHRROM chip....
I'll take the 256k/512k decision later.


Just set the bank number of a certain area of PPU space to the CHR-ROM bank you need. And then something like:
LDA #$00
STA $2006
STA $2006 ;set PPU address to $0000 (the first bank of CHR)
;switched via $5120

LDA $2007 ;junk read.....fill buffer
LDA $2007 ;this will store the first byte of ROM * whatever bank is in

Quote:
I guess I'll first watch how all the hardware part of Just Breed's scrooling code works, and them rewrite one similar with hardware registers, but softwarely different to increase chances to get something working. I guess someone should try to update the whole JustBreed gane on a devcard and replaces writes to $5800 for nops to see wat happens. I'll do this when I'll be able to found one of thoose damed Koei games to destroy them and make a devcard.


Really I don't they do anything. That's the only game that writes to them and even though they are unemulated, emulators run the whole game just fine. So don't worry about $5800 and just write any normal scroll routine and I'm sure someone has an MMC5 devcart to test it on :-)


Top
  
 
 Post subject:
PostPosted: Sat Dec 25, 2004 3:54 am 
Offline
User avatar

Joined: Fri Nov 12, 2004 2:49 pm
Posts: 7234
Location: Chexbres, VD, Switzerland
Quote:
I meant you can't normally write to the other nametable unless it's swapped in via $5105. Yeah, try to make it look good (and make it easy to read).

Ah, I undersand now. For example having $11 loaded into $5105 (so inversed vertical mirroiting), write to the PPU nametable will do it exactly the same as a normal vertical mirroiting, right ?
So here you are my guess :
While walking/staying on normal fieldscreen, mirroiting is single ($00) and no midframe changes will ocurs, ExGrafix are enabled via $5104.
Scince a box message opens (one who can be scrooled), the mirroiting is turned into vertical ($44) and all data is written to the segond name table.
When all data is written, the midframe IRQ will be enabled, and the mirroiting will turn back to 1-screen mirroiting in VBlank.
When an IRQ occurs at box's begining scanline-1 (this scanline will change to make a cool effect like FF1, CT, etc...), wait for HBlank with a few nops.
Then I have to :
-Turn off ExGrafix rendering (write 2 to $5104) scince the text box should not be affected by the bg's attribut in the other name table.
-Change horizontal scrooling to #$00 (may the vertical one should also be changed).
-Change mirroiting for #$55 or (only the segond name table is shown)
-Wait for the end of boxes with timed code or something
-Change mirroiting again for #$00 (1-screen mirroiting)
-Re-set the horizonzal scrooling to it's original value
-Turn on back ExGrafix rendering (write 1 to $5104)
So scince all data is written to the segond nametable, the screen will be able to scroll again with 1-screen mirroiting, and the segond nametable won't be affected (it'll just be shown midframe).
The only problem is that the segond name table shold be write only once at time, so for example a long message would stop scrooling evertime you need to change the text.
Tell me if you found something wrong.
Quote:
It's actually a real fun game even though it has Disney characters. I think it's an intresting combination that was actually done well.

It's just a awfull crap stuff. I like disney and I like Square, but both CAN'T go together. Don't talk about it anymore, please.
Quote:
I personally think the games will get much better. FF1 and 2 remakes for the playstation was actually pretty amazing

I can't know scince they're not released in europe, but the game boy version will be released in europe. I play to FF1 and 2 in NES emulators anyways.
Quote:
Wouldn't be simple, but prolly be needed.

Yeah, I guess it would be needed only on the over-world map.
Quote:
Just set the bank number of a certain area of PPU space to the CHR-ROM bank you need. And then something like:

I can't see why I have to store data like this in Chr-Rom, it's longer to read data and I guess this shall be done in VBlank. If I need more data, I'll push up the PRG size to 512kb
Hey, do you know how many emulators does emulate $5130 correctly today ? If many does, I could try push up my CHR size to 512kb (actually for now it's only 16kb, heh)
Quote:
So don't worry about $5800 and just write any normal scroll routine and I'm sure someone has an MMC5 devcart to test it on

I'll watch how Just Breed scrooling code's works hardwarely not for $5800, but for PPU and ExRam writes, and MMC5 registers such as $5104.
I hope someone could test my game, but I've to be sad to don't test it myself, but I've to found a MMC5 game with SRAM and it's very hard to found in europe. I actually don't know if thoose Koei games are relased in europe (hum, Gemfire and Napoléon-L'empreur happens in england-france so they "should" be released here...)

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


Top
 Profile  
 
 Post subject:
PostPosted: Sat Dec 25, 2004 4:33 am 
Offline

Joined: Mon Nov 22, 2004 3:24 pm
Posts: 162
Location: Sweden
Why do I get the feeling that Bregalad and J2 has teamed up to conquer the universe by breaking the world record of submitting many long posts in a row?
Hopefully this will stop your evil scheme once and for all!

I guess I'll just have to fetch some coffee before reading though the new entries..


Top
 Profile  
 
 Post subject:
PostPosted: Sat Dec 25, 2004 7:10 am 
Offline
User avatar

Joined: Fri Nov 12, 2004 2:49 pm
Posts: 7234
Location: Chexbres, VD, Switzerland
You're right. J2, you'd better email me about that like usual.

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


Top
 Profile  
 
 Post subject: Merry Christmas
PostPosted: Sat Dec 25, 2004 10:08 pm 
Quote:
Why do I get the feeling that Bregalad and J2 has teamed up to conquer the universe by breaking the world record of submitting many long posts in a row?
Hopefully this will stop your evil scheme once and for all!


Uh, word. Um, I guess I do get too detailed. Hmmm, looks like this thread started about PPU mirroring....lol. Looks like I did accidentally double post :? One thing that is good using this instead of e-mail, is that I can be corrected when I give wrong info (which will probably happen when I answer the next question :-)) Anyway, I'll keep things precise and to the point then :-)

Quote:
When an IRQ occurs at box's begining scanline-1 (this scanline will change to make a cool effect like FF1, CT, etc...), wait for HBlank with a few nops.

-Turn off ExGrafix rendering (write 2 to $5104) scince the text box should not be affected by the bg's attribut in the other name table.
-Change horizontal scrooling to #$00 (may the vertical one should also be changed).
-Change mirroiting for #$55 or (only the segond name table is shown)
-Wait for the end of boxes with timed code or something
-Change mirroiting again for #$00 (1-screen mirroiting)
-Re-set the horizonzal scrooling to it's original value
-Turn on back ExGrafix rendering (write 1 to $5104)


Hmm, that will work, but only in an 8-pixel boundary (to match up with nametable entries), that is your "scanline -1" can't be just any scanline (otherwise your textbox will be "cut up"), + you'll have to write to the proper spaces in the 2nd nametable for the textbox depending on where "scanline -1" is.

So, you'll defintly need to change vertical scrolling of the screen "manually" to match the nametable OK, this I might need to go in depth (+ this really isn't my area, so Quietust will almost defintly have to correct me :) ). OK, $2005-w1 (horizontal scroll) will affect the screen while rendering (due to th fact it is used as an offset on a per pixel basis I believe), but $2005-w2 (vertical scroll) works very differently, it is not updated in real time (it doesn't need to be), I believe a specific "counter" is updated before rendering starts and effects the PPU address ($2006 access this), so that it'll start on the right scanline and go on from there. Well, since $2005-w2 isn't updated in realtime, the PPU internal address must be updated manually (which is done by writing to $2006). Anyway, An emulator author could tell you better, but generally it wouldn't be too hard. Just keep your nametable data at the top of the "2nd nametable" and come HBLANK time you'll have to write to $2006 ($00, $00?) to sttart at the text box and then change $2006 back to where it should be at the end :-)

Oh, and about writing to the NT2 for the textbox, it shouldn't take too long to update (what like 6 columns...6x30 = 150 bytes-borders (which are constant) = about 90 bytes), but if it does, span it accross a couple frame.


Quote:
I can't see why I have to store data like this in Chr-Rom, it's longer to read data and I guess this shall be done in VBlank. If I need more data, I'll push up the PRG size to 512kb
Hey, do you know how many emulators does emulate $5130 correctly today ? If many does, I could try push up my CHR size to 512kb (actually for now it's only 16kb, heh)


You don't have too, that was just a simple suggestion in case you run out of PRG ROM SMB1 does this for music data, I believe).

As for $5130. Nintendulator!, Quietust knows everything :-). and as soon as somethings discovered BOOM it's there. Nessie will prolly get updated soon. Fx3 has an emulator, I think he'll prolly update it. Is FCEU Ultra open source? Well, there'll be a few that do, some that don't. I mean it was just discovered 3 or 4 days ago...1 day ago came KHs doc (which had some interesting info, I thought the 8x8 sprite fetching was interesting), and I'm sure Nintendulator will be updated with that info soon also :-)


As for your scrolling routine, try to write one and if it works in Nintendulator (although not perfect, the emulator's very accurate), then ask someone to test it on a MMC5 devcart.

Hehe, I'm goin for 3 pages 8)


Top
  
 
 Post subject:
PostPosted: Sat Dec 25, 2004 10:12 pm 
Offline
User avatar

Joined: Sun Sep 19, 2004 10:59 pm
Posts: 1390
Okay, there's something I really need to point out to Bregalad, something that's been bugging me for quite a while now.

There is no such thing as "mirroiting". The word you are looking for is "mirroring" (derived from the word "mirror").

_________________
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: Eh...
PostPosted: Sat Dec 25, 2004 10:39 pm 
Heh, I was actually going to make a joke about that, but I decided not to + I didn't really mind.I was wandering where he got the "t" from... :?

Oh, BTW. After rereading my comments on changing vertical scrolling midscreen, there wrong. I tried to leave out some details to make it less space, but I left out important ones :?

OK, in HBLANK, you'll need to update $2006-w1 with the hi-address, then update $2005-w1 with the horizontal scroll value, then update $2005-w2 with the vertical scroll value, and then lastly you'll write to $2006 with the low-address. Anyway, you'll prolly need a nice table so that you get the values for all the scanlines and such. All of this has to do with the PPU addressing. Loopy wrote a nice little summary about what the $2005/6 actually update so it'd be good to read that. So, $2006,$2005,$2005,$2006... might need to preload the values into A,Y, and X before HBLANK even starts to get enough time to do everything in HBLANK :-)


Top
  
 
 Post subject:
PostPosted: Sun Dec 26, 2004 3:58 am 
Offline
User avatar

Joined: Fri Nov 12, 2004 2:49 pm
Posts: 7234
Location: Chexbres, VD, Switzerland
I know that the vertical scrooling should be updated differently, I've asked this in another thread long ago (so why do you write theory of 50 pages about this scince it's not the point ?)
I guess I'll change only horizontal scrooling when the main screen doesn scroll, and change both scrooling (0, 0 like you said) when the main bg will be scooling. After all, I've not to wander about thoose little details now.
Quote:
There is no such thing as "mirroiting". The word you are looking for is "mirroring" (derived from the word "mirror").

Oh my god ! Please forgive me.
Quote:
So, $2006,$2005,$2005,$2006... might need to preload the values into A,Y, and X before HBLANK even starts to get enough time to do everything in HBLANK

Yeah, it's still a good idea to avoid gliches as possible.

Nintendulator is a very acurate emulator for developpement, but, I actually guess that people that wants to just play the NES rether than developpiong doesn't like how nintedulator is made because :
1-There is a few option that they won't understand
2-It's very slow
3-Grafics outpout isn't very good (and the top and bottom 8 lines are shown is both PAL and NTSC mode and this will add gliches)

For this reason I decided that my game won't do mid-scanline $2001 changes or anything like that. It shall at least work in FCEU, VirtuaNES and Nestopia. (FCEU emulates very badly the MMC5).
May japaneese emulator like VirtuaNES already emulates $5130 correctly. (oops am I writing long theories just like J2) ?

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


Top
 Profile  
 
 Post subject:
PostPosted: Sun Dec 26, 2004 2:29 pm 
Quote:
I know that the vertical scrooling should be updated differently, I've asked this in another thread long ago (so why do you write theory of 50 pages about this scince it's not the point ?)


I write a "theory" that is 50 pages long (really like only 12 lines) because it is very important for your text box to show properly at any scanline. If you don't always change the vertical scroll at the HBLANK when your text box will display, you will be limited to where you can actually "put" your text box + your code will require more logic to put the text box in at the right spots in the 2nd nametable (vertcically), which will indefintly leave your text box needing to be on the screen at only certain spots to show up properly. I also want to make sure I understand this stuff properly so that if I'm wrong, someone will tell me.

If you always change vertical scrolling then you can always put your text box at the top of Nametable 2 and then whever scanline's HBLANK your currently in wouldn't matter since you could easily change the address pointer exactly to the top of nametable too (your text box), thus no extra logic wouldn't even be needed (where to put the bytes in Nametable 2) + your text box could be displayed on any scanline instead of needing to be a multiple of 8. Also in HBLANK you'll need to change the MMC5s CHR bank register to the "text" bank, but I'm sure you already knew that.

BTW, doynax I don't think especially minds our posts as he, in reality, doesn't have to read them. I think he's just being cool, as in if there something he can post to help, then he will and thats why he's reading the posts I believe.

Quote:
I guess I'll change only horizontal scrooling when the main screen doesn scroll, and change both scrooling (0, 0 like you said) when the main bg will be scooling. After all, I've not to wander about thoose little details now.


You might "want" to change it always as your text box display will be more flexible and easier (above).


------

Yeah, although Nintendulator is accurate, it's slow and not really designed to play NES games...

I believe Nestopia is very accurate. Nestopia can do midscanline rights to $2001 as well BTW. And it's fast :-). It's IRQ timing gor MMC5 is a bit off, but then again so is Nintendulator, so I guess you could have an option in your game, that says playing on "emulator" or "real NES"


Top
  
 
 Post subject:
PostPosted: Sun Jan 02, 2005 11:11 am 
Offline
User avatar

Joined: Fri Nov 12, 2004 2:49 pm
Posts: 7234
Location: Chexbres, VD, Switzerland
I just don't need to change bg scrooling midframe, font tiles would be swapped into $5128-$512b in VBlank and become unused in the field aera beacause of ExGrafix mode.
Also, the 2nd attribute table have to be full of the text's color.
I calculated how much size would my maps take :
Let's say, I've 512 maps of an average size of 64x32 (so 2kb), the calculation is :
32x64x512/1024= 1024 kylobytes !!!
So I hope to have smaller maps, and also advanced-RLE comression can reduce the size a lot, to imput this in a 512kb PRG chip

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


Top
 Profile  
 
 Post subject:
PostPosted: Sat Aug 20, 2005 1:16 am 
Offline
User avatar

Joined: Wed Aug 03, 2005 3:15 pm
Posts: 393
Man, this was a crazy thread...

Alright, so I'm trying to grasp the concept of mirroring here. I take it that it's basically how you're game is going to operate in terms of directions of travel pretty much (that's what I got out of it).

Horizontal >> Scroll Vertically

Vertical >> Scroll Horizontally

Now, what are the games that only travel in one direction, and there's no going back? (i.e. Super Mario Bros., you can't go back to the left) Does that have anything to do with using mirroring? Also, I don't quite grasp this either, from another thread: http://nesdev.com/bbs/viewtopic.php?t=202 :

Quote:
It means where 2 addresses point to the same memory location.

The main example is with the nametables. There's addresses for 4 nametables, but normally only memory for 2 of them. "horizontal mirroring" would mean that writing to (VRAM) $2000 would be the same as writing to $2400. Or with vertical mirroring, writing to $2000 and $2800 would be the same.

It also applies to the NES's RAM ($0000-$07FF). Writing to $0900 would be the same as $0100.

I hope my explanation makes sense.


Since mirroring is used you get all four nametables in memory that can be used... I guess... (I'm still not understanding, I'm not even sure if I know what I'm trying to ask here... :? ) I suppose I should ask what a nametable exactly is, since I can't seem to find a file anywhere that has basic definitions.... or is a nametable something that I'll learn about in my book?

Sorry for the blob of crap I just posted, but I am confused on mirroring and the whole concept, and can't quite come up with a way to ask about it :oops:


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

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