Help - Porting PC RPG Maker Game to SNES

[Fiskbit]

You'll certainly find a range of opinions on this topic, but I think it makes a lot of sense when targeting a legacy platform to also consider (at least to some extent) the display that is intimately tied to that platform, regardless of how most people play today.

[GValiente]

It's not like better shading looks worse on CRTs, right?

[93143]

It's not like better shading looks worse on CRTs, right?

It's kind of a waste of resources. Eight sprite palettes isn't as many as it sounds like for an RPG.

And frankly, I like my version better (it might be a bit dark in spots, but that can be adjusted; right now the palette is the same as rtp-bpp4 with the dark green split into two and the full black removed). The original looks as though the artist was distracted by the ability to use a ton of colours and forgot about contrast, so it looks oddly flat and the outlines stand out too much. It's also plainly designed for a display with sharp square pixels, and the fineness of the palette is out of proportion to the resolution of the sprite. The pixel remaster of FFVI has the same problem - both it and this are imitating the style of FFVI without respecting the technical limitations that made that style what it is. It's fakebit, and looks it.

This could be considered a matter of taste, I suppose... If you can make it work on a real SNES, it's not fake any more. I question the need.

(Also note that even I didn't respect the full software specifications of FFVI. It seems they saved a few indices per palette for something else, so the character sprites only use 11 colours - four colours for the clothes, two each for the hair and skin, off-black for outlines, off-white for highlights, and a single eye colour. Some characters use even fewer, and some share palettes with each other. I don't feel like trying to rejigger this dude to fit into that scheme right now...)

As for the output device, every decent modern emulator has an NTSC filter anyway, so you don't need a real CRT to approximate the results of the analog video signal a real SNES puts out. Using sharp square pixels is objectively inaccurate, and anyone who does that deserves the consequences.

...

I wonder if an RPG Maker port would need HDMA for anything much... Assigning a single channel to each character palette could allow you to change up to one colour per scanline per character, which would enable stuff like reusing the hair and eye colour indices for the pants. Extensive use would restrict your ability to use HDMA for anything else (there are only 8 channels, so one per sprite palette uses all of them), and sharing palettes between characters would become difficult or impossible, but technically it's an option.

[turboxray]

Although what you have posted look much better than my quantization (especially the minimum variance one), they still don't look good enough for me, there's always some missing shading

Then I would question why you're on a retro forum or into retro dev??? Old systems have limitations. It's just a matter of retro dev life. I think the conversions hold up/pretty decent.

[tepples]

Would you recommend a resource on the web to learn about the technique you're talking about?

https://en.wikipedia.org/wiki/Dither#Algorithms
https://cv.ulichney.com/papers/1988-blue-noise.pdf
https://cv.ulichney.com/papers/1993-void-cluster.pdf
https://blog.demofox.org/2019/06/25/gen ... d-cluster/
https://momentsingraphics.de/BlueNoise.html
https://surma.dev/things/ditherpunk/

Thank you. By the time I finished reading the article behind the fourth link, I understood what was going on with generation of a blue noise matrix:

1. place a point for threshold level 1 in the center
2. generate a dozen random points that have not yet been assigned to a threshold level
3. place the point for the next threshold level at the least crowded among those points, with "crowded" defined with respect to distance in the tile grid
4. repeat step 2

[Pokun]

Keep in mind, the target display device isn't a 4K OLED monitor

Are you sure? How many players are going to try your homebrew on an old CRT, instead of their laptop?

You'll certainly find a range of opinions on this topic, but I think it makes a lot of sense when targeting a legacy platform to also consider (at least to some extent) the display that is intimately tied to that platform, regardless of how most people play today.

Yeah there are many opinions and while trying not to sound CRT-elitist, I think most would agree that targeting the original environment of the system pretty much always makes a lot of sense and is more future-proof.
As 93143 said there are NTSC filers, scanline generators, CRT-glow simulation and other effects used by emulators and display devices, and with modern 2K or 4K monitors more possibilities opens up as they can reproduce these effects better.

If the user have some way to play a video game system, he might have access to some way to replicate the original type of monitor that all licensed games for the platform already targets, so it would only make sense for homebrew to do that too.
If the user doesn't have access to that, that is fine since he can't play any game for the system in a more authentic way anyway. People normally doesn't play old game systems just to play our homebrew.

[93143]

I don't feel like trying to rejigger this dude to fit into that scheme right now...

Okay, here's an attempt in 11 colours. It's a lazy attempt, starting from the hand-optimized 15-colour version I posted earlier; I just removed all the light red and light blue, and harmonized the two dark greens and the gray into a single colour, with appropriate tweaks to cover the losses.

I think it looks okay. Certainly more idiomatic than the original, although I can absolutely understand somebody preferring the original's bright colours and subtle gradients. Again, my version is a bit dark and desaturated, even more so than before (though arguably the original is too bright and oversaturated...), and some tweaking of RGB values might be warranted.

...although it occurs to me that I've messed up again. The light skin colour is used for the hair, and you absolutely cannot do that in FFVI or the hair will look weird when your character is Berserk...

EDIT: Botched his shoulders, fixed/reuploaded. They're now 100% skin tone with no hair/vest.
EDIT2: Messed with his pants a bit. I feel like the front and back walk frames are improved...

That's better. Pretty sure skin tone only shows up for actual skin, and I've brightened up the colours too. This should be fully compatible with the Final Fantasy VI palette scheme now, unless there's some other subtlety I've missed...

...

When I was first considering my shmup port, I was sketching out all sorts of stuff the SNES could technically do, but which wouldn't fit together with everything else that needed to happen at the same time. As the planning went on, I was forced to downgrade a bunch of stuff so the game would work. If I were porting an RPG Maker game to the SNES, I'd probably want to focus on getting the game to fit on the system first, and take stock afterwards to see if there are spare resources that could be put towards making it look better than it should.

[GValiente]

Although what you have posted look much better than my quantization (especially the minimum variance one), they still don't look good enough for me, there's always some missing shading

Then I would question why you're on a retro forum or into retro dev??? Old systems have limitations. It's just a matter of retro dev life. I think the conversions hold up/pretty decent.

I can't ask for more colors and/or better shading because I'm into retro dev? Of course old systems have limitations, that's a big part of the fun.

I also think most of the conversions posted here are pretty decent, but I would prefer doubling sprites count to have 30 colors per character instead of 15.
If others don't like this approach, it's fine too, so where's the problem?

Yeah there are many opinions and while trying not to sound CRT-elitist, I think most would agree that targeting the original environment of the system pretty much always makes a lot of sense and is more future-proof.
As 93143 said there are NTSC filers, scanline generators, CRT-glow simulation and other effects used by emulators and display devices, and with modern 2K or 4K monitors more possibilities opens up as they can reproduce these effects better.

I also think that new SNES homebrew should target the original environment, but I think nowadays you shouldn't ignore shading issues by thinking that a CRT is going to hide them, or that users are going to enable a CRT filter that hides them.

Most emulators don't enable a CRT filter by default, and that's the setup most people will use to try new homebrew (I think).

[tepples]

Say you do use 30 colors per character. Now you're limited to four characters per scene. If you exceed that, do you flicker the characters so you can draw four characters with their respective 30-color palettes in one frame and then the four other characters with their respective 30-color palettes in another frame?

Another way is to have 15 colors shared across all characters and one set of 15 character-specific colors per character. This increases the number of simultaneous characters without needing to flicker to seven.

[GValiente]

Another way is to have 15 colors shared across all characters and one set of 15 character-specific colors per character. This increases the number of simultaneous characters without needing to flicker to seven.

That's what I proposed in the previous page:

If I had to show RPG Maker 2K characters on the SNES I would do a Megaman: two sprites per character, one for the skin colors and the other for the rest. The palette of the first one could be shared between all character sprites, so palette usage would be more or less the same.

[turboxray]

I can't ask for more colors and/or better shading because I'm into retro dev? Of course old systems have limitations, that's a big part of the fun.

I also think most of the conversions posted here are pretty decent, but I would prefer doubling sprites count to have 30 colors per character instead of 15.
If others don't like this approach, it's fine too, so where's the problem?

Just for clarification, we're talking about every character.. not just the main character, right?

[GValiente]

I can't ask for more colors and/or better shading because I'm into retro dev? Of course old systems have limitations, that's a big part of the fun.

I also think most of the conversions posted here are pretty decent, but I would prefer doubling sprites count to have 30 colors per character instead of 15.
If others don't like this approach, it's fine too, so where's the problem?

Just for clarification, we're talking about every character.. not just the main character, right?

It would be good for most characters, when 15 colors are not enough.
But for example if you want to render an army and you want more characters per scanline, using a single color palette for them should be better.

[Pokun]

It depends on the game that is to be ported of course, but I think RM2K can fill the entire screen with "map events" (which are whats used as NPCs) without problems (there is a limit of the number of events per map but it is quite high) so it's quite easy to exceed SNES limitations if you want to.

A scene with an army or something might of course be reproduced in other ways, such as using tiles or a mix of tiles and sprites to increase the number of colors.

[GValiente]

There's tons of ways to exceed SNES limitations with RPG Maker 2K if you want to.
For example, all pictures have their own 256 color palette, zoom level, transparency level, etc.

[Colin Sandquist]

[/quote]
. RM2K/RM2K3 uses SNES-like limitations so it might be possible but RMXP uses a higher resolution than the SNES can output so you are definitely going have to redraw the graphics of the game in a SNES-compatible resolution, and there is also the Ruby interpreter that I doubt is going to be ported to SNES and run at the same speed as on an IBM PC from 2004 or later. If the game you want to port doesn't use any Ruby scripts it might not be a problem though.


For the RM2K/RM2k3 Ports - Maybe I should ditch the idea of putting it onto the SNES because of the graphics problem alone?
Because it would take up too much space. Each game I know carries about 700 MB of Data I think - so It can get on a Windows CD -
But no way on a SNES Game? I don't know how to compress the graphics to give it that very old school look.


That's a huge shame really.

Also: you are talking to someone that has zero skills in what your
knowledge is: you are all probably experts ... to me its a question of time and if its worth investing taking months trying to figure this
out and learn, or even possibly, years. Because the majority of this forum is starting to make zero sense to me.


What about porting the games to playstation 1 or 2?
I'd be okay with that!


I've got Windows CD Copies made. I know I can sell PC Copies. Problem is: my video game store guy said there is zero
market for it. Maybe a market if It was released on the PS1 or PS2.


If I could port the game on the SNES and sell it CIB - he said I could get 100$ for each game. Not Bad, considering
I only want to release a limited amount. And I am getting tired of figuring out ways to fund my projects. I truly love what I do,
and I just wish I was all wise and knowledgeable to do these things myself but time on earth is limited for everyone. Kind of sucks.


And Its a shame - I got the SNES Boxes custom printed.
And don't worry - I got express permission and copyright confirmation from Kadokawa games And Go Go Games,
so the issues of licensing and re-selling at a store are not an issue at all.

Anyways, thanks for the help everyone. I will note this entire help board and do further investigations, but because of the SNES
limitations, may be a dead end. Then there is the game size and graphics problems alone. As for the music, I do my own music
but would have to also compress the music into a bit format. Could also ruin the music. Yeah - just a lot of problems.