[Klarth]

So I've had a few new romhacking-related ideas in my head over the past few years. I won't give details here, but each would be an upgrade significant enough to make the current utilities of choice obsolete (monkey-moore, CrystalTile2 / Tile Molester). I believe I can write a romhacking guide better than what's available, but not sure if it would be as transformative as the others. Let me know what you guys think.

[hanhnn]

A graphic editor that can support bitmap imported and produce the correct order of color palette

[dougeff]

And cut and paste from the clipboard. And import / export an indexed format like .gif , .tiff, or .png.

I don't care about .bmp which is RGB...it makes sense that RGB will have their color screwed up.

I suppose ypu could reduce any RGB image to its relative brightness, as if it were B+W image, and use brightness to create an index into 2bpp,4bpp indexing.

[jink640]

It would be nice to have a monkey-moore type of program that would work with japanese characters. Every time I try with MMoore it screws stuff up 

[SleepyFist]

Ive been using Tile Layer Pro with two roms open at a time, Zelda, and a "Blanked" rom for graphics storage and editing in place of the arranger, would be nice to have a graphics editor utility that has an saveable arranger that works the same way as storing in a blank rom,
Multiple switchable palettes would be cool too.

and this

A graphic editor that can support bitmap imported and produce the correct order of color palette

[FAST6191]

It would be nice to have a monkey-moore type of program that would work with japanese characters. Every time I try with MMoore it screws stuff up 

Japanese does not exactly have a relative order to search with though. You kind of have something with kana but there are enough variations between cases, punctuation and such that they are hardly set in stone.
Monkey Moore has a kind of annoying to use hex relative search so I guess you could find the font and try a font order type search, though that is usually the opposite way people go. Then again it might be the opposite way because it is a pain to use.

[Klarth]

Japanese does not exactly have a relative order to search with though.

Actually the method I have in mind builds upon relative search and is way more elegant for the end user. The end user would still need to manually identify the often out-of-order characters, control codes, and kanji, but finding a representation of the main alphabet is more than half the battle.

And import / export an indexed format like .gif , .tiff, or .png.

I suppose ypu could reduce any RGB image to its relative brightness, as if it were B+W image, and use brightness to create an index into 2bpp,4bpp indexing.

I don't see the point of specifically .gif, .tiff, or .png. BMP can be palette-indexed at a specific power-of-2 bpp's. Additionally, the program would likely generate a configuration file for reimporting the graphic back into the game that would take care of RGB->game palette, file location, and any other required info.

[STARWIN]

more elegant

It doesn't matter what you have in mind, this alone sounds like fun.

[BlackDog61]

Since we're asked for a wish-list I'd go script analysis first.
Better guide to RH would come next in my mind.
Though they can be improved, graphics tools have done what I wanted from them so far (or I created my replacement scripts from edited BMP's when it was not the case).

[VicVergil]

Anything PS1 related, especially manipulating graphics and textures (to help fix the 12px fixed width fonts, or move stuff around the screen).

[Gemini]

A generic purpose library for hacking, maybe? Like a class to manipulate text and images. Anything task-specific usually falls behind pretty quickly, becoming obsolete as soon as your topic of hacking starts using complex formats or structures beyond logical blocks of continuous data.

[shadow501]

Good idea to make graphics editor for PS1 because unitl now no tool for it.

[Klarth]

A generic purpose library for hacking, maybe? Like a class to manipulate text and images.

I already have TableLib that was released a long time ago. It's gotten some use, but maybe not as much as I had hoped. Mainly because it's in C++ and doesn't have a C# or python interface.

Image manipulation is interesting, but a library alone would defeat the purpose of why I would make a graphics editor -- for some specific features that nobody has made yet. It's more of a usability gripe than image decoding/encoding limitations. Though those certainly exist and I would try to address them, at least from the tile editing perspective. Linear modes may not see as much improvement.

Good idea to make graphics editor for PS1 because unitl now no tool for it.

PS1 graphics are going to be difficult to deal with regardless. TIM is more of a guideline than a standard in many games. A lot of graphics is behind compression. Browsing through large files looking for graphics in linear modes has limited success because you need to get the location and image width pretty spot on or image data will be completely unrecognizable. I'm really not sure how to significantly improve upon what's currently out there given these circumstances.

[STARWIN]

Browsing through large files looking for graphics in linear modes has limited success because you need to get the location and image width pretty spot on or image data will be completely unrecognizable. I'm really not sure how to significantly improve upon what's currently out there given these circumstances.

I'm not a graphics hacker so I have no idea what I'm talking about, but couldn't a program search for the exact location by using something from the emulator output (like taking a piece of a screenshot manually and using it as the search "string")?

[Klarth]

I'm not a graphics hacker so I have no idea what I'm talking about, but couldn't a program search for the exact location by using something from the emulator output (like taking a piece of a screenshot manually and using it as the search "string")?

That approach would have some success in specific settings, but you shouldn't use screenshots (even at native resolution and unfiltered) in a PSX game because textures are drawn on rotated/stretched triangles. You'd need to take the texture data out of VRAM to have a shot. The algorithm would need to allow for data gaps in between image lines to account for image strides and whatnot, but it could be reasonable in games without any sort of compression. Seems like a cumbersome method with not a lot of payoff. Reminds me of searching for SNES palettes, just less successful.

[shadow501]

I don't mean TIM Viwer or else, I mean like yy-chr-chr..etc

[Gemini]

I already have TableLib that was released a long time ago. It's gotten some use, but maybe not as much as I had hoped. Mainly because it's in C++ and doesn't have a C# or python interface.

I mean a more comprehensive library, not just to manage encoding and codepage. Something a bit more complex, like an xml parser for complete dumps and meta data required in more advanced projects. That would leave the user with a better dump format that can be integrated in a greater application with ease.

Image manipulation is interesting, but a library alone would defeat the purpose of why I would make a graphics editor -- for some specific features that nobody has made yet. It's more of a usability gripe than image decoding/encoding limitations. Though those certainly exist and I would try to address them, at least from the tile editing perspective. Linear modes may not see as much improvement.

A bitmap class for manipulation is the way to go here, something that can grab and impress pixels in an abstraction layer to keep all the math away from the final user. For example, you create a generic Image class wrapper that  can be used to replace data and saved to a custom format. Say, you start from a PNG/BMP loader and then the user can override a virtual method to save the new data required by a game. I've been using something like this for years, it's quite useful when you don't wanna use editors that follow either a weird standard or doesn't align with custom needs (say: Tilemolester easily messing up your palettes because it tries to match a 32 bit picture to indices that are easily missed or altered to make reinsertion fail).

[Klarth]

I have begun work on a graphics editor. This is the most ambitious project of the three (though the writing of a comprehensive romhacking document would take a long time). I will make a separate thread once substantial progress has been made. There are a lot of design considerations I still need to solve.

Additionally, the project will use C# / WinForms / Direct2D. This means Win7 (or Vista SP2) or above will be required. The decision to keep the codec core in C# or external in C DLLs has not been made yet. Performance will dictate that and I have not even started in that direction yet.

[aweigh]

A guide dedicated to explaining all of the hundreds of ways to go about extracting textures-with-text from games, how to edit them and with what software; how to convert them and back again into all of the different file types and finally how to re-insert them back into the game.

There really are NOT many good guides/FAQs that i've seen that really detail how to go about this and there are tons of ppl like me who have never edited an image in their entire life and more than that, have never extracted something from files that are not meant to be extracted from: bins and the like, and stuff that is compressed. Of course I know how to do this stuff now but I still know only maybe 10% of the subject.

I had to give up for the time being on the NDS rpg Wizardry: Asterisk because I just couldn't find any good guides on GBATemp that detailed how to deal with that games specific images. Sure, there are guides there on GBATemp about hacking and graphical hacking and the answer to everything is: LOL USE CT2. the problem is no one really explains how.

[Klarth]

extracting textures-with-text from games

Fonts are one of the secondary areas where I'll add some features if I have time, but the feature set is already ambitious as-is. I have a few ideas, but they are not as concrete or as universally powerful as my core idea for the editor.

For your case with text-on-top-of-textures (I think this is what you're describing), you need artistic skill. If you can extract from the format into BMP and reimport, then software like GraphicsGale will be very useful. You will basically need to "redraw" the underlying image to some extent, then layer the new text on top.