02-01-2023, 02:07 PM
The resizing that you're speaking about is all tied in with windows DPI Awareness. Back in September, before my heart surgery, I was looking into fixing it to do like you're suggesting -- add a _WindowScale percentage and then have the window scale to that amount. What I had back then worked, kinda, but it wasn't stable and couldn't be called inside your program without taking risks with it blowing up on you. (The issue then was the same as what some people reported with _screenmove _middle and several other commands -- our QB64 programs tend to run on a couple of different threads, with one handling a lot of the glut stuff and the other handling the rest of our stuff. The problem which we kept running into was basically a race condition which depended on when a glut command was called, the state of the other thread, and which one finished first.)
Since then, Matt has overhauled the glut system we have, making it a lot more independent and streamlined, stopping those race conditions from popping up, but nobody has gotten around to working on the DPI Awareness issue and being able to toggle between automatic and manual scaling (which is what you're wanting to do, and which can't currently be done since we're letting the OS handle scaling automatically). It's an issue we're aware of, and we more or less have a good idea of what all pieces are necessary to have scaling work properly. (For Windows, at least. Mac and Linux will take a little more digging into.) At this point, it's just a matter of someone finding time and motivation to go in and make the changes to the language to add a toggleable automatic/manual scaling system for us -- I just can't say when that might happen. a740g is working on fixing _LOADIMAGE to work with images in memory and not just from your drive/filesystem. (This means something like iamgehandle = _LOADIMAGE("www.mywebsite.png",32) will become possible in the near future.) Matt is working on all sorts of stuff (tons of bug fixes anytime they're reported, and the https support, and correcting our keyboard input routines, and...). As for me, I've just been hibernating mainly. As anyone who's been around the project for a while knows, I've got arthritis and the cold hurts my knuckles. I don't do much coding, writing, or anything much except hibernate in the wintertime...
...So manual scaling is on the ToDo list, but nobody is currently working on it due to other stuff that they've just prioritized first. Honestly, I'd imagine it to be in the 6+ month timeline before it gets all sorted and added to the language, so you'll probably want to look for a workaround rather than wait for it to be included in a package from us.
Question: Can you transform the images over to hardware images instead of software images? They render a TON faster, and your 3x delay probably wouldn't be of any concern with them. See my demo of the speed differences which we're talking about here: https://qb64phoenix.com/forum/showthread.php?tid=1399. Perhaps they might be the simplest solution to the problem which you're facing.
Since then, Matt has overhauled the glut system we have, making it a lot more independent and streamlined, stopping those race conditions from popping up, but nobody has gotten around to working on the DPI Awareness issue and being able to toggle between automatic and manual scaling (which is what you're wanting to do, and which can't currently be done since we're letting the OS handle scaling automatically). It's an issue we're aware of, and we more or less have a good idea of what all pieces are necessary to have scaling work properly. (For Windows, at least. Mac and Linux will take a little more digging into.) At this point, it's just a matter of someone finding time and motivation to go in and make the changes to the language to add a toggleable automatic/manual scaling system for us -- I just can't say when that might happen. a740g is working on fixing _LOADIMAGE to work with images in memory and not just from your drive/filesystem. (This means something like iamgehandle = _LOADIMAGE("www.mywebsite.png",32) will become possible in the near future.) Matt is working on all sorts of stuff (tons of bug fixes anytime they're reported, and the https support, and correcting our keyboard input routines, and...). As for me, I've just been hibernating mainly. As anyone who's been around the project for a while knows, I've got arthritis and the cold hurts my knuckles. I don't do much coding, writing, or anything much except hibernate in the wintertime...
...So manual scaling is on the ToDo list, but nobody is currently working on it due to other stuff that they've just prioritized first. Honestly, I'd imagine it to be in the 6+ month timeline before it gets all sorted and added to the language, so you'll probably want to look for a workaround rather than wait for it to be included in a package from us.
Question: Can you transform the images over to hardware images instead of software images? They render a TON faster, and your 3x delay probably wouldn't be of any concern with them. See my demo of the speed differences which we're talking about here: https://qb64phoenix.com/forum/showthread.php?tid=1399. Perhaps they might be the simplest solution to the problem which you're facing.