News:

MASM32 SDK Description, downloads and other helpful links
MASM32.com New Forum Link
masmforum WebSite

OpenGL Breakout underway!

Started by OceanJeff32, September 29, 2005, 03:51:18 AM

Previous topic - Next topic

OceanJeff32

You know, I find this amazing, I must complement you:

Your framework.asm and support files, make it EASY to start working with this API!  I haven't even looked at a reference list for the functions, and I'm almost 1/2 way there to BREAKOUT (2D anyway)

I modified the Sprites_Collisions file to display a breakout like demonstration.

Check out the attachment.

Just wait until I get ahold of the documentation!

Later, and thanks for starting my journey into OpenGL, and making the beginning of the journey PLEASANT!!!
:U

Jeff C
:dance:

P.S. The graphics, go into the media folder of the examples, and the sprites_collisions is the new source (because it has the same filename, watch out it will override your old one.)

P.S.S. The graphics are from http://www.grsites.com and I've also included the executable, because it's so small!

Update!  This second attachment, has a release2.bat which compiles to the directory you are working in, so you don't have to go to the bin directory to see your executable.

ALSO, it has an updated bouncing object, a white ball, that I used the transparent background functionality (in the source code, the background color can be specified and the OpenGL function tells the hardware to render that color as transparent) to give the ball a more round(er) look.

(*BUG*) but it's mine...the collision routine provided by OpenGL works awesome, but the bouncing of the ball off the paddle is not perfect yet.

Also, note the paddle is provided from http://www.nasa.gov (they do not mind if you use their images, as long as you give them the credit...nice government attitude isn't it?)  :lol

Any suggestions on how I could improve the collision detection???

Let me know,

Jeff C
:dazzled:

[attachment deleted by admin]
Any good programmer knows, every large and/or small job, is equally large, to the programmer!

hitchhikr

Quote
(*BUG*) but it's mine...the collision routine provided by OpenGL works awesome, but the bouncing of the ball off the paddle is not perfect yet.

I'm not sure about what you mean but if i remember well arkanoid like games had several zones on the paddles used to determine the bouncing angle of the ball against the vertical axis (the more the ball hit the paddle in the center the less the angle is opened), also i think the x speed (and maybe the y one too) was modified after the collision. Use ball/paddle coordinates during collisions for this.

Basically the direction of the ball is a rotation on z axis.

The best for you is to check some real breakout to find out.

OceanJeff32

Quote from: hitchhikr on September 29, 2005, 07:51:15 AM
I'm not sure about what you mean but if i remember well arkanoid like games had several zones on the paddles used to determine the bouncing angle of the ball against the vertical axis (the more the ball hit the paddle in the center the less the angle is opened), also i think the x speed (and maybe the y one too) was modified after the collision. Use ball/paddle coordinates during collisions for this.

Basically the direction of the ball is a rotation on z axis.

The best for you is to check some real breakout to find out.

I appreciate the information.

I have seen an awesome JAVA demo of breakout (very similar to my own JAVA applet) except that it used THREE paddles to emulate what you are talking about here, yes the designer actually had the code draw three blocks for the paddle, and depending upon which paddle was hit, the ball changed direction to three different speeds...directions.

I am an EXPERT on other breakouts, I collect them actually.

My actual question was different, I am still working on the problem:

When the ball misses the paddle, and still is travelling within the range of the paddle, everything is fine until the paddle moves into the range of the ball!  The ball shakes back and forth, haphazardly, but it follows the algorithm I coded, a very simple Y bounce only algo.

I have an awesome collision detection, and physics perfect bouncing routine (2d and 3d) but it involves floating point arithmetic, and I just didn't want to bother using it so early in the game.  Perhaps it is time to drag out the big guns. FPU watch out!  :bdg :lol  Jeff's getting out the Calculus book.

Actually, Andre LaMothe leads you through the calculus, and vector math step by step in his book:

[PLUG]  Tricks of the 3D Game Programming Gurus.  [/PLUG]

[PLUG_DESCRIPTION]
He develops from pixel drawing individually, to a full 3D Graphics Engine (drawn a pixel at a time), awesome book, he uses C and some Assembly to show you the floating point units engine.
[/PLUG_DESCRIPTION]

Later all,

Jeff C
:U

P.S. Did you like the XML I added at the end to plug Andre's Book?? (Andre is worth it)
Any good programmer knows, every large and/or small job, is equally large, to the programmer!

hitchhikr

I know this book and some others aswell but i like to stick to free resources if possible. Paying for acquiring knowledge is against my religion most of the time  :green

But if you're really into buying or borrowing books:

"3d game engine design - A practical approach to Real-Time Computer graphics"
by David H. Eberly published by Morgan Kaufmann Publishers.

The one you mentioned (which is a huge ~1500 paving stone) and eventually:

"Beginning OpenGL game programming"
by Dave Astle & Kevin Hawkins published by Premier Press.

And some others more oriented toward directx like "Advanced 3D Game Programming with DirectX 9.0" or specific to a type of game like "Programming Role-Playing Games With DirectX", "Strategy Game Programming with DirectX" etc.

And more generallo i think books specifically crafted for beginners, are a rip off; they don't go far enough and a better content can be found on the web nowadays.

Also most of them focus on 3d games.