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...

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.

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)

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...

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"...

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.

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

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.

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).

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...

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...

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.

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?

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

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?

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.

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

Perhaps have two SVN folders?

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.

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

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.

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.

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?

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, 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.

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.

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.

Good work!

Thanks.

Any idea what goes wrong with the text? I have compiled Glyphkeeper 0.29.1 (from the OL 2.0 distro), such that it uses allegrogl (SVN) and freetype 2.2.1 (the current distro).

I don't have Glyphkeeper, or the other libs required so I built OpenLayer without that support.

How do you display text then? Do the sample programs work for you?

I don't use the text functions. I haven't tried the sample programs or the demo with this build.

How do you know that the library(ies) you use really are compiled correctly and do work as expected? That's why I like to try the demo programs first...

I've copied all that stuff now to my laptop, which has an Intel graphics chip. To be precise, it's an 82852/82855 GM/GME.

The samples which work are: gameloop, renderbitmap and shapedemo.
The other samples do not work:
linestripdemo shows those rectangular area instead of text, and no wandering dot at all. Just black background.
textdemo shows garbage all over the window. Weird!
gamedemo flickers and only shows part of the window. Mouse input is not working, and the ball is not moving.

Maybe some of this is related to the problems of AllegroGL with Intel chipsets?

I haven't tried all the AGL emamples yet, but most of what I tried seems OK (dumbtest crashes because of a NULL pointer on both PCs).

I'm looking at this from the perspective of does my game work ok with it, not does every command in OpenLayer work. I don't have the time to try every command (and some I wouldn't use anyway).

Tobing: Do these problems occur on a PC without Intel Chipsets?

No. This morning I have set up a bunch of MSVC project files to get all that compiled, and all this was on my PC with RADEON X850 Pro AGP (Omega 3.8.252), everything fine. Of course I did it this way, because I knew that there might be problems with my Intel based laptop, so I did that second.

So, this is with the latest SVN patch?

I haven't seen any errors apart from crashing on setting up a screen with Intel chipsets. Once I patched that I haven't seen any more errors.

Can you narrow down exactly what commands or parts of the example code it's doing wrong?

Latest SVN, yes. I've updated yesterday evening.

Maybe I can narrow down any of these, depends on if I have time to go into it. Real life is calling...

I understand.

I have found that non-power of 2 texture sizes cause problems on some chipsets. So, it might be that making some of the demo textures be a power of 2 fixes some problems.

I've tried the fonttest example from AllegroGL, but it doesn't work. Crashes within the first call of load_bitmap, when it tries to load a32.tga.

Also single-stepped the textdemo example of OL, but couldn't see anything obvious.

Difficult...

Edit: Tried to compile AllegroGL with various other targets. GLYPH_TARGET_ALLEGGL works, GLYPH_TARGET_OPENGL does not compile (missing stuff from windows.h and allegro.h). GLYPH_TARGET_ALLEGRO does compile, but does not link with OL. Seems that OL requires GK compiled with GLYPH_TARGET_ALLEGGL, right?

I think I'll give up for today. Debugging this requires much deeper understanding of the inner workings of the text rendering part of OL...

That all sounds pretty strange. I imagine the demos work for the devs of AllegroGL and OpenLayer, so I wonder what's different here?

I have the demos running fine now. The point was to not use GlyphKeeper from OL, so I guess there are some problems buried there.

One thing remains to be debugged: The gamedemo and the linestripdemo do not work on my laptop (with the 82855 etc. Intel graphics chip), but do work on my Radeon X850 Pro. I'll check tomorrow on the Intel 910 graphics chip at work. Most probably it's some OpenGL feature which is not fully supported by the graphic chip...

Neil bangs his head on the keyboard at this point

For the first point, I mentioned this earlier being the code in the demo that uses GCC specific code. Just ignore it, flad said he was going to remove it.

For the second, that's what I was saying all along, the demos don't work with MSVC, in particular the linstrip.

They DO work now, at least on my PC. All of them. It was worth trying, wasn't it?

Edit: The demos work on this PC (at work: Intel(R) 82915G/GV/910GL Express Chipset graphics). The gamedemo however only gets about 10 fps, both Debug and Release builds, and is really choppy, making it unplayable.

Seems that the implementation if OpenGL on Intel graphics chips is ...not good...

Yep, in our tests some Intel Chipsets are pretty slow.

Hello!

I've been trying to follow this thread but I'm not getting a clear picture of the progress you guys have done.
Is the latest svn good enough to build for MSVC? Or are there still some quirks that needs to be straightened out besides the Intell chipsset issue?

I'd love to use OL in MSVC since CodeBlocks IDE is giving me the creeps o_0

As soon as the latest changes are submitted to SVN, the code should compile and run with MSVC 7.1. There are no project files however in SVN...

I'm not saying there's no harm it trying, i'd love to seen OL working for MSVC

All I said was under MSVC, during the history of OL various examples have crashed my computers (different ones). The latest SVN crashes during linestrip demo and tracing the code ended up with the vector (I think) being null, despite being previously populated), or something like that.

As for no project files, just add your own like there are the .dev files for devc++

That's most likely because a32.tga is broken. SVN update breaks it when downloading but I can't see why.

That explains why I can only see the letter 'A' in that file.

Maybe I should think about putting my project files up somewhere. The point is: I have not only project files for all libraries which are part of the build (of an openlayer demo in this case), but also a different naming convention for the output files, location of output files and location of intermediate files. That way I can have different versions of allegro, zlib, lpng, whatever next to each other and pick what I intend to use easily. Now, a MSVC solution file assembles the projects contained in it, using the dependencies you define, which are stored in the solution file. So you can't easily use the solution if not all projects are present.

Once in this state, it's very easy to single step into any function in any of the libraries which are part of your program, be it a static library or a dll. That's the feature I use mostly to get understanding of foreign code: try to use it, then step into to see how things happen. Also I like to step through sample programs. And that doesn't work well, if you link the libraries using extra libraries property instead of adding the project...

A hint for hunting a possbile bug in AGL that affects NPOT textures:
- open AGL's src/glex.c, function void __allegro_gl_manage_extensions(void)
- put "allegro_gl_extensions_GL.ARB_texture_non_power_of_two = 0;" at the botton of the function.

This will make AGL unaware of NPOT extension even if it is available and use texture rectangle instead (if available, fail otherwise).

If you update you AGL copy with the latest patch (committed a minute ago), you can enable extensive logging with LOGLEVEL env variable on MSVC build. Building AGL as "make DEBUGMODE=1 LOGLEVEL=3" should do. There should be a list of available extensions in logfile. Can you attach it please?

I'll try it when I'm back home. Don't have SVN access from work...
Which program should I run to produce the output? linestripdemo?

Any AGL example.

Here you are. 4 logs of exalleg, two on my X850Pro card, two on the 82855 Intel chip. I can make two more tomorrow in the office on an Intel 910.

tobing: Applied your changes to SVN. Check it out or go over it when you get a chance to make sure it's all there.

Do you need to 'binary' files as 'binary' files on SVN? With CVS you need to in order to prevent line-ending conversions when going between DOS/Windows and UNIX; I can imagine that something similar is true of SVN.

I'll update from SVN immediately.

SVN seems to work with mime-type, and in that case it's a stream of octets. It also seems that the file is already broken in the depot, because I couldn't retrieve it by the web interface.

Files are OK when I checkout from linux and broken when I checkout from cygwin.

Both Intel82855 and X850Pro seem not to support ARB_texture_non_power_of_two. The texture is rescaled to power-of-2 by AGL. I don't see any relevant differences between the two cards. Does the problem persist if you rescale bitmaps manually before passing them to OL?

Another thing I have noticed with X850Pro. It reports EXT_texture_rectangle extension presence but AGL only checks for ARB_texture_rectangle and NV_texture_rectangle. Check for EXT_texture_rectangle is made MacOSX only. It may even fix something, who knows. Anyway, try the attached patch.

First here are two more log files, made with an Intel(R) 82915G/GV/910GL Express Chipset graphics card.

Second, how do I apply the diff? I only have Windows, so where can I find the right tools and how is the command? Sorry actually for asking, I know this is really some unix elementary question...

Try something from here.

Thanks. I DO know how to use google. I'm also using WinMerge (besides Perforce P4WinMerge), but that only gives me diff's - but I need to apply a diff file to the originals.

Found GNU patch command, I guess that is what I should use?

yes, but iirc there exists gui patchers that show you details and let you customize the patching.

That would be nice. Seems I can't get the path command going...

Edit: got it. The diff file had the wrong line breaks - with CR/LF it was fine.

Edit2: compiles and runs fine. In fact, there's no noticable difference running the example... I've attached the log file...

It was a fix for X850Pro. Even if it doesn't fix anything here I still believe it is needed.

Ah. The X850Pro is what I have at home, so I'll check this evening.

Edit: Here we go. exalleg works fine, log file is attached.

Now I'm confused. Wasn't everything with X850Pro just fine anyway, or does this patch fix actually something?

Everything was fine on the X850Pro, so the patch didn't change anything I could observe. I wanted to give feedback so you might be able to see what your changes did on that card - so that's why I attached the log file.

OK, give me logfile from dumbtest then.

dumbtest has always crashed upon me, all PCs I've tested. It tries to create a video_bitmap, but seemingly doesn't succeed. Then it crashes in the following clear_to_color call, because the bitmap pointer is 0.

Lines 51 and 52 from dumbtest.c:

  vid_bitmap = create_video_bitmap(50, 50);
  clear_to_color(vid_bitmap, makecol(255,0,255));

Edit: dumbtest does not crash, if I create the video bitmap as 64x64.

Attached is the log file on my PC at work (82855 Intel). I'll be home late tonight, so I most probably can't run the test on my X850pro this evening...

That's something that needs to be fixed. It is related to ARB_texture_rectangle and ARB_texture_non_power_of_two extensions.
create_video_bitmap(50, 50); is expected to fail on chips where these extensions are not available, because of NPO2 size. It won't work on Intel 915G and Intel Montara-GM, but it should work on X850Pro with the patch.

Note that I'm referring to agl_ext_tex_rec_fix.diff patch, the "allegro_gl_extensions_GL.ARB_texture_non_power_of_two = 0;" patch doesn't do anything to any of your GFX cards, you can omit it.

Oops. I completely forgot this thread...

So here's the logfile of dumbtest on my X850pro.

So, the conclusion is that dumbtest, or more specifically, "create_video_bitmap(50, 50)" works with the patch?

Correct. This time the allocation was successful.

Great! The patch will be passed to the mailing list. Thanks for testing.

Still, the original problem with OL was not fixed... I have no clue what could be wrong. I'd rather just blame Intel.