nesdev.com
http://forums.nesdev.com/

Please try my NES emulator HDNes
http://forums.nesdev.com/viewtopic.php?f=3&t=9935
Page 18 of 19

Author:  tepples [ Fri Mar 20, 2015 6:54 pm ]
Post subject:  Re: Please try my NES emulator HDNes

What's the "true address of the read" in Contra or Castlevania or Bee 52?

Author:  mkwong98 [ Sat Mar 21, 2015 4:28 am ]
Post subject:  Re: Please try my NES emulator HDNes

For CHR RAM games, that will be the address of the last PRG read before writing to CHR RAM.

Author:  tepples [ Sat Mar 21, 2015 7:18 am ]
Post subject:  Re: Please try my NES emulator HDNes

Do you mean the address of the last PRG ROM read other than an opcode fetch?

Author:  mkwong98 [ Sat Mar 21, 2015 8:20 am ]
Post subject:  Re: Please try my NES emulator HDNes

Yes

Author:  tepples [ Sat Mar 21, 2015 9:57 am ]
Post subject:  Re: Please try my NES emulator HDNes

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?

Author:  mkwong98 [ Sun Mar 22, 2015 3:56 am ]
Post subject:  Re: Please try my NES emulator HDNes

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.

Author:  evgeny [ Sun Mar 22, 2015 4:21 am ]
Post subject:  Re: Please try my NES emulator HDNes

May be use tile number in VRAM (tile adress) + tile graphics data (hex data of graphic tile) for VRAM games?

Author:  GGuy [ Sun Mar 22, 2015 7:35 pm ]
Post subject:  Re: Please try my NES emulator HDNes

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

Author:  mkwong98 [ Mon Mar 23, 2015 3:35 am ]
Post subject:  Re: Please try my NES emulator HDNes

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.

Author:  tepples [ Mon Mar 23, 2015 6:17 am ]
Post subject:  Re: Please try my NES emulator HDNes

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.

Author:  evgeny [ Mon Mar 23, 2015 6:23 am ]
Post subject:  Re: Please try my NES emulator HDNes

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.

Author:  GGuy [ Mon Mar 23, 2015 6:45 am ]
Post subject:  Re: Please try my NES emulator HDNes

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.

Author:  8bitMicroGuy [ Thu Apr 02, 2015 2:49 pm ]
Post subject:  Re: Please try my NES emulator HDNes

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?

Author:  tepples [ Thu Apr 02, 2015 4:32 pm ]
Post subject:  Re: Please try my NES emulator HDNes

mkwong98 wrote:
I don't have any idea how to add HD support to those games yet.

"Those games" presumably include Battletoads.

Author:  8bitMicroGuy [ Fri Apr 03, 2015 5:15 am ]
Post subject:  Re: Please try my NES emulator HDNes

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 :(

Page 18 of 19 All times are UTC - 7 hours
Powered by phpBB® Forum Software © phpBB Group
http://www.phpbb.com/