It is currently Fri Nov 24, 2017 11:41 am

All times are UTC - 7 hours





Post new topic Reply to topic  [ 279 posts ]  Go to page Previous  1 ... 15, 16, 17, 18, 19  Next
Author Message
PostPosted: Fri Mar 20, 2015 6:54 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19256
Location: NE Indiana, USA (NTSC)
What's the "true address of the read" in Contra or Castlevania or Bee 52?


Top
 Profile  
 
PostPosted: Sat Mar 21, 2015 4:28 am 
Offline

Joined: Mon May 30, 2011 9:01 pm
Posts: 179
For CHR RAM games, that will be the address of the last PRG read before writing to CHR RAM.


Top
 Profile  
 
PostPosted: Sat Mar 21, 2015 7:18 am 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19256
Location: NE Indiana, USA (NTSC)
Do you mean the address of the last PRG ROM read other than an opcode fetch?


Top
 Profile  
 
PostPosted: Sat Mar 21, 2015 8:20 am 
Offline

Joined: Mon May 30, 2011 9:01 pm
Posts: 179
Yes


Top
 Profile  
 
PostPosted: Sat Mar 21, 2015 9:57 am 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19256
Location: NE Indiana, USA (NTSC)
Consider a game that copies or decompresses tile data from ROM to $0100-$017F during active picture, waits for vertical blanking, and uses a partially unrolled loop to copy $0100-$017F to video memory. At least Action 53, DABG, and RHDE are known to use a compression library that operates this way. How would your scheme handle this?


Top
 Profile  
 
PostPosted: Sun Mar 22, 2015 3:56 am 
Offline

Joined: Mon May 30, 2011 9:01 pm
Posts: 179
I don't have any idea how to add HD support to those games yet. May be I'll add an option to select how to identify the tiles: PRG ROM address + tile data, PRG ROM address only or tile data only. Then those game will have to use the tile data only and ignore the PRG ROM address. This may cause problem if several different tiles have the same tile pattern and palette but this is the best I can come up with.


Top
 Profile  
 
PostPosted: Sun Mar 22, 2015 4:21 am 
Offline

Joined: Sat Dec 27, 2014 7:40 am
Posts: 10
May be use tile number in VRAM (tile adress) + tile graphics data (hex data of graphic tile) for VRAM games?


Top
 Profile  
 
PostPosted: Sun Mar 22, 2015 7:35 pm 
Offline
User avatar

Joined: Fri Jul 18, 2014 4:52 pm
Posts: 24
A method for parallax scrolling.
I don't know how the emulator renders the frame but I was thinking today about how to implement parallax scrolling on solid color backgrounds or any background in general.

Using PPUSCROLL as the base we can determine where the camera is. Because that is default NES behavior used in most games. In the parallax settings tab we will have a setting to determine the speed in which the background image scrolls when compared to the PPUSCROLL location as well as tell it which picture to load per screen similar to the music having to define one or more addresses for it to take effect. So if the address is 0D for example show this for the background and if it’s 1B then show this one if you’re clever you might use the same music addresses for this effect. Since the background color is actually blank and determined by the game itself no special green screen color replacement is needed. It will just draw the image instead of transparency and then draw the tiles on top. Multiple images can be used for the background to create multiple parallaxes each with their own separate speeds. Think Super Mario All-Stars. Like I said I don’t know how the frames are drawn but all it would need is a way to render the background image independent of the game and then draw the replaced game sprites and tiles over it.

That's my idea. Forgive me if anything is incorrect or the information is invalid. My knowledge of how the NES works is next to nothing. :D


Top
 Profile  
 
PostPosted: Mon Mar 23, 2015 3:35 am 
Offline

Joined: Mon May 30, 2011 9:01 pm
Posts: 179
evgeny wrote:
May be use tile number in VRAM (tile adress) + tile graphics data (hex data of graphic tile) for VRAM games?


Do most games use fixed CHR RAM address for the same tile? If they do then this may work.

GGuy wrote:
A method for parallax scrolling.
I don't know how the emulator renders the frame but I was thinking today about how to implement parallax scrolling on solid color backgrounds or any background in general.

Using PPUSCROLL as the base we can determine where the camera is. Because that is default NES behavior used in most games. In the parallax settings tab we will have a setting to determine the speed in which the background image scrolls when compared to the PPUSCROLL location as well as tell it which picture to load per screen similar to the music having to define one or more addresses for it to take effect. So if the address is 0D for example show this for the background and if it’s 1B then show this one if you’re clever you might use the same music addresses for this effect. Since the background color is actually blank and determined by the game itself no special green screen color replacement is needed. It will just draw the image instead of transparency and then draw the tiles on top. Multiple images can be used for the background to create multiple parallaxes each with their own separate speeds. Think Super Mario All-Stars. Like I said I don’t know how the frames are drawn but all it would need is a way to render the background image independent of the game and then draw the replaced game sprites and tiles over it.

That's my idea. Forgive me if anything is incorrect or the information is invalid. My knowledge of how the NES works is next to nothing. :D


The PPU can only hold the map data upto 2 screen wide and it is up to the program to load new data and overwrite the old as the screen scroll. So the scroll values inside the PPU alone is not enough to determine the real scroll value. The best bet is to find the scroll values directly from RAM and calculate the real scroll value with a formula. Both the formula and the RAM address will be game specific.


Top
 Profile  
 
PostPosted: Mon Mar 23, 2015 6:17 am 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19256
Location: NE Indiana, USA (NTSC)
So long as the scroll amount doesn't change by more than about 100 pixels from one frame to the next, you can guess how far it's scrolled. For example, if the scroll in successive frames is 509, 511, 1, then 3, you can probably guess that it has wrapped.


Top
 Profile  
 
PostPosted: Mon Mar 23, 2015 6:23 am 
Offline

Joined: Sat Dec 27, 2014 7:40 am
Posts: 10
Quote:
Do most games use fixed CHR RAM address for the same tile? If they do then this may work.

Games use nametables and sprite attributes for static tile address, why something should be shifted? Yes, the same addresses can be downloaded new tiles, but the image data (in hex) will be different and it can be determined that it is a different tile. May be to slow compare all 16 bytes of tile data, then may use partially data or hash, checksum.


Top
 Profile  
 
PostPosted: Mon Mar 23, 2015 6:45 am 
Offline
User avatar

Joined: Fri Jul 18, 2014 4:52 pm
Posts: 24
mkwong98 wrote:
The PPU can only hold the map data upto 2 screen wide and it is up to the program to load new data and overwrite the old as the screen scroll. So the scroll values inside the PPU alone is not enough to determine the real scroll value. The best bet is to find the scroll values directly from RAM and calculate the real scroll value with a formula. Both the formula and the RAM address will be game specific.

I see, well it was worth a shot. I just figured if the value went up in RAM then scroll right and if it went down scroll left. I didn't think about when it resets. I was looking at addresses $2005 and $2006 in Super Mario Bros 1 and $0022 and $0023 in Super Mario Bros 3. It would have been a cheat way to do it anyways probably.

edit: so I figured out that $2005 in SMB is one pixel and $2006 is one 8 pixel block. So basically you just gotta count and keep track of it. Some kind of counter value that stays behind the scenes. And that would translate into 1 pixel on the PNG background file (which can loop or be as long as the level). Or if you set it 1 pixel per 2 hex values or whatever. 2 pixels per 1 hex etc. Then hopefully that would produce parallaxing. The lowest layer on the emulator would be an image viewer essentially that the emulator plays on top of. Anything marked transparent in the palette or transparent in the png would of course show the image on the bottom layer.

edit 2: or maybe not. You guys know more about the system then I do.


Top
 Profile  
 
PostPosted: Thu Apr 02, 2015 2:49 pm 
Offline

Joined: Sun Mar 08, 2015 12:23 pm
Posts: 251
Location: Croatia
mkwong98 wrote:
8bitMicroGuy wrote:
Awesome! So original and new! I've never seen an emulator like this. It's great! Now, when the cartridge bankswitches, how do you manage to keep track of which sprite goes where?
I think you should do the following
Name every HD sprite as the hex sequence of the sprite's data and 3 colors from the palette. For example: 01020408102040800103070F1F3F7FFF2C2E31
That way every sprite, wherever it comes from, will have its HD sprite.


In HDNes, the mappers return the real address of the read so bankswitching is not a problem.


What about Battletoads where the player sprites are loaded by copypasting from PRG-ROM to CHR-RAM?


Top
 Profile  
 
PostPosted: Thu Apr 02, 2015 4:32 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19256
Location: NE Indiana, USA (NTSC)
mkwong98 wrote:
I don't have any idea how to add HD support to those games yet.

"Those games" presumably include Battletoads.


Top
 Profile  
 
PostPosted: Fri Apr 03, 2015 5:15 am 
Offline

Joined: Sun Mar 08, 2015 12:23 pm
Posts: 251
Location: Croatia
tepples wrote:
mkwong98 wrote:
I don't have any idea how to add HD support to those games yet.

"Those games" presumably include Battletoads.

And my game NESCraft. All sprites are loaded on unused tiles on demand from PRG-ROM because there will be more mobs and player sprites than it's possible to fit 1KB banks at the same time.

mkwong98, as I said:
8bitMicroGuy wrote:
Name every HD sprite as the hex sequence of the sprite's data and 3 colors from the palette. For example: 01020408102040800103070F1F3F7FFF2C2E31
That way every sprite, wherever it comes from, will have its HD sprite.

This above is hexadecimal data of a tile and then the 3 colors of the tile. If this won't be implemented, then my game won't be HD :(


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 279 posts ]  Go to page Previous  1 ... 15, 16, 17, 18, 19  Next

All times are UTC - 7 hours


Who is online

Users browsing this forum: Donqustix, MLX and 8 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