23 replies to this topic

[tsg1zzn]

The Resize Image dll can resize images. You can of course get the images width and height before specifying how much to resize, for example, you can divide their height and width on two to resize to 50%.
Input formats supported: bmp, ico, tga, jpg
Output formats supported: bmp, jpg
You can specify the compression level when saving as jpg.

The wbitToTiff dll is somewhat more limited. It can convert bmp files to tif files. TIFF stands for "Tagged Image File Format". You don't have to specify the path, if you don't it will automatically look for and save files in the current directory where your game is.

Both dll's come with an example in 5.0 format, but I expect them to work under any later version as well.
They won't work under 4.x. If you require this, alert me, and I will fix the problem, it's just a formality.

Download the Resize Image dll here (125 kb)
Download the wbitToTiff dll here (92 kb)

EDIT: Wrote toooooo fast, forgot some words

Edited by tsg1zzn, 24 January 2005 - 07:35 PM.

[Argathron]

It doesnt works
.3A registered, and registered...
Can you make anything?
The program cannot open the image.

[tsg1zzn]

"It" doesn't work? Look, there are TWO dlls there.

If I should have a guess, I would guess it's the resize dll. As stated in the manual under "Important Information", it says that you MUST specify the whole path. That may or may not be the problem. Try to export as exe, and run again.

[Argathron]

For example i must be typ c:\exampledir\example.jpg?
Im at school, so i cant see it. I seeking for a bmp to jpg converter, so its cool me, but the resize dll cant open the picture file. I will go home, and i will see it.
Thanx:
Argathron

[tsg1zzn]

Yes, you must type c:\blah\mydir\mypicture.bmp. I'm sorry.

[Argathron]

COOL!!
ITS WORKING!!!!!
But

OpenImage(''+working_directory+'\test.jpg')

no
Do you know why?

[tsg1zzn]

Yes, because when you run the game from the editor, the game is actually exported to the temp directory and the ran. So when you gun the game from the editor, the variable working directory points to your temp directory and not the directory of your gmd. It will work when the game is exported manually, though.

[Porfirio]

Yes, because when you run the game from the editor, the game is actually exported to the temp directory and the ran. So when you gun the game from the editor, the variable working directory points to your temp directory and not the directory of your gmd. It will work when the game is exported manually, though.

<{POST_SNAPBACK}>

that is not true !!

gm will give you the path of the gmd with the exe extencion in working_directory variable

try it

[Shaltif]

You should not expect the working_directory variable to be a constant. I have found a way, by accident, to have that variable change. I'm starting to learn that in the world of GM, nothing is a constant...

Anyway, it's a good rule of thumb that you should ALWAYS pass the filepath along with a filename when pointing to a file's location. Just passing a filename and hopeing it fills in the correct filepath may lead to unexpected errors.

EDIT: Actually, the working_directory should point to the "local" directory when you use debug mode. However, it could be changing due to your DLL (dll's can change that variable without realizing it). I recommend storing the working_directory into another variable on runtime, before initializing your DLL. Then you know the variable won't suddenly change.

Also, the filepath of parameter_string(0) is what your thinking about tsg1zzn. If you use that to get the "working directory" then you will get a different path if your debugging or running from EXE.

~Brandon

Edited by Shaltif, 02 May 2005 - 06:59 PM.

[tsg1zzn]

that is not true !!

gm will give you the path of the gmd with the exe extencion in working_directory variable

try it

Don't you think I tried it BEFORE I posted - unlike someone else?

You should not expect the working_directory variable to be a constant. I have found a way, by accident, to have that variable change. I'm starting to learn that in the world of GM, nothing is a constant...

Anyway, it's a good rule of thumb that you should ALWAYS pass the filepath along with a filename when pointing to a file's location. Just passing a filename and hopeing it fills in the correct filepath may lead to unexpected errors.

EDIT: Actually, the working_directory should point to the "local" directory when you use debug mode. However, it could be changing due to your DLL (dll's can change that variable without realizing it). I recommend storing the working_directory into another variable on runtime, before initializing your DLL. Then you know the variable won't suddenly change.

Also, the filepath of parameter_string(0) is what your thinking about tsg1zzn. If you use that to get the "working directory" then you will get a different path if your debugging or running from EXE.

~Brandon

My dll does not change anything. You've found a way to change the working directory variable you said? I have always thought the working directory changed when you saved files to a different location. This is untested though.

I'm sorry to say this - but I'm afraid I'm more right than you. I'll show you why in 10 easy-to-follow programming-explained-like-I-was-three-years-old steps.

1. Start Game Maker 5.0 (which this dll was designed for)
2. You will have an empty game
3. Add a new room
4. In the room properties window, go to the "settings" tab
5. Click "creation code"
6. Type in: show_message(working_directory);
7. Close the code editor by clicking the green checkmark
8. Press the green arrow on the MDI parent's tool bar to run the game
9. Wait for the progress bar to finish and the game window creates
10. Look at the contents of the message box

I almost hear you thinking: "It's not my fault that retarded guy use 5.0". Well, the behaviour is the same for 6.0, except the message box pops up before the game window shows.

Also, the behaviour is the same when you view the variable in debug mode, and this also applies to 6.0.

EDIT:
parameter_string(0) returns: C:\DOCUME~1\Trond\LOKALE~1\Temp\gm_ttt_15169\game.exe
working_directory returns: C:\DOCUME~1\Trond\LOKALE~1\Temp\gm_ttt_15169

Edited by tsg1zzn, 02 May 2005 - 07:48 PM.

[Porfirio]

OK this is wheird

i run gm5 and make new and put on creation code of the room

show_message(working_directory)

and it give me the path to the temp directory of gm and then i saved it to desktop and it gives me the path to the desktop

Something is wrong here ....

Betwen nice dll

[Smarttart62]

lol nice dll,
and yes working_directory gives you exactally that, the working directory. Mark isnt gonna lie about something that small
-Steve

[Shaltif]

The working_directory variable should not be returning the same place as parameter_string(0). I know this is going far off topic but I need to prove this point.

Here is a screenshot of my console.



I first got the return of the working_directory variable, it showed the working directroy.

I then did parameter_string(0) and it gave me the temp directroy (since I'm in debug mode).

Then I used my DLL to change the working_directory variable, which you see becomes C:\soldat

The only reason working_directroy could be the same as parameter_string(0) at the very beginning of the game is because the working_directroy variable might not have been set to the "local directroy" yet. Since your trials only check that variable at game start rather than during it's progression.

(Actually, scratch that. Just checked it and working_directroy returns correctly, so I don't know why your working_directroy is returning that)

And no, the working_directroy variable doesn't change if you use the open_file_ dialog's in GM.

~Brandon

[tsg1zzn]

I WAS WRONG!!!!! The reason it returns so strange stuff for me, is that game isn't saved yet.

But that does not explain why my dll, which requires the whole path, can't load the image when you run the game from the editor (and passes the whole path by using the working_directory + the filename), but when you export it to standalone, it works. Very strange.

[Porfirio]

I WAS WRONG!!!!! The reason it returns so strange stuff for me, is that game isn't saved yet.

But that does not explain why my dll, which requires the whole path, can't load the image when you run the game from the editor (and passes the whole path by using the working_directory + the filename), but when you export it to standalone, it works. Very strange.

<{POST_SNAPBACK}>

I was right but i dont realy undertand why your dll dont work ...

off-topic :
Shaltif where can i get your console ??
It looc's very cool !!

[Shaltif]

tsg1zzn, I'll test you dll via my console and see if I can figure it out. Technically, if the user makes sure to include a backslash (like working_directory+"\my_image.bmp") then it should work without flaw.

I'll post back with my results then.

PORFIRIO, check your PM's =)

~Brandon

[Timber]

It (the first one) worked fine for after:

1) Resaving the example's file (.gm6, no less!) to the same directory as the DLL
2) Specifying THE FULL PATH to the save files. As in C:/TestDir/test_small.bmp instead of test_small.bmp

The problem isn't that it's not working most of the time, it's that it's saving the files to somewhere other than whewre you're expecting.

Tsg1zzn, i suggest a few modifications to your object's code in the future...

StartResizeDll();

if not OpenImage(get_open_filename('Input Image Files|*.bmp;*.ico;*.jpg;*.tga',"")) begin
  show_message("Image not found");
  return 0;
end;

h = GetImageHeight();
w = GetImageWidth();


ResizeImage(w/2,h/2); //50%

imagedirname=get_directory(working_directory)

SaveImage(imagedirname+"\test_small.bmp",global.f_bmp);
SaveImage(imagedirname+"\test_small_bad.jpg",global.f_jpg,2);
SaveImage(imagedirname+"\test_small_default.jpg",global.f_jpg);
SaveImage(imagedirname+"\test_small_good.jpg",global.f_jpg,11);

Actually, now that i look at it, it's a bit more confusing, but it works. You load a file, and that looks fine. It's the "get directory" window that's confusing... on the other hand, it starts right out in the working directory of gm, so if you lose something, you'll know where to look for it.

I might even go so far as to pop up seperate get_save_file() windows for each example saved, so the user knows and controls EXACTLY where they go.

Downside, it's useless, unnecessary code.
Upside, your users won't lose their files anymore.

[Todd101scout]

can you make it convert from bmp to jpg plz?

[master123]

Link not working any more please re upload if you still have it!

[sophiababy]

Hey, need this badly, please reupload