Allegro.cc - Online Community

Allegro.cc Forums » Programming Questions » basic dx_ball project(like breakout)

This thread is locked; no one can reply to it. rss feed Print
 1   2 
basic dx_ball project(like breakout)
yukcell
Member #14,650
October 2012

hi guys.
Our department give us a game project on c programming.this project includes bricks ,ball and bar(paddle).we have a problem about ball's bounce.The ball doesnt bounce from the bar(paddle).how can we make this?can you help us?Thanks everyone

Kris Asick
Member #1,424
July 2001

if (ball.y > PADDLE_Y) ball.y_dir = -ball.y_dir;

I'm going to be frank: If you can't figure something like this out then you aren't anywhere near ready to code a game. I recommend reading through some game programming tutorials before you go any further with your project.

--- Kris Asick (Gemini)
--- http://www.pixelships.com

Arthur Kalliokoski
Second in Command
February 2005
avatar

@Kris: My guess was that it's getting stuck in the paddle, changing direction every time in the loop.

They all watch too much MSNBC... they get ideas.

Dizzy Egg
Member #10,824
March 2009
avatar

Oh that's easy to do, just program it so it bounces off the paddle.

----------------------------------------------------
Please check out my songs:
https://soundcloud.com/dont-rob-the-machina

yukcell
Member #14,650
October 2012

it was a my first experience.we study on 1. grade so before we dont study on allegro.yeah we need change ball's direction off the paddle.Also we study on c programming.Can you write codes or algorithm?

Dizzy Egg
Member #10,824
March 2009
avatar

Yeah sure, just make the ball bounce off the paddle and that'll work, ok?

Good.

----------------------------------------------------
Please check out my songs:
https://soundcloud.com/dont-rob-the-machina

yukcell
Member #14,650
October 2012

hey Dizzy;
we couldnt make to ball bounce off the paddle.the ball stuck in paddle.ball couldnt move when it hits the paddle.Can you help me ?can you write code about this?

Kris Asick
Member #1,424
July 2001

yukcell, did you even read my response? I said you are NOT READY to work on this game of yours because you are asking questions that show you do not have the most basic skills necessary.

If you truly want to make this game, what you need to do is search for some online tutorials to learn the basics of game design and game programming. No one here is going to program your game for you; This forum is for sharing bits of code and asking why they're not working. If you have no code to show nor a specific coding problem to solve then we can't help you. :-/

Same goes for Compile Error in the following post if he happens to also be you or is working on your team: http://www.allegro.cc/forums/thread/611316

--- Kris Asick (Gemini)
--- http://www.pixelships.com

Audric
Member #907
January 2001

yukcell, as harsh as it can sound, it's true. Kris gave you the technical answer in the first line of the first response to your post. If you don't understand yet what that line of code meant, go see your teacher and ask him.

Specter Phoenix
Member #1,425
July 2001
avatar

Seem to be seeing this a lot lately on a lot of forums. People who have never coded a single application coming to sites wanting help to make Pong/Breakout. The one I still love to see is guys that are beginners at best claiming to be putting a team together to make a MMO-RPG/FPS/etc.

Dizzy Egg
Member #10,824
March 2009
avatar

They do make me smile...."I have to write a game, can you please show how"

Lolz.

----------------------------------------------------
Please check out my songs:
https://soundcloud.com/dont-rob-the-machina

Luiji99
Member #12,254
September 2010

If he doesn't recognize that first line of code then (s)he should take a programming tutorial before even touching on game anything.

Programming should be fun. That's why I hate Java.

Raidho36
Member #14,628
October 2012
avatar

Really now, game programming is an art. It requires extreme programming skills to make a decently running game, unless it's something as simple as mario or arkanoid. But even those two were assembly masterpieces back then when they came out, it's just modern hardware would let you waste it's processing power because it has vast of it.

Specter Phoenix
Member #1,425
July 2001
avatar

Programming is an art, game, application, or OS makes no difference. With the tools out there it really doesn't take that extreme skills to make a game. If you make a game maker game or torque engine game you are doing game programming using a scripted language that is designed to make game programming easier. Truth is that everyone uses libraries and APIs to make games and rarely make everything from scratch. Even allegro at times seems like it is just a wrapper for multiple cross platform APIs (libpng, libogg, physfs, etc). Game programming is hard if you are wanting to learn C/C++/C#/Java/D etc, but in the same breath it is easy too due to all the tools companies have brought out for allowing those interested in game design to make a functioning game with little effort.

Luiji99
Member #12,254
September 2010

I think that game programming would still be pretty easy if we just used OpenGL directly and wrote a simple FreeImage-based PNG-to-easierToLoadFormat converter setup. OpenGL is fairly easy, and easierToLoadFormat is ingenious.

Audio is where I might folly.

Programming should be fun. That's why I hate Java.

Arthur Kalliokoski
Second in Command
February 2005
avatar

I'd say that when you get the OpenGL and the audio working, you're 25% done with a game. OTOH, if by "OpenGL working" you mean you've already finished level design, you might be 50% - 60% done.

They all watch too much MSNBC... they get ideas.

Luiji99
Member #12,254
September 2010

You say "OpenGL working" in quotes as if I said that. This is weird.

My point is that programming the game isn't mostly setting up OpenGL. In fact, that has nothing to do with what I said. My point is that it isn't an massive setback to flunk out Allegro and libraries that are like it. Albeit, if you want something robust with support for PNG, JPEG, OGG, software-level virtual file systems, easy portability, etc., Allegro is definitely an important thing to use (unless you want to reinvent some serious wheels).

Programming should be fun. That's why I hate Java.

Raidho36
Member #14,628
October 2012
avatar

Well, since allegro is basically a wrapper with some extras, it doesn't have much to do with game programming itself.

The difference between game programming and generic programming is that in generic programming stability and precision always go first with robustness just a bit behind them, and in game programming performance is everything and nothing else is even slightly important. If you need a lot of extra execution code to fix some undesired behavior that would add considerable delays, in generic programming you just add that code, but in game programming you can really just throw it away and get to go with that bug, or come up with "slightly unstable" code that would be really short and won't impact performance, where "slightly" is very widely ranged. Say, in generic programming you wouldn't even consider using fast inverse square root, but in games that invention turned out to be incredibly handy. Of course modern hardware offers much faster and precise direct inverse square root computation, but the idea remains the same: anything goes for the sake of running fast. And "running fast" is an absolute value. If something runs fast on your I7 it doesn't mean it is actually fast. It could be as much as 0.5 FPS fast on p3. For such cases there's very common approach which states "screw them", but you can't really use it unless you create a monster like doom4 or diablo3 that would naturally require hell of a processing power.

By the way, I was looking into allegro's sources and it really lacks of game techniques exploitment. It would constantly call malloc/free in events queue for an instance, which is a fine way to program a software, but bad way to program a game. In video game, you allocate your memory once and then you use whatever you have. That's because continiously allocating and deallocating small chunks of memory creates a memory fragmentation, which is virtually unsolvable within mehtods reasonable for game programming, apart from being slow by itself. Another thing is probably brought in by plusesers. That thing is application of C++ patterns where they're don't belong, which only adds up confusion and slightly increases execution time and memory consumption for absolutely no reason other than just having them there.

here was a huge rant about C++ and coders that use it, but it is now absent because they're not susceptible to reasoning and it would cause nothing but holy war

Luiji99
Member #12,254
September 2010

I almost TL;DR'd but got interested. I'd say that Allegro is a bit generic in that you can write non-games with it, but fairly game-oriented in that the majority of non-games would have extra bulk and weird designs on it. I.e. a media player running on an event queue might not be as natural as with a game.

On the note of the event queue...it seems very un-optimum to do so many (de)allocations every frame. I wonder of there's a way to optimize this out (at least partially).

Programming should be fun. That's why I hate Java.

Raidho36
Member #14,628
October 2012
avatar

Easy: allocate as much as required to contain all the events that could possibly arrive between two discardtions. I believe, 4096 bytes events array would be satisfying for most cases. And if happens to be not, it could be easily re-allocated to 8192 bytes. That makes for a single malloc and free call and one or maybe two realloc calls, ever. That would also save up a bunch of memory compared to initial approach, because every single malloc creates 12 through 48 bytes overhead, depending on implementation.

Peter Wang
Member #23
April 2000

Raidho36 said:

It would constantly call malloc/free in events queue for an instance,

Where?

Raidho36
Member #14,628
October 2012
avatar

Let me just download sources again... there.

#SelectExpand
1void _al_event_queue_push_event(ALLEGRO_EVENT_QUEUE *queue, 2 const ALLEGRO_EVENT *orig_event) 3{ 4 ALLEGRO_EVENT *new_event; 5 ASSERT(queue); 6 ASSERT(orig_event); 7 8 _al_mutex_lock(&queue->mutex); 9 { 10 new_event = alloc_event(queue); 11 copy_event(new_event, orig_event); 12 ref_if_user_event(new_event); 13 14 /* Wake up threads that are waiting for an event to be placed in 15 * the queue. 16 */ 17 _al_cond_broadcast(&queue->cond); 18 } 19 _al_mutex_unlock(&queue->mutex); 20} 21 22static ALLEGRO_EVENT *alloc_event(ALLEGRO_EVENT_QUEUE *queue) 23{ 24 ALLEGRO_EVENT *event; 25 unsigned int adv_head; 26 27 adv_head = circ_array_next(&queue->events, queue->events_head); 28 if (adv_head == queue->events_tail) { 29 expand_events_array(queue); 30 adv_head = circ_array_next(&queue->events, queue->events_head); 31 } 32 33 event = _al_vector_ref(&queue->events, queue->events_head); 34 queue->events_head = adv_head; 35 return event; 36} 37 38static void expand_events_array(ALLEGRO_EVENT_QUEUE *queue) 39{ 40 /* The underlying vector grows by powers of two. */ 41 const size_t old_size = _al_vector_size(&queue->events); 42 const size_t new_size = old_size * 2; 43 unsigned int i; 44 45 for (i = old_size; i < new_size; i++) { 46 _al_vector_alloc_back(&queue->events); 47 } 48 49 /* Move wrapped-around elements at the start of the array to the back. */ 50 if (queue->events_head < queue->events_tail) { 51 for (i = 0; i < queue->events_head; i++) { 52 ALLEGRO_EVENT *old_ev = _al_vector_ref(&queue->events, i); 53 ALLEGRO_EVENT *new_ev = _al_vector_ref(&queue->events, old_size + i); 54 copy_event(new_ev, old_ev); 55 } 56 queue->events_head += old_size; 57 } 58} 59 60void* _al_vector_alloc_back(_AL_VECTOR *vec) 61{ 62 ASSERT(vec); 63 ASSERT(vec->_itemsize > 0); 64 { 65 if (vec->_items == NULL) { 66 ASSERT(vec->_size == 0); 67 ASSERT(vec->_unused == 0); 68 69 vec->_items = al_malloc(vec->_itemsize); 70 ASSERT(vec->_items); 71 if (!vec->_items) 72 return NULL; 73 74 vec->_unused = 1; 75 } 76 else if (vec->_unused == 0) { 77 char *new_items = al_realloc(vec->_items, 2 * vec->_size * vec->_itemsize); 78 ASSERT(new_items); 79 if (!new_items) 80 return NULL; 81 82 vec->_items = new_items; 83 vec->_unused = vec->_size; 84 } 85 86 vec->_size++; 87 vec->_unused--; 88 89 return ITEM_START(vec, vec->_size-1); 90 } 91}

Is there anything I missing?

Thomas Fjellstrom
Member #476
June 2000
avatar

It's a dynamic vector array, it only grows once in a while. In most use cases, it'll only realloc a few times. It's size will double every time it needs more room, after a few resizes, it'll never need to expand again (unless you let the queue backup and never drain).

--
Thomas Fjellstrom - [website] - [email] - [Allegro Wiki] - [Allegro TODO]
"If you can't think of a better solution, don't try to make a better solution." -- weapon_S
"The less evidence we have for what we believe is certain, the more violently we defend beliefs against those who don't agree" -- https://twitter.com/neiltyson/status/592870205409353730

Raidho36
Member #14,628
October 2012
avatar

Oh, that line...
if (vec->_items == NULL) {
And couple of ithers... I must've been reading the code diagonally when I thought it allocates space per event.

But what's with re-allocating to space two times bigger than necessary? It works okay if initial size is 1 unit, i.e. it would reallocate to 2 units, that makes perfect sense, but with 128 units it would reallocate to 256 units, while only giving 129 units data length i.e. just one more unit size increase to vectors' mind. It is certainly a memory waste. And this time I read the code line by line and then symbol by symbol so I'm fairly sure of it.

On the second thought, it supposed to double the vector size. But then the adjustment should be like this instead:

vec->_items = new_items;
vec->_unused = vec->_size;
vec->_size *= 2;

And if so, vector allocation is called old * 2 times, which grows the vector size in cubic progression, i.e. 0 -> 1 -> 2 -> 8 -> 1024 -> 67108864 -> 288230376151711744. It is enough to simply call it once to double it's size. But the thing that really confuses me here is that vectors' allocate back for some reason thinks that it uses up one unit. Absense of comments doesn't help at all.

Also, reallocation pointer is supposed to be void pointer, to match vector's _items field (and because *alloc returns void pointers).

Peter Wang
Member #23
April 2000

Raidho36 said:

But what's with re-allocating to space two times bigger than necessary?

It's a standard technique. Other expansion factors are possible; see, for example: http://en.wikipedia.org/wiki/Dynamic_array

Quote:

grows the vector size in cubic progression

Don't know what you're talking about.

Quote:

But the thing that really confuses me here is that vectors' allocate back for some reason thinks that it uses up one unit

It allocates a slot for the caller to fill.

Quote:

Also, reallocation pointer is supposed to be void pointer, to match vector's _items field

The _items field is declared as char *. We perform pointer arithmetic on it (see ITEM_START) which, in standard C, would return casting it to char * anyway.

By the way, the average length of an event queue is zero.

 1   2 


Go to: