clear/draw/display pattern and some others stuff

[CorrodedCoder]

A night of insomnia caused me to dig out an old C++ game engine research project I'd written years ago to see if I could change the view (as in view/model arch) to something more respectable (it was using the MS-DOS console ). I've kept an eye on SFML for a couple of years when I last had the urge but never got beyond reading about features. Well, last night I did and successfully wrote a muckabout app followed by porting my old "snake" game to SFML 2.0RC 

Firstly I'd like to congratulate you on an excellent intuitive library. It was very easy to get started and the concepts were clear and tutorials helpful, hopefully I find the time to experiment further and try out some more things.

Anyway, enough praise already - time for a couple of questions/suggestions:

I've done enough Windows GUI programming (and FYI I normally dislike it given how particular and unnatural many are) to know some of the patterns, but one I wanted to validate here is the clear/draw/display pattern. My old MS-DOS console view optimized the output as it's so slow so that only changed areas were rewritten. In my first attempt to port the view I copied this approach too but it led to some peculiar outcomes. Following a similar pattern I did not call "clear" each time before drawing a few moving shapes (rather I would overwrite the old position in black and then write the new one in color). This led to a peculiar flashing window almost as if there were two alternating buffers in play (well - that's what I'm guessing you're going to tell me). So my question is really, and I apologize I just couldn't seem to find any relevant docs on this, does one always need to consider the window as needing to be redrawn when changes are made? I know the common windows pattern is to have some kind of separate working image and then keep blitting it over the display when asked, but I wasn't sure if the same deal was true here. FWIW I wasn't actually intending to stick with this approach in the long run, but I was simply curious as to what was going on.

The second thing is really more of a suggestion to consider compiling with the Windows libs with the "/Zl" switch to make them MS runtime agnostic. I very much appreciated the option you provide to link SFML itself statically, but I often also prefer to link with the MS runtime statically to avoid the redist issues. If you're interested in using that switch let me know and I'll dig up a define which it's also wise to set to be completely clean. Oh and on a related topic I was getting a warning when I linked that leads to me to think that one of your libs is mixed up there:
1>LINK : warning LNK4098: defaultlib 'LIBCMT' conflicts with use of other libs; use /NODEFAULTLIB:library

I had a look at it seems that the graphics libraries both have references to both LIBCMT and MSVCRT, so that would seem to be the culprit:
              ..\..\..\objs\release_mt\*.obj

Anyway, kudos again on some nice work - I hope I get some more time to play and upgrade my "view" from drawing shapes to drawing something more exciting

CC

[Laurent]

Yes, nowadays you need to clear/draw/display every frame, and yes, the "flashing" is caused by double-buffering

SFML can be compiled with static MSVC (or gcc) runtime on Windows, this is supported. However this is not the default option since it's not the default in Visual Studio; and it should only be used in specific cases, dynamic runtime is recommended as the default choice anyway.

I never really understood the LNK4098 warning, it seems to always occur regardless of what you do. Trust me, all the libraries involved in SFML were compiled with the same runtime options.

[eXpl0it3r]

I never really understood the LNK4098 warning, it seems to always occur regardless of what you do. Trust me, all the libraries involved in SFML were compiled with the same runtime options.

I can second that, it doesn't really seem to matter what you do, VS always complains with that linker error and in most cases it can be ignored. From time to time it has happend to me though that the warning also produced some errors, in such cases you'll just need to exclude all the other runtime libraries and the warning puls the errors will go away.

[CorrodedCoder]

Thanks for the quick response guys - that's a good sign

Thanks for the info on double-buffering, makes sense.

On the linker error, I can give some background if that helps (for a living I design/provide APIs for cross platform purposes). In essence MS add some data to each object file you compile, called directives, and these contains things like /DEFAULTLIB:LIBCMT which are then passed to the linker when it's all pulled together. These days on windows there are four choices: LIBCMT, LIBCMTD, MSVCRT, MSVCRTD for each of the release/debug static/dynamic linking choices (dumpbin /all shows you the details).

Ultimately when you get a complaint you're seeing that two modules were compiled differently (/MT, /MTd, /MD, /MDd and so have different defaultlib's specified.

In your case all your libraries contain object files which are specifically specifying either MSVCRT or MSVRTD except for those few modules I mentioned which contains references to LIBCMT - so at least for the libraries I downloaded yesterday there is a mismatch there.

Sometimes it doesn't matter, but sometimes it does if the layout of objects/etc differs when compiling in different modes you can get nasty problems like crashes and whatnot. If you're largely calling C functions, then odds are it won't matter as much.

In any case, that "/Zl" switch I mentioned turns this capability off so that the MS runtime no longer implies a default library and the use can just link regardless of their settings. From memory, you do typically also specify "/MT" just to keep everything sweet, but you won't have any sections containing those DEFAULTLIB statements.

If you're interested, I could take a look at your build files if I get the chance this week?

Thanks for a speedy response!
CC

Edit: I had a quick look and it appears the third party dependancy freetype.lib is compiled as MT, so that's where it's coming from. i didn't check the other third party bits. Hope that helps!