[sebastianangel]

Fantastic art Xander max!

[sics]

sebastianangel
It is a mostly manual process, to achieve a decent result you should not only analyze the graphics you want to adapt, but you should consider other variants of it and especially the original version

Spoiler:

The first thing I noticed after I started testing was that there was a lot of information in this image that would inevitably be lost if I scaled it up, so the solution that convinced me the most was to find an optimal point to cut the image based on the original NES framework:


But when comparing the result with the portraits of Ryu's classic version, it was noticeable that he had become very big-headed or at least his head was the only thing that stood out:


So instead of just cropping it scale part of the illustration, as follows:


Although for this specific case the soft resizing was not the most indicated since the finish of the original work is rough or whatever.

Using the ImageResizer-r129 tool, scale the image using the Bicubic <GDI+> method already to its final size.


In this part I usually use Color Quantizer, to get the best result, but looking for alternative ways to facilitate your task I discovered a very interesting function in RIOT (Radical Image Optimization Tool).


With it you can filter the original image to improve the output results, in this example I used an additional color by mistake, since I usually work using images that include an alpha channel, this means that you have to configure a palette of 5 colors to be able to preserve the transparency.

Already with several different versions, it is only a matter of taking the best of each one and unifying them in a single illustration, paying special attention to the original version of the NES, since it can take the greatest amount of resources to hide the limitations of the system.


On the other hand it is a waste of effort to use the real rom for testing. It is better to create a mockup with NESImageConverter2, since it is fast, it is easy and it allows you to make changes efficiently.

^{That tape is very badly drawn, I fall from sleep xD}

Changing the subject, I can't quite understand why we should replace the mapper with MMC5, it's a sincere question, I don't understand what advantages it offers over the mapper that this game is currently using

cartridge_rom
Logically, the artistic style used in a game should be the same from beginning to end, so although it may be a reference, I do not think that a version is created directly using the GBA graphics

RealGaea
Regarding the endings, at the moment we are conditioned by the space for graphics, so we must consider it.

You have thought that if there are 9 players it would be necessary to draw 36 illustrations to fulfill your request, you are going to decompose the poor robot and then I will have to take him to the technician

I did some arts, maybe they can inspire or enjoy something!

Great illustrations!

[Xander max]

sebastianangel
It is a mostly manual process, to achieve a decent result you should not only analyze the graphics you want to adapt, but you should consider other variants of it and especially the original version

Spoiler:

The first thing I noticed after I started testing was that there was a lot of information in this image that would inevitably be lost if I scaled it up, so the solution that convinced me the most was to find an optimal point to cut the image based on the original NES framework:


But when comparing the result with the portraits of Ryu's classic version, it was noticeable that he had become very big-headed or at least his head was the only thing that stood out:


So instead of just cropping it scale part of the illustration, as follows:


Although for this specific case the soft resizing was not the most indicated since the finish of the original work is rough or whatever.

Using the ImageResizer-r129 tool, scale the image using the Bicubic <GDI+> method already to its final size.


In this part I usually use Color Quantizer, to get the best result, but looking for alternative ways to facilitate your task I discovered a very interesting function in RIOT (Radical Image Optimization Tool).


With it you can filter the original image to improve the output results, in this example I used an additional color by mistake, since I usually work using images that include an alpha channel, this means that you have to configure a palette of 5 colors to be able to preserve the transparency.

Already with several different versions, it is only a matter of taking the best of each one and unifying them in a single illustration, paying special attention to the original version of the NES, since it can take the greatest amount of resources to hide the limitations of the system.


On the other hand it is a waste of effort to use the real rom for testing. It is better to create a mockup with NESImageConverter2, since it is fast, it is easy and it allows you to make changes efficiently.

^{That tape is very badly drawn, I fall from sleep xD}

Changing the subject, I can't quite understand why we should replace the mapper with MMC5, it's a sincere question, I don't understand what advantages it offers over the mapper that this game is currently using

cartridge_rom
Logically, the artistic style used in a game should be the same from beginning to end, so although it may be a reference, I do not think that a version is created directly using the GBA graphics

RealGaea
Regarding the endings, at the moment we are conditioned by the space for graphics, so we must consider it.

You have thought that if there are 9 players it would be necessary to draw 36 illustrations to fulfill your request, you are going to decompose the poor robot and then I will have to take him to the technician
Great illustrations!

Thanks for the instruction! Always very detailed in his explanations!
Which mapper does this game use? Currently I do not see reproductions for sale of this game, a reason to change the mapper may be to be able to make physical copies more easily.

[sebastianangel]

sebastianangel
It is a mostly manual process, to achieve a decent result you should not only analyze the graphics you want to adapt, but you should consider other variants of it and especially the original version

Spoiler:

The first thing I noticed after I started testing was that there was a lot of information in this image that would inevitably be lost if I scaled it up, so the solution that convinced me the most was to find an optimal point to cut the image based on the original NES framework:


But when comparing the result with the portraits of Ryu's classic version, it was noticeable that he had become very big-headed or at least his head was the only thing that stood out:


So instead of just cropping it scale part of the illustration, as follows:


Although for this specific case the soft resizing was not the most indicated since the finish of the original work is rough or whatever.

Using the ImageResizer-r129 tool, scale the image using the Bicubic <GDI+> method already to its final size.


In this part I usually use Color Quantizer, to get the best result, but looking for alternative ways to facilitate your task I discovered a very interesting function in RIOT (Radical Image Optimization Tool).


With it you can filter the original image to improve the output results, in this example I used an additional color by mistake, since I usually work using images that include an alpha channel, this means that you have to configure a palette of 5 colors to be able to preserve the transparency.

Already with several different versions, it is only a matter of taking the best of each one and unifying them in a single illustration, paying special attention to the original version of the NES, since it can take the greatest amount of resources to hide the limitations of the system.


On the other hand it is a waste of effort to use the real rom for testing. It is better to create a mockup with NESImageConverter2, since it is fast, it is easy and it allows you to make changes efficiently.

^{That tape is very badly drawn, I fall from sleep xD}

Changing the subject, I can't quite understand why we should replace the mapper with MMC5, it's a sincere question, I don't understand what advantages it offers over the mapper that this game is currently using

cartridge_rom
Logically, the artistic style used in a game should be the same from beginning to end, so although it may be a reference, I do not think that a version is created directly using the GBA graphics

RealGaea
Regarding the endings, at the moment we are conditioned by the space for graphics, so we must consider it.

You have thought that if there are 9 players it would be necessary to draw 36 illustrations to fulfill your request, you are going to decompose the poor robot and then I will have to take him to the technician
Great illustrations!

Excellent explanatory tutorial !!! It helps me 100% in the process and with an optimal result! I will put it into practice now!
thanks for teaching us all to improve

[RealGaea]

On the other hand it is a waste of effort to use the real rom for testing. It is better to create a mockup with NESImageConverter2, since it is fast, it is easy and it allows you to make changes efficiently.

^{That tape is very badly drawn, I fall from sleep xD}

RealGaea
Regarding the endings, at the moment we are conditioned by the space for graphics, so we must consider it.

You have thought that if there are 9 players it would be necessary to draw 36 illustrations to fulfill your request, you are going to decompose the poor robot and then I will have to take him to the technician

Ok, I get it, I won't break the robot. SSF2 is then. Loved how the proportions were handled.

[BZXGCS]

The command to perform the Shoryuken/Tiger Uppercut is very difficult. Is it possible to change the command or make a way to make it easier?

a nes game "fighting hero 3" has the correct Shoryuken command. However, I have no idea about how to transplant command to other game.
The link is:
https://bootleggames.fandom.com/wiki/Fighting_Hero_III

[BZXGCS]

Very good contribution if it is one of the soundtracks that we had considered in the beginning: and we do not rule out the idea, only that I think we have something better in middi format that we want to adapt to the game. The energy bar will verify it and it will surely be fixed : , at this moment I was full with the theme of the finals and now with the screens versus. Chun lee's Kikoken already goes to a more pure programming area that perhaps others want to give a hand, any contribution is always welcome , but we go by parts and we do not rule out any idea or proposal that is within our reach!
When we have solved these commented areas, a more significant improvement of the stages is still missing
then I leave the limk of agunos middis for the gamehttps://www.youtube.com/watch?v=kCMgPT3BV-8

Will you collaborate with vasyanchichek（Vasil in romhacking.net）? UMK3 nes project shows his impressive programming skills.

[song6502]

改成mmc5是为了扩充容量！以整体游戏引擎来看，PRG方面：目前一个游戏人物动作精灵数据占一个8k-PRG空间。假如需要添加三位人物的话，就需要多出24k-PRG空间。（添加ken的话是30k-PRG空间）stage nametable数据也需要多出8K-PRG空间。现在场景音乐数据有空闲的空间可以写入，也许不需要增加新空间。
在chr方面：每一位人物的图形差不多需要40k左右的CHR空间，加一起就是120k-CHR左右的空间。结局画面最小共需要6k~12k空间。
游戏引擎有一个开机自检的程序，去除的话可以富余出一些空间，利用这些空间也许可以去写入VS画面的程序，使VS画面更接近arcade。
原rom:128k prom+512k crom
修改后rom：256k prom +1024k crom

这些是我当初的计划，假如将引擎弄清楚了，就可以重新编译，就可以有任何的可能性！--------修改VS画面、重绘stage、添加人物数量等！而mmc5是目前唯一支持这个容量的映射！
也许是不正确的调查：https://drive.google.com/file/d/1FziBD1vwgW9TVQrTHGpagWNC3VxRn6BD/view?usp=sharing

November 14, 2020, 07:35:23 am - (Auto Merged - Double Posts are not allowed before 7 days.)有一个小细节，不知道大家有没有发现。
mapper197的SF3比mapper91的SF3多了一条扫描线
https://drive.google.com/file/d/1TBxREzsqdk1UnaXszEDH45kyrgATk3XI/view?usp=sharing
我想这是生命值nametable显示造成的，不知道为什么。
November 14, 2020, 07:45:28 am - (Auto Merged - Double Posts are not allowed before 7 days.)

song6502, one way to check if the writing mode was correct is to take the converted text and translate it back into your language, if it is understandable to you, then it was correct. I saw your video on youtube, your scenery was amazing!

谢谢！我做了三个stage后发现，还是把引擎弄明白吧！以后就停止了。做像素画很有趣，就是太浪费时间。

[sebastianangel]

Will you collaborate with vasyanchichek%uFF08Vasil in romhacking.net%uFF09? UMK3 nes project shows his impressive programming skills.

It would be a great pleasure for us to have the help of (Vasil), it is incredible what has been achieved in mortal combat! For now he is busy with his own projects but as soon as he is released he will contact him. That would be wonderful
November 14, 2020, 10:00:33 am - (Auto Merged - Double Posts are not allowed before 7 days.)

Switching to mmc5 is expanding capacity! From the perspective of the overall game engine, PRG: Currently, the data for an action sprite of the game character occupies 8k-PRG space. If you need to add three characters, you need a 24k-PRG space. (If ken is added, it is a 30k-PRG space) The data in the stage name table also needs more space than 8K-PRG. Now that the music data in the scene has free space to write, it may not be necessary to add new space.
In terms of chr: each character's graphic needs approximately 40k CHR of space, in addition to approximately 120k-CHR. The final screen requires a total of 6k ~ 12k of space.
The game engine has an ignition self-test program. If it is removed, it can leave some space. With this space, you may be able to write VS screen program to bring VS screen closer to arcade%u3002
%u539F rom: 128k prom + 512k chrom
%u4FEE%u6539 %u540E rom %uFF1A 256k prom + 1024k chrom
%u8FD9%u4E9B%u662F%u6211%u5F53%u521D%u7684%u8BA1%u5212%uFF0C%u5047%u5982%u5C06%u5F15%u64CE%u5F04%u6E05%u695A%u4E86%uFF0C%u5C31%u53EF%u4EE5%u91CD%u65B0%u7F16%u8BD1%uFF0C%u5C31%u53EF%u4EE5%u6709%u4EFB%u4F55%u7684%u53EF%u80FD%u6027%uFF01--------%u4FEE%u6539VS%u753B%u9762%u3001%u91CD%u7ED8stage%u3001%u6DFB%u52A0%u4EBA%u7269%u6570%u91CF%u7B49%uFF01%u800Cmmc5%u662F%u76EE%u524D%u552F%u4E00%u652F%u6301%u8FD9%u4E2A%u5BB9%u91CF%u7684%u6620%u5C04%uFF01
%u4E5F%u8BB8%u662F%u4E0D%u6B63%u786E%u7684%u8C03%u67E5%uFF1Ahttps://drive.google.com/file/d/1FziBD1vwgW9TVQrTHGpagWNC3VxRn6BD/view?usp=sharing

November 14, 2020, 07:35:23 am - (Auto Merged - Double Posts are not allowed before 7 days.)%u6709%u4E00%u4E2A%u5C0F%u7EC6%u8282%uFF0C%u4E0D%u77E5%u9053%u5927%u5BB6%u6709%u6CA1%u6709%u53D1%u73B0%u3002
mapper197%u7684SF3%u6BD4mapper91%u7684SF3%u591A%u4E86%u4E00%u6761%u626B%u63CF%u7EBF
https://drive.google.com/file/d/1TBxREzsqdk1UnaXszEDH45kyrgATk3XI/view?usp=sharing
%u6211%u60F3%u8FD9%u662F%u751F%u547D%u503Cnametable%u663E%u793A%u9020%u6210%u7684%uFF0C%u4E0D%u77E5%u9053%u4E3A%u4EC0%u4E48%u3002
November 14, 2020, 07:45:28 am - (Auto Merged - Double Posts are not allowed before 7 days.)

song6502, one way to check if the writing mode was correct is to take the converted text and translate it back into your language, if it is understandable to you, then it was correct. I saw your video on youtube, your scenery was amazing!

%u8C22%u8C22%uFF01%u6211%u505A%u4E86%u4E09%u4E2Astage%u540E%u53D1%u73B0%uFF0C%u8FD8%u662F%u628A%u5F15%u64CE%u5F04%u660E%u767D%u5427%uFF01%u4EE5%u540E%u5C31%u505C%u6B62%u4E86%u3002%u505A%u50CF%u7D20%u753B%u5F88%u6709%u8DA3%uFF0C%u5C31%u662F%u592A%u6D6A%u8D39%u65F6%u95F4%u3002

fantastic explanation and data song! you
Investigation is great, there will be many possibilities for improving the game, thank you for sharing your research and discoveries with us, I hope the connoisseurs can clarify any doubts you may have!

[sics]

Replacing the game's mapper to MMC5 implies increasing its capacity, in terms of the game engine, of course.

PRG: Currently, the data to manage the sprites of a fighter occupies 8k-PRG, therefore, if you want to add three additional fighters, you will need to have 24k-PRG (And if we also included Ken, a total of 30k-PRG would be necessary)

In the same way, for each new scenario that is developed, it will need an additional 8k-PRG to store its nametable, unless we take into account the version with the new soundtrack, since this dispenses with the original songs, leaving that space free to be modified.

CHR: The graphics of a character require approximately 40k-CHR and for the complete set around 120k-CHR, on the other hand, for their endings they require between 6k~12k-CHR.

The game engine has a power-on self-test program, if this were removed, it would be possible to reuse this space to program a VS screen closer to that of the Arcade.

ROM: 128K PROM +  512K CROM (Original)
ROM: 256K PROM + 1024K CROM (Modified)

Originally these were my plans, since, if the engine is completely deciphered, the game could be recompiled, opening up many possibilities, be it modifying the VS screen, redrawing the scenes or adding new characters and more!!

And currently the MMC5 mapper is the only one that supports that capability or maybe my research is wrong 

NES Space Checker (Capture)

Our idea is to start initially by improving all the present content and although all the limitations mentioned are true, we must not forget that there is a large margin of resources that can be optimized.

For example, although the type of compression that this game uses for nametables is great, if you analyze it carefully you would notice that there are many cases where its implementation is not optimal, the most obvious case of this is when you cut a string to compress five numbers or less, it is not useful to compress two numbers, if two numbers are needed to do so

Or in the case of graphics, it is evident that each scenario has been created separately with some automated method, since if they had managed the cut-off points of each one they could have shared part of their graphics, freeing up more space.

Obviously thinking that we can meet our goals in this way is just speculation, but there is always the possibility of expanding the rom, others in my case would not have doubted it, but I like to work thinking that I am really developing a NES game with all the limitations that this implies

BZXGCS
What good voice samples this game has, about the controls, the only difficult thing is to locate where this data is, but as I mentioned earlier, we do not have enough human capital to go overboard planning new features, not if we want this project to come to fruition, like this that time will tell

Regarding collaborations, certainly this issue does not depend on us, but on the interest of others in our project.

More taking into account that the benefits of doing a job like this are almost nil, you invest hundreds of hours, weeks and months, so that later your hack is eventually forgotten or marketed by people completely unrelated to you

That is why I do not blame people for not forming a line to collaborate with these kinds of initiatives

[sebastianangel]

I like the idea of ​​sharing parts of the scenarios !! and working as if it was being done to make it work in a nintendo orginal software!

[cartridge_rom]

greetings, any news or small advance ? 

[4lorn]

PRG: Currently, the data to manage the sprites of a fighter occupies 8k-PRG, therefore, if you want to add three additional fighters, you will need to have 24k-PRG (And if we also included Ken, a total of 30k-PRG would be necessary)

Not being a programmer I have no idea if this can be done, but can't Ken simply share the same sprites as Ryu, other than his hair? IIRC, that was even a running joke about Street Fighter 2 for a while, because other than some sounds and animations at the end of a fight, Ken was virtually a palette swap of Ryu.

[sebastianangel]

greetings, any news or small advance ? 

Hello, thanks for following the thread of this project and always being with good proposals and suggestions, I tell you the project goes ahead, we take a few days for other projects that we have simultaneously and waiting for the sound experts to join, which would be the finishing touch of gold for this great game, it is not ruled out those who have a deeper knowledge in ASM, to modify things that are beyond my reach,(4lorn) regarding ken's hair is something complex to achieve a satisfactory result since they are shared sprites Between characters they also share color palettes with their own body, and it is not just changing the color, the type of hairstyle is different and certain moniments too. As the saying goes, if you are going to do it, do it right! So it is preferable to take a little but arrive at a result worth all the effort!

[cartridge_rom]

This is good news, all the users who are contributing to the project do an incredible job for the NES console, thanks

[sebastianangel]

Here testing a new scenario for chun lee, I passed in 30 tiles I see if I can lower the amount, the good thing I use only one sheet, it is a wink at the end figth 2 of snes

[sics]

Hello, I am reconditioning my workspace and in a few days I hope to continue with this great project

Regarding the scenario test, I do not think it is at the level of the rest of the graphics of the game, remember that the original scenarios use an average of 3 128x128 tiles, and if necessary you can have up to 4 tiles.

For the same reason, if you try to limit the amount of graphics you use too much, the result will be affected

About the proposal to manage the graphics in a different way so that Ryu and Ken can share part of their designs, although I am not a programmer, it sounds possible to me.

First, it could simply be changed from BankCHR, also the body and the head could be managed as two different characters and even if we take into account that in this game for the title screens there are values ​​that depending on how high they are represent one instruction or another, in In theory it would be possible to program something similar to create an identifier that defines which sprites should be loaded by one character or another

[90s comeback]

Sics! I am very amazed by the playful way that exposes the changes. There is a tutorial explaining how the changes were made to this screen, both the new sprite distribution and the color palette changes.
I do some hacks, but my knowledge is limited only to yy-chr and simple color changes.
Thank you!

                                                                                                                  Can you please tell me where can i find this tutorial you are talking about?, wanna learn how to do this kind of stuff, thanks.

[Xander max]

Nice picture!  Much better!  Any news Sebastian ?!

[4lorn]

About the proposal to manage the graphics in a different way so that Ryu and Ken can share part of their designs, although I am not a programmer, it sounds possible to me.

First, it could simply be changed from BankCHR, also the body and the head could be managed as two different characters and even if we take into account that in this game for the title screens there are values ​​that depending on how high they are represent one instruction or another, in In theory it would be possible to program something similar to create an identifier that defines which sprites should be loaded by one character or another

Like I said, I'm not programmer but the idea made sense based on what Capcom did for SF2. Regardless of the way it's done by the team working on this NES version, I'm sure it'll be great.