Originally posted by Spooniest:

Originally posted by Sh1nRa358:

Would be even better if FF Brave Exvius does all of the FFVI characters. Those sprites could be used in battle and would look awesome.

I also hope for these to be fixed:
-bright snow lacking detail like the original snow (out of battle)
-kefka fight music not continuous like it's supposed to be
-atma weapon not transparent (the sword)
- we need both version of the classic window back
- we need the classic ui graphics back (vines, choco, brick, etc.)


this guys work looks even better. Hope he does them all:
http://www.spriters-resource.com/resources/sheets/67/70091.png

I really think it was rude of you to post this. You don't have any manners at all.

Agreed.

Originally posted by Saftle:

Originally posted by Dangus ))<>(( Taargus:

but I never learned how to reverse the process after the code is compiled! How does one even get into it!?

Yeah, no idea on that one. It's pretty amazing what Nyxo and Krisan Thyme have managed to do with FFV and FFVI so far.

I talked to Krisan about it a few days ago, and he definitely seemed interested in working on this, but only after he tackles a few other projects. I would try getting in touch with him and see if he can give you a push in the right direction.

Thanks, if anyone can do it, it's him. And I am very excited to know you talked to him, as I don't like pestering people unless its absolutely necessary.

This is my last issue with both V and VI (Does it even happen in VI, I haven't looked yet), once this problem is solved, I'll be a happy boy. I think it's the last great problem SE left in the game...

Originally posted by Saftle:

Yeah, I feel the same way. An official fix would be awesome. I think all we can do is actively expand the group, and make people aware of what tools are already there for people to start modding, and what tools are needed, etc. Currently we have ALOT of members, but not enough threads where people are actively talking, engaging, etc. Talking about the mods would help spark interest.

It got to the point with my pixel analysis topic where I felt like I was talking to myself...so what I found is there for those that can do something with it... but after days with debuggers open, hex editors and the like, I gave up. Because I realized I didn't really know what to do with any of the data I was getting.

I taught myself how to program years ago... but I never learned how to reverse the process after the code is compiled! How does one even get into it!?

Originally posted by Saftle:

It definitely makes it less noticeable, but sadly they are still there if you are actively looking. I made it primarily for myself to make the game tolerable, and it definitely did the trick :D

It's definitely an upgrade eitherway, since the other effects bring out the colors etc.

Ok thanks, I was thinking about while I drove home, and realized that if anything were being "blown up" that it might end up removing the rim pixel, but then also reducing the tiles from 32x32 to 30x30... a not so desirable solution to fixing the, unfortunately still present, tile seam issue.

I really wish there were some more official way to fix it. I mentioned the opengl code in my topic about what we may need to change, but unfortunately I'm not skilled enough to implement the kinds of mods the Krisan and Nyxo used when they made the bilinear filter tools and they don't seem interested in going any futher with these types of mods.

Does this get rid of the 1 pixel seam around all of the world tiles that I talked about in my pixel analysis topic? I'm not home right now so I can't test it but of that's the case I'm super happy about it.

I found this thread that might point to what needs to be changed to remove the thin pixel border. Is this something somebody might be able to change?

http://stackoverflow.com/questions/19611745/opengl-black-lines-in-between-tiles

I've got say I think the consistent pixel size is way better. There's no logical basis for the large, original pixels to have a skinny border... it looks inconsistent.

Originally posted by BONKERS:

PPSSPP's texture scaling filters catch all of the textures before they draw most likely.
Because it's an emulator they can catch all that as it goes in and out easily.
http://blog.metaclassofnil.com/?p=306

If GeDoSaTo expanded support to OGL natively and the same texture scaling as PPSSPP was made available for any game. (Since he's the same guy who implemented it in PPSSPP)
You could probably get it easier
http://blog.metaclassofnil.com/?p=763

The result would end up being similar to if the textures were all ripped and batch scaled probably. But a lot less messy.

Ok, so it seems like the most logical thing to do is actually just contact him and see if he thinks he can add it into the list of GeDoSaTo perameters, instead of trying to reinvent the wheel for this one game, we'd be better off working on an getting another option included in the list for ANY game that supports GeDoSaTo.

Yeah so the solution to fix that would likely be the same as batch scaling all the textures... you'd have to add an alpha channel or extend the pixel border to accomodate the filter reading beyond the 'png' that constitutes the texture.

So hand applying pre-filtered textures, and fixing the black border, would create the same work load. I do find it intersting that a PSP emulator can handle this without issue though, I wonder what was done to get that to work?

Originally posted by SirNinja:

Hmm. This doesn't seem to work with Final Fantasy III. The game will crash on startup if OpenGl32.dll is in the game's directory at launch. The regular OpenGL.dll file will allow the game to open, but doesn't do anything. Any ideas?

Yeah I think the above solution is an interesting hack, but not a real fix.

Btw, the earlier post where I mentioned that the game was a DS rom, was only to point to the fact that the game's archives and files are types you'd find in a regular DS rom. So using those tools might work to mod graphics, but again, the issue is seeing if it can handle any changes to begin with.

Also, those black borders around everything are likely due to the textures not properly using an alpha channel or something typical with filtering algorithms.