I´m new to the DirectDraw and game thing, I do know C++ and MFC, I´ve been trying to do a 2d engine, here are some of the questions I´ve been wondering about. Game Questions: ****************************************************************** 1. Is it possible to do bit manipulation to a surface in DirectDraw? How? ****************************************************************** 2. When a sprite is hitting an other sprite: Say that sprite A is touching sprite B, whos in charge of the consequense? Shall sprite B get a pointer to sprite A, and be able to do what ever he want´s with it, or shall sprite A get a pinter to sprite B, and then ask for the consequense? ****************************************************************** 3. Direct Draw, MFC and speed: Is it a known problem that MFC will slow down the process of rendering the screen? I´m updating my screen through the SetTimer funktion, but even if I´m setting the period to 3 ms ther´s, it still ain´t updating the screen fast enough. I don´t have a lot math with in the loop, and only three sprites. What can I do to increase speed? ****************************************************************** 4. How to do a scrolling scene? I can load a big map (2000x2000) when in windows 98, but when running it on a NT machine it crashes. What is the matter with NT? I''ve read some about Clipping, what´s that? ***************************************************************** Well, that´s it for now. Hoping that someone can answer these newbie questions... Patrik

1. When you mean bit Manipulation, what exactly are you trying to do?

2. Well, when two sprites collide, no one is really in charge, you set that all up yourself. If you want the "hit" sprite to react, then you program it that way, if you want the "hitting" sprite to react, again, your choice. Take a look at some of the tutorials on Collision Detection.

3. DirectDraw takes care of all the screen refreshes for you, so you don''t need those timer functions. Also, using Win32 greatly simplifies and streamlines your code, put that is just a personal preference. To increase speed there, just let DirectDraw Handle it. Look more into the DirectDraw Tutorials and the SDK.

4. Ok, here is how I did this one. First I created an offscreen surface that was as big as the primary surface, then I used the funtion LoadBitmap() from the DDUTIL library to read in the section of the bitmap from 0,0. This loaded section of the bitmap from 0,0 to surface_height,surface_width. Then I draw the bitmap.

When I wanted to scroll the bitmap, I just adjusted the starting point value. For example. Say I wanted the middle of the bitmap, I would use LoadBitmap(...100,0) and that would take the section of the bitmap at 100,0 to surface_height, surface_width. That is just one way to do it.

-- I would strongly suggest that you take a look at the tutorials here as well as pick up a book or two. The one I started off with was Windows Game Programming for Dummies. It is very straight forward, and easy to follow. Good Luck

Kevin =)

1. If you mean writing data to the buffers directly, then ''yes'' It is possible. Look up the help on Lock() and Unlock(). (HINT: DDLOCK_SURFACEMEMORYPTR is the flag you''ll want to use )

2. Hmm... I''ve been thinking about that too. Perhaps setting up a message queue in each of the sprites, and then when they collide, post a message telling them they''ve been hit and include info such as the ..um.. ''hitters''.. type, velocity, etc.

3. You probably should be using straight Win32 code. You really don''t have to write that much to get a fullscreen DDraw application running. There is also a lot of help on the subject, just check around this site.

4. Hrm.. dunno why it would work in 98 but not NT... Um, next question.

5. Clipping is the process of determining which drawable objects are within the drawable area (usually the entire screen), and drawing only the portions that should be drawn.

DirectDraw clipping only works with blits however, so you''ll need to do line and direct buffer access clipping yourself.

--
Hope that (and the post above) helped you out some.

Just my thought on 2. Tell A it got hit by B and tell B it got hit by A. As an example if they bounce off each other then each determines their own new velocity and direction. This actually needs to be done in two phases so that both can refer to the other at the time of impact rather than the second one referring to the first after impact. So you tell them both they collided so they can calculate their new velocity and direction, but they don''t commit the change until a second pass tells them to do so. I think this will make it much easier to build complexity. As an example picture a person and a bullet. You could have the person determine the damage the bullet did on impact, but what if it was a rocket hitting a wall instead and they just happen to be in the blast radius? What if you have ten differant types of bullets? Putting all that code into the person is going to get difficult to deal with. Where instead you could just have an apply damage function on the person that the bullet calls when it collides and the rocket calls for every object within a certain radius of the blast. The person only has to check the type of damage and it''s protection from it rather than knowing the damage and type for each weapon/ammunition.