ZEdit: the ultimate PCE dev tool

[Gravis]

FINALLY! the venture to get opengl actually working at all has paid off.

it took entirely too long to get this part to work.



note: the coordinate system in opengl is vertically inverted, so it's painting in the reverse direction (i JUST got it working, so i dont care )

opengl can be painful.

[peperocket]

Hey gravis, very happy to hear some news about this tool !

Can you expect to compile it for win32 ?

[Gravis]

Hey gravis, very happy to hear some news about this tool !

Can you expect to compile it for win32 ?

qt is compatible with all major OSes. however, for some reason (see being assholes) microsoft slightly changed the name of opengl function names which isnt really a big problem, just annoying. the previous software rendering version should compile for win32 with no problem. currently zedit is of no use so there is little point in releasing binaries but if any of you want the source to it, just ask.

[Gravis]

FINALLY! now i can scroll with opengl and it's much more efficient than before. there are still some kinks to work out but the hard part is done. i did major rewrites in various parts and ultimately i only had to add a handful of lines. -_-

oh well. now i understand opengl a bit better.

here it is:

[MooZ]

Go! Gravis Go!

[Gravis]

i've been busy with other stuff and been discouraged from working on the editor due to combining raw opengl code with qt opengl code being a nightmare.

i think i finally tracked down the issue in the qt source code that i'm having with gl framebuffers. qt uses a gl framebuffer to draw the opengl widget. my code makes a conflicting framebuffer which results in lots of nothing showing up. i just may have to make my own opengl widget.

*sigh*

what's with removing old functionality in opengl?! palette based textures would make everything so simple but nooooo, it's too old to add even rudimentary or emulated support.

[Gravis]

i was looking into some alternatives to framebuffers today when i ran across a forum thread titled " glLists - why the hell is it faster to have multiple glBegin(GL_TRIANGLE) than one?!" to which i had to see... because i've been using glLists. as it would turn out, glLists lack optimization and some technical garbage. upon reading this, i went back to my code from jan 27 and found that removing the lists made things faster and usable for editing! if you are asking why i had a glList in the first place, the answer is that it was a form of caching because data retrieval from the model is a bit... slow. so, looks like i'm i can make some minor modifications and get back to it.

[MooZ]

If you want speed you can try VBO (vertex buffer objects).
Here's a little doc.

[Gravis]

If you want speed you can try VBO (vertex buffer objects).
Here's a little doc.

from what i see, a VBO can only handle one texture at a time, meaning i would need to use 256 VBOs.

please say i'm wrong and cite and example.

[MooZ]

If you have multiple texture coordinate per vertex use glClientActiveTexture(GL_TEXTURE0+texUnit) before calling glTexCoordPointer.
And you can have one big VBO that stores all your data (vertices and texture coordinates). The last parameter of gl[Vertex|Normal|Color|TexCoord|Whatever]Pointer is the offset in the VBO.

Check the VBO article on OpenGL wiki for more infos.