NFO Editor
Moderator: Graphics Moderators
Do you have to register the dll somehow? Is it also in your dlls folder?
Development Projects Site:
http://www.as-st.com/ttd
Japan, American Transition, Planeset, and Project Generic Stations available there
http://www.as-st.com/ttd
Japan, American Transition, Planeset, and Project Generic Stations available there
There is a new version, now with changes that make it worth to download.
- Third release
- Added checksum to see if msimg32.dll is found.
- When unknown flags are found in the PCX, popup message will not appear
- Program does not freeze anymore while converting PCX
- Added progress bar into the PCX to BMP conversion process
- Added multiplier to change NFO values faster
I couldn't do anything about windows 95, the dlls and their dependencies are there, in fact I installed all the Visual Studio libraries, yet this msim32.dll file is supposedly missing.
- Third release
- Added checksum to see if msimg32.dll is found.
- When unknown flags are found in the PCX, popup message will not appear
- Program does not freeze anymore while converting PCX
- Added progress bar into the PCX to BMP conversion process
- Added multiplier to change NFO values faster
I couldn't do anything about windows 95, the dlls and their dependencies are there, in fact I installed all the Visual Studio libraries, yet this msim32.dll file is supposedly missing.
Sad task of mine, but I have to do some bug reports.
The program still runs out of memory on my w98se. Try the following:
Start the program and load an nfo file. Open the Help/About NFO editor... and look for Phisical memory free. If no nfo loaded, then it's okay, but as soon as you load any nfo file, the free memory starts decreasing, and eventually it will eat up all memory. Just before running out, the sprites will not be displayed, and after this it will display a message saying "run time error '7'. Out of memory". This makes it _very_ difficult to use, because you can alter maybe 2 or 3 sprites data (if you are fast enough), then quit and restart the app. That error could be severe too, because of the memory leak, but until now I have not encountered anything more serious than the program quitting. I have a slight feeling, that this problem is caused the way windows(9x) handles bmp images, so I'd like to ask, if that bmp conversion is _really_ necessary?
I suppose you don't encounter this on XP otherwise you would have already corrected this (or you are not using it long enough to crash?).
As for the msimg32.dll the one attached does not work for me, but copying the one in the windows folder over it makes it work (that one's 52kb long). Could this cause the problem (ie. the windows one)?
There is another problem, this one's related to GRFWizard. If I de/encode a file, and using split image/custom box size at the same time it also gives me an error message, and quits (see image). I know what causes this: the usage of too long command line, and the usage of long filenames without "". You/the program gives too many parameters, and dos can't handle that. I don't know how to correct this though. Maybe using "" in the path parameters can help, but not sure.
The program still runs out of memory on my w98se. Try the following:
Start the program and load an nfo file. Open the Help/About NFO editor... and look for Phisical memory free. If no nfo loaded, then it's okay, but as soon as you load any nfo file, the free memory starts decreasing, and eventually it will eat up all memory. Just before running out, the sprites will not be displayed, and after this it will display a message saying "run time error '7'. Out of memory". This makes it _very_ difficult to use, because you can alter maybe 2 or 3 sprites data (if you are fast enough), then quit and restart the app. That error could be severe too, because of the memory leak, but until now I have not encountered anything more serious than the program quitting. I have a slight feeling, that this problem is caused the way windows(9x) handles bmp images, so I'd like to ask, if that bmp conversion is _really_ necessary?
I suppose you don't encounter this on XP otherwise you would have already corrected this (or you are not using it long enough to crash?).
As for the msimg32.dll the one attached does not work for me, but copying the one in the windows folder over it makes it work (that one's 52kb long). Could this cause the problem (ie. the windows one)?
There is another problem, this one's related to GRFWizard. If I de/encode a file, and using split image/custom box size at the same time it also gives me an error message, and quits (see image). I know what causes this: the usage of too long command line, and the usage of long filenames without "". You/the program gives too many parameters, and dos can't handle that. I don't know how to correct this though. Maybe using "" in the path parameters can help, but not sure.
- Attachments
-
- grfwiz_err.JPG (13.48 KiB) Viewed 2097 times
NFO Editor has been discontinued, and I was unable to run it under win95/98 due to problems with msimg32.dll. The BMP conversion is of course necessary, since VB does not handle PCX files.
About GRF Wizard, try with version 1.8, which fixed some bugs.
PS, try to avoid using spaces in paths used by the GRF Wizard, and definitely, do not use spaces in filenames. 8.3 filenames should be completely compatible with the windows 9x command.com.
About GRF Wizard, try with version 1.8, which fixed some bugs.
PS, try to avoid using spaces in paths used by the GRF Wizard, and definitely, do not use spaces in filenames. 8.3 filenames should be completely compatible with the windows 9x command.com.
I'm very sad at this 
.
NFOEditor is one of the greatest tools (if not THE greatest) for modifying graphics, and there's no replacement for it. For someone who doesn't understand the .nfo format (like me) this tool would mean all, for doing graphics.
Please... are you absolutely sure you can't make it work better. Maybe somone else could help you, or do it if you could release the source. I know programmers don't like releasing their work, but if you don't want to continue working on it, then at least allow others to.
-edit- it does run on w98se if the above file msimg32.dll was copied from the windows folder, but it does have this memory error...
As for GRFWizard 1.8, it still has the same problem stated above. Is there no solution to this? (FYI: i don't use spaces in file/dir names)
-edit- OK, I think I just understood your statement, so FYI the above error was produced while decoding the trg1r.grf file (absolutely compatible with the 8.3 format)
Might I suggest that the "add file" on page 3 of decode/encode defaulted to the ttd's grf/sprites folder. The program knows it already on page 2.
Szappy
. NFOEditor is one of the greatest tools (if not THE greatest) for modifying graphics, and there's no replacement for it. For someone who doesn't understand the .nfo format (like me) this tool would mean all, for doing graphics.
Please... are you absolutely sure you can't make it work better. Maybe somone else could help you, or do it if you could release the source. I know programmers don't like releasing their work, but if you don't want to continue working on it, then at least allow others to.
-edit- it does run on w98se if the above file msimg32.dll was copied from the windows folder, but it does have this memory error...
As for GRFWizard 1.8, it still has the same problem stated above. Is there no solution to this? (FYI: i don't use spaces in file/dir names)
-edit- OK, I think I just understood your statement, so FYI the above error was produced while decoding the trg1r.grf file (absolutely compatible with the 8.3 format)
Might I suggest that the "add file" on page 3 of decode/encode defaulted to the ttd's grf/sprites folder. The program knows it already on page 2.
Szappy
-
orudge
- Administrator
- Posts: 25218
- Joined: 26 Jan 2001 20:18
- Skype: orudge
- Location: Banchory, UK
- Contact:
Doing a bit of Googling finds this: FIX: TransparentBlt Leaks Memory in Msimg32.dll. It suggests:
The code in 79212 is in C, and is more complicated than just calling TransparentBlt, but it can be converted to VB fairly easily. Andrex, let me know if you need help with this.Instead of using TransparentBlt(), use the code that is provided in the following Microsoft Knowledge Base article:
79212 HOW TO: Draw Transparent Bitmaps
Who is online
Users browsing this forum: Google [Bot] and 16 guests