The Spriter's Toolkit

[Kelvin]

Ohhhh, I see what you mean now. Hadn't thought of that. Hmm... Well, some options come to mind: having it lean towards either the lesser or greater hue. And it could also be made to lean towards warmer or cooler colors, or one of greater or less saturation. There's lots of ways weighting could be determined, and, yeah, checking manually would really be a chore just to sort out a few equidistant colors.

[puggsoy]

Yeah. There should be a range of options but I guess leaning toward lesser or greater hue is probably the simplest way and should maybe be the default. Anybody who specifically wants it done is a particular way can just go ahead and do it manually.

[Kelvin]

OK, so I got some time to code this weekend, and decided to work on SNEStify a bit, since I think it'll be the easiest one to start with. And heeeere's my first debug log!

Code:

>:Initializing program...

>:8
Argument count: 2
>:F:\C++\CodeBlocks\SDL_SNEStify\Debug\SDL_SNEStify.exe
>:F:\C++\CodeBlocks\SDL_SNEStify\Debug\herdvsswarmderp.png

>:36
Loading image: F:\C++\CodeBlocks\SDL_SNEStify\Debug\SDL_SNEStify.exe...

>:37
Image failed. Retrying...

>:37
Loading image: F:\C++\CodeBlocks\SDL_SNEStify\Debug\herdvsswarmderp.png...

>:38
Image failed. Retrying...

>:38
Image failed to load. Surrendering without a fight.

Yeah, for some reason, IMG_Load() from SDL_Image can't understand a full path when an image is passed as an argument. The reason why it tries to load itself as an image is because, for some reason, when you drag an image onto an executable, the EXE path becomes the first argument, so I set it to go through all arguments and search for an image. It's obviously finding the image; just not loading it. So now I have to figure out how to get around this path issue. I considered just trimming the path off and only passing the file name, but what about files that aren't in the same folder as the EXE?

I need to figure this out, because this same method is going to be used in my tileset digester. Here's the actual image loading code:

Code:

//Create the work image
for(int i = 0; i < argc; i++){
    sFileName = args[i];
    fprintf(fLog, ">:%i\nLoading image: %s...\n\n", SDL_GetTicks(), args[i]);
    image = IMG_Load(sFileName.c_str());
    if(image != 0){
        fprintf(fLog, ">:%i\nImage loaded!\n\n", SDL_GetTicks());
        break;
    } else fprintf(fLog, ">:%i\nImage failed. Retrying...\n\n", SDL_GetTicks());
};

Any ideas anyone?

[puggsoy]

What if you try load the file as just "herdvsswarmderp.png" (by hard-coding or something)? What about from a relative path? And can you print the error? (IMG_Error() is what I'm finding online.)

What I'm basically saying is, make sure that the issue is due to the fact it's loading from an absolute path and not something else. I've been Googling around and I'm seeing no indication of an absolute path being a problem (in some cases it's even a solution to a problem).

[Kelvin]

I would try converting the string to a relative path, but then that raises the issue of what if someone drags an image from another folder? I'll check and see what IMG_Error() reports and post that here. I was also thinking of changing it around so the image editing is part of the argument loop, which would make it edit every valid argument it finds; basically allowing for batch processing.

[puggsoy]

I meant just try using a relative path temporarily, to see if it loads at all. That narrows it down for you to tell whether it's an issue of the string being an absolute path, or something else. If it doesn't load with a relative path, then you know that it's not related to the type of path and that the issue is elsewhere.

But yeah, hopefully IMG_Error() sheds some light on it.

[Kelvin]

I had forgotten to put libpng.dll into the debug folder, since VC++ can't just use one folder and stick with it, so it's loading now. I'm getting an access violation, however, so I think it might have something to do with the direct pixel manipulation, making me think I missed a step somewhere. I'll check out my old code I did for XYG and see what I missed, but I have a good feeling I'm about to make this work. Thanks for the advice, all. If it turns out it's still not loading properly, I'll try making it just load a local "input.png", and then have the GUI automatically handle renaming a temporary file in the EXE path, which should handle everything.