I am using Borland Turbo C and the Borland Graphics Interface.
I have two questions:
I have to process a 256 color bitmap image. It is difficult to process using EGAVGA driver, so I decided to use SVGA driver. It works fine, but when I convert the image into gray scale, instead of showing only the image in gray scale, the whole window goes into gray scale mode. Is there any method to change the color palette for a specific area using outp(0x03c8, data) and outp(0x03c9, data) functions?
The mouse functions works fine with EGAVGA mode but the cursor is not visible in the SVGA mode. Even the mouse is functional. How could I create a custom mouse cursor for SVGA mode in 256 color? I have the codes for creating custom mouse pointer in EGAVGA mode using 0x10 interrupt but it is not working with SVGA mode?
In paletized video modes, palette entries affect the whole screen. If you change any index, all pixels on screen with that index will change, whether if they belong to your image or not.
If your image is going to share the screen with others, and you want that image the only one that changes into grayscale, you have to set aside some palette entries for exclusive use by your image, so changing them won't affect other graphic elements in your screen.
On Windows, and X-Window if my memory serves well, the entire screen will have the colours of your palette when your window application has the focus. When not, it will revert to system palette and your windows and its contents will show "weird".
Related
I would happily provide a screenshot of this, however the problem is the captured image, is much larger than my actual desktop.
I am completely frustrated with this as I have tried using BitBlt with the desktop hdc AND the new "Graphics" commands.
My actual desktop resolution is 1920x1080 - 1080p .
BitBlt and "Graphics" both return that my resolution is 1536x864 # 96 DPI.
A form (WinForm), Maximized, borderless, and irrelevant of scaling mode the form is set to, also shows 1536x864 # 96 DPI.
Now the image that is captured, is like it is being done from 1920x1080, but clipping the region 1536x864 as the screenshot.
If I do PrintScreen directly using Prtscn button, I get the entire image, but still it is about 1.5-2x larger than what I actually see.
What I am looking for -- is a resolution for how I can take a picture of what is on my screen in the scale/dpi/whatever is going on here that it visually looks like. I have written a screen capture program, and using a few different examples for the RubberBand form (overlay form to select a region of the screen by drawing a box), and as you can imagine, this scaling crap is causing those box captures to be offset, and the contents are zoomed.
This is very annoying -- even to explain, however I am positive that most of you are familiar with the terms I use, and also know what to expect from taking a screenshot, so my explanation above should be pretty clear as to what my problem is.
Example/Consideration
Imagine, taking a picture of a window that is 300x300, and getting the top left 150x150 of that zoomed to 300x300 completely skipping the remainder of the window. Resulting image is still 300x300, but it's not what you selected.
Now imagine, you grab a picture of your screen by the only dimensions you can get programmatically, and then put the image into a picturebox. Even though both your screen and the picturebox claim to be the same dimensions and dpi, the image in the picturebox requires scrolling even if the picturebox is maximized to fullscreen on a borderless with no borders / etc. -- again, the picture is zoomed, but how is it still reporting that it's the same size as the form XD (comparing Graphics or BitBlt dimensions with the actual form. also tried comparing picturebox contents, and still same effect)
This, is EXACTLY what the effect is that is happening. When I try to capture a region or segment of the screen. I am not sure why windows api/crl is lying about this seemingly trivial stuff, however there must be a way to accurately obtain screenshots/capture regions without this faux zoom effect -- across all resolutions.
Thank you Hans Passant for pointing me in the right direction.
To add "true" dpi scaling support to a winforms application, you can make it so by adding the following block to your manifest :
Project > Add New Item > Visual C# Items > Application Manifest File
One the file has been added, open it up and look for a line like
</asmv1:assembly>
Whatever the "asmv" number is, (in the example above it is 1), use that to format the code:
<asmv1:application>
<asmv1:windowsSettings xmlns="http://schemas.microsoft.com/SMI/2005/WindowsSettings">
<dpiAware>true</dpiAware>
</asmv1:windowsSettings>
</asmv1:application>
Paste the above code (changing the asmv1 to whatever version the manifest is), just above the final closing line for the ""
Also, make sure your forms are set to AutoScale to dpi (and all sub-elements).
In the last days, while I'm working on a project, I was introduced to the sprite - Byte Array.
Unfortunately, I didnt find out any kond of information about the sprite which can tell me mote about what is this and how it's works.
I really be pleased if you can give me some information and examples for sprite.
A sprite is basically an image with a transparent background color or alpha channel which can be positioned on the screen and moved (usually involving redraw the background over the old position). In the case of an animated sprite, the sprite may consist of several actual images making up the frames of the animation. The format of the image depends entirely on the hardware and/or technology being used to draw or render it. For speed, the dimensions are usually powers of two (8,16,32,64 etc) but this may not be necessary for modern hardware.
Traditionally (read: back in my day), you might have a 320x200x256 screen resolution and a 16x16x256 sprite with color 0 being transparent. Each refresh of the screen would begin with redrawing the background under the sprites, taking a copy of the background under their new position and then redrawing only the visible colors of every sprite in their new position.
With modern hardware, however, it is more efficient to pass data in a format that the driver can handle (hopefully in the graphics accelerator) rather than do everything by hand.
I have a WPF application with a custom windows style (AllowsTransparency="True" WindowStyle="None"). This window has a custom Peak Meter control which uses WriteableBitmap to draw data from DirectSound audio input.
I am using a bitmap with all levels drawn as colored rectangles (red/yellow/green/red) and when the audio arrives I just draw a black rectangle over my level meter form the top. It works fine on my machine (Windows 7, Pentium 4 single core). But it works bad on a laptop with Windows XP SP3 and integrated video.
I know that transparency effects have some issues on DirectX 9, but I have read the problem should be fixed in SP3. Still the call to _writeableBitmap.AddDirtyRect takes 30-40% CPU on XP and sometimes it causes dropouts in audio (if USB audio is used, and those dropouts occur not in my application but somewhere in DirectSound<->drivers subsystem).
On Windows 7 the same app takes no more than 3% CPU and no audio dropouts noticed (but the CPU is actually weaker on the Win7 PC than on the laptop with XP).
I tried not to use AddDirtyRect but just draw a WPF Rectangle element over the Image with leds and set the height of the rectangle when new audio level arrives. What a surprise! Somehow changing the height of a Rectangle element takes noticeably less resources than calling _writeableBitmap.AddDirtyRect for 100x20 pixel rectangle! Now on XP it took just 10-20% instead of 30-40% with AddDirtyRect.
But when I removed transparency effect from the window, finally also XP (and even on VirtualBox) went down to 2-6% CPU. Obviously transparency makes it really hard to redraw 20x100 rectangle 10 times per second.
I could live with no transparency in my application, but the problem is - the design uses rounded corner windows and I need to cutoff the area around them. But as soon as I set AllowsTransparency="False", the window shows the background color behind.
So the main question is - how do I make the contents of the window to clip away the background of the window so the corners stay round without using XP-heavy transparency?
I remember that I could do than even on a C++ Windows application just by setting a custom window region and not using any transparency (that was on a Windows 98 machine). Can the same thing be done on WPF?
Or maybe there is some trick how to make WriteableBitmap to use less resources on XP?
As I did not find anything better, I used the old way: SetWindowRgn API.
It was a bit complicated because my application uses some animated slide-out parts which protrude out of the main window so I had to sync WPF animation with SetWindowRgn calls to make slide-out effect look as clean as possible. The result is not ideal but acceptable. And the main thing - no more high CPU and no audio dropouts.
Guys i am writing a simple graphic program to create a polygon of n sides by taking input from the user.After obtaining co-ordinates of vertices i would ask user to enter the vertex pairs between which he wants an edge.
To make this more interactive i thought i would gradually start drawing the polygon in graphic mode simulatneously i.e i would gradually add the edges and would display it to the user .Now i would again switch to the text mode to obtain further set of vertices between which he wants to insert edges.But what i found that as i switch between graphics and text mode everything which i draw in graphics mode is erased .
Guys is there any way or any function in turbo C compiler so that i could switch between text and graphic mode and at the same time restoring the contents of graphic mode.Should i use different compiler??
Switching between modes makes the video adapter lose all retained graphics. A workaround for this is to use a 'canvas', an in-memory bitmap that stores the pixels. You'd make modifications to this bitmap and blit it to the video adapter to make it visible. Not supported by this ancient graphics library you use. Review the CreateCompatibleDC() winapi function in you plan to get ahead.
This is hardly a problem. Simply re-render the graphics when you switch back to graphics mode. You do have to store a 'model' of the polygon so you can render it. Just store the vertex points.
You could use restorecrtmode(),setmode() and getmode() functions available in TURBO c library.These functions are present in graphics.h header file.
You may stay in graphics mode to get user input, but you will need to create a input function that works in graphic mode, reading char by char (getch()), composing your input and updating the graphic screen with the characters typed. If your graphic card have more then one page, you can use "setactivepage" and "setvisualpage" to create separated pages for the data entry and graphic.
When a child window of my application is opened and I view the ALT+TAB menu, the application icon looks pixellated. I assume that Windows uses a low resolution version of the icon (16x16 pixel I think). What can I do that Windows selects the right version which would be 32x32 pixel?
I assigned an icon to the window in question that has 16x16, 24x24, 32x32, 48x38 and 256x256 in true color. Please note that VS says in the proterties that 32x32 is used and that it works fine for the main window of my application where I assigned the exact same icon.
The caption bar of a Windows application window display icons in 16x16 pixels. The Alt-Tab list, however, shows icons in 32x32 pixels. It uses the same icon as is set for the window. If you only set a 32x32 one, the caption bar has to scale it down, which tends to look ugly as it uses nearest-neighbor interpolation. So how does one support both?
The answer is the ICO file! It supports embedding multiple icons in one file, typically the same (or similar) icon in various sizes and, less commonly, color formats.
Browsers, Windows, and others are typically designed to smartly use the appropriately sized variant within a given ICO file. So the answer is to have an ICO file with both sizes (or more) inside. The result is that the caption bar correctly uses the 16x16 version and Alt-Tab uses the larger 32x32 one.
The methods for saving an ICO file with multiple icons inside varies from program to program. However, GIMP can easily do it (and it's free). The trick is to have your variously-sized icons as separate layers. When you go to save it as an ICO file, GIMP will prompt you with the ability to set the size and color format of each layer. A good tutorial, with images, can be read here.
If anyone has any links or suggestions for creating multi-icon ICO files in other programs, feel free to add them. Also, I'm unsure if the Visual Studio built-in image editor can do it or not — I've rarely bothered with it.
Fixed the problem. I put the icon on the wrong form. As I don't think that this question will be of any help for anybody feel free to delete it.