KingCoin

I can make it so only the edges are smoothed. This is how it looks:

It's still the original. I can create a new version if you'd like however I made it so the program accepts some different settings now so I'm not sure which version of the pack you would want. There are a few trade offs that can be made, one of which is either I can preserve more detail (size of eyes for example) but have a more pixelated result in the end or make the textures smoother but some details shrink.

I've posted what I believe to be a working version of the program which you can use to create a texture pack for any game where you have access to the png files. You can find it on my original post which I've edited. Let me know if you find any issues with it, I haven't really tested the latest version. In other news, I've apparently been permanently muted in pokemon insurgence chat because the developers felt I insulted them by creating a tool to fix their scaled textures which they feel implies I think they're bad artists even though I never said that.

Thank you, I'm glad you like it.

Yes, it worked on that image:

If people want me to I will. I'll release the program once it is working better.

I'll try it when I get a chance but one thing I don't really like is how common shinies are. I'd prefer if they were still 1/8192 or if they had the fanmade shinies at the current rarity and official nintendo shinies at the 1/8192 chance. I like having something rare to find.

Here's a download link for the latest version if you want to test it. I've given it a threshold of + or - 10 for comparing pixel colors when smoothing. Please try it and let me know if you notice any new issues or if you notice that some older issues are fixed. It should also change the overworld tiles and make them smoother than before but there may be issues with that change so I'd like to know. https://drive.google.com/open?id=0B0muzpfLQvV4V1FncGFJUm9HX00

Also, if someone could give me a fairly progressed save file(assuming that's allowed here) I could test things easier myself. I haven't actually played this game before past the first battle. I originally created this program for pokemon insurgence but wanted to share it with more people that could enjoy it and had already received requests for some other fangames so I came here.

I currently have no idea how to fix the issue, I've spent a few hours trying to fix it and I haven't been able to find what differentiates the few images it doesn't work on from the vast majority that it works on. I'm using a method called getRGB() which you pass pixel coordinates and it gives you the RGB color value of the pixel at that location. When I call getAlpha() on it(which should give me a value between 0 and 255 where 0 is fully transparent and 255 is fully opaque) it gives me a value of 255 even though I can see the area on the original image is entirely transparent. I've made a post on a programming help forum to see if anyone could help me figure it out but there hasn't been a response yet. I'll try making the changes to the program to allow for similar colors. It will probably also have some of my new changes for smoothing as well. I'll try to post a complete pack with the new changes and you guys can copy just the box sprites from it if you want or install the entire pack if you want to help me find any new issues created by the changes.

I think the issue with boxes around sprites is something to do with the original texture file. Simply taking the original texture and copying it into another blank image turns all the transparent areas opaque. It doesn't appear to be related to transparency color as I originally thought. I'm working on figuring out a fix.

Alright, I've looked into the gen 6 box sprites issue and what I've determined is that my program does smooth them a little bit but it's not super noticable. The reason for this is that for whatever reason, these sprites appear to be made up of a ton of similar colored pixels instead of solid colors. So for example, the brown part of litleo isn't one shade of brown, almost every pixel is a different shade of brown. Here's an image that shows a before(left) and after(right) of an earlier generation sprite and a 6th generation sprite: If you zoom in on the image in an image viewing/editing program you'll see the difference between the initial sprites for each generation. My program smooths pixels that are the same color together. I can easily make it check for similar color pixels instead of pixels that are the exact same color but it may make the sprites lose detail or blend incorrectly(perhaps it will say the eye is similar color to the face and delete the eye). I could try this change if you want. Do you want me to?

I don't see a double post either but here's what I've found when I was looking into the shiny dustox sprite issue. I downloaded pokemon reborn and when I look in the graphics/battlers folder there doesn't appear to be any texture files at all for shiny female dustox. My program only modifies the files it gets so it didn't modify the shiny female sprites because they didn't even exist. Are you sure you didn't at some point use textures copied from another game or in some way modify your texture folder before installing my texture pack? It's not possible that my pack gave you those images, I just downloaded my pack and I don't see those sprites in it at all. Anyways, it looks to me like pokemon reborn doesn't naturally have separate sprites for female shinies vs male. I could actually have my program generate shiny female sprites using the colors from the shiny male sprites on the non shiny female sprite but I consider that to be a less major issue than some of the other things I need to fix like this issue with some sprites having a box around them instead of transparency.

I think I might know what causes this. I haven't figured out how to fix it yet but this occurred one other time on an image I was testing with and what was happening in that image was it was making the background pink instead of transparent similar to your image where the transparent parts have become black. I believe what causes this is an image is when the image uses any fully transparent color besides white. I tried to fix this earlier but after about an hour of messing with it I wasn't able to make it work properly and I gave up because I hadn't actually found any actual game textures that had this issue. I'll look into ways to fix this later now that I know it does seem to affect at least one texture in an actual game. My fixes I was messing with earlier seemed to me like they should have fixed the issue but for some reason they weren't. I use the same alpha(transparency) value for each pixel as was in the original image so this shouldn't be happening. It's a strange issue.

You're right. That does appear to be the normal shiny sprite which seems odd to me. This is what that sprite looks like after my program ran on it for pokemon insurgence: Here are the shiny sprites I see in the folder that contains my texture pack though: Those are both in the folder as they should be for me so I have to assume you somehow didn't copy them in properly when you installed the texture pack. I'm not sure why you would have the sprite you currently have unless I somehow packed the wrong sprite into the archive file for the pack. If you download these two images and name the back sprite 269sb.png and the other one 269s.png you should be able to put them in your graphics/battlers folder and replace the current images with the same name with them to fix your issue with that particular sprite. I'm still working on the box sprite issue.

I see what you mean with the gen 6 box sprites however dustox looks fine to me. The shiny portrait is fine and the game doesn't appear to have separate box sprites for shiny and non shiny if that's what you were talking about.

At the moment the program has about 1,200 lines of code although I admit that a lot of the code could be written better and some is repetitive or unused. It's written in java so to use it you would need to have java on your computer. The main reason it's not easy to distribute at the moment is that it currently lookes in a "textures" folder inside the directory of the project and uses that folder for input. When you run the program it prints information about what it's currently doing to the console/terminal and traverses the textures folder recursively converting all the textures it finds. When a texture is converted the program first tries to convert the entire texture image at once, if it can't improve the image then it divides the image up into 32x32 pixel sub-images and tries to smooth each individual sub-image, then rebuilds the original image and saves the changes. Images which could be improved are saved to the "results" folder in the same directory as the textures folder and automatically saved in a directory structure the same as it was taken from in the textures folder. Images that couldn't be improved are saved into the "rejects" folder. There are several operations I apply to the images but the main ones that it does at the moment are: 1. getOffset() - determine the offset of the sprite in the image from the edge of the image. (some sprites which have been scaled to 2x size were put an odd number of pixels from the edge of the image, some were put at an even number of pixels from the edge. 2. getImageScale() - determines the scale of the given image (if it has been resized to 2x normal size, 4x normal size, etc) 3. shrink() - this is only called on images which have 4x scale to convert them to 2x scale, they are later resized after smoothing/sharpening 4. sharpenImage() - loops through every other pixel in the image(skipping a pixel between each pixel it checks) adding pixels between any two pixels that are diagonal to each other whose shared adjacent pixels are not the same color. 5. smoothImage() - loops through every pixel in the image and adds a blended pixel between any diagonal pixels of the same colors to smooth the edge(Tricks your brain into thinking it isn't jagged like a staircase even though it technically is) This image illustrates the process on an image which has 2x scale detected. The middle image is after sharpenImage() is applied. So when I want to create a texture pack I simply do these steps: 1. Paste the entire graphics folder for the game into my textures folder. 2. Compile and run my program. 3. Navigate to the results folder. 4. Pack the newly created graphics folder from the results folder into an archive file. 5. Upload the archive file. What makes the program difficult to use in it's current state is that if I were to release it as a runable jar file that anyone could use, The textures folder and the results folder would be packaged into the runable jar file and the user couldn't access them(I'm pretty sure). They would also have to know how to run it with a terminal so output could be displayed if they wanted to be able to know when the program was finished converting (It takes quite a while to convert every texture, for me it's as much as 15 minutes). I'm not really an expert programmer(still at university for another year, I've probably only written like 500,000 lines of code in my lifetime) and I thought of the process while taking a shit then wrote the code in a night so I'm sure some things could be implemented better. If you have any ideas let me know. At the moment I'm thinking I could allow people to choose the location of the textures folder and the results folder by inputting it in the terminal but that would still require them to launch it from a terminal. As far as changes that I intend to make: 1. smoothImage() is currently not called on tiles to avoid making them no longer line up properly or blending them with nearby tiles in their respective texture file. I intend to make some changes to prevent issues it may cause with tile alignment and start calling this method on all textures including tiles. 2. I intend to make the program work better in situations like this:

Thank you for the information. I haven't had a chance to look at the gen 6 pokemon sprite issues yet but I believe I've fixed the small eyes thing in my latest version of the code. I probably won't post a version of the texture pack with this change though until I look into the other issue you mentioned and see what I can do to fix it first. If you're curious, the small eyes issue stems from an issue I've had for a while. My algorithm tries to smooth corners and diagonals. A lot of things have eyes which are just a 2x2 square of pixels so my program would detect that there was a corner on the eye and replace the tip of the corner with a blended pixel. It did this for all 4 pixels in the eye because they were all detected as corners and left the sprite with a faded or removed eye/eyes. I've made a change that makes sure my program can't remove details from any textures anymore so that particular issue should be fixed.

I'd be willing to do that however not in the program's current state. I think I can improve the textures a lot more than I do in the current version with some changes I thought of recently and the program is currently too hard to use for anyone without a programming background. I don't have time to improve the program right now but I'm definitely willing to release it in an improved version when I get the time as long as I keep seeing interest in such a thing. Also, I'm glad you like it so much! It's good to know when people appreciate your work.

Could you tell me which pokemon(by name) specifically? My program says "Improved a total of 7681 textures, 338 could not be improved.". So almost all textures should have been changed.

Thank you, I'm glad you like it.

Isn't this already in the fan game expose?

Ok, I've gone ahead and created the texture pack. Please tell me if I should put it in another section of the forums besides this one. I've edited my original post with the file. Also, if anyone is interested. I can apply this process to any game in existance that uses png files for textures so if you have another fanmade pokemon game or something you think would benefit from my work, let me know.

My changes don't affect performance at all. It doesn't increase the resolution of the images, it just fixes their pixelation from being scaled.

Yes, it would do the best it could with the limited pixels there are originally on overworld sprites. The program currently smooths them this much and intentionally doesn't smooth overworld tiles as much as all the other textures because I thought it might mess with how the tiles line up in game. I never actually tested to confirm if it would have that negative effect or not though.