hello again,
so i spent the whole afternoon on trying to compile sfml2 (updating the whole xcode project before) and trying to figure out what needs to be done and what is going on behind the scenes.
for that i compared it to what was going on in sfml1 on the macosx side...
first of all - kudos to the person that wrote the macosx part before!
it is clean (in terms of coding convention/style/formatting, no dead code) and it does some things really well. like providing standard functionality available on other platforms for SFML, i.e. creating opengl views + and windows at runtime. before i thought this was done via Carbon. but then i saw that it already had an Cocoa implementation. hell, i didn't even know this was possible without a NIB.
and it is hiding the implementation from the user!
and IMHO this is also the bad part. it tries so hard to mimic behavior of other platforms (like linux and windows) and for this a lot is going on in the background (create a global context, global appcontroller, a dummy window, etc) and i can only think this thing must be hell to test, debug and maintain ... ok ok, i knew that mixing objective-c(++), cocoa and c++ would be strange and that everything is packed in 3 gigantic obj-c++ files certainly does help to further obfuscate things ...
so my questions would be?
what would you like to change for the new macosx/cocoa backend?
and why? why not stick with the old?
do you want to have a opengl-context wrapper because of multithreading?
it would really help if someone could shed some light on this topici n general ...
gracias!
