well hot digity, look at you go...how's it feel? First, do you like the behavior when you run it? yes?Job well done. May I make more suggestions? What I think now is, I want to be able to pull that conditional set out of the main paint block into its own function block. How can I do this while retaining access to the PaintEventArgs?

Try to reorganize your code to have this stand alone function. (refactor it) then we'll see what options become available to us with another trick up our sleeves. (conditional we got, something must be worth some practice, let's find out) after you get this try to make your test smaller in keywords and symbols so when you look at it, it almost tells you what it's doing. (self commenting)

I like it phil. Keep going. This is the point where you decide to try to be a smart organized coder and write pretty code or a sloppy bad coder. Take your time...You can do it.

 

Going after a variable name for that stinkin' 510 decimal and find out what the crackin' that is. I know it's not a killZ, the logic is backward going in. Bullets travel in y direction? Probably. Need to finish off with the other axis check for a good hit.

well can you give one more little hint, I have almost solved my problem.

Did you try to make your switch better? (reusable) 

2 minutes ago, GoliathForge said:

Did you try to make your switch better? (reusable) 

what do you mean?

2 hours ago, phil67rpg said:

well can you give one more little hint, I have almost solved my problem.

well, what do you mean? If we're going back to the beginning, that's cool. What ever it takes conversation wise is fine. Perhaps explain your new problem or better said 'what you're trying to do now' and after you do that see if any solutions come to you. Let's try that.

 

Maybe think about this. That little piece of code you wrote yesterday. You can take that and turn it into an object. When it's an object, you can now do things to it when you want, poke it numerous times and make it give something back, make it call itself guided by a walk-able tree structure (iterators)... from there you throw it in a lambda and now we're talking. Lots to learn eh? What do you fancy today?

well I am working with some  of my old code, I have got my code to draw a bug and then drawing a collision sprite for a moment but then it redraws the bug again, I want to erase the collision sprite after it is drawn.

        int[] board = new int[1] { 0 };
        bool draw_flag = false;
        private void timer2_Tick(object sender, EventArgs e)
        {

        }
        private void Form1_Paint(object sender, PaintEventArgs e)
        {
            e.Graphics.DrawImage(ship, 350 + x, 530);
            e.Graphics.DrawImage(bullet, 375 + x, 520 + y);

            e.Graphics.DrawImage(bug_one, 350, 0);

            if (draw_flag == false && y <= -510)
            {
                board[0] = 1;
                draw_flag = true;
                Thread.Sleep(100);
                Invalidate();
            }
            else if (draw_flag == true && y <= -510)
            {
                board[0] = 0;
                Thread.Sleep(100);
                Invalidate();
            }
            if (board[0] == 0)
            {
                e.Graphics.DrawImage(bug_one, 350, 0);
            }
            else if (board[0] == 1)
            {
                e.Graphics.DrawImage(coll, 350, 0);
            }
        }

 

9 hours ago, phil67rpg said:

9 hours ago, GoliathForge said:

Did you try to make your switch better? (reusable) 

what do you mean? 

I believe @GoliathForge is suggesting trying to find a way that would allow you to easily handle displaying (or not displaying) multiple bugs.

As for erasing the collision sprite consider that if you call

e.Graphics.Clear(this.BackColor);

at the beginning of your paint function it erases everything. So anything in your paint function after that would be logic to decide whether or not to paint a sprite.

Also, using Thread.Sleep() is not using a timer. It is pausing processing of your program. It may create an illusion that you are ok with for your project but it won't allow other things to occur during that time.

Consider that in working with timers you have this function that is repeatedly called at a rate that you set. You can use that to regularly check variables for some value or regularly update variables. For a first project using timers, rather than attempting a sprite animation, I would suggest showing the value of a variable as it continually increments.
 

well goliath did you look at my new code I value your input.

Okay my friend. The pain is unbearable, it hurts to the core that we are a four page discussion and as a norm, very little content. What this needs is a kick in the, right direction. Are you getting a feel for what my impression is tending? I thank you for your trust and yes, I did look at your new code. A little disappointing. We fell back to an earlier exercise that should not have been applied here instead of following a natural progression of new ideas. Please don't ever Sleep() again.  And I think since we're a .net application, we let the system handle invalidation. 

Someone please correct me if I'm wrong. 

Please. 

Let's take a break for a moment and try something different. Forget about code. I'm going to pretend to be the one looking for input on well, my problem. My problem is similar to yours but I don't know what your exact problem is. What I want to do is shoot a bullet at my bug and when the bullet hits, display a collision image (on top of and or instead), wait for a time period (and or allow a sequence to run) and then clean up(deactivate). A fairly simple idea right.  All of this happening as a simulation, so we have to imagine our solutions tracking points(game state) in time. What we do is organize ourselves so that we can make common tasks logically grouped. All game related tasks that have some dynamic purpose is dealing with a timer. 

I feel it was also a mistake to dismiss the advise of @Daniel Ricci someone who has clearly been deeper behind the scenes. 

I think we're past the point of evaluating the technology and dumping our test code into the overload. I think it's time to actually think about what you want to build, start grouping your ideas into similar tasks. Think on how the heartbeat of your game will be. How often do I want to make changes to my world? And what ever I choose, will it run the same on my friends computer? Chances are low unless you understand time(fixed time step). well, now I'm tired.

I'm sorry I didn't litter my words with url links to relevant writings, but I did try to give you google keywords inside (curve brackets) in a lot of cases. 

Yes your code is cleaner. That's a plus. I urge practicing using this tick callback scheme to see what you come up with... no more calling Sleep()