Please try my NES emulator HDNes

Discuss emulation of the Nintendo Entertainment System and Famicom.

Moderator: Moderators

tepples
Posts: 22708
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: Please try my NES emulator HDNes

Post by tepples »

What's the "true address of the read" in Contra or Castlevania or Bee 52?
mkwong98
Posts: 282
Joined: Mon May 30, 2011 9:01 pm

Re: Please try my NES emulator HDNes

Post by mkwong98 »

For CHR RAM games, that will be the address of the last PRG read before writing to CHR RAM.
tepples
Posts: 22708
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: Please try my NES emulator HDNes

Post by tepples »

Do you mean the address of the last PRG ROM read other than an opcode fetch?
mkwong98
Posts: 282
Joined: Mon May 30, 2011 9:01 pm

Re: Please try my NES emulator HDNes

Post by mkwong98 »

Yes
tepples
Posts: 22708
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: Please try my NES emulator HDNes

Post by tepples »

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?
mkwong98
Posts: 282
Joined: Mon May 30, 2011 9:01 pm

Re: Please try my NES emulator HDNes

Post by mkwong98 »

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.
evgeny
Posts: 10
Joined: Sat Dec 27, 2014 7:40 am

Re: Please try my NES emulator HDNes

Post by evgeny »

May be use tile number in VRAM (tile adress) + tile graphics data (hex data of graphic tile) for VRAM games?
User avatar
GGuy
Posts: 24
Joined: Fri Jul 18, 2014 4:52 pm
Contact:

Re: Please try my NES emulator HDNes

Post by GGuy »

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
mkwong98
Posts: 282
Joined: Mon May 30, 2011 9:01 pm

Re: Please try my NES emulator HDNes

Post by mkwong98 »

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.
tepples
Posts: 22708
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: Please try my NES emulator HDNes

Post by tepples »

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.
evgeny
Posts: 10
Joined: Sat Dec 27, 2014 7:40 am

Re: Please try my NES emulator HDNes

Post by evgeny »

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.
User avatar
GGuy
Posts: 24
Joined: Fri Jul 18, 2014 4:52 pm
Contact:

Re: Please try my NES emulator HDNes

Post by GGuy »

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.
8bitMicroGuy
Posts: 314
Joined: Sun Mar 08, 2015 12:23 pm
Location: Croatia

Re: Please try my NES emulator HDNes

Post by 8bitMicroGuy »

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?
tepples
Posts: 22708
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: Please try my NES emulator HDNes

Post by tepples »

mkwong98 wrote:I don't have any idea how to add HD support to those games yet.
"Those games" presumably include Battletoads.
8bitMicroGuy
Posts: 314
Joined: Sun Mar 08, 2015 12:23 pm
Location: Croatia

Re: Please try my NES emulator HDNes

Post by 8bitMicroGuy »

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