why the graphics.h and conio.h was losed?
Pages: 12
If the game is turn based, you can get away with GDI (or better yet, a GUI framework that is cross platform, like Qt or WxWidgets).
If the game has real time elements, but they are 2D, you might still get away with GDI on modern hardware.
If the game has complex graphics, you'd need DirectX, but there again you'd be better off with a framework/engine that is platform independent (there are many).
You must choose before you create the menu. Each one is extremely different.
I sense GDI might be a reasonable choice. You can not only choose colors and fonts, but include images, backgrounds (images as backgrounds), and perform rudimentary 2D animation. It is at least late 20th century in style.
The problem with DirectX (or an engine, OpenGL, Vulkan, Metal, etc) is that they don't have built in text or controls like GDI does. Those things are handled by a small UI framework within the engine, which is best consumed from an existing game engine than writing one yourself.
If you choose GDI, your issues about color and font are solved, but choosing a framework has thorns. MFC, ATL (and others) bind you to Windows targets only. Qt is portable, but you need to use the Qt developer to get that to work out well. WxWidgets works with just about any IDE/compiler, and your targets will work on MAC, Linux, Windows, etc. like Qt.
I could recommend WxWidgets, but you may run into people who are Qt evangels and accept nothing else.
If the game has real time elements, but they are 2D, you might still get away with GDI on modern hardware.
If the game has complex graphics, you'd need DirectX, but there again you'd be better off with a framework/engine that is platform independent (there are many).
You must choose before you create the menu. Each one is extremely different.
I sense GDI might be a reasonable choice. You can not only choose colors and fonts, but include images, backgrounds (images as backgrounds), and perform rudimentary 2D animation. It is at least late 20th century in style.
The problem with DirectX (or an engine, OpenGL, Vulkan, Metal, etc) is that they don't have built in text or controls like GDI does. Those things are handled by a small UI framework within the engine, which is best consumed from an existing game engine than writing one yourself.
If you choose GDI, your issues about color and font are solved, but choosing a framework has thorns. MFC, ATL (and others) bind you to Windows targets only. Qt is portable, but you need to use the Qt developer to get that to work out well. WxWidgets works with just about any IDE/compiler, and your targets will work on MAC, Linux, Windows, etc. like Qt.
I could recommend WxWidgets, but you may run into people who are Qt evangels and accept nothing else.
Last edited on
for use GDI, i must get the console(instead create the window) HDC.... can you advice me?
There is no console in GDI programming.
I've not seen any code from you to this point, and noting that Albatross already posted a link to the modern Windows approach to positioning the cursor in a console, I'm not sure how to advise you.
For students, everyone must begin somewhere at the command line (naturally a console window), so the software is simple. Once the basics are fully covered, the student is then familiar with declarations, writing and calling functions, and for C++, building classes, implementing consructors, destructors and virtual functions.
Depending on the direction, most schools tend to continue at the console for a while longer than is warranted. Stroustrup (the inventor of C++, and occasionally a teacher of this language at university) observed that modern students really need to see GUI development early, or they get bored.
It is understandable, and he takes effort to include it in his book, "C++: Principles and Practice".
If you were familiar with everything in that book, you'd probably not have the questions I see here.
It suggests to me that you probably need that book before you go much further. I sense you're at that point Stroustrup describes, where the basics are just too boring and you want to target a project that is more interesting, hence a game.
That naturally brings up so many issues that you end up right here, with questions about how to do things which aren't part of the standard for console development, despite the fact there have been color text mode applications built in the past.
GUI development is even 20th century at this point, but still relevant. It is, however, a deep dive if you're not familiar with intermediate level C/C++. That's where Stroustrup's book would be a good fit.
Stroustrup introduces the FLTK GUI toolkit. It's simple, though all GUI is quite a puzzle at first.
GUI development is also event driven. This is quite unlike the console based applications you're accustomed to (if I have guessed your position in the study accurately).
Event driven programming is kindof inside out. In a console application, the software starts at main, runs through a list of statements and possibly (hopefully) calling functions, looping, changing modes...but basically running through a series of steps until it finishes.
Event driven programs on the other hand initialize, then stop. As in, they don't do anything.
They are waiting. Always waiting.
For the user to do something, like click a button, drag the mouse, change a slider.
The entire GUI application is written as a series of response functions to events like these.
The main notion is that, unlike a menu based approach where the user chooses from a list, the user is presented with most (or all) options through interface objects, like buttons and edit controls, and, as an addon feature, the menu bar.
When a message fires from any of these things, the response function is selected by the event message. That message indicates what the user did - which button the clicked (and, pedantically, when they pressed the mouse down on that button, and then when they released the mouse).
Even keystrokes work that way. Every keystroke is a message (actually, a series of them). You get keyboard down, keyboard up, keyboard character and keyboard repeat messages. Fortunately, they are usually routed into a control, like an edit control, which turns that into text typing...but there's no "cin" or "cout". There's no console.
It takes a while to study how to write this way. That is in part why I suggest a framework for anyone doing it, but if you're not yet ready...you need something like Stroustrup's book.
Either that, or take the advice from Albatross' early response to you, ignore conio.h and use the Windows modern means of controlling the console, with cursor addressing and color highlighting.
I've not seen any code from you to this point, and noting that Albatross already posted a link to the modern Windows approach to positioning the cursor in a console, I'm not sure how to advise you.
For students, everyone must begin somewhere at the command line (naturally a console window), so the software is simple. Once the basics are fully covered, the student is then familiar with declarations, writing and calling functions, and for C++, building classes, implementing consructors, destructors and virtual functions.
Depending on the direction, most schools tend to continue at the console for a while longer than is warranted. Stroustrup (the inventor of C++, and occasionally a teacher of this language at university) observed that modern students really need to see GUI development early, or they get bored.
It is understandable, and he takes effort to include it in his book, "C++: Principles and Practice".
If you were familiar with everything in that book, you'd probably not have the questions I see here.
It suggests to me that you probably need that book before you go much further. I sense you're at that point Stroustrup describes, where the basics are just too boring and you want to target a project that is more interesting, hence a game.
That naturally brings up so many issues that you end up right here, with questions about how to do things which aren't part of the standard for console development, despite the fact there have been color text mode applications built in the past.
GUI development is even 20th century at this point, but still relevant. It is, however, a deep dive if you're not familiar with intermediate level C/C++. That's where Stroustrup's book would be a good fit.
Stroustrup introduces the FLTK GUI toolkit. It's simple, though all GUI is quite a puzzle at first.
GUI development is also event driven. This is quite unlike the console based applications you're accustomed to (if I have guessed your position in the study accurately).
Event driven programming is kindof inside out. In a console application, the software starts at main, runs through a list of statements and possibly (hopefully) calling functions, looping, changing modes...but basically running through a series of steps until it finishes.
Event driven programs on the other hand initialize, then stop. As in, they don't do anything.
They are waiting. Always waiting.
For the user to do something, like click a button, drag the mouse, change a slider.
The entire GUI application is written as a series of response functions to events like these.
The main notion is that, unlike a menu based approach where the user chooses from a list, the user is presented with most (or all) options through interface objects, like buttons and edit controls, and, as an addon feature, the menu bar.
When a message fires from any of these things, the response function is selected by the event message. That message indicates what the user did - which button the clicked (and, pedantically, when they pressed the mouse down on that button, and then when they released the mouse).
Even keystrokes work that way. Every keystroke is a message (actually, a series of them). You get keyboard down, keyboard up, keyboard character and keyboard repeat messages. Fortunately, they are usually routed into a control, like an edit control, which turns that into text typing...but there's no "cin" or "cout". There's no console.
It takes a while to study how to write this way. That is in part why I suggest a framework for anyone doing it, but if you're not yet ready...you need something like Stroustrup's book.
Either that, or take the advice from Albatross' early response to you, ignore conio.h and use the Windows modern means of controlling the console, with cursor addressing and color highlighting.
Last edited on
If you are interested in learning the basics of game programming using GDI (yes, it is possible) and basic Windows system calls for sounds and music you might want to look at:
Beginning Game Programming
https://www.amazon.com/gp/product/0672326590
The book was released in 2004, so there are some code parts that might need to be updated for the changes that occurred with Windows since then.
I've read the book, modified and compiled the example "game" program source code with Visual Studio 2015, 2017 & 2019. The time I spent modifying the old source helped me to understand the changes, delving into the Win32 API deeper and deeper.
It does teach the basics of what a game engine does, managing the details of doing the graphics, keyboard/mouse/joystick input, sound & music. The book step by step creates a game engine framework so you can create your own windowed games.
Beginning Game Programming
https://www.amazon.com/gp/product/0672326590
The book was released in 2004, so there are some code parts that might need to be updated for the changes that occurred with Windows since then.
I've read the book, modified and compiled the example "game" program source code with Visual Studio 2015, 2017 & 2019. The time I spent modifying the old source helped me to understand the changes, delving into the Win32 API deeper and deeper.
It does teach the basics of what a game engine does, managing the details of doing the graphics, keyboard/mouse/joystick input, sound & music. The book step by step creates a game engine framework so you can create your own windowed games.
Last edited on
Ah, a video game.
Might I recommend SDL2?
Your life will be infinitely easier.
And there are quite a few very nice GUI libraries for it.
@Niccolo
Yeah, I liked the Trident. It was, I thought, very well designed.
Unfortunately it was a little on the late end of the SVGA market, and not a lot of games (the ones I played, anyway) had drivers for it...
Might I recommend SDL2?
Your life will be infinitely easier.
And there are quite a few very nice GUI libraries for it.
@Niccolo
Yeah, I liked the Trident. It was, I thought, very well designed.
Unfortunately it was a little on the late end of the SVGA market, and not a lot of games (the ones I played, anyway) had drivers for it...
Follow the link I gave you. The book takes you step by step though creating a VERY simple game engine with graphics, sound and music. The graphics part of the engine uses Window's GDI system.
Furry Guy's link, cleaned up and made valid: https://www.amazon.com/gp/product/0672326590
-Albatross
-Albatross
Heh, Amazon invalidates a link that worked just fine previously.
Typical.
Typical.
thanks to you i found the Sams Teach Yourself Game in C++ by Michael Morrison book ;)
thanks you so much for all to all
thanks you so much for all to all
That Sams book is an older version of the book I linked. There are some differences between the two, though most of the material is the same.
The newer book details more source code than the older one.
Make sure you get a book copy with a readable CD, no matter which version you decide on. The CD contains graphics and music/sounds needed for the programs.
I would recommend getting a joystick, several of the programs use one.
I bought both books. There is material in one that isn't in the other.
<edited to add:>
One major difference between the books is how the multiple frames of an animated sprite are rendered into a single picture. The earlier book has the frames being drawn in a horizontal fashion, the newer book is vertical format.
The game engine functions that render the sprites are very sneakily different because of that. For the most part the game engine source code is interchangeable between the books for the same game, but not for animated sprites.
The newer book details more source code than the older one.
Make sure you get a book copy with a readable CD, no matter which version you decide on. The CD contains graphics and music/sounds needed for the programs.
I would recommend getting a joystick, several of the programs use one.
I bought both books. There is material in one that isn't in the other.
<edited to add:>
One major difference between the books is how the multiple frames of an animated sprite are rendered into a single picture. The earlier book has the frames being drawn in a horizontal fashion, the newer book is vertical format.
The game engine functions that render the sprites are very sneakily different because of that. For the most part the game engine source code is interchangeable between the books for the same game, but not for animated sprites.
Last edited on
Topic archived. No new replies allowed.
Pages: 12