Graphics related

Hey !

As part of my pacman game graphics, I have done the following :

1) Created a maze
2) Filled the maze with pills
3) Moved the pacman

I yet have to deal with the collision part but my question is that when the pacman starts moving around & touches other objects (even their boundaries), the other object's outline sort of diminishes where pacman's boundary touches it...why does that happen ?...& how come pacman's graphics aren't affected ?

I have been redrawing my maze every time pacman has to be redrawn (i.e., every time the user moves the pacman), & even though the graphics are smooth, there has to be a better way, right ?

I am working in turbo c, dos environment...just in case

I haven't written a pac-man game, but you only want to redraw the area's of the screen that change. Say the old pacman location, and the new pacman location.

All the area's that haven't changed since the last move, stay as they were, and are not re-drawn.

In a graphics environment, you should be using "put to place your images" , I would imagine, or are you drawing each item on the fly?

Quote:

---

I haven't written a pac-man game, but you only want to redraw the area's of the screen that change. Say the old pacman location, and the new pacman location.

All the area's that haven't changed since the last move, stay as they were, and are not re-drawn.

---

Adak, I got what you are saying & instead of explaining back, I am attaching my sorry excuse for a program, so far...
Comment out the drawMaze function call from within drawPacman function & see the difference...taking me back to my question, why does the graphics of other objects gets affected when pacman moves into them while the latter remains as it is?

Redrawing the maze was the easiest & by far the most braindead solution I could come up with...

Oh ! & use the arrow keys for moving pacman...

I ran your program, both with and without the maze being redrawn, but there was no discernible difference on my system. The pacman figure always overwrote anything beneath it. Nice maze and layout, by the way! :) IMO pacman needs interior content of black/or something/, to cover the pills that he's on top of. They shouldn't be shining through.

Pacman figure is too big for the maze - he can't fit into the corridor without touching the walls, because he's the same size (in fact, slightly larger). He needs to be just slightly smaller than the corridor's width to fit correctly and that fit should include when he moves his "mouth" closed (and becomes more like a full circle).

Next problem is that pacman is able to run outside the corridors of the maze. He's the X-Country PacMan! :p It changes of course, but whatever corridor he's in, his center point has to be the center point of the corridor. (Which means both pacman's radius, and the width of the corridor, should be an odd number.) If he's in a horizontal corridor, he can't move up or down, at all. If he's in a vertical corridor, he can't move left or right. The only place he can move all 4 directions, is at an intersection of those corridors. This refers to all the ghosts, as well, since they also have to fit in the same corridors, and move in the same way. No part of pacman or the ghosts should ever make contact with the walls of the corridor.

What do you think?

Quote:

---

The pacman figure always overwrote anything beneath it.

---

Really !? On my system, if the maze is redrawn, the pacman does not overwrite...how does that work ?

I do agree that the pacman needs to be "filled out" but I intend to jazz it up after I can get the "game in it" working...

I do realise that the pacman figure is too big...tried making it smaller but it gets too small to fit the corridor's width correctly, but will have to work it out, its crucial to detecting when pacman is trying to move through the walls.

Quote:

---

Next problem is that pacman is able to run outside the corridors of the maze. He's the X-Country PacMan! It changes of course, but whatever corridor he's in, his center point has to be the center point of the corridor. (Which means both pacman's radius, and the width of the corridor, should be an odd number.)

---

I totally agree & I tried in vain to solve the problem just described, as it is impossible to start the "game programming" bit before getting this right. Although I have another approach to try now as suggested by you.

Quote:

---

If he's in a horizontal corridor, he can't move up or down, at all. If he's in a vertical corridor, he can't move left or right. The only place he can move all 4 directions, is at an intersection of those corridors.

---

That's true again...but yes, whatever are the semantics for the movement of the pacman are meant to be followed by the ghosts as well with the major difference being that, for pacman, the check has to be made each time (or only at intersections ?) as to the path that the pacman is allowed to move in the maze but for the ghosts it needs to be specified before hand as they will have their own ai or graph traversals coded using the same...wotsay ?

For the time being I am going to (try &) rectify my X-Country PacMan.

This is perfectly the reason why you don't use DOS for graphics. Learn opengl.

I think it's a great programming project to learn from, though. And turbo C is pretty fair with graphics modes that were available at that time.

Adak, my pacman wont chuck being a 'X - Country Pacman'...I initially thought that your suggestion of having the corridor & pacman's radius of odd values would help...but in hindsight, I think the point where pacman is initially positioned also contributes, moreover, in movepacman(), I have incremented the value of pacman's y or x co - ordinate by 5, shouldn't that make a difference as well...

Moreover, should it make a difference if pacman does not fit the corridors exactly ? (It shouldn't be bigger but it can be smaller, right ?) The graphics functions of line & circle don't take float values, so I cant come up with the exact fit...

I think I finally got the graphics part (sort of)...can finally start with the actual thing..

Thanks again, adak !

Quote:

---

Originally Posted by trish

Adak, my pacman wont chuck being a 'X - Country Pacman'...I initially thought that your suggestion of having the corridor & pacman's radius of odd values would help...but in hindsight, I think the point where pacman is initially positioned also contributes, moreover, in movepacman(), I have incremented the value of pacman's y or x co - ordinate by 5, shouldn't that make a difference as well...

Moreover, should it make a difference if pacman does not fit the corridors exactly ? (It shouldn't be bigger but it can be smaller, right ?) The graphics functions of line & circle don't take float values, so I cant come up with the exact fit...

---

Pacman should be 2 units, smaller than the corridors. He has to "slip" inside, like a hand into a glove. They can't be the exact same size. Since both the corridor and Paccy need to have an exact center point, they both need to be an odd dimension. Width for the corridor, and radius for Paccy. Should be easy if you calculate the exact center of the corridor, and a corresponding center point on Paccy.

This is PacMan on Mimas, a Moon of Saturn. Pic was made using thermal imaging. Each color shows a different temperature on Mimas. Regular image is on the left. This is NOT photoshopped, it's from Nasa.

Been caught up with submissions (yawn !)...

Anyhow, back to the problem...

Just when I thought I could get away with gaping flaws in my code...Adak, you are right again (for the nth time, now ?)...on my way to making changes, hopefully, I understood you correctly this time (& trashed my rubbish assumptions)...will post the results/ more doubts - whichever is applicable.

As for the image, seen it before, left me stunned...

Thanks for the suggestions, Adak, helped greatly....additionally, modified my strategy a bit to move pacman, changed the structure of pacman to include a x_dir & y_dir to monitor its movement & instead of manually increasing the x or y values(as I was doing earlier), based on keypress, the column or row values are updated & pacman redrawn in the new grid...

Took me a little too long (been caught up)...at this rate hopefully, I can complete it by next year <chuckle>

Welcome back, Trish! :)

When you get a chance, fill us in on how the program is doing.

sure thing, Adak !