| 00:19.13 | *** join/#bzflag infobot (~infobot@rikers.org) |
| 00:19.13 | *** topic/#bzflag is https://BZFlag.org || http://ohloh.net/p/bzflag || https://bzflag.org/help || Channel Logs: http://infobot.rikers.org/%23bzflag/ || 2.4.10 released! https://forums.bzflag.org/viewtopic.php?f=8&t=19401 |
| 00:19.13 | *** mode/#bzflag [+v infobot] by ChanServ |
| 00:19.46 | *** join/#bzflag afreshmelon (sid25548@gateway/web/irccloud.com/x-dxkbdempocgzbeab) |
| 00:20.20 | afreshmelon | macsforme: not sure if those sent properly |
| 00:20.31 | afreshmelon | 17:19:19 <afreshmelon> macsforme: Yeah I can test. I'll be back in Germany on Tuesday but you can send me a link now. I'll do it when I'm home |
| 01:06.57 | *** join/#bzflag bertman (~bert@unaffiliated/bertman) |
| 01:24.26 | *** mode/#bzflag [-v short_circuit] by ChanServ |
| 02:12.31 | macsforme | afreshmelon: thanks... https://download.bzflag.org/bzflag/osx/2.4.11/BZFlag-2.4.11-20170630-macOS.zip |
| 02:14.17 | macsforme | blast007: yes, I can if they need it... right now I don't have the source file in the exact format needed to produce that output |
| 02:14.46 | macsforme | but I did amend the post to say exactly what procedure and functions I used |
| 02:24.08 | blast007 | macsforme: have you tried a test app where you have NSHighResolutionCapable set to YES in Info.plist (or in the Xcode project?) and provide SDL_WINDOW_ALLOW_HIGHDPI when creating the SDL window? |
| 02:26.55 | blast007 | cuz if that does a similar thing to what the Visual Studio multi-monitor DPI aware setting did, it might be the magic settings that make macOS give you real resolutions, not the crazy scaled values |
| 03:04.56 | blast007 | and possibly also setting NSHighResolutionMagnifyAllowed to NO |
| 03:05.04 | blast007 | https://developer.apple.com/library/content/documentation/GraphicsAnimation/Conceptual/HighResolutionOSX/Explained/Explained.html |
| 14:22.39 | *** join/#bzflag answaribenhanity (uid238732@gateway/web/irccloud.com/x-qibwvzrrusnirohq) |
| 15:38.19 | JeffM | blast007: so make it behave like a real computer ;) |
| 15:44.45 | the_map | whoever makes the URLs for Apple must be a java developer |
| 16:02.42 | blast007 | the_map: or Objective-C + apple SDK developer... UIGraphicsGetImageFromCurrentImageContext() |
| 17:22.01 | the_map | actually, Swift looks like that too |
| 17:22.02 | the_map | go figure |
| 17:28.32 | JeffM | long names may be long but they are not ambiguous. |
| 17:31.08 | the_map | In my opinion though, at a certain point the names are long enough that it's cluttering the code. If the names are suitably short, you can read a line of code and not forget what the beginning of the line was by the end of the line. If the names are long, then you use the name in place of a natural understanding of the function, and it takes longer to get through a simple line. |
| 17:34.04 | blast007 | https://github.com/Quotation/LongestCocoa |
| 18:24.28 | *** join/#bzflag Zehra (~Zehra@unaffiliated/zehra) |
| 19:56.37 | JeffM | if a single thing ends up being too long to read, it should not be a single thing, and should be broken up into functions :) |
| 19:57.39 | the_map | function getImg(args) { return UIGraphicsGetImageFromCurrentImageContext(args); } |
| 19:58.00 | JeffM | well apple did take it way too far |
| 19:58.10 | JeffM | objective C must have some crappy namespacing |
| 20:00.09 | JeffM | I'd think that'd be better as using UI.Graphics; GetImage(CurrentImage.Context,args); |
| 20:02.14 | JeffM | probalby easier to maintain too, since if UIGraphicsGetImageFromCurrentImageContext needed to be a name, there are probalby other UIGraphicsGetImage... functions |
| 23:03.42 | *** join/#bzflag bertman (~bert@unaffiliated/bertman) |
| 23:50.01 | *** join/#bzflag dcat (~dcat@c-98-244-106-246.hsd1.va.comcast.net) |