New sprite conversion tool: Tilificator

A place for your artistic side. Discuss techniques and tools for pixel art on the NES, GBC, or similar platforms.

Moderator: Moderators

Bananmos
Posts: 552
Joined: Wed Mar 09, 2005 9:08 am
Contact:

Post by Bananmos »

I tried adding the path to path specifically, but unfortunately I still get the same error
Seems this sounds more and more like TheFox's hypothesis that other gtk .dlls are getting in the way. Again, I'd recommend you to remove those from the search paths by either renaming them, or moving them to some place you are sure will not be searched by Windows...
User avatar
Bregalad
Posts: 8056
Joined: Fri Nov 12, 2004 2:49 pm
Location: Divonne-les-bains, France

Post by Bregalad »

I renamed all the others from *.dll to *.d__ but I still have the same error.

EDIT : In fact even if I rename even the good dll in d__ I still get the same error.
Useless, lumbering half-wits don't scare us.
User avatar
tokumaru
Posts: 12427
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Post by tokumaru »

I wasn't gonna say anything, but the kind of problem Bregalad is having is one of the reasons I tend to avoid making tools that need frameworks, plugins and the like... These things are supposed to "just work", but sometimes it's just hell to figure out what's wrong. Good old native compiled code never presents these problems.
Bananmos
Posts: 552
Joined: Wed Mar 09, 2005 9:08 am
Contact:

Post by Bananmos »

I wasn't gonna say anything, but the kind of problem Bregalad is having is one of the reasons I tend to avoid making tools that need frameworks, plugins and the like... These things are supposed to "just work", but sometimes it's just hell to figure out what's wrong. Good old native compiled code never presents these problems.
This is going a bit offtopic and would benefit from a split, but I feel the need to say that getting stuck in ".dll hell" is commonplace on Windows and is hardly dependant upon using native compiled code or scripts/JIT compilation. Besides that, you are confusing and mixing up a lot of different things here in one sentence.

About native code:
Tilificator is written in Python, as it has been a project where I've experimented a lot with quite complex algorithms, and frankly would never have been able to finish it had I used "native code" instead (meaning C/C++ in these days as thankfully few people write their PC applications in asm)

Besides that, native code gives you the joy of "illegal exceptions" instead, leaving the user without any clues of where to look for answers as to your crashing application. That's more close to having "a hell to figure out what's wrong", if you ask me. :)

About frameworks:
Tilificator also uses GTK+, as it needed a GUI and GTK+ was the one I was most familliar with. Of course there are alternatives to GTK+, such as Qt, wxWidgets etc, each having their pro's and cons.

And no, none of their runtimes will come bundled with a Windows installation, so they all need some sort of thirdparty installation. Besides the fact that the Win32 widget framework is just horrible to use IMHO, I would not want to exclude GNU/Linux users from running my software just to make the experience of Windows users slightly smoother. I hope some non-Windows users will appreciate my choice.

About plugins:
Windows uses .dlls, so naturally it is the most natural way to use above said frameworks on Windows. And frankly I must say that for all the bashing that GNU/Linux usually gets, the package management there is really superior to .dll hell on Windows.

That said, my home computer which Tilificator is currently being developed on uses Windows 7, so I am surprised to see the difficulties people are facing, and am trying to investigate the reaons. But unconstructive picking on my choice of development tools isn't really helping much.
User avatar
tokumaru
Posts: 12427
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Post by tokumaru »

Relax, I wasn't "picking" on you. It's just that sometimes people think I'm weird for always wanting the simplest and smallest development environments possible, and I have a bit of trouble explaining why.

This was just a good example of the kind of thing I like to avoid, when making my own personal tools for my personal use. I think it's great that you are thinking about the Linux guys. Personally, I don't have the patience to deal with these kinds of issues, but I'm not saying everyone has to be like me.

Sorry if my post seemed offensive.
tepples
Posts: 22708
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Post by tepples »

Bananmos wrote:About native code:
Tilificator is written in Python
[...]
About frameworks:
Tilificator also uses GTK+, as it needed a GUI and GTK+ was the one I was most familliar with. Of course there are alternatives to GTK+, such as Qt, wxWidgets etc, each having their pro's and cons.
Tkinter, the Python interface to Tcl/Tk, comes bundled with every copy of Python for Windows. IDLE uses it, and 8name II (a nametable editor that I wrote in late 2009) uses it. You could probably get away with just making a tool depend on Python, Tkinter, and PIL, which a Windows user can install with two EXEs and an Ubuntu user can install with sudo apt-get install python-imaging-tk.
mic_
Posts: 922
Joined: Thu Oct 05, 2006 6:29 am

Post by mic_ »

You could use Dependency Walker to see exactly which imports a Windows executable has.
One way out of this problem would be to add a manifest that specifies which exact version of each library to link against, and then include those libraries with your application (assuming that you're allowed to do so).
User avatar
Bregalad
Posts: 8056
Joined: Fri Nov 12, 2004 2:49 pm
Location: Divonne-les-bains, France

Post by Bregalad »

I also have Linux installed on my PC so maybe I could try running the tool from here if someone would explain me how I'm supposed to achieve this.

And don't worry it's not the first time I have issues with tools running on my PC ! A lot of stuff is problematic, sometimes I even have to use DoxBox or Wine (form linux) to run tools that are supposed to work in Windows.

My Windows 7 has been installed 2 years and a half ago (when it came out) and not it's basically a huge mess and very slow Windows I have, and I should definitely back up and format to get PC for a second youth.
However, I never wants to do it right away because I'm lazy and I have some *ahem* programs I got from *ahem* odd ways and I'm afraid of loosing them completely if I format my drive.

I don't think Baramos is to blame for using libraries, in fact I guess his tools use complex logic (it's not something simple like a hex to .db converter or something in the like like the tools I'm able to develop on my own), so obviously he has to use some libraries.
I remember getting trouble getting other similarly complex tools like the drum to while noise converter, the NES image converter and other things, to run.
Useless, lumbering half-wits don't scare us.
Bananmos
Posts: 552
Joined: Wed Mar 09, 2005 9:08 am
Contact:

Post by Bananmos »

Tkinter, the Python interface to Tcl/Tk, comes bundled with every copy of Python for Windows. IDLE uses it, and 8name II (a nametable editor that I wrote in late 2009) uses it. You could probably get away with just making a tool depend on Python, Tkinter, and PIL, which a Windows user can install with two EXEs and an Ubuntu user can install with sudo apt-get install python-imaging-tk.
Yes, Tkinter does have the appeal of being the only GUI that's included in the standard Python library, which could ease the setup process for people. Like I said, I've been using GTK+ mostly out of tradition, but do change my preferences over time. You probably won't see me porting Tilificator to Tkinter anytime soon, but I might indeed take the opportunity to familliarize myself with Tkinter the next time I need to make a simple GUI program from scratch.
I also have Linux installed on my PC so maybe I could try running the tool from here if someone would explain me how I'm supposed to achieve this.
In theory things should be much simpler in GNU/Linux, since the package manager should fix everything for you if you just find the package for PyGTK and PIL. In practice... I haven't tried Tilificator on a Linux system in quite a while, so can't gurantee it'll work well. But hey, that's what beta testers are for, right? ;)

I also had a try with py2exe to produce a win32 native build with all .dlls included which you could also try out, but I don't know if it'll be any more successful at solving the .dll hell...

(btw, are you using 32-bit or 64-bit Windows?...)
User avatar
Bregalad
Posts: 8056
Joined: Fri Nov 12, 2004 2:49 pm
Location: Divonne-les-bains, France

Post by Bregalad »

I use 32-bit Windows.

And the .exe version actually works ! This definitely looks like a very advanced tool, it's amazing ! I'll have to play with it a lot.

Edit : OK the next problem is already here. When I load the demo megaman sheet, it works perfect, but when I load my own sprite sheet, it seems like it works at first, I press the "Ok" button and then nothing happens (the metasprites does not show up on the right panel).
Useless, lumbering half-wits don't scare us.
Bananmos
Posts: 552
Joined: Wed Mar 09, 2005 9:08 am
Contact:

Post by Bananmos »

Nice to hear you got it working! I would recommend trying to get the source version working eventually though, as it's more fun to play with when you can experiment.
Edit : OK the next problem is already here. When I load the demo megaman sheet, it works perfect, but when I load my own sprite sheet, it seems like it works at first, I press the "Ok" button and then nothing happens (the metasprites does not show up on the right panel).
In order for the automatic locating of sprites in the sprite sheet to work, the background should be color#0 (the image needs to be 8-bit indexed color format), and it must be possible to find a blank line between each row of sprites in the sheet.

If it's possible for you to share the sprite sheet in question, I can look into it.
Karatorian
Posts: 76
Joined: Sun Sep 30, 2007 9:54 pm
Location: Corneria
Contact:

Post by Karatorian »

Nice to see that py2exe fixed the problem. I've used it in the past to release stand-alone win32 versions of some programs I wrote.
User avatar
thefox
Posts: 3134
Joined: Mon Jan 03, 2005 10:36 am
Location: 🇫🇮
Contact:

Post by thefox »

Bananmos wrote:Tilificator is written in Python, as it has been a project where I've experimented a lot with quite complex algorithms, and frankly would never have been able to finish it had I used "native code" instead (meaning C/C++ in these days as thankfully few people write their PC applications in asm)
It's the same way for me, I've only recently discovered the joys of Python, but now it's pretty much all I use for tools like this, unless I absolutely need the performance gains of C++.
And no, none of their runtimes will come bundled with a Windows installation, so they all need some sort of thirdparty installation. Besides the fact that the Win32 widget framework is just horrible to use IMHO, I would not want to exclude GNU/Linux users from running my software just to make the experience of Windows users slightly smoother. I hope some non-Windows users will appreciate my choice.
Yeah the native Win32 GUI API has a ton of baggage. It can do everything, but not in a programmer friendly way. Personally I've used wxWidgets with Python, I like it a lot. Qt also seems great, but wxWidgets is a little bit more lightweight. Then again, Qt (probably) has better support tools. Pros and cons, like you said. :)
About plugins:
Windows uses .dlls, so naturally it is the most natural way to use above said frameworks on Windows. And frankly I must say that for all the bashing that GNU/Linux usually gets, the package management there is really superior to .dll hell on Windows.

That said, my home computer which Tilificator is currently being developed on uses Windows 7, so I am surprised to see the difficulties people are facing, and am trying to investigate the reaons. But unconstructive picking on my choice of development tools isn't really helping much.
Personally I don't think the DLL hell is all that bad. Or it wouldn't be if authors always distributed their applications with all the necessary DLLs. There's really no excuse to not be doing that nowadays (unless the application is being distributed as source code, like in your case). The actual issues behind errors like seen by Bregalad are always very simple, I'm still willing to be that older copies of the same DLLs were "somewhere". Unfortunately Windows doesn't make it easy by default to diagnose these problems...

The package management systems of *nix distros are fine until you need to install something more specialized, and then the dependency hell often becomes even worse than on Windows.

That's my 5 cents on derailing the thread. :)
User avatar
Bregalad
Posts: 8056
Joined: Fri Nov 12, 2004 2:49 pm
Location: Divonne-les-bains, France

Post by Bregalad »

If it's possible for you to share the sprite sheet in question, I can look into it.
I just wanted to point out I've sent you a PM with the sprite sheet linked in it (apparently you didn't notice ?).
I'm sorry but I don't want my sprites to be too much revealed to the public yet, as I want people to have some surprise when the game comes out (if it ever comes out).
Useless, lumbering half-wits don't scare us.
Bananmos
Posts: 552
Joined: Wed Mar 09, 2005 9:08 am
Contact:

Post by Bananmos »

Sorry for not noticing your PM until now, I usually only login if I need to write in a thread.

Like I suspected, your spritesheet does not use color#0 for the background, and this triggered a bug in the cut spritesheet dialog where it would use the color of the upper-left pixel of the sheet as the background color in some of its code, but still assume color#0 to be the background code in another routine.

I've fixed that bug in the SVN source repository, so your sprite sheet now loads. But I kind of doubt the result is what you wanted: the composite sprite window on the write will end up showing gray rectangles around the characters, while the black contours will end up as transparent.

Instead, I think what you want to do is remap the colors and switch color#0 with color#3, so that the gray bg will be color#0 and the black contours will be color#3. I easily did this with the "Rearrange Colormap" menu in GIMP. If this is not what you want, please try to explain what you would expect Tilificator to do here.

With the 'ShiftedRows' method, your spritesheet ends up using 90 tiles. I could also reduce this to 89 tiles by noticing some suboptimal tiling (a result of the order of images and the lack of global optimization mentioned earlier) and deleting some tiles manually and running a second pass, forcing it to use another, similar instead. I also noticed at least two tiles which differed only in the color of one pixel.

With the 'DragQueen' method, I got 90 tiles at well, although the results look very different since that method squezees the tiles together as much as possible (which may be considered an advantage when doing OAM cycling, since less total pixels will flicker).

However, it also seemed to produce a worthless completely blank sprite/tile! I need to look into this.
EDIT: This bug in now fixed in the SVN source repository.


Anyways, that mans 89 tiles for that spritesheet should really be the result without manual tweaking. Does that satisfy your tile budget? :)
Post Reply