HD Pack's Mesen

[welweb]

This is my HD Pack for Road Fighter

Video: https://youtu.be/b15N4fucrWk


Road Fighter HDPAck by AllanUr4.zip

I can't find the origin rom,i tried a lot (E) version,but no one can work,can you provide a link to download?

[mkwong98]

A joke character replacement for Kung Fu that I have made:
https://youtu.be/hK2mhQW50hQ?si=FJ6P9NlGFyS5h4uP
https://www.mediafire.com/file/2hqt2iaq ... uy.7z/file

[mkwong98]

This is my HD Pack for Road Fighter

Video: https://youtu.be/b15N4fucrWk


Road Fighter HDPAck by AllanUr4.zip

I can't find the origin rom,i tried a lot (E) version,but no one can work,can you provide a link to download?

You can get it to show if you remove the line from the hires.txt:
<supportedRom>0D5099BCF2ACDBA811FF9CEFFC4AC0FE076BB54D

[2ericcannon]

Hello, I would like to use the original nes music for games instead of the HDpack music. Can anyone tell me how to disable the hd music and use the original audio? Thanks

[mkwong98]

Hello, I would like to use the original nes music for games instead of the HDpack music. Can anyone tell me how to disable the hd music and use the original audio? Thanks

HD pack music requires a patch for the ROM. So if the patch which comes with the HD pack changes music and nothing else, then you can remove the patch.

[IfTRUEthen]

Hello.
When I record the game I am working on and then look in the Hires.txt file, I see that the generated <tile> entries have an extra 2 numbers at the end of the line. Here's a snippet of what I mean from the Hires.txt file:

Code: Select all

#Chr_2.png
<tile>2,0204010D00060E07010307070A0F010E,FF172530,64,64,1,N,18403312,144
<tile>2,A0F030F8A8289818C080C080D0D0E0E0,FF172530,64,72,1,N,18403312,145
<tile>2,6D6F7FEDF2F77F3E47575716CD480343,FF0F2730,72,64,1,N,18403312,146

#Chr_3.png
<tile>3,00FFE0E0E0E0FF0000FF00000000FF00,0F151930,96,0,1,N,541078280,12
<tile>3,38382C647E46CE0038382C647E46CE00,0F0F0818,0,8,1,N,541078280,16
<tile>3,F84C464646CEFC00F84C464646CEFC00,0F0F0618,24,8,1,N,541078280,19

I know what everything refers to up until after the N,. The two numbers after the N don't seem to be documented in the documentation.

The 8 character number can remain the same across several PNG entries before changing.

The last number always goes up in value, but not always sequentially, i.e. there are gaps in the numbering but they always increase until the end of that PNG entry.


Does anyone know what those numbers refer to?

[Sour]

Does anyone know what those numbers refer to?

These don't do anything - they're only there to help the HD Pack Builder find the correct tiles in CHR RAM games when it starts recording using data from an existing pack.
When running the HD Pack normally, these values are not used for anything (which is why they were never documented)

[IfTRUEthen]

Does anyone know what those numbers refer to?

These don't do anything - they're only there to help the HD Pack Builder find the correct tiles in CHR RAM games when it starts recording using data from an existing pack.
When running the HD Pack normally, these values are not used for anything (which is why they were never documented)

Thank you for your response! May I ask another question?

First, I am an artist, not a programmer, so I apologize if this is stupid. What I have started doing is cutting and pasting <tile> entries from one Chr_*.png section to different ones to better consolidate sprites and to replace tiles for whatever reasons. Should I leave those last 2 values alone? I have been changing the ending number to be the next number "up" in value. For example, I paste an entry to the bottom of ,say, Chr_0.png. The last entry there has a "143" value at the end, so I change my new entry to have a "144" at the end so that it follows the pattern of the other entries.

Should I just leave everything as it was when I copied it (except for the img index)?

Also, have you ever had problems with the HDpack recording not capturing everything? I sometimes have to make several passes over a scene to get it to record all the sprites/tiles.

[tepples]

It appears that hd in hd pack is a stop word.

Search found 1163 matches: hd pack
Searched query: +pack

ignored: hd

I had to use texture pack to find this topic. It links to documentation for Mesen 0.9.9's HD pack support, and I don't know what's changed between then and Mesen 2.

----------

I'm struggling to understand the details of how authors and users of a high-resolution texture pack expect it to work. As I understand it, the image contains a 32×32-pixel replacement (assuming <scale>4) for each 8×8-pixel tile in the original game, and the mapping file describes which tile in one of the provided images to use for the tile at each address in CHR ROM or for each distinct tile in CHR RAM. Tile selection can be conditional, based on other nearby background or sprite tiles, tiles at fixed positions on screen, or memory contents.

I'll use Super Mario Bros. 3 as an example for the first thing I fail to understand: palette swapping. What does a player expect to happen to the game's graphics when the palette changes for these reasons? And what does the author need to do to make that happen?

1. Fading the whole palette in and out
2. Mario grabs a Fire Flower or Starman
3. Luigi tags in
4. Coins flash (usually they spin, but on treasure ships they flash like in SMB1)
5. Green vs. red Koopa Troopas

In Mega Man games, the player's palette changes based on which weapon is in use, as well as (in later games) whether the weapon's alternate fire is being charged. Does the game need to have separate tiles for each combination of weapon and charge state?

When a background pixel, a sprite pixel with rear priority, and a sprite pixel without rear priority are all overlapping, and the sprite with rear priority has a lower OAM index, the background pixel shows through. Super Mario Bros. uses this unintentionally when a Bullet Bill passes a Piranha Plant. Super Mario Bros. 3 and one of the Dizzy games use this to selectively push part of sprite behind the background. Would the triple overlap condition be evaluated for all 16 subpixels (at <scale>4) of each pixel?

I've seen games that fade both to black and to white. The <tile> tag description claims that "the brightness can be set to values above 1.0 to increase the PNG’s normal brightness level". Do values above 1.0 change only the contrast or also the black level?

In Battletoads, the ice cave level draws a parallax background using bit shifting. Would I need to store each resulting tile at each of 64 shift offsets, as if it were Metal Storm?

Is there anything that can be done for games like Solstice that cut holes in tile data before sending it to CHR RAM? Or for games like Nova the Squirrel that use a variable-width font?

And does any of this work on Game Boy games?

[Fiskbit]

It appears that hd in hd pack is a stop word.

Just to quickly address this so we don't get sidetracked talking about search: This is expected, because hd is too short a word. See this thread where we reduced the minimum searchable token size to 3. I don't expect it to be reduced further. Please continue any discussion about search in the linked thread.

[Sour]

I don't know what's changed between then and Mesen 2.

A fair bit has been added:
-<addition> and <fallback> rules
-blend mode options for <background>s
-loop position for <bgm>s
-flag to ignore palette for the tileNearby, tileAtPos, spriteNearby, spriteAtPos conditions (e.g to match a tile regardless of its palette)
-positionCheckX, positionCheckY conditions which are true when the pixel is at the position X/Y specified on the screen
-originalPositionCheckX, originalPositionCheckY conditions which are true when the top left corner of the bg tile/sprite is at position X/Y

There's no documentation for any of these atm - the only doc would be the code in HdPackLoader.cpp.
There's also a potentially slightly less out of date version of the specs here: https://github.com/SourMesen/Mesen/blob ... /_index.md
Which should include a few changes to HD packs done between 0.9.9 and the last dev build of the old Mesen

And what does the author need to do to make that happen?

<tile> definitions are for a tile+palette combination, so you need to define <tile> rules for each you need to replace. There's a "default palette" flag that can be used, too, to use a given <tile> rule when no other exact palette match is found for the tile. So palette swaps, fade ins/out, etc. do require a lot of definitions, afaik.

Would the triple overlap condition be evaluated for all 16 subpixels (at <scale>4) of each pixel?

I don't remember the exact details, but I'm fairly sure this is evaluated correctly and in a way that makes sense, but it's been a long time.

I've seen games that fade both to black and to white. The <tile> tag description claims that "the brightness can be set to values above 1.0 to increase the PNG’s normal brightness level". Do values above 1.0 change only the contrast or also the black level?

This is just a multiplication of each color component by the brightness level specified.

In Battletoads, the ice cave level draws a parallax background using bit shifting. Would I need to store each resulting tile at each of 64 shift offsets, as if it were Metal Storm?

Every combination of unique 8x8 tile needs to be defined separately.

And does any of this work on Game Boy games?

This feature is NES-only (and I don't really have any plans to expand it to other consoles at the moment - it would require a huge amount of work)

[mkwong98]

I've seen games that fade both to black and to white. The <tile> tag description claims that "the brightness can be set to values above 1.0 to increase the PNG’s normal brightness level". Do values above 1.0 change only the contrast or also the black level?

And does any of this work on Game Boy games?

I have made a cut down version of GBE+ with HD pack feature. One of the differences is that it fades to white when the brightness level increases to 2.0. And it can play sound using midi too, just for fun.

[nEwli y00zd]

Is there a way to extract graphics without having to play through an entire game?

I noticed some graphics don't get recorded while playing.

[my_Ruicky]

Does anyone know what those numbers refer to?

These don't do anything - they're only there to help the HD Pack Builder find the correct tiles in CHR RAM games when it starts recording using data from an existing pack.
When running the HD Pack normally, these values are not used for anything (which is why they were never documented)

Thank you for your response! May I ask another question?

First, I am an artist, not a programmer, so I apologize if this is stupid. What I have started doing is cutting and pasting <tile> entries from one Chr_*.png section to different ones to better consolidate sprites and to replace tiles for whatever reasons. Should I leave those last 2 values alone? I have been changing the ending number to be the next number "up" in value. For example, I paste an entry to the bottom of ,say, Chr_0.png. The last entry there has a "143" value at the end, so I change my new entry to have a "144" at the end so that it follows the pattern of the other entries.

Should I just leave everything as it was when I copied it (except for the img index)?

Also, have you ever had problems with the HDpack recording not capturing everything? I sometimes have to make several passes over a scene to get it to record all the sprites/tiles.

So, what does the 18403312 part of 18403312,144 mean

[LiQuiDz]

I've updated my website

Mesen Graphic Packs at

https://liquidzretrogaming.net/