|
| |
Website :
http://hermit.sidrip.com
Credits :
Download :
Look for downloads on external sites:
Pokefinder.org
User Comment
Submitted by Compyx on 19 February 2022
| The updated version runs fine on Debian 11.2. Thanks! |
User Comment
Submitted by Hermit on 19 February 2022
It works for me with Allegro-4.4 since the beginning, so that may not be the issue.
A bit late maybe, but I added a fixed zip file which has an up-to-date 64bit Allegro4.4-build of the Linux HermIRES executable.
The name of the fix comes from an other issue I targeted: The config-file was created in HermIRES executable's folder in the released 1.29 version, but it caused segfault when HermIRES was launched from a folder non-writable by the user (like /usr/bin). Now it checks for the HOME folder by getenv(), and creates the config there in ./config/ subdirectory, as it's normal in Linuxes. For me all works fine in a custom-built Debian 10. |
User Comment
Submitted by Compyx on 25 May 2020
The Linux version doesn't run due to my box having a more up-to-date liballegro (4.4 vs 4.2). Compiling from source results in a lof of weird errors.
Managed to get it to run via wine, but that causes a lot of weird bugs. |
User Comment
Submitted by grip on 27 January 2019
| It's rather CPU-intensive for the platform, but I've managed to compile HermiRES on Raspbian (Raspberry Pi). In source/AllegroPNG/alpng_filters.c, in the function paeth_predictor, change all calls to abs() to static_cast<uint32_t>, E.G. pa = abs(p - a); ===> pa = static_cast<uint32_t>(p - a). It's worked so far, including loading PNG files and saving them as .hbm. |
User Comment
Submitted by Hermit on 2 March 2016
An user has reported how he solved a Win7 error message: Don't put HermIRES into folders that has a path containing non-ASCII characters. It seems Allegro4 can't handle Cyrillic/etc. non-ASCII characters in paths and filenames...
I hope this helps some people who couldn't start HermIRES on Win7 or other OS for this reason... |
User Comment
Submitted by Hermit on 9 February 2014
| I don't use Windows anymore, not even for testing, so my quest to make HermIRES more Windows (XP/7/8/whatever) compatible or make allegro-routines better has ended here. Source-code is shared, so anyone can customize to make it to fit better... |
User Comment
Submitted by Monte Carlos on 6 February 2014
Why not use common WinApi Dialogs?
Maybe would be easier than fiddling around with some buggy API. |
User Comment
Submitted by N3XU5 on 6 February 2014
| Nice one Hermit! Will try it out! ;) |
User Comment
Submitted by Hermit on 6 February 2014
| Anyway, as I moved onto other (time-consuming) projects I think no more feature-updates will come in the (near) future, only fixes if needed... |
User Comment
Submitted by Hermit on 6 February 2014
I had to use Win7 at my previous workplace. I remember that it tended to shut down some of my small useful apps regularly without notifying me. Probably they were not safe enough or something like that, I'm not expert at Win privileges. In my opinion XP is the most comprehensive of all Windowses. I tried a lot of variations, e.g. tuning Win95 up, and ended in a more complicated system than a WinXP which was stripped down with Nlite.
I had no experience with Win8 but I've heard enough about it, and cannot imagine it could get much better after Win7 (e.g. 'Surface' tablet failing at demonstration and reviews), especially for minimalist people like me... |
User Comment
Submitted by Hermit on 6 February 2014
One more thing: You can find workarounds to Windows related issues in the previous HermIRES versions' comments.
I remember, I had to change from Allegro 4.2 to 4.4 because it was better in some aspects.
And IIRC the keypress-repeating was simply not supported in WinXP, that's why I had to write a custom repeater function for some tasks (like the Undo/Redo)... |
User Comment
Submitted by Hermit on 6 February 2014
Dunno...maybe this is also related to operating version system vs allegro compatibility because it doesn't do anything like this in Linux.
The only difference compared to the previous HermIRES 1.28 is probably that I used other Allegro devpak (4.4.0) to compile it. It might behave differently in Windows than the previous allegro version (4.4.2 monolith) I used...
The source is all the same in this regard, just some minor changes, so recompilation testing with different allegro 4.2, 4.4 libraries, or changing the alleg44.dll, etc. might solve that and fit better to a given Windows. As I don't have Windows right now I can't make these thorough tests, I leave it to others...
Funny, but it cannot be guaranteed that the exact HermIRES binary runs the same on different machines... A little experiment might be needed in cases, unfortunately...Good to hear it works fine after saving the .cfg file on exiting...
One thing what I know for sure about Allegro that its dialogs run in fast endless loops and eat much CPU power. So it depends on the OS how much CPU it gives to this kind of application in the task/process-manager...and that is proportional to the slowdown a machine can do in this case...
Until now I couldn't find workaround to slow the Allegro dialog event-polling loops down to reduce CPU usage despite there is a way commented in allegro manual... |
User Comment
Submitted by grip on 6 February 2014
| Hermit, I've made a lot of pics using HermIRES in Windows 8. True, sometimes it crashes/bugs out, but so does a lot of the other editors I've tried as well. However, these are free apps for a very esoteric purpose so I feel that can live with the quirks. |
User Comment
Submitted by Shine on 6 February 2014
EDIT:
After the program saved "HermIRES.cfg" this bug doesn't come again. |
User Comment
Submitted by Shine on 6 February 2014
BUG?:
Windows XP 32 Bit (2.3 GHZ):
If i want load a picture, HermIRES freez for a while. Mouseclick doesn't work, so i need to use ENTER.
The first 20-30 seconds it freez (maybe some initialization). After this time i can choose directory/files with keys.
Short:
Everytime using the mouse the programm freez for a while (more than 10 seconds).
After a while i can use keys only to load a picture. |
User Comment
Submitted by Hermit on 6 February 2014
*EDIT* for previous comment: If "HermIRES" runs well on Win8 I'm surprised...
PS: I understand that Editing is disabled at CSDB however I don't like it, I accept the decision. But then I don't understand why the 'Edit' button is still there for comments, so sometimes I try it if it maybe came back... |
User Comment
Submitted by Hermit on 6 February 2014
That says everything about Windows (Micro$oft) backwards compatibily :P
If on the other hand HerMIDI runs on Win8 I'm surprised...
I liked P1 very much when I used WinXP many years ago, especially its conversion capabilities, but since I use Linux I had some issues when tried to run it in Wine... that's why I had to write a hires editor for Linux that has only one dependency (that is allegro)... because something (and maybe the only one) what I hate in Linux environments is the lot of dependencies some programs require to compile/run... |
User Comment
Submitted by grip on 6 February 2014
| Oswald, I had actually forgotten that. P1 doesn't work on Windows 8, which I'm running :/ |
User Comment
Submitted by Oswald on 6 February 2014
| grip, p1 can scroll the picture completely off from under the floating windows, so you are not forced to move them to reach under. |
User Comment
Submitted by grip on 6 February 2014
| Jailbird, ah, I get it. Well, I like the interface with the fixed toolbox and edit/preview pane. It suits me much better than having to constantly shuffle floating toolboxes around like one is prone to do in P1/Timanthes. To each his own, I guess! |
User Comment
Submitted by Hermit on 6 February 2014
| And if middle button (scrollwheel pushed down?) doesn't work either the cursor/home/end/pgup/pggn keys can be used to navigate around in the zoomed pixelling-area... |
User Comment
Submitted by Hermit on 6 February 2014
For the sake of usability despite the OS/Allegro related things:
-Filer window sometimes really need the cursor/enter keys to react. It could be better if only keys were used than this tricky mouse/keyboard combination. If someone comes up with a good cross-platform but simple (so/dll dependency-less) idea to have native file-manager of the OS inside...
-If for some strange reason the mouse-wheel doesn't work, +/- keys can be used as zoom-in/-out, but of course it's much harder to use the app that way. For fast 32x/16x zoom you can use SPACE / Shift+SPACE
-The GUI-size is set automatically at startup depending on resolution. Only some discrete sizes are possible. I may add a GUI-size selector button, it's in the ToDo list.
In the first place I coded HerMIDI just to draw the splash-screen for SID-Wizard. I turned out as a featureful tool in the end, so why not share, and others can profit from it too... If some operating systems don't like the Allegro4.4 library (GUI,controls) that's out of my reach. I don't plan to rewrite the code to the very different but up-to-date Allegro5 library just to have better Win7/Win8 compatibility...XP might be the best for HerMIDI if your preferred OS is windows...Linux seems to work fine, even the newest ones. |
User Comment
Submitted by Hermit on 6 February 2014
@Jailbird: Unfortunately a lot of things you mention (resizing, wheel, GUI) are according to Allegro library that HermIRES is based on and Operating Systems...
The filer really sucks, that's what is built into Allegro. I started developing an own filer, it's just a matter of time, currently it's commented out in the source. I might use the codebase of filer which I created in my MIDItrk app (released at sourceforge), but enhance it with mouse-support.
If I could start it all over again I'd use SDL instead for this project too, where I have control over everything.
I'm sure other coders could also tell you how hard is to find a suitable cross-platform library for GUI-application development. All of them has their issues. At least Allegro/SDL code seems really working on Linux vs Windows without modifications...more-or-less...
I could do workarounds, but I'm now tired of workarounds. PC (be it Linux or especially Windows) ar full of bugs and workarounds and wasting resources. That's why now I'm working on my own architecture (on FPGA) where I'd like to make GUI things simple and small and fast...maybe it will need less time than the time was needed to try nearly all GUI-libraries and find none of them is perfect and full-featured at the same time... (maybe only C/C++ Standard library is bugless and really cross-platform)
In a sense coders are users too, and we need a platform where we can easily code stable and fast apps. |
User Comment
Submitted by jailbird on 6 February 2014
Quoting gripJailbird, yeah, I have problems with the file browsing as well. I have to click in the path box and then press enter to make the directory load.
Tried that (and a bunch of other things too). Nop, doesn't work.
Quoting gripI can zoom both in the edit and preview panes.
You mean rescaling within the panes, right? Still no luck with that, but I was rather thinking of an option to resize those panes (preferably with a combination of rescaling - just as it's done in P1), so I could append their dimensions to a certain height/width. I'm usually tiling windows on my workspace, but since this editor's UI is for some reason fixed to a certain size, it's impossible to have other ranges than the default one. |
User Comment
Submitted by grip on 6 February 2014
Jailbird, yeah, I have problems with the file browsing as well. I have to click in the path box and then press enter to make the directory load. I'm used to it now and it autoloads the latest project so I'm not really suffering from it.
No problem with zooming, however - mouse wheel works great. I can zoom both in the edit and preview panes.
Then again, my screen is a measly 1366*768. |
User Comment
Submitted by jailbird on 6 February 2014
What is this, a pixelling tool for ants? :) Is there a way to enlarge the zoom and the preview "windows"? It's barely usable on higher resolutions (I have tried everything, and the mouse-wheel zoom doesn't seem to work). To illustrate my point, these are my settings on P1
For some reason I can't change drives or move up/down directories (clicking doesn't seem to do anything, I'm stuck on the example folder).
I could more or less live with it, but why is the UI so counter-intuitive, especially the file dialogs? Reminds me of DOS software from the early 90s.
Otherwise, I was fiddling a bit with it, seems like a fine and stable tool. Unfortunately, it doesn't really suits my way of work, so I think I'll pass on this... |
User Comment
Submitted by Linus on 6 February 2014
Sid-Wizard, HermiRes, HerMidi, Mortal Kombat and a hell awesome music. You're a sick, sick man! ;)
Hermit for president, seriously! |
User Comment
Submitted by Dr.j on 6 February 2014
Want to Emphasize i am not a gfx man but this tool look so friendly and powerful.
Thanks Hermit for preserving this tool and keep improving it all the time. Thumbs up mate! |
User Comment
Submitted by JackAsser on 6 February 2014
| @fierman: evil test case. According to the look of the strace it seems your bmp-file is zero bytes long. Lseek with seek_end returns 0. |
User Comment
Submitted by hedning on 6 February 2014
User Comment
Submitted by grip on 5 February 2014
| Nice to see this fine program being updated! |
User Comment
Submitted by pby on 5 February 2014
| ...such a breeze to work with! Thanks a lot for this fine piece of software! |
User Comment
Submitted by leonofsgr on 5 February 2014
| perfect stuff! go hermit, go! |
User Comment
Submitted by Fierman on 5 February 2014
Some small mistakes in Makefile (make clean is not intended to use to remove the binaries from their installation paths:), but that is not of a real issue.
HermIRES crashes here (linux 3.5.0-28) on importing a BMP file.
Relevant output from strace here:
http://pastebin.com/XDJFreME
Other than that: awesome program!! thanks! |
User Comment
Submitted by Hermit on 5 February 2014
Thanks for the help, Ian. I corrected the binaries that now they include the correct allegro44.dll.
(I was mislead/confused by the allegro version numbers and wanted smaller size. Stripping out debug symbols solved the size-issue.) |
User Comment
Submitted by iAN CooG on 5 February 2014
| rename allegro-4.4.2-monolith-mt.dll alleg44.dll to make it work =) |
User Comment
Submitted by Hermit on 5 February 2014
Not too much improvements compared to 1.28.
I added the AFLIexe patch and made a correction in the REUSE mode. (When drawing colour matches the opposite bg/fg colour, the colours are swapped, ergo you can always set different pixels with the two mouse-buttons)...
32bit linux binary compiled in Puppy Linux, maybe works on other 32bit Linux distros, maybe not.
(32bit .exe binary compiled in Wine with executables of DevCpp and Allegro devpak.)
I uploaded in tar.xz because that way I could get below 1M upload limit. If you need simple .zip, you can download it from the sourceforge-link... |
|
|
|
 | Search CSDb |
|
| Navigate | |
|
| Detailed Info | |
|
| Fun Stuff | |
· Goofs
· Hidden Parts
· Trivia
|
|
| Forum | |
|
| Support CSDb | |
|
 |  |
|
