I use LCDHype with various types of LCD that I have.
But I can´t use it properly with a GU128x64-800.
The driver initialises the display and I can see messages using the driver designed for the GU192x16-800.
My display only shows 16 px in vertical in graphical mode and in text mode.
I'm wondering if it's possible to modify the driver for a 128 x 64 resolution in order to use the screen properly?
Tweaking the settings in the LCD configuration doesn't solve the issue.
Related
I have a VCL application that works fine with D10.4. Created with D11, all elements of the form are displayed greatly enlarged at runtime.
Depending on the project settings (Project/Options/Manifest) you can make the program run on the development computer with a 4K monitor in the specified font (everything set to 8 points).
If you start the same program on an HD monitor, all elements except the main menu (!) are displayed in a larger font.
Windows settings on the 4K: 200% scaling, on the HD: 100%
The Delphi has all patches up to 2/22.
The exe, created with 10.4, runs perfectly on both test computers.
Is there a solution for this or do I actually have to build an own environment for VCL apps?
Is there maybe a hidden option to disable all this scaling stuff?
Thanks for every hint!
Many greetings
I am writing an android game with Libgdx. I want the possibility to port it to iOS in the future. I read some comments that all image assets need to be sized in multiples of two for iOS. Is this true for all assets/textures and do the width and height need to be the same, ie: 256 X 256 or is 256 x 128 OK?
I am pretty sure that iOS supports any size, as I never heard that there's a need to transform downloaded images to other sizes to show them.
I know for sure that I never encountered an Android phone that does not support any texture size. I had my game released with different texture sizes for a year without problems until I switched to using a TextureAtlas. That's what I would recommend you, too.
If you are using Scene2d.ui and a Skin, just use SkinComposer to create your TextureAtlas. If you don't use Scene2d.ui, you can use TexturePacker GUI.
I am using DPro Rio 10.3 on an HP Spectre x360, which has a 4K display. The indicator on DbGrids and icons for DbNavigator controls scale fine at 1980 X 1080, but are almost invisible at 4K resolution. Text scales fine at any resolution.
I looked at the source code for both components and they contain methods which use LoadfromResource to load the appropriate graphic from the executable. TDbNavigator calls LoadfromResourse in a virtual method, SetButtonGlyph at runtime.
In addition, the DbGrid code seems to make an effort to scale the indicator in one of its methods. This, however, does not work, at least on my laptop.
FYI, I have set the form's Scaled property to TRUE. I have also tried several settings in the manifest, but none make a difference.
How can I fix this problem. Is it because these controls use a 16 x 16 graphic or is there some other cause? Is there a way to replace the graphics for each component with ones of higher resolution either in the executable resource file or programatically at runtime?
I stumbled across the answer from a post on the TMS Software website. In order to display properly on 4k screens, DPI awareness must be set to none. I tested this both in Rio and Tokyo, and it works. For Rio, you would select Project|Options and go to the Application section. Select Manifest and from the dropdown box for DPI Awareness, select None.
For Tokyo, also Project|Options, go to Application and uncheck Enable DPI.
We have a Delphi 7 program running on Windows 7 Professional SP1, developed approximately 10 years ago. On the current system, it became unusable as some form elements have incorrect size so the text they contain doesn't fit there or the graph overflows the bottom of the window:
Picture 1: Table rows have incorrect size (or the text is bigger than it should be)
Picture 2: There is a graph in the window but the bottom part of the graph isn't visible. And there are no scrollbars...
We have no source code nor we do we have contact with the people who developed the software. We think the software was built in Delphi 7 because it uses several xxxx70.bpl libraries.
We tried to change resolution of the screen and change compatibility mode used to run the program with no luck.
Is there anything we can try?
Your program is not DPI aware, and you are running with font scaling settings that mean the application is asked to scale. The application font is scaled automatically but your Delphi application does not adapt.
I can see some options for you:
Run your machine with 100% font scaling.
Run your machine with >125% font scaling. Then DPI virtualization will kick in which should fix the issue. Although the app may appear fuzzy as it will suffer aliasing when scaled.
Try to find a compat setting that forces DPI virtualization. Don't know if such a thing exists.
Edit the .dfm resources in the executable to set the Scaled property to true. This would require a resource editor that understands Delphi. For instance XN resource editor. I've no idea whether or not this will work. If it does work, each form will re-scale themselves according to the font scaling.
Update
Forcing DPI virtualization won't help, on second thoughts. The system will tell your app that the font scaling is 125% and scale from there. But your app won't even handle 125% scaling correctly it seems. So you have little option other than to disable all font scaling or perhaps try with the Scaled property.
I have a Delphi 3 app which has been distributed far and wide for at least a decade. Today I received a report that the app is not functioning properly on an Asus Transformer T100TA-C1-GR(S) Windows 8 tablet. Specifically, the app is refusing to run because it detects a screen resolution too small for the app to properly display itself. In the app, I have the following conditional check:
if (Screen.Width < 800) or (Screen.Height < 600) then begin
// display a message reporting screen resolution too low
ShowMessage('blah blah...');
Application.Terminate;
When I compiled a special version of my app to help debug the problem, and gave the app to the complaining user, they report back the following numbers:
Width: 980
Height: 550
Here is the extra code I added the special compilation that I then gave to the user:
ShowMessage('Width: ' + IntToStr(Screen.Width) + #13#10 +
'Height: ' + IntToStr(Screen.Height));
The user, however, swears that their tablet is configured to 1368x768. They even switched to 1024x768 and the same incorrect numbers are being reported by Delphi.
All TForm.Scaled properties are set to False.
One clue that might help... The screen width and height detection code (above) is run within the following procedure:
procedure TForm1.WMDisaplayChange(var m: TWMDisplayChange);
Any idea what might be going on?
Your application is subject to DPI virtualization. Your app has not indicated to the system that it is aware of and supports high DPI display devices. The machine in question uses a font scaling of greater than 125%. That's the high DPI cut off point. Beyond that scaling, the system virtualizes the font scaling for non DPI aware apps. From the documentation:
Windows Vista introduced a feature called DPI virtualization, which provides a level of automatic scaling support to applications that are not DPI–aware. With this feature, Windows scales the size of the text and UI elements of applications that are not DPI-aware so that they are appropriately sized on high DPI settings without changes in the application. This prevents potential usability and readability issues that occur when applications render too small on high DPI screens.
In Windows Vista through Windows 8, this feature provides "virtualized" system metrics and UI elements to not DPI–aware applications, as if they are running at 96 DPI. The application then renders to a 96 DPI off-screen surface and DWM scales the resulting application window to match the DPI setting. For example, if the DPI display setting is 144, DWM scales the application's window by 150%, or 144/96.
A consequence of this is that the system fakes the screen dimensions. When your application is DPI virtualized the system reports the virtualized dimensions rather than the true dimensions.
Best practice is to declare your application to be high DPI aware, and scale the UI according to the user's font scaling preferences. Of course, this is going to be quite a change for you. Possibly not one that you wish to take one.
Another option is to ask the user to use a reduced font scaling. They probably won't be very keen on that either.
Yet another option would be to manifest your app to be high DPI aware and continue not to scale it. Then it would certainly run, but it would fail to respect the user's font scaling preferences. Again, I imagine that the user would be non-plussed.
If you don't currently manifest your app, then doing so now will result in it not being virtualized. And by that I mean app virtualization rather than DPI virtualization. Whilst you really should not still be running virtualized, you may run into trouble if you disable virtualization.
And Sertac suggests another option. Get the user to apply compatibility settings for your app to disable DPI virtualization. You could apply that to the app as it is today, without re-compiling and at least your user would be able to make progress.
Fundamentally, there is a problem with your user's machine setup. If it has 768 vertical pixels and around 140% scaling, that really is a 100% scaled equivalent of 550 pixels. That's not very many pixels. Your application is objecting because the screen is too small and, well, perhaps that really is the case.
This various answers here may be useful to you: How do I make my GUI behave well when Windows font scaling is greater than 100%