2) Do you want the texture to be zig-zagging like the polygon, or drawn normally on the polygon like it's a cookie-cutter?

3) Why the weird shape?

I'l assume you're using OpenGL. If you aren't, ignore this

Firstly, render in triangles. It's better. Don't ask why to avoid getting off-topic (there will be people who have long explanations for this)Secondly, render in whatever order you want as long as the triangles cover the whole shape. Just make sure the texture coords are rendered in the same order.

(h_interval is the height of a tile, l is the left x coordinate of a tile, r is the right x coordinate of a tile, b is the bottom y coordinate of a tile, offZ is just a number i'm incrementing after each render, to make the effect move)

I'm trying to get a 'mirage' effect (tiles waving back and forth using sine. also i'm sure there's a way better way of doing this, if you know of it point it out)

edit: how do I get the smallest number of triangles (not reuse vertices) is my question I guess, in response to your edit

@davedes that's what the code I posted does, I just wasn't sure if I was taking the long way about doing it

That's probably one of the easiest ways if your code already relies on fixed function pipeline, glVertex, and all that deprecated jazz.

If you were using the programmable pipeline, it would be achieved with shaders. Potentially much more efficient, and much more flexibility for other effects (blurs, vignettes, etc). Further reading here.

If your end goal is to learn graphics programming and OpenGL, I wouldn't spend too long on immediate mode (glBegin/glEnd). It teaches bad practices and doesn't really help you understand what's going on under the hood.

Take this thread, for example. You've learned how to solve the problem, but only by using deprecated code. When you switch to the programmable pipeline, you wil probably want to re-learn how to solve the problem using different techniques, be it for performance or greater flexibility (i.e. FBOs and fragment shaders).

Shaders are really not hard to learn and will give you much more flexibility and power -- it just takes a bit of reading and experimentation. The hardest part is the boilerplate (ShaderProgram, SpriteBatch, etc), which you can avoid with a library like LibGDX, or the minimal lwjgl-basics API.

But that's just my two cents, as somebody who was once in the same boat that you're in now.

Quote

But it's easier to learn to use VBOs than to learn to use shaders

What part of shaders is hard to learn? In my experience the actual GLSL is fairly simple, given you aren't doing anything too crazy.

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org