It is currently Sun Oct 22, 2017 9:32 pm

All times are UTC - 7 hours





Post new topic Reply to topic  [ 279 posts ]  Go to page Previous  1 ... 9, 10, 11, 12, 13, 14, 15 ... 19  Next
Author Message
PostPosted: Mon Aug 25, 2014 1:24 am 
Online

Joined: Sun Apr 13, 2008 11:12 am
Posts: 6297
Location: Seattle
You may as well just set aside all of Nintendo's AxROM, BNROM, and UxROM games right now, rather than bothering to test them—they all use CHR-RAM.
SGROM, SMROM, SNROM, SOROM, SUROM, SXROM, TGROM, and TNROM too. ( http://wiki.nesdev.com/w/index.php/SxROM & http://wiki.nesdev.com/w/index.php/TxROM )


Top
 Profile  
 
PostPosted: Tue Aug 26, 2014 12:22 am 
Offline
User avatar

Joined: Fri Jul 18, 2014 4:52 pm
Posts: 24
Alrighty, thanks for the suggestion.
I'm pretty much finished with it now. Just a few more Japanese carts left to check. Hopefully this list will help anyone that wants to make a pack.


Top
 Profile  
 
PostPosted: Tue Aug 26, 2014 12:59 am 
Offline

Joined: Mon May 12, 2014 6:43 pm
Posts: 10
Attachment:
QQ截图20140826153810.jpg
QQ截图20140826153810.jpg [ 120.16 KiB | Viewed 1146 times ]

hi, author!
the tiles which color are red correspond to the same one,
how can i make the tiles correspond to the different?
sorry i dont know much about the technic.
my problem may be naive...


Top
 Profile  
 
PostPosted: Tue Aug 26, 2014 2:16 am 
Offline

Joined: Mon May 30, 2011 9:01 pm
Posts: 179
GGuy wrote:
Alrighty, thanks for the suggestion.
I'm pretty much finished with it now. Just a few more Japanese carts left to check. Hopefully this list will help anyone that wants to make a pack.


Thank you! It will be useful for me too.

LittleMike wrote:
hi, author!
the tiles which color are red correspond to the same one,
how can i make the tiles correspond to the different?
sorry i dont know much about the technic.
my problem may be naive...


Sorry, the emulator can't do that yet. BTW do you speak Chinese? You can ask questions in Chinese if you want. If you ask in Chinese here, I'll translate it to English for other readers. Or you can ask in the Chinese board and notify me about it, then I'll answer it there.


Top
 Profile  
 
PostPosted: Tue Aug 26, 2014 2:20 am 
Offline

Joined: Sun Jan 19, 2014 5:15 pm
Posts: 50
It would be interesting to see Yie Ar Kung Fu in an HD Street Fighter style.


Top
 Profile  
 
PostPosted: Tue Aug 26, 2014 6:33 pm 
Offline

Joined: Sun Jan 26, 2014 9:31 am
Posts: 256
Hey, I am the author of GB Enhanced, a Game Boy emulator that has the same ability as HDNES more or less (just without a GUI at the moment...)

I have been watching your work and just wanted to stop and say hello. I am really excited to see the source code online on GitHub. I would like to see your approach to handling certain situations, so I will examine the code some time soon.

I am also working on a white-paper detailing a general "theory" about "HD Graphics" in 2D systems like the NES, Genesis, Game Boy, etc, by replacing the game's graphics (the tiles). I am still working on it, but I would like to have the input from another person developing a similar emulator. I see LittleMike asked about replacing tiles that are technically the same on a given screen. I can assure you, this too is an issue I have encountered, and I believe it is an inherent issue that emulators like ours must deal with. How would you solve the problem LittleMike described? Do you have any ideas (even untested ones) that might work? I do not know much about the NES (I know a lot about the GB/GBC/GBA systems though) so I would like to hear what you would do. I have my own preliminary idea on how to solve LittleMike's problem, but it still needs to be refined.

Keep up the good work :)


Top
 Profile  
 
PostPosted: Tue Aug 26, 2014 6:45 pm 
Offline

Joined: Sun Jan 19, 2014 5:15 pm
Posts: 50
You're doing great work, Shonumi.


Top
 Profile  
 
PostPosted: Tue Aug 26, 2014 8:21 pm 
Offline

Joined: Mon May 30, 2011 9:01 pm
Posts: 179
Shonumi wrote:
Hey, I am the author of GB Enhanced, a Game Boy emulator that has the same ability as HDNES more or less (just without a GUI at the moment...)

I have been watching your work and just wanted to stop and say hello. I am really excited to see the source code online on GitHub. I would like to see your approach to handling certain situations, so I will examine the code some time soon.

I am also working on a white-paper detailing a general "theory" about "HD Graphics" in 2D systems like the NES, Genesis, Game Boy, etc, by replacing the game's graphics (the tiles). I am still working on it, but I would like to have the input from another person developing a similar emulator. I see LittleMike asked about replacing tiles that are technically the same on a given screen. I can assure you, this too is an issue I have encountered, and I believe it is an inherent issue that emulators like ours must deal with. How would you solve the problem LittleMike described? Do you have any ideas (even untested ones) that might work? I do not know much about the NES (I know a lot about the GB/GBC/GBA systems though) so I would like to hear what you would do. I have my own preliminary idea on how to solve LittleMike's problem, but it still needs to be refined.

Keep up the good work :)


If the tiles are stationary then I can use the tile location as well as the tile pattern and color to identify the tile, or I can let the user add a HD background image based on some value in the RAM. Otherwise it may be possible to use tile location and the scroll offset values from RAM to identify every single background tile on the screen, but that will be much more complicated and may require a script engine.


Top
 Profile  
 
PostPosted: Tue Aug 26, 2014 8:27 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19116
Location: NE Indiana, USA (NTSC)
I think a hash table based on tile pattern would probably be the most productive way to start handling CHR RAM based systems like Master System, Game Boy family, and 25% of the FC/NES library. (I just checked NesCartDB, and 356 out of the 1397 known distinct games contain CHR RAM.)


Top
 Profile  
 
PostPosted: Tue Aug 26, 2014 9:42 pm 
Offline

Joined: Sun Jan 26, 2014 9:31 am
Posts: 256
@tepples - This is the conclusion I have come to, and it pretty much forms the basis for my general theory on being able to replace 2D graphics for any tile-based console or handheld. Adequate hashing (in theory anyway) should provide every single tile for a system. So long as you can generate a unique hash for every tile that the emulator wants to draw, it should be possible to replace that. Obviously there are unique difficulties to adapt to (like when colors "fade in" or "fade out" which requires some careful hashing of tile and palette data) but that is the gist of it.

One of the bigger problems I have faced using this method is that some tiles are usually reserved for the background but appear in multiple places and serve multiple functions. The all-white tiles that make up the sky in Super Mario Land are a great example. These can be hashed, dumped, and edited, but this has the effect of replacing every all-white tile in the game, unfortunately, because the hash is the same. Not only is the "sky" replaced, but everywhere that has a white background (which is most of the game). To this end, I have disabled dumping tiles that are solid colors by default. Obviously this issue is reduced when moving to the GBC and the GBA, since the tiles become more unique and varied.

@mkwong98 - Someone mentioned to me that using the location of a tile to be included as part of a hash (or an ID if you will) would be a nice solution for something like LittleMike's problem. I have no idea about how viable that is on the NES, but I have expressed my doubts, at least as it concerns the Game Boy. I guess what you NES folks call the Nametable is most comparable to the GB family's Background Maps. I believe you are correct when it comes to replacing stationary images, since this is very simple. The Background Map is essentially static data at that point. When the screen moves in scrolling games, however, the BG Map is rewritten (not all at once, usually) because new areas need to be shown. Is this how NES games with CHR RAM work as well?

If that is the case, it makes replacing tiles like LittleMike pointed out troublesome because the tile's location in the Nametable/Background Map continually changes. It is definitely possible to do it for non-stationary backgrounds, I just can't imagine it being very fun to code :D

Sorry if you consider this off-topic talk, I just find this to be a fascinating area of emulation, one we have yet to perfect, and one that we have yet to fully exploit.


Top
 Profile  
 
PostPosted: Tue Aug 26, 2014 10:47 pm 
Offline

Joined: Mon May 30, 2011 9:01 pm
Posts: 179
For CHR RAM games, besides the tile pattern, HDNes also remembers the address of the last PRG ROM read when writing the tile to CHR RAM. The emulator assumes the game does not read from other PRG ROM addresses when transfering tiles from PRG ROM to CHR RAM. Then this address can be used as part of the tile identification as well. I'm not sure how well this will work, I haven't make a HD pack for a CHR RAM game yet.


Top
 Profile  
 
PostPosted: Tue Aug 26, 2014 11:28 pm 
Offline
User avatar

Joined: Fri Jul 18, 2014 4:52 pm
Posts: 24
Hey Shonumi. I believe it was me that suggested the ID thing. I posted it on google code. Anyways I have an idea about the all solid colors thing. It's not ideal but what I've been doing is editing the CHR data in the rom and making the solid tiles unique. Of course having people patch a rom is kind of a pain so perhaps the way to resolve this temporarily is to implement ips patching. Then whoever makes an HD pack can simple add a IPS file to the directory and resolve any duplicate hash problems because they would have edited the solid colors in the CHR.

Mkwong, I've experimented with Metroid a CHR-RAM game and the only issues I was running into was unsupported mappers. It's been awhile since I did anything with that though so I will need to retest that.
edit: Well that's strange. Starting a CHR-RAM game with graphic pack data now crashes the emulator.


Last edited by GGuy on Wed Aug 27, 2014 12:16 am, edited 1 time in total.

Top
 Profile  
 
PostPosted: Wed Aug 27, 2014 12:00 am 
Offline

Joined: Sun Jan 26, 2014 9:31 am
Posts: 256
@GGuy - Oh, so that was you :D Actually what you suggested just now is very similar to the WIP idea I have. Essentially I guess you would call it a "Virtual Tile Map" ("Virtual Nametable" in NES-speak?) in that the emulator reads the Map data as usual, but the user can forcibly override certain entries with data of their own. It's basically in-game patching, but without touching the ROM itself. I am trying to figure out a reliable implementation; the emulator needs to determine when it is time to override the Map provided by the ROM, and when to leave it alone.

mkwong98's comments about detecting transfer addresses into CHR-RAM (or really just VRAM in GB-speak) is something I will consider in solving the so-called "solid-color" problem. There's something there, I know it. I'm too busy getting my GBA emulator off the ground to mess with anything GB/GBC related though.

I will give HDNES a try later this weekend. It is Windows only, correct? I should be able to run it in WINE though.


Top
 Profile  
 
PostPosted: Wed Aug 27, 2014 6:14 am 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19116
Location: NE Indiana, USA (NTSC)
Shonumi wrote:
I guess what you NES folks call the Nametable is most comparable to the GB family's Background Maps. I believe you are correct when it comes to replacing stationary images, since this is very simple. The Background Map is essentially static data at that point. When the screen moves in scrolling games, however, the BG Map is rewritten (not all at once, usually) because new areas need to be shown. Is this how NES games with CHR RAM work as well?

Yes. Both games with CHR ROM and games with CHR RAM work this way. Load Contra into an emulator with a nametable viewer and see updates at the scroll seam not unlike those of Super Mario Bros. Heck, SMB1 itself runs on at least one board with CHR RAM, namely the Nintendo World Championships (NES-EVENT) board.

GGuy wrote:
Anyways I have an idea about the all solid colors thing. It's not ideal but what I've been doing is editing the CHR data in the rom and making the solid tiles unique.

That might work for CHR ROM, not so much for CHR RAM because a solid tile often compresses to one or two bytes. And for a couple compression methods I've been meaning to implement, not even "last data fetch from ROM" would help because they'd end up seeing a constant table used by the decompression code. Your real-time IPS would end up having to rewrite all the CHR loading code to write a unique ID instead of tile data.


Top
 Profile  
 
PostPosted: Wed Aug 27, 2014 8:36 am 
Offline

Joined: Mon May 30, 2011 9:01 pm
Posts: 179
GGuy wrote:
edit: Well that's strange. Starting a CHR-RAM game with graphic pack data now crashes the emulator.


Ok I fixed the bug when reading HD pack of CHR-RAM games. Thanks for telling me.

Shonumi wrote:
I will give HDNES a try later this weekend. It is Windows only, correct? I should be able to run it in WINE though.


Yes, it is windows only. The platform specific code is for file and directory handling and I can't figure out how to do it cross platform.

tepples wrote:
That might work for CHR ROM, not so much for CHR RAM because a solid tile often compresses to one or two bytes. And for a couple compression methods I've been meaning to implement, not even "last data fetch from ROM" would help because they'd end up seeing a constant table used by the decompression code. Your real-time IPS would end up having to rewrite all the CHR loading code to write a unique ID instead of tile data.


If I can define a list of address ranges to be included/excluded when monitoring the last data fetch then it might work. Script engine will be the most robust approach. I have problems keeping it running at 60 fps as it is so I'm not too keen on adding more to it yet.

Shonumi, which library do you use for graphics? I'm using GLSL, but the uploading the tiles as a texture onto the graphics card is not a fast process and doing it every frame makes the emulator very slow on older machines.

GGuy, what program did you use to record the youtube clips? I can't a recording with good frame rate and no slow down.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 279 posts ]  Go to page Previous  1 ... 9, 10, 11, 12, 13, 14, 15 ... 19  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