I use SetConsoleDisplayMode() to switch the console into fullscreen mode. It is 80x25, centered in the middle with quite a small font, which I'd like to enlarge.
I still work on WinXP, so SetCurrentConsoleFontEx() is not an option for me. I found this link which describes some undocumented functions including SetConsoleFont(). They work great: the GetNumberOfConsoleFonts() returns 9 usable fonts on my system and I can pick some, however under fullscreen 0 font were found, which means it is not supported.
I also tried to create shortcut to the program and set the console there, but there's no fullscreen option and after switching to fullscreen all font settings are discarded.
I'd like to convince the screen to show nice big text font, just like in sci-fi movies or in good old BIOS assembly coding. Is it possible under XP?
The full-screen console mode switches the display adapter into 80x25 VGA text mode.
Thus font-rendering is completely different. In a normal console window the font is rendered using GDI; in full-screen mode Windows writes a character code to the display buffer and the hardware renders the font.
VGA supports loadable fonts and Windows uses this feature to support its different language versions. I don't remember if the font is fixed by the language version of Windows or if its chosen to match the current code page. (Full-screen mode doesn't work on x64 and I don't have a 32-bit system handy to try it.)
I'm not aware of you getting any kind of choice in the VGA font used, though there's probably some mileage in overwriting the VGA fonts in the Fonts directory. Though obviously this isn't something you'd want to be doing in production.
Finally, it might be possible to change the font using an actual DOS app! I know Windows NT traps some video-related IOs and passes them through to the hardware. This isn't much use though.
Did you try to write out GetLastError()? My opinion is that this will not be working on windows 7 or later.
Maybe you could try this: #define _WIN32_WINNT 0x0601
Cheers!
Related
In my app (C++14, MacOsX 10.11) I use glfw3 to create two windows that should run in fullscreen mode in two monitors with different native resolutions. I'm creating the windows like this:
glfwCreateWindow(capture_monitor_width, capture_monitor_height, "Capture Window",capture_monitor,NULL);
//..
glfwCreateWindow(projection_monitor_width, projection_monitor_height, "Projection Window",projection_monitor,NULL).
(where projection_motinor_width, projection_monitor_height,capture_motinor_width,capture_monitor_height have been retrieved by the appropriate GLFWvidmode* and they have been tested to be correct in all cases)
The problem is that while I'm getting the fullscreen window correctly in my primary monitor, in my secondary one it is displaced upwards so that it only covers the upper 3/4 (more or less) of the screen. Note that by simply replacing projection_monitorwith NULL in the snippet above I get a properly aligned window that does cover the entire screen (yet it has a title bar which I don't need in my app).
Any ideas? Could this be some sort of bug? Any hacks around it?
With the latest 'devel' version the problem is no longer there. So apparently it's a bug that has already been fixed.
I have a full screen QT OpenGL application which needs to display the virtual keyboard (tabTip.exe) when input textboxes are entered. The problem I'm facing is that the virtual keyboard appears behind the application when the keyboard is invoked. I have tried many different things and found that the only way I can make it appear in front, is if my window is not fullscreen (e.g. making it 1 pixel less than full screen in the width and/or height). If I have the tablet in portrait mode this also still displays the keyboard even in full screen.
Now I'm trying to figure out if this is a driver issue, Qt issue, OpenGL issue or general windows issue.
Any suggestions?
Update:
I have investigated this a bit further and I think I see what's going on.
Windows 8, upon detecting that the monitor rotation is set to zero, and that it has an OpenGL window that matches the desktop resolution and covers the whole screen, kicks into legacy mode that blocks any Windows 8 themed animations from running (including virtual keyboard).
Do you have any suggestions on how I can stop windows from doing this? DwmEnableComposition has been removed in windows 8.
Okay, this is a really strange question and I'm not sure how to phrase but, but I can't seem to find anything on it anywhere, most likely because I'm not using the correct terminology. Also, this may be operating system specific, if it is, I'm using Debian.
Basically, when you boot an older computer or a modern server computer, or stuff along those lines, they boot to a terminal screen. Where all you do is type stuff. And if you want to do anything graphically, you usually download a desktop environment.
But I'm wondering, how could I go about drawing graphics without a desktop environment?
I remember back on MS-DOS you could use QBASIC to change the screen mode and you could then draw colored lines onto the screen like that. It's probably much more complicated in C++, but I'd still like to be pointed in the right direction.
Sorry if this question is a bit unspecific, but I'd really like to be pointed in the right direction.
This is done by using a framebuffer console. Then you use a framework/library that can draw on that. For example DirectFB. There's also some small libraries floating around, like libFB. I think SDL can also use the framebuffer. Never tried it myself though.
Then there's framebuffer versions of GUI toolkits like Gtk+ and Qt, if GUI widgets is that you want.
There's also SVGAlib, which talks to graphics cards directly, but it's outdated by now. Not recommended. In general, you're looking for "Linux framebuffer graphics". That should get you a few starting points.
To get a framebuffer console, you need to configure your kernel accordingly. Usually you enable a KMS driver for you graphics card, and also enable the KMS framebuffer. If there isn't a KMS driver for your card, you can use a generic VESA framebuffer console that works on most hardware (although, it being just generic VESA, is slow and non-accelerated.)
Commonly, a "desktop environment" (on Linux) is made of two parts: XWindow-like graphics "library" plus a "window management" (Gnome, KDE, Xcfe,..). So, if I understand your question, you only have to setup a XWindow system without a window manager.
On MS-DOS, you could write software which wrote to the screen, either by writing into a range of RAM which was shared by the video controller, or calling a BIOS API.
A newer O/S (i.e. Windows) will prevent you from doing either of those: instead you call an O/S API, which calls to an O/S-specific video device driver, which outputs to the hardware.
As I read it you're asking how to deal directly with the graphics hardware.
That depends on the hardware.
If you have an old PC at hand and want to experiment with it, then you need correspondingly old development software that can run on that hardware under the particular OS, i.e. some C compiler from those days running in MS-DOS. You may be able to do this is in a "DOS-box" in Windows (not a console window but an emulation of the old PC). 64-bit Windows 7 does not support DOS boxes, but there is a free alternative called DOSbox.
Then, if you go that route, you can search for "graphics adapter" graphics modes etc. on the net.
Basically, with the old PC architecture and a program running under DOS, you used a DOS service to switch the graphics mode, and then you accessed the graphics memory at a known memory address for the mode.
The curses (or ncurses) library is the old way of doing it in Unix flavours, although these days there is probably something better...
I am learning to use the allegro library right now and when using the set_gfx_mode function if I use GFX_AUTODETECT_FULLSCREEN for the first argument the window will go fullscreen when running the compiled application, but after about the first second of running, all the colors change. Using any other graphics mode this doesn't happen, but on two separate machines the colors change just after changing to fullscreen mode. Has anybody else seen this happen before? I can't find any discussion on this problem at all.
I am using the pre-compiled allegro 4.4.2 library for visual studio 2010 and running windows 7.
Allegro 4 is old and uses APIs that are no longer very well supported by modern operating systems. The full screen mode is going to be buggy, especially on 8-bit graphics. The best way to get a reliable full screen is to honor the user's current desktop settings:
int w, h;
get_desktop_resolution(&w, &h);
set_color_depth(desktop_color_depth());
set_gfx_mode(GFX_AUTODETECT_FULLSCREEN, w, h, 0, 0);
Then your application will need to center/scale the drawing. It's not really that difficult, just draw everything to an intermediate buffer that is the width/height of your native game, and then stretch blit it to the appropriate screen size.
All that said, you should really be learning Allegro 5 as it is designed to work on today's hardware and operating systems, including iOS and Android.
let me first specify my development essentials. I am writing an Windows DLL. The programming language i do focus on is C/C++. Asm blocks are possible aswell when required for my task. Maybe even a driver, but i do not have any experience with them at all.
The DLL is being injected into a host process. That's always a Directx environment. Either Dx9, Dx10 or Dx11 and may run in fullscreen or windowed mode.
The method should support windows xp up to windows 7 and is being compiled in x86 only.
The goal is to come up with a function taking a screenshot of a given process-window. The screenshot is never being taken from the host process itself. Its always another process! The window may contain directx or gdi32 content. Maybe other contents are possible i do not think of at the moment (windows forms comes to my mind. i am not sure how that is being rendered internally). The windows may be minimized.
That screenshot needs to be accessable/convertable to an directx texture such as Texture2D, depending on the Directx environment i am working in. Saving the screenshot as an png/bmp is enough thoe, as i do know how to create such a texture from memory.
I've already tried the oldstyle BitBlt way, that didnt work on minimized applications thoe. The minimized applications are being drawn, when i send WM_PAINT messages to the targeting window. That aint a solution for me, as i also need to keep up with directx applications which doesnt react to such messages.
Maybe i need to hook each single DirectX window to accomblish my task, to access the backbuffer directly, i do hope for some better methods anyways.
For the reason that i do take a lot of screenshots from multiple windows, i would like to implement a fast method, which isnt such a cpu bogus. Copying from VideoRAM may be a bad way to go when having such performance needs.
I do hope for some ideas, maybe code samples as i am not familar with all the possibilities i could go for. I've looked at some windows thumbnail api, but that didnt support xp from what i could read.
Thanks in advance,
Frank