Allegro.cc - Online Community

Allegro.cc Forums » Installation, Setup & Configuration » Compiling OpenLayer with MSVC 7.1

Credits go to Fladimir da Gorf and Neil Walker for helping out!
This thread is locked; no one can reply to it. rss feed Print
 1   2   3 
Compiling OpenLayer with MSVC 7.1
tobing
Member #5,213
November 2004
avatar

I'm trying to compile OL latest SVN with MSVC 7.1. There are several compile problems here.

Oh, please don't flame about using MSVC or not. I will use this compiler for my own development, I'm used to using it, and I want to compile OL using a project file, because that really helps debugging etc.

In two places (OlRectangle.hpp and Circle.hpp) the compiler complains about std::max and std::min - which is because somewhere max and min are defined to be macros. It seems that there are two places where these #defines come in: stdlib.h and windef.h. The first seems to be PL though, because there's an #ifndef __cplusplus masking the #define, but the second does introduce the #define.

Well, does anybody know why windef.h is included? I couldn't find out easily where this include is introduced, it's definitely not included directly from OL itself.

My workaround is to add

#ifdef max
#undef max
#endif

#ifdef min
#undef min
#endif

to both files. Not beautiful, but works.

Next one is more difficult: In Internal.hpp there's a definition of OlAssert which uses___PRETTY_FUNCTION__ - which seems to be special to gcc or whichever compiler, but is not supported by MSVC (and most probably not included in standard C++). I guess this has to be changed to be portable? For this moment, I'll just remove the line to continue.

Bitmap.cpp line 1150 reveals that a for-loop reuses the name of a local variable, defined before the for statement, as loop variable. According to the standard, that is allowed, and the loop variable is not visible outside the loop. MSVC complains though, because in this particular case, the compiler behaves downward compatible unless told to not use language extensions (which wouldn't compile for many other reasons). At best, it is confusing to read this code, so I think it should be changed, so that the loop variables have names different from the local variables outside.

Same in line 1178 of that file.

With this it compiles and links - will try to compile the demo program later...

Neil Walker
Member #210
April 2000
avatar

For the first point, what I did was simply a search/replace of std::min/std::max and replace with just min/max (i.e. miss out the std:: bit). I don't know what the real fix is, but I think min/max aren't actually part of the STL and for once MSVC is failing correctly.

For the second, I thought flad was going to change this, but either way what I did is as below. I haven't updated the SVN with all my changes as there are various things that don't work. Try compiling all the examples, and depending on the version of OL you have one or more will fail. The last time I tried, the linestrip example fails due to something in the linestrip class being initialised incorrectly. Anyway, here's the code for internal.hpp

Basically, I would say don't bother with OL for MSVC as it simply doesn't work properly, and I'm pretty sure it has nothing to do with MSVC. You're best off getting a copy of devc++/mingw, developing in MSVC as you can't beat the editor, then compile with devc++/mingw to get the fecker working.

1#if defined(_MSC_VER) && _MSC_VER < 1300
2 #define OlAssert( condition ) \
3 if( !(condition) ) { \
4 char linechars[64]; \
5 OlError( "Assertion failed somewhere in a VC6 program. Shutting down. Sorry can't be any more help"); \
6 exit( -1 ); \
7 }
8 
9#elif defined(_MSC_VER) && _MSC_VER > 1300
10 #define OlAssert( condition ) \
11 if( !(condition) ) { \
12 char linechars[64]; \
13 sprintf( linechars, "%i", __LINE__ ); \
14 OlError( "Assertion failed in \nFile: " + std::string( __FILE__ ) \
15 + ", line " + std::string( linechars ) \
16 + "\nFunction: " + std::string( __FUNCDNAME__ ) \
17 + "\nProgram shutting down" ); \
18 exit( -1 ); \
19 }
20#else
21 
22 #define OlAssert( condition ) \
23 if( !(condition) ) { \
24 char linechars[64]; \
25 sprintf( linechars, "%i", __LINE__ ); \
26 OlError( "Assertion failed in \nFile: " + std::string( __FILE__ ) \
27 + ", line " + std::string( linechars ) \
28 + "\nFunction: " + std::string( __PRETTY_FUNCTION__ ) \
29 + "\nProgram shutting down" ); \
30 exit( -1 ); \
31 }
32#endif

Also, note that some of the examples won't compile either and you'll have to hack the code! one such thing is the demo game that is coded with some GCC specific code (a wierd ?: variant)

Neil.
MAME Cabinet Blog / AXL LIBRARY (a games framework) / AXL Documentation and Tutorial

wii:0356-1384-6687-2022, kart:3308-4806-6002. XBOX:chucklepie

tobing
Member #5,213
November 2004
avatar

First thanks. I've replaced the OlAssert with what you posted and it compiles fine.

For max and min, I'm sure that the right solution is to get rid of the defines, because max and min are template function from somewhere in the std namespace. Unfortunately windef.h does not do it correctly (at least I think so), so one needs to #undef these symbols.

As for using it or not: I would really prefer to use the compiler I know, no need to install another IDE and compiler, and of course in the office I can't do that anyway. The question is, would Fladimir be interested in having OL compile and run with MSVC? If yes, I'd be happy to help. If not, well... maybe I won't use OL at all. Depends...

Fladimir da Gorf
Member #1,565
October 2001
avatar

Quote:

The question is, would Fladimir be interested in having OL compile and run with MSVC? If yes, I'd be happy to help

Of course I am. It's just that I've never learned to use it myself, so that's why I'm not aware of it's "specialities"...

OpenLayer has reached a random SVN version number ;) | Online manual | Installation video!| MSVC projects now possible with cmake | Now alvailable as a Dev-C++ Devpack! (Thanks to Kotori)

tobing
Member #5,213
November 2004
avatar

Great! So how do I send you the changes I would propose? I can access SVN from home, so I could verify whatever you put in there.

Fladimir da Gorf
Member #1,565
October 2001
avatar

You could join the project if you get a BerliOS account...

OpenLayer has reached a random SVN version number ;) | Online manual | Installation video!| MSVC projects now possible with cmake | Now alvailable as a Dev-C++ Devpack! (Thanks to Kotori)

Neil Walker
Member #210
April 2000
avatar

Get yourself tortoise svn and it's a doddle.

But remember, as well as getting it to compile there are the problems with it crashing at various points in code with the samples (and obviously there are many areas not tested in the samples!). I posted the code to the mailing list that causes MSVC build to crash, but everyone seemed to be in agreement that the code was fine, it just crashed when running as MSVC.

Neil.
MAME Cabinet Blog / AXL LIBRARY (a games framework) / AXL Documentation and Tutorial

wii:0356-1384-6687-2022, kart:3308-4806-6002. XBOX:chucklepie

tobing
Member #5,213
November 2004
avatar

Fladimir: I consider this a an honor for me. So I'll try to get an account there.

There's one thing: I can't verify any changes against gcc or any other compiler than MSVC. So how do you do it then? I wouldn't like to simply submit any changes to SVN, because I can't be sure that it works for everybody else. So I would prefer having any changes be checked before submission...

Neil: I have Tortoise SVN already. Remains to learn how to use it. At work we're using Perforce, which makes many tasks really simple, and many years ago I remember that I used plain SCCS (Good old days).

Fladimir da Gorf
Member #1,565
October 2001
avatar

TortoiseSVN is almost too easy to use, just right-click the directory in Windows where you want the project to be placedc, choose "SVN Checkout..." and enter the repository URL.

Would installing GCC be too difficult? Playing with different brances would just complicate the whole process...

OpenLayer has reached a random SVN version number ;) | Online manual | Installation video!| MSVC projects now possible with cmake | Now alvailable as a Dev-C++ Devpack! (Thanks to Kotori)

tobing
Member #5,213
November 2004
avatar

Are you using gcc under Windows or linux? For me, it might be possible to install gcc, but I think it would be easier if you just check my changes and submit them. No need for any additional branches. For now, it's just some small things, and I can try to get gcc running for more changes at a later time. Would that be fine? I guess using MinGW would be OK? Don't have linux...

Fladimir da Gorf
Member #1,565
October 2001
avatar

I don't have Linux either, but the main thing is to check if the code still compiles with GCC. Sending the files over using email, for example, could be a bit tendious.

OpenLayer has reached a random SVN version number ;) | Online manual | Installation video!| MSVC projects now possible with cmake | Now alvailable as a Dev-C++ Devpack! (Thanks to Kotori)

tobing
Member #5,213
November 2004
avatar

So I would suggest I send you two changes by mail, because they are really small changes and are essentially what has been discussed here already. You verify these and put them into SVN. Meanwhile I continue to compile and run the samples, and get MinGW with gcc to work. As soon as that runs (and I got a berlios account) I'm willing to verify my changes against gcc and submit them myself. OK?

Fladimir da Gorf
Member #1,565
October 2001
avatar

That's fine. (Email: fladimir2002 ... at ... hotmail.com)

OpenLayer has reached a random SVN version number ;) | Online manual | Installation video!| MSVC projects now possible with cmake | Now alvailable as a Dev-C++ Devpack! (Thanks to Kotori)

juvinious
Member #5,145
October 2004
avatar

You could always roll back changes if they hose anything up. But the best thing to do and to prevent us from any headaches is to install gcc/mingw and make sure that your changes are fully compliant with gcc.
You know if msvc is having a problem with ansi c++, maybe looking into stlport woud be a good idea in bridging the gaps between gcc and mvsc for openlayer.
Flad: Is there any consideration into getting a newer release out soon?

__________________________________________
Paintown

Fladimir da Gorf
Member #1,565
October 2001
avatar

As soon as I get time to finish the minor stuff I'm working on. Altough making a new release doesn't mean so much nowadays, when we have the SVN repository.

OpenLayer has reached a random SVN version number ;) | Online manual | Installation video!| MSVC projects now possible with cmake | Now alvailable as a Dev-C++ Devpack! (Thanks to Kotori)

Evert
Member #794
November 2000
avatar

Quote:

So how do you do it then? I wouldn't like to simply submit any changes to SVN, because I can't be sure that it works for everybody else. So I would prefer having any changes be checked before submission...

The way this works for Allegro is to submit a patch, which is (supposedly) tested before being commited to the repository.

Richard Phipps
Member #1,632
November 2001
avatar

juvinious
Member #5,145
October 2004
avatar

Quote:

Altough making a new release doesn't mean so much nowadays, when we have the SVN repository.

Which I believe is true, though I've seen quite a number of people reluctant to grab stuff from svn for some reason, even if the svn snapshots would make it easier for those people who'd rather not. The main issue I see here is that people are still grabbing the 2.0 release thinking that it's the latest. You could just do an interim release by grabbing the latest svn snapshot and throwing it on the downloads page. In any case I'm not bothered by it, I do prefer svn.

Quote:

Perhaps have two SVN folders?

I don't see why we would need to unless OL is going to go through a complete refactoring of the entire source tree.

__________________________________________
Paintown

tobing
Member #5,213
November 2004
avatar

Patch sounds good. Have to read the manual of SVN to learn what a patch is (in terms of SVN). Perforce does not have the concept of a patch.

stlport is not needed, the stl which is delivered with MSVC 7.1 is OK. There have been issues with the stl of the older MSVC 6.0.

I have only recently started to use SVN instead of official releases. And I don't like it - in general. So it's good to use SVN if you want to contribute. It's not good if you want a tested, reliable version to build upon. Well, that's actually why I decided to get OL from SVN: OL 2.0 didn't work for me. This in turn means to get AllegroGL from SVN, too. The advantage is, that it's new. The disadvantage is: It's new! So probably not as thoroughly tested and reliable as an 'official' release.

Thomas Fjellstrom
Member #476
June 2000
avatar

The concept of a patch isn't really related to the version controll system. you just use patch and diff to make and apply patches. Applying a patch will change certain files which will get updated when you commit.

--
Thomas Fjellstrom - [website] - [email] - [Allegro Wiki] - [Allegro TODO]
"If you can't think of a better solution, don't try to make a better solution." -- weapon_S
"The less evidence we have for what we believe is certain, the more violently we defend beliefs against those who don't agree" -- https://twitter.com/neiltyson/status/592870205409353730

tobing
Member #5,213
November 2004
avatar

Ah. patch and diff commands, right? Not available on Windows, that's probably why I'm not familiar with them. Are they contained in MinGW? If not, where can I get Windows versions of them?

Neil Walker
Member #210
April 2000
avatar

My assumption was that I was just going to post my changes in one go, someone would check them and rollback if it didn't work. However, I use mingw as well, which is how I can test OL with msvc and gcc and given it works in the mingw version (and the changes were targetted at msvc anyway) the likelihood of an error should be close to zero.

I never got round to posting all my updates (they are still on my computer in tortoise) due to it crashing in the demos with the msvc version. All I would say, is you really need to check all the examples plus demo run as expected before you update the system, and test with mingw/devc++

Neil.
MAME Cabinet Blog / AXL LIBRARY (a games framework) / AXL Documentation and Tutorial

wii:0356-1384-6687-2022, kart:3308-4806-6002. XBOX:chucklepie

juvinious
Member #5,145
October 2004
avatar

Neil, well if the changes didn't affect the mingw/gcc build, I wouldn't see why you don't apply them. That way others can take a look at your changes and contribute or assist. That's what svn is intended for anyhow, WIP. :)

__________________________________________
Paintown

Neil Walker
Member #210
April 2000
avatar

true, but people might start downloading and using OL only to find out (like me) that after a lot of investment in time and effort, they can't actually get OL to work properly with MSVC. tbh, every few months I download OL, redo the changes and test it to death to see if it works. So far, it still works beautifully with devc++ but fails at various parts with MSVC, and I'm at a loss as to why it fails, despite tracing it to the line of error.

Neil.
MAME Cabinet Blog / AXL LIBRARY (a games framework) / AXL Documentation and Tutorial

wii:0356-1384-6687-2022, kart:3308-4806-6002. XBOX:chucklepie

tobing
Member #5,213
November 2004
avatar

I guess most projects with several developers have this kind of problem, in various flavours. So whenever I submit a change, it's my task to verify the changes against a defined series of test programs before submitting. Question is, which are these? And which platform has to be tested?

With OL I understand that the sample programs are expected to work fine with gcc under Windows and maybe linux (?). So we don't know for sure if MSVC 7.1 will be able to run the samples. This would mean that you may submit any changes that don't break gcc (compile and run all samples), and hopefully improve MSVC 7.1. Maybe we can reach a state where we also know that the samples work fine with MSVC, then one could try to ensure that not only gcc works fine with each change, but also MSVC.

I know, this creates some work, especially for those who wish to submit a change, because one has to run the tests. Nevertheless, that's the way we do things here at work, and it has proven to be more effective this way than submitting bugs, which will slow down all others who get the bad changelists.

Well, I have a berlios account now (tobing), which I might use for submitting anything. But before that, I'll install MinGW and get things compiled also with that - to be sure that I don't break anything.

Edit: Got the sample programs compiled and run, also the demo game.

What does ballYSpeed += ((float(mouseYMovement) <? 2.5) <? 0 ); mean?

There's one problem though. All demos showing text only show rectangular outlines of where the letters should be displayed. Probably something wrong with Glyphkeeper or AllegroGL or Freetype or something else?

Remarks to the SVN version: I had to copy the Fonts from textdemo to the linestripdemo directory to have that run, and I had to change the shapedemo to use PointerAlpha.png.

 1   2   3 


Go to: