Allegro.cc - Online Community

Allegro.cc Forums » Allegro Development » MSVC 8 project file

This thread is locked; no one can reply to it. rss feed Print
MSVC 8 project file
Matthew Leverton
Supreme Loser
January 1999
avatar

See this thread for the previous discussion (MSVC 6).

Project files for MSVC 8 are now ready for testing. See the wiki page for instructions. Note that the project files only work with a custom version of 4.3.1 (available on the wiki). They build everything from Allegro to the tools and examples.

If you have Visual Studio 2005 or Visual C++ Express 2005, please test it out. I recommend not copying the header and lib files to your VC directory, since it will overwrite your current version of Allegro. However, copying the alleg43.dll to your system folder will be required if you want to run any of the demos, etc.

The project files were all generated by a script. The process has evolved into an "elaborate" mini PHP project that is actually capable of building all sorts of project files for any project. Originally it was just going to be a simple hacked together thing, but I came to the conclusion that doing a proper job would be better.

Once everything is working properly, I'll be releasing the code as a stand-alone project. Some details are available on the wiki.

BAF
Member #2,981
December 2002
avatar

Well, I'm getting compiler errors because I don't have DirectX SDK installed, so you may want to add that to the requirements.

[edit]
After installing the DX SDK, it works great.

gillius
Member #119
April 2000

:( wiki site is down.

If this works it would be nice to be able to compile Allegro in a pure MSVC environment.

Gillius
Gillius's Programming -- http://gillius.org/

Timorg
Member #2,028
March 2002

The example on the wiki has "c:\allegro" and "C:\Program Files\Microsoft Visual Studio 8\"

I am using
z:\allegro
z:\msvc8 (spaces in install path breaks some libs)

I get the following errors when I build all the tools, everything else works fine.
--------------------------------------------------------------------------------
------ Build started: Project: pat2dat, Configuration: Release Win32 ------
Compiling...
pat2dat.c
Linking...
LINK : fatal error LNK1181: cannot open input file '..\..\..\lib\msvc\aldat.lib'
Build log was saved at "file://z:\allegro\obj\msvc\alleg\BuildLog.htm"
pat2dat - 1 error(s), 0 warning(s)
------ Build started: Project: grabber, Configuration: Release Win32 ------
Compiling...
grabber.c
Linking...
LINK : fatal error LNK1181: cannot open input file '..\..\..\lib\msvc\aldat.lib'
Build log was saved at "file://z:\allegro\obj\msvc\alleg\BuildLog.htm"
grabber - 1 error(s), 0 warning(s)
------ Build started: Project: dat2s, Configuration: Release Win32 ------
Compiling...
dat2s.c
Linking...
LINK : fatal error LNK1181: cannot open input file '..\..\..\lib\msvc\aldat.lib'
Build log was saved at "file://z:\allegro\obj\msvc\alleg\BuildLog.htm"
dat2s - 1 error(s), 0 warning(s)
------ Build started: Project: dat, Configuration: Release Win32 ------
Compiling...
dat.c
Linking...
LINK : fatal error LNK1181: cannot open input file '..\..\..\lib\msvc\aldat.lib'
Build log was saved at "file://z:\allegro\obj\msvc\alleg\BuildLog.htm"
dat - 1 error(s), 0 warning(s)
--------------------------------------------------------------------------------

If allegro is inside the visual studio 8 directory (z:\msvc8\allegro\ in my case) it works fine.

BAF said:

Well, I'm getting compiler errors because I don't have DirectX SDK installed, so you may want to add that to the requirements.

I found I didn't need the sdk, I just needed the minimal headers (dx70_min.zip) installed.

On a side note, (if my memory is correct,) I can remember when the windows version of allegro needed visual studio to build it. Then it was made so that you could build it completely with free tools, now we are trying to fix it so that you can build it completely in visual studio. I guess allegro has come the full circle.

____________________________________________________________________________________________
"c is much better than c++ if you don't need OOP simply because it's smaller and requires less load time." - alethiophile
OMG my sides are hurting from laughing so hard... :D

Matthew Leverton
Supreme Loser
January 1999
avatar

Quote:

I get the following errors when I build all the tools, everything else works fine.

Those tools depend on aldat.lib, which you hadn't built yet. It won't be a problem once I fix the dependency checking (which used to be working until I changed some things around...).

Timorg
Member #2,028
March 2002

I just ran over it again, your right, it fails on the 1st build, but if i run build again, everything comes out fine. :)

I built it the 1st time not in the msvc directory, then I moved it, and compiled it again, and it worked. It was the dependency being build, not the moving that made it work.

____________________________________________________________________________________________
"c is much better than c++ if you don't need OOP simply because it's smaller and requires less load time." - alethiophile
OMG my sides are hurting from laughing so hard... :D

gillius
Member #119
April 2000

I'm sorry I'm not trying to sound critical, but CMake builds MSVC workspaces and a lot of other targets are possible as well. In GNE I was able to replace several versions of MSVC workspaces and Makefiles for several different systems as a single CMake system. The process of generating workspaces even in a high-level scripting language like PHP sounds like a non-trivial task, so I ask this out of curiosity.

Gillius
Gillius's Programming -- http://gillius.org/

Matthew Leverton
Supreme Loser
January 1999
avatar

I used PHP because I know it, so it didn't take me long at all. However, if CMake can easily do the same thing, then surely someone will volunteer to do it. (They just haven't yet for some reason.)

gillius
Member #119
April 2000

It's easy for someone who knows Allegro's structure and CMake. I did it for GNE but GNE is somewhat of a simple case. But that was my first CMake application so I "worked through it" with documentation. I'm sure Allegro is pretty achievable but CMake is probably not trivial enough for someone to do it. CMake is basically a logical replacement for automake in that it's a system that makes makefiles, but it can do MinGW, Linux, MSVC, nmake, etc.

Gillius
Gillius's Programming -- http://gillius.org/

Peter Wang
Member #23
April 2000

Allegro 4.3 (4.9) has had a CMake build for about half a year now. It's mainly for the Unix port, although it did work with MinGW at one stage.

Timorg
Member #2,028
March 2002

Something has just occurred to me, When I build allegro, I build the dll version first, then I build the static version, so that all the examples and tools are statically linked, so I don't have to copy the dll into the directories to use them. I could copy the dll to the system directory, but I prefer not to do that, because then I get my system directory polluted, and if the dlls go out of date, applications might use the older version, and have things crash or what-not.

Not sure the best way to fix this though, maybe have an alternative configuration set that will statically link, this will show up in the batch build window, but you would need to change the drop down box for every thing you want to build, or have twice as many items in the list, one for dynamic and one for static, and I'm not sure what would happen if you selected both.

Just thinking out loud really.

____________________________________________________________________________________________
"c is much better than c++ if you don't need OOP simply because it's smaller and requires less load time." - alethiophile
OMG my sides are hurting from laughing so hard... :D

gillius
Member #119
April 2000

Peter: Well since CMake is designed to be portable, it should already work to generate MSVC workspaces. I guess it's possible to have it working only in one environment but I figure that's pretty hard to do. Then again I'm not a huge CMake guy -- I only did it once so I'm no expert.

Gillius
Gillius's Programming -- http://gillius.org/

Peter Wang
Member #23
April 2000

It shouldn't be hard to make it work with MSVC, but I doubt it would work as-is. It's easy to miss a #define or two, or try to pull in a library that only exists on Linux, etc.

We used to require some asm code on Windows, and CMake doesn't (didn't) have very good support for that, even with MinGW, so who knows what kind of hoops you had to jump through to get it to use gcc for a few files but MSVC for the rest. Matthew's recent changes should solve that problem at least.

Matt Smith
Member #783
November 2000

Well I finally got asmlock.asm ported fully, and it was a valuable learning experience. I learned the following things

  • Only pro/enterprise versions of VC come with MASM installed. MASM is available for VC8 express but comes with a non-commercial license. VS6 is fundamentally broken in its use of external tools (which is why earlier attempts to use gnu as have failed too)

  • The functions in asmlock.s are NOT compatible with ALLEGRO_NO_ASM. This means that all the iblit*.s files would also need porting to MASM

  • asmlock.s was heavily rewritten somewhere between Allegro 4.0 and 4.2.1. Nobody is credited with the changes at the top of the file.

  • The performance benefits of the calling convention used in the asm code are negligible, as these funcs could easily be inlined.

  • None of these funcs are user functions. They lie deep in the DX and GDI drivers and do not need exporting in the dll ABI. Thus it is safe to replace any alleg4*.dll with a C version. There are no conceivable circumstances where it would not work 100% correctly.

My conclusion is therefore that the C code is the only viable solution, and so I will modify my 4.2 projects to match Matthew's 4.3.1 ones. I shaln't inflict my asmlock.asm on anyone ever again.

I would suggest keeping the 386 gnu code indefinitely (at least in the 4.x branch), as this covers a lot of bases, and serves as a template should anyone fancy trying their hand at mmx (edit: duh already there for blit) or sse versions.

ixilom
Member #7,167
April 2006
avatar

bump

___________________________________________
Democracy in Sweden? Not since 2008-Jun-18.
<someone> The lesbians next door bought me a rolex for my birthday.
<someone> I think they misunderstood when I said I wanna watch...

Matt Smith
Member #783
November 2000

GullRaDriel and I have both had problems with the GDI driver, which has been repainting incorrectly. I think I have discovered the reason. EDIT: rest of post deleted because it was all WRONG!

GullRaDriel
Member #3,861
September 2003
avatar

And so now MattyMatt, is it working ?

"Code is like shit - it only smells if it is not yours"
Allegro Wiki, full of examples and articles !!

Matt Smith
Member #783
November 2000

IT IS WORKING! 8-)

src/win/wgdi.c line 52

---
gdi_dirty_lines[bmp->y_ofs] = 1;
+++
gdi_dirty_lines[bmp->y_ofs + line] = 1;

Can I have my "I Am An Allegro Dev" badge now please? ;D

GullRaDriel
Member #3,861
September 2003
avatar

Cool ! So now do we have a full C version of allegro working ? (The important part is Full C )

EDIT due to irc speak: Yes it does, and it is Nice ;-)

"Code is like shit - it only smells if it is not yours"
Allegro Wiki, full of examples and articles !!

Go to: