Welcome, Guest. Please login or register. Did you miss your activation email?

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Topics - CorrodedCoder

Pages: [1]
Window / clear/draw/display pattern and some others stuff
« on: August 12, 2012, 08:37:16 pm »
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 :D). 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:

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


Pages: [1]