You don't erase the text, you stop drawing it.
Imagine a flip-book, with a little picture drawn on each page. If each picture is slightly different, then if you flip quickly through the book whilst staring at the spot with the drawing it will appear as if you have a moving image. You don't erase the old image and then change it, you draw a completely new image on a new page.
Your text works the same -- each frame you draw the entire game scene, including the text, and when you want the text to disappear you simply re-draw the entire scene without the text included -- you don't have to "erase" it.
It's unlikely that you'll find Win32 significantly easier than Direct3d, but good luck.
0
31 replies to this topic
#21 Staff - Reputation: 9020
Posted 04 November 2012 - 12:43 AM
- Jason Astle-Adams.
From my blog: 20 ways to advertise your game | What next? Intermediate to advanced C++
How to make games WITHOUT programming | 4 reasons you aren't a successful indie developer
Sponsor:
#23 Staff - Reputation: 9020
Posted 04 November 2012 - 07:57 PM
C++ is a complex language.
If I may depart from the topic at hand to some more general advice, I think that one of the problems you have is a lack of focus. I've seen you posting for quite a long time now, and without checking I remember you working on-and-off with C++, giving C# a go, jumping from one API to another and constantly moving from project to project -- most of which seem to have been attempts at Pong or if I recall correctly Tic-Tac-Toe.
You find a tutorial or book and start working away. You encounter one or more problems and make a topic looking for help. Sometimes you sort out your original issue and then run into another one, or sometimes it's the original that you're stuck on, but either way you seem to at some point get stuck, and then you put the project aside and move on to a different approach; suddenly you're trying C# instead of C++, or trying Win32 instead of DirectX.
If you don't want to still be making Pong in another 7 years from now you have to actually choose one approach and stick with it until you've solved all of the problems and learned to overcome whatever was holding you back. Follow through, and keep working at it when things get difficult.
If I may depart from the topic at hand to some more general advice, I think that one of the problems you have is a lack of focus. I've seen you posting for quite a long time now, and without checking I remember you working on-and-off with C++, giving C# a go, jumping from one API to another and constantly moving from project to project -- most of which seem to have been attempts at Pong or if I recall correctly Tic-Tac-Toe.
You find a tutorial or book and start working away. You encounter one or more problems and make a topic looking for help. Sometimes you sort out your original issue and then run into another one, or sometimes it's the original that you're stuck on, but either way you seem to at some point get stuck, and then you put the project aside and move on to a different approach; suddenly you're trying C# instead of C++, or trying Win32 instead of DirectX.
If you don't want to still be making Pong in another 7 years from now you have to actually choose one approach and stick with it until you've solved all of the problems and learned to overcome whatever was holding you back. Follow through, and keep working at it when things get difficult.
- Jason Astle-Adams.
From my blog: 20 ways to advertise your game | What next? Intermediate to advanced C++
How to make games WITHOUT programming | 4 reasons you aren't a successful indie developer
#25 Members - Reputation: 4032
Posted 04 November 2012 - 08:30 PM
From what jbadams says, giving up and trying something else seems to be your problem here. You need to stick to it instead.
It appears that the gentleman thought C++ was extremely difficult and he was overjoyed that the machine was absorbing it; he understood that good C++ is difficult but the best C++ is well-nigh unintelligible.
#28 Staff - Reputation: 9020
Posted 04 November 2012 - 09:01 PM
To be specific, if you want to complete a game you need to pick one game to make, pick one language, and pick one library and then stick with those choices until the game is really finished. You will make mistakes, and you will run into difficulties -- but you can fix your mistakes and you can learn to overcome your difficulties if you stick with it and work hard.
In your position I would "give and up try something else" one last time -- don't spend too much time on the decision, but re-examine your options and choose a programming language and library to work with. Pick a game to make -- I think Pong is probably the best choice though. Then stick with the language and library that you choose until your game is completely done.
Given your experiences from previous attempts good choices might be C# with XNA, or C++ with SDL, but anything you feel comfortable to use will be fine. I would suggest spending some time practising the programming language first and then work through some basic tutorials on your chosen library -- then attempting your game again.
Alternatively, if programming really isn't your thing you can still create games using tools such as Construct 2, Game Maker, or others. These tools allow you to assemble games using point & click interfaces, sometimes with a bit of scripting in highly simplified languages, and if used properly can actually make much better games than a lot of people give them credit for -- there have even been commercially successful indie titles made with these types of packages.
Another option to allow you to participate in the creation of games without programming would be to learn about another discipline such as creating art or sound assets.
Remember though that using "game maker" packages or creating assets also requires you to stick with things if you want to be successful.
Whatever you do, if you continue moving from project to project, library to library and from language to language every time things get difficult you won't make progress.
I hope that's helpful and I wish you good luck!
In your position I would "give and up try something else" one last time -- don't spend too much time on the decision, but re-examine your options and choose a programming language and library to work with. Pick a game to make -- I think Pong is probably the best choice though. Then stick with the language and library that you choose until your game is completely done.
Given your experiences from previous attempts good choices might be C# with XNA, or C++ with SDL, but anything you feel comfortable to use will be fine. I would suggest spending some time practising the programming language first and then work through some basic tutorials on your chosen library -- then attempting your game again.
Alternatively, if programming really isn't your thing you can still create games using tools such as Construct 2, Game Maker, or others. These tools allow you to assemble games using point & click interfaces, sometimes with a bit of scripting in highly simplified languages, and if used properly can actually make much better games than a lot of people give them credit for -- there have even been commercially successful indie titles made with these types of packages.
Another option to allow you to participate in the creation of games without programming would be to learn about another discipline such as creating art or sound assets.
Remember though that using "game maker" packages or creating assets also requires you to stick with things if you want to be successful.
Whatever you do, if you continue moving from project to project, library to library and from language to language every time things get difficult you won't make progress.
I hope that's helpful and I wish you good luck!
- Jason Astle-Adams.
From my blog: 20 ways to advertise your game | What next? Intermediate to advanced C++
How to make games WITHOUT programming | 4 reasons you aren't a successful indie developer
#31 Members - Reputation: 4032
Posted 04 November 2012 - 09:15 PM
I'm going to make another suggestion here; either approach may be valid for you.
Your pattern seems to be that you begin something, hit a roadblock, can't get beyond it, then give up and try something else. Rinse and repeat.
Unfortunately those roadblocks seem to happen quite early and with quite findamental things, but yet you obviously want to do this kind of programming.
So my suggestion is that - instead of starting from scratch - why not take an existing open source game engine - one of the Quakes perhaps - and bash at it for a while?
You won't be dealing with the best, cleanest or most nicely written code in the world, but you will be dealing with code that works. With code that has already solved the problems you seem to get stuck on. There's no need to get too ambitious at an early stage, just trace through it, learn how things are structured, get a feel for what's done where, and remember that it's often going to be nasty gnarly code, so maybe try to rewrite some of it to be nicer, with the safety net of always being able to roll back if you mess up. Build up some experience that way and it might help you with some of the things you get stuck on in your own work.
Your pattern seems to be that you begin something, hit a roadblock, can't get beyond it, then give up and try something else. Rinse and repeat.
Unfortunately those roadblocks seem to happen quite early and with quite findamental things, but yet you obviously want to do this kind of programming.
So my suggestion is that - instead of starting from scratch - why not take an existing open source game engine - one of the Quakes perhaps - and bash at it for a while?
You won't be dealing with the best, cleanest or most nicely written code in the world, but you will be dealing with code that works. With code that has already solved the problems you seem to get stuck on. There's no need to get too ambitious at an early stage, just trace through it, learn how things are structured, get a feel for what's done where, and remember that it's often going to be nasty gnarly code, so maybe try to rewrite some of it to be nicer, with the safety net of always being able to roll back if you mess up. Build up some experience that way and it might help you with some of the things you get stuck on in your own work.
It appears that the gentleman thought C++ was extremely difficult and he was overjoyed that the machine was absorbing it; he understood that good C++ is difficult but the best C++ is well-nigh unintelligible.
