a squircle! game isn't running, but a test gl scene under a qquickview

works neatly..time to try and integrate my own renderers into this..
doesn't compile. it did though, i swear!

it looks like qt's opengl shit is fucked. so I may have to go back to
utilizing glew/someloader.  But i'd want something better than glew because
glew is a pile of shit too.

other than that though, when it compiled it was rendering an example
gl scene beneath the qtquick ui layer. so that was cool.
fix glew.h usages (lack thereof actually)

instead of using qt's builtin opengl bullshit, we're now using some
other extension loader. looks like it's just impossible otherwise, and
nobody has a clue on how to do it like that anyways.
bit of progress towards switching over to qt

still have a lot of sdl to strip out
fix glew vs sdl vs qt competing, don't call qopenglfunctions before init

(or at all, in the case of now)
it's a start! got client and game hooks merged into the qt stuff

so now it goes to (a dummy) render function and clears properly.

I now will have to go through all the world rendering code and such,
be sure it's not accessing the old gui or anything, and make sure it's
not leaving bad state.
set main qquickview item thing to full screen res (1024x768 for now)

needs to be obtained from C++, by accessing the view directly i guess.
opacity test
reinstate client net poll
comment out temporarily, the chat and other gui calls

since that'll all get stripped out and repurposed towards qt.

chat also needs to be stripped into model/view, much like quickbarinventory
already does.
try to reinstate rendering and other things, but poll()/tick()

isn't getting called because our main loop/accumulator is borked now.

wondering how i can  nicely do that, preferably running on the same qt thread
...or maybe not?
begin merging and restructuring game -> client handling, for qt progress..
event loop transition is in much better shape now

looks like the render window expires though, so gotta fix that.

then after that i need to make the client main entrance on its own thread
and have the client rendering take place *only* from the qt event thread,
and do some simple big locking there (which should be sufficient i guess).
no more view expiry issues..and i see the qml scene now.
add debugs...looks like windowchanged never gets called here, oddly..
rename qml main element
wow,  basically a drop-in replacement now (works with qt + my rendering)

only issue is that on my r600 laptop (hd4520 iirc), it's incredibly slow.

this hasn't actually changed though. just that before my game loop would
cap the logic if the rendering fell below 15 fps, so it kept it there.

now it's falling (by itself, uncontrolled) at 120ms, which is like, what?
almost 8fps?

The biggest culprit is the sky shaders. I could do a lot of optimizations
there, from doing early z cutouts to allowing one to disable the dynamic
night sky shader (and just sample from a static star image, which would
probably drastically speed things up), to stopping it altogether.

or something.

It's no surprise really though, this mobiles gpu is totally shader capped,
as is my game, early-z should help fix a lot of overdraw.

perf would probably be loads better if i were not using mesa (9.1), but
this is my secondary test system so I want it to run well on here for
other people.

the GUI right now is just completely stripped out and non-existent...

i'll slowly start peeling layers away, adding some, and sprinkling some
warm Qt goodness all over it.
add --no-sky-renderer startup flag, for making testing on crappy

systems easier..at least until we get a good settings save/load to disk,
as well as good optimizations for sky renderer and settings to adjust
performance therein.
make a direct connection here (and probably from now on, in most cases)

play with the qml a bit. i need to brush up on it a lot.
add launcher.sh launcher script, qml rect drag and drop

(will use for windows mainly, like chat box and what not).

soon to implement is resizing