[SOLVED] FreeImage.dll not found

6

Are you using that Extended thing? [Still new to it myself, not had the time to explore it as of yet]

If not, are you using a dev branch?

Why are you not using [As it appears as though you are using an XNA project for this at the moment or something along that line] the pipeline tool itself?

You are contradicting or mixing up your meaning in your messages… first you said:

compile images through the content pipeline tool

and then you said…

I just want to compile my graphics assets in a new, simple project.

So it is difficult to gauge if you are using a project to compile your assets or the pipeline tool executable…

I am not even going to start going through your original post… my head exploded reading that one… :cry:

Even I have read this thread a number of times… I am still lost. :no_mouth:

7

Perhaps start again, what is it you are trying to do, what are you using, what is your setup and where exactly are you getting that error?

A little back story may help more here :slight_smile:

EDIT

Also welcome to the forums :slight_smile:

8

Hi MrValentine and thanks for the welcome~

I shall try to be clearer.

The error I receive, which you can see in the first post, is when I attempt to compile image assets using the Pipeline tool. So, when i click the Build button in the pipeline tool after adding assets.

I am using a Windows 10 machine, I have Visual Studio 2015 Community installed, DirectX, and the appropriate runtime libraries. I have attempted to use the pipeline tool from the Development build of Monogame unsuccessfully, and then the 3.5.1 stable release, also unsuccessfully.

The rest is not important in this issue. To attempt to simplify the problem further, I created a new ‘Cross-Platform’ project (as the Windows Desktop template seems to create a broken project)…

I am able to Build this project.

However, when attempting to use the Pipeline tool to compile image assets, I receive described above.

I hope that this has made the issue clearer.

9

Ok! Yeah, the whole content pipeline thing can be tricky for a lot of us to fully understand :slight_smile:
Luckily, once everything is setup, and the workflow is established, it will run smooth, no problems.

I think you should delete those png files from your project enirely (including the actual files in the build dir, any xnb files by the same names)…

Then, add the png files to your project simply by dragging the files into your content folder in the solution explorer side-bar.

Then high-light all these new png items in the solution explorer, and set their properties fields to ‘Content’ and ‘Copy if newer’…

You don’t really need the tool for png files in the first place, it just adds another layer of confusion :slight_smile:

10

Awesome, and that’s interesting to know.

Basically, this stems from me playing around with Monogame on a Mac a while back, but finding some issues with Mouse input with the OpenTK implementation that it’s currently using. (The issue was that when holding a mouse button, it would no-longer update the mouse position until the button is released.)

So, with the knowledge that OpenTK is being replaced with SDL2 in the 3.6 Milestone, I decided to leave it for a while in hope that 3.6 would be released soon…

Fast-forward a few months and sadly that still hasn’t yet been released. I’ve got a Windows machine now and decided to just try to play with Monogame anyway. I thought that if I used the Development build, that It might have the SDL implementation in place in some manner at least.

However, I noticed that it seemed unable to find any of my texture assets, throwing ContentNotFound Exceptions, and I noticed in the error text that it was looking for XNB files and not the PNGs, which is why I wanted to try and make use of the Content Pipeline utility.

Due to the length of time between looking at Monogame 3.5 on my Mac and the development build on my Windows machine, I did not connect the dots that it might be an issue with using the dev build instead of the stable one.

In Conclusion, and TL:DR;
I cant seem to load PNG texture assets when using the MonoGame development build, as it seems to exclusively look for XNB files. But I can just make use of 3.5 stable for now, so it’s ok.

The original FreeImage.dll issue is still present, but thanks to @monopalle’s suggestion, I can work around it, easily enough.

Thanks everyone.

1 Like
11

Curious @monopalle that you are recommending not using the content pipeline as it’s one of the most powerful features of XNA and now MonoGame. Yes there is an extra layer, however what you get for managing and maintaining your content, it is well worth it. (Keep an eye out as I’ll be doing a fair bit on my new MG channel on this)

Would still like to get to the root of your issue @aetharr (oh and yes welcome :D).

Could you let me know a bit more about your PC build, is it x86 or x64?

After a little digging, I did find a dependency of FreeImage which is the C++ runtime in this post:

You can get the installer for the C++ redistributable here:
https://www.microsoft.com/en-us/download/details.aspx?id=40784

Although it’s odd that this old issue has reared it’s head. I personally am running the same build as you (except I use enterprise) and have never had this issue.

I do need to rebuild another machine (for a demo) so I will try just the components you are using and see if I can replicate

3 Likes
12

Hi @SimonDarksideJ

Haha, my god! I’ve spent ages looking into this, and also found the various posts suggesting to install the C++ runtimes. Though each post had a different version, and I must’ve missed the 2013 versions as it seems to have resolved my issue!

Thank you very much! I wanted to be able to use XNBs in the long run to try and have it that my art assets wouldn’t be quite so easy to rip upon completion, but I also wanted my project to actually run, so there’s that.

To answer your question, my PC is running Windows 10 x64, with Visual Studio Community 2015.

Sorry that it ended up being the issue of C++ runtimes, as described in the other posts… I did try most of them, but again, must’ve missed these ones.

Thanks again!

UPDATE:
I can also confirm that this works with the current Dev build of MonoGame, thanks a lot :slight_smile:

2 Likes
13

Oh I use it, didn’t mean to imply that its use-less… I just mean to say that while learning the basics, you can go far without involving the tool… Drag/drop png files is fine, I think… In my experience…

14

True but even with PNG’s you lose the binary compress you get by default with XNB’s which are tied to a specific platform :smiley:

So you can, but I’d not recommend it.

Only thing I’d say to use without the Content Pipeline is audio, as there is still a way to go (as far as I know) to improve that side and there are better ways to compress it yourself at the moment with free compression algorythms. The lack of Xact support also hurts (but that’s a different problem)

15

Glad to help @aetharr

Also to note, I’ve updated the homepage on the XNAGameStudio github archive site for those trying to use those samples. Until I get round and migrate them all, you can use the MXA VS addon to open the original XNA game projects in modern VS :smiley:

16

Whats a binary compress? And what does it mean to lose it? :scream:

17

The XNB format is a compressed format, which is compressed using a binary format particular to each platform you build it for (hence why some XNB’s are different between platforms)
Without it, your images and text files remain the same size in the game package.

18

I thought that was accounted for automatically during the build process, with or without the tool… -I thought when I published for each platform, my png’s were just built as xnb’s (if newer) for whatever target platform I had selected :frowning:
we’d probably need a whole other thread for this.

19

definitely not. If assets are in the solution, then it’s completely up to you, there is no magic involved.
Simply comes down to have mg manage your assets in a content project or do it yourself.
XNA was exactly the same.

20

I downloaded C++ redistributable reinstallation worked for me thanks. Now, i get Spritefont “Index was out of range” error.

1 Like
21

A workaround is only a TEMPORARY solution till a proper solution is found. Why on earth build a new Monogame version unless these errors are ironed out in the first place?

22

For me it helped to install Visual C++ Redistributable 2013, although i use visual studio 2013

23

Same here. I just recently ran into this problem, and installing the 2013 Redistributable fixed it. I’m using Visual Studio 2017 Community.

24

This worked for me on Windows 8.1 x64 using Visual Studio Community 2017. Thank you so much!

25

I’m curious if the root cause of this issue was ever discovered? I’m currently running into this same error when building. I’m hoping to avoid the redist installation workaround, as everyone on my team would have to do this same workaround. I’ve done some work trying to ensure there are no build dependencies for our project aside from a Visual Studio install and syncing to our perforce depot, but have not been able to find a systemic fix for this error.