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.
Related
I have a desktop application where all windows (HWND) render itself with Direct2D 1.1. My question is how to do it more correctly?
Should each window has its own Direct2D device context derived from one Direct2D device? In this case, I cannot render transparent content on a child window without additional tricks (I have to change target on parent window’s context, render parent window to Direct2D bitmap and then draw this bitmap on child’s target).
May be it is better to have one Direct2D device context where all windows render itself? I believe DirectComposition works in a similar way. Unfortunately, I cannot use it because I target Windows 7.
You're asking a question whose answer will be very application specific. I recommend avoiding the whole problem of trying to get HWNDs to render with transparency amongst each other, especially if you're throwing Direct2D into the mix. There is just too much pain in that direction. Every version of Windows that you support will have different bugs that you'll be constantly bumping into and grasping at workarounds for.
Case in point: For the v4.0 release of Paint.NET, I converted all text rendering to DirectWrite, and almost all UI controls to use Direct2D. The image thumbnail control at the top of the window (the MDI selector) is using Direct2D for rendering but it also has to compose on top of what's behind it. And it has to play nice with glass on Win7 (it looks great though!). The code for this is awful, tricky, barely maintainable, and it seems to bump into a different rendering bug on every release of Windows: 7, 7 SP1, 8, 8.1, and 10 all behave slightly differently! It's really annoying to test, too; it's the only reason I have to set up and maintain VMs for every version of Windows that I support (other than the installer and updater). Windows 7 worked fine, then 7 SP1 added a bug which required some tuning to how I filled the alpha channel. Windows 8 has flickering when you resize the window unless I do a certain hack, but 8.1 works fine. 10 then has its own flickering bug if software rendering is used. Remote Desktop breaks things in its own way. Then you also have to worry about High Contrast, and whether DWM is enabled/disabled if you're supporting Windows 7. They all behave differently and it's really really painful.
Anyway. What you seem to really need is a UI system like WPF or XAML which doesn't use anything other than a top-level HWND container. At that point you're custom rendering everything and doing your own hit-testing and input routing (and accessibility and all sorts of other things), so it's not a small task.
Regarding the "how to do it more correctly" question and cardinality of device and device context: Have you thought about just using ID2D1Factory::CreateHWNDRenderTarget or ID2D1Factory::CreateDCRenderTarget ? They return ID2D1RenderTarget but you can call QueryInterface to cast them to ID2D1DeviceContext (this fact is missing from the docs but is also clearly intentional). This should simplify working with Direct2D and HWNDs quite a bit. This is what I do in Paint.NET: I still use an HWND for each control, but each control is using its own HWND or DC render target. If you're willing to poke around with Reflector or ILSpy, checkout Direct2DControl and Direct2DControlHandler in the Paint.NET DLLs.
Also, be careful about using more than 1 hardware accelerated HWND render target. You don't want to get into a weird area where every Direct2D-based UI control is waiting on VSync. Using D2D1_PRESENT_OPTIONS_IMMEDIATELY when creating the HWND render target should help. DWM already handles VSync, so you should be fine to tell Direct2D to ignore it unless you're doing some rather specific stuff with animations and timers.
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!
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.
I want to draw a small dot at the center of the screen so that it must remain after running of any application. A dot should stay even after I launch an application in full screen mode. Like a dead pixel.
I have already installed Visual C++ on my computer with Windows 7. I have some experience with C++, but I never worked with graphics under Windows OS.
How can I draw a dot on a screen?
Many graphics cards have overlay features, and it is likely possible to set one up to be foremost on the screen regardless of what other applications are rendering in other layers.
But the method to do that would be specific to the video card model and driver.
Or, you can try to get your code inside the application doing full-screen rendering, find their rendering context, and draw to it at the ideal time. Which still requires a bunch of variants for all the different graphics APIs.
Here is someone who describes Steam's attempt to solve the portability issue (with a zillion implementations) and how to take advantage of that.
I would create a properly positioned 1x1 pixel (or whatever size you need) window with no borders or title bar, all client area and paint it appropriately. It's important that the window is created with the WS_EX_TOPMOST style. As long as your program is running, the window will be visible as long as there are no other windows with that style overlapping it.
I've done this as a prank. It worked really well over a full-screen OpenGL game (Quake III). I installed it on a friend's machine so that it would flash the word LOSER! in big letters in the center of the screen at random times during the game.
This worked perfectly well on an XP system. I imagine it should work on Windows 7.
I am using C++ with Allegro 4.2 to build a windows game.
I want stretchable graphics in windowed mode.
I'm am one who likes giving users of my programs lots of options; I always hate when I'm playing a game in windowed mode and I'm either not allowed to stretch the window or the content inside the window doesn't stretch with it (this sucks a lot for 640x480 size games played on high resolution screens that don't even allow for fullscreen; requiring a magnify tool to play it properly). I'm wondering if there is some way in Allegro or perhaps if there is another programming library that allows the graphics to stretch with the shape of the window itself. I already know how to have my Allegro applications switch to fullscreen mode; I'm trying to improve the windowed mode.
A big reason for this is because my artstyle is low-resolution art (I call it "Bitmap Brothers" style); it's very good for games since it's organized and easy to edit. I don't want to have to go higher than 640x480 to increase the size because it's far to high for low-resolution art, but my window remains too small during windowed mode.
I noticed that Allegro 5.0.8 has this line of code:
al_set_new_display_flags(ALLEGRO_WINDOWED | ALLEGRO_RESIZABLE);
At the end it says "ALLEGRO_RESIZABLE", could that be the feature I'm looking for? If so, just how much does Allegro change from 4.2 to 5+?
Allegro 4 doesn't support user-resizable windows.
Allegro 5 does (as you've noted), but it is completely rewritten and is not backward compatible at all. Still, I would highly recommend that you switch to it as development on Allegro 4 is all but dead.