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.
Related
I'm trying to learn Direct3D 12 to do some simple 3D graphics for fun.
I've heard that pure fullscreen is the way to go for maximum fps, but now that I'm testing it, fullscreen seems way, way worse than windowed mode.
For example, a static color on a WS_BORDER window (with fullscreen size), and Windowed set to TRUE in the DXGI_SWAP_CHAIN_FULLSCREEN_DESC, can be rendered (with triple-buffering) at about 5000 fps on my computer.
On the other hand, a static color on a WS_POPUP window, Windowed set to FALSE in the DXGI_SWAP_CHAIN_FULLSCREEN_DESC and also IDXGISwapChain3::SetFullscreenState(TRUE, nullptr) called, only renders (with triple-buffering) at about 3000 fps.
Should this be the case or am I missing something?
The story of "fullscreen" for Direct3D is a complex one, and from the other comments/answers in this thread continues be a confused one.
For DirectX 12 on Windows 10, there is no FullScreen Exclusive mode (FSE). When you use SetFullscreenState with either of the modern DXGI_SWAP_EFFECT_FLIP_DISCARD or DXGI_SWAP_EFFECT_FLIP_SEQUENTIAL effect modes then use are really using emulated Fullscreen Exclusive mode (eFSE). DirectX 12 does not support using the the older 'blt-style' effects DXGI_SWAP_EFFECT_DISCARD or DXGI_SWAP_EFFECT_SEQUENTIAL.
If you run with a borderless window that is maximized to cover the entire screen in "windowed mode", it's the same performance as using "eFSE".
There are some 3rd party video card vendor APIs and scenarios that require you use "fullcreen mode" rather than "windowed mode", so in those cases there's a difference.
The other issue is if you are trying to change the display mode vs. using the native resolution. The performance impacts here are the "pixel-fill' rate for the render target size. There are techniques for scaling performance by rendering to an 'offscreen' render target size and then scaling that up to the native resolution of a backbuffer vs. changing the display mode to try to reduce the size of the backbuffer.
See The Care and Feeding of Modern Swap Chains and Demystifying Fullscreen Optimizations.
Do the three major operating systems Linux, Windows and Mac support toggling between fullscreen and windowed mode without recreating the window? Recreating is problematic since it implies to recreate the OpenGL context as well, or at least some OpenGL objects.
What API functions are available on those platforms for performing the task?
Windows: Yes
X11/GLX: Yes
MacOS-X: It's complicated.
First the easy stuff: In Windows and X11 there are no such things as special fullscreen mode OpenGL windows. They're all just regular toplevel windows and you can add or remove the window decorations (title bar, border) anytime you like. If you remove the window decorations and set the window size to maximized you essentially get a fullscreen OpenGL window; in fact the graphics drivers are smart enough to detect this situation and switch to a fast track then.
Now MacOS X. In MacOS X clear distinction is made between Windowed and Fullscreen (which IMHO is quite annoying).
The good news is, that you can get access to the underlying context object which allows to implement some resource sharing so that you don't have to recreate the data containing OpenGL objects.
Big Fat Disclaimer: I never ventured as deep into MacOS X as I did with other OSs so my practical experience with this certain topic on MacOS X is only theoretical.
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 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.
I'm porting a small graphics engine from DirectX 9 to OpenGL. The engine uses SDL (now ported to 2.0) to manage input and window creation.
I want to know how to correctly handle window events for both OpenGL and DirectX. I'm interested in these for Desktop platforms (linux, OSX and windows)
Window resolution change
Full screen to windowed / windowed to fullscreen handling
Alt+tab handling -
I've tried to search through the net but information is quite not focused in one place. I imagine many others faced the same problem before.
Are there any resources to read guidelines on that kind of handling for my engine?
Is it possible to handle resolution change without losing transfered resources to the renderer system in both OpenGL and DirectX?
Window resolution change
OpenGL itself requires no special treatment for this. Unfortunately SDL goes through a full window reinitialization, including the OpenGL context on a window size change, which means, that all OpenGL state objects (that is, textures, vertex buffers, shaders and so on) are lost.
This is however a limitation of SDL.
Personally I thus prefer GLFW for creating a OpenGL window and context. You can still use SDL for other things though (like audio, networking, image loading and such).
Full screen to windowed / windowed to fullscreen handling
The is effectively a window size change as well. See above.
Alt+tab handling -
OpenGL requires no special effort for this. Just minimize the window when Alt+Tab-ing out and stop the game loop. When the window gets restored just continue the game loop.