Game Development

i know this... I mean the last source of Qt3D for Qt 4.8.4.... sorry for the disambiguation.

Yes, What utcenter said. I've created FPS-like interaction in a QGLWidget, and using the restrain to dead-center approach worked best for me. If you let the cursor get too close to the edge, rapid subsequent mouse movements can leave the frame, resulting in sometimes missing mousemove events. And you want to avoid things like using grabMouse() to get around that if at all possible.

Here is the rehash - works fine after I discovered an error in Wikipedia article :-)

@ QVector3D point1 = QVector3D((double) 100, (double) 20, (double) 10);
QVector3D point2 = QVector3D((double) 200, (double) 20, (double) 10);
QVector3D point3 = QVector3D((double) 100, (double) 20, (double) 110);

double d1 = (double)92.736; double d2 = (double)81.240; double d3 = (double)92.736; qDebug() << "--------------"; qDebug() << "Initial Values"; qDebug() << "--------------"; qDebug() << "Point1 : " << QString::number(point1.x()) << " " << QString::number(point1.y()) << " " << QString::number(point1.z()); qDebug() << "Point2 : " << QString::number(point2.x()) << " " << QString::number(point2.y()) << " " << QString::number(point2.z()); qDebug() << "Point3 : " << QString::number(point3.x()) << " " << QString::number(point3.y()) << " " << QString::number(point3.z()); QVector3D ex = point2-point1; ex.normalize(); double i = QVector3D::dotProduct(ex, (point3-point1)); QVector3D ey = point1-point3-i*ex; ey.normalize(); QVector3D ez = QVector3D::crossProduct(ex,ey); double d = sqrt((pow(point2.x()-point1.x(),2))+(pow(point2.y()-point1.y(),2))+(pow(point2.z()-point1.z(),2))); double j = QVector3D::dotProduct(ey,(point3-point1)); double x = (pow(d1,2) - pow(d2,2) + pow(d,2))/(2*d); double y = ((pow(d1,2) - pow(d3,2) + pow(i,2) + pow(j,2))/(2*j)) - ((i/j)*x); double z = sqrt(pow(d1,2) - pow(x,2) - pow(y,2)); QVector3D triPt = point1 + x*ex + y*ey + z*ez; qDebug() << "--------------------------------------"; qDebug() << " Point generated by Trilateration "; qDebug() << "--------------------------------------"; qDebug() << "New Point : " << QString::number(triPt.x()) << " " << QString::number(triPt.y()) << " " << QString::number(triPt.z());@

MANY THANKS for the help.

Thank you very much Andre and stuk for the helpful replies. I will try your suggestions when I get a chance! Much appreciated.

I Qt5.2 will have a lot of updates in that area, thanks to Sean's work. I'm not into using QOpenGL so I did not follow the announcements closely, but here is the latest post: "link":http://lists.qt-project.org/pipermail/development/2013-March/010190.html.

http://stackoverflow.com/questions/14823364/qt-opengl-update-unusably-slow/14865984#comment20841445_14865984

sorry, not in a position to test any code, but if this is all the opengl code then I would think you'd see something flying off the screen. First of all, i think the glOrtho() call should be made with the glMatrixMode as projection, since that's the projection transformation.

Second of all, the ortho call is being made every frame, so what ever matrix is on the top of the stack, so it is just getting completely warped.

tl;dr:
@
ClearTheScreenAlready();
glMatrixMode(GL_PROJECTION);
glLoadIdentity();
glOrtho(ORTHO_PARAMS_CONVENIENTLY_DEFINED_SOMEWHERE_ELSE);
glMatrixMode(MODELVIEW);
@

While you are at it, i'm not so sure the matrices initialize to identity, so a glLoadIdentity() call when the model view matrix is up would maybe help. Not sure. anyhow, good luck.

ok, I got the test to compile, no funny numbers on the screen. what compiler are you using? For mingw, if you get the "SDL-devel-1.2.15-mingw32.tar.gz" file from the SDL website, then set the SDL_DIR below to match where you put it, then:

@TEMPLATE = app

CONFIG += windows
CONFIG -= console
CONFIG -= app_bundle
CONFIG -= qt

SOURCES += SDL_TEST.cpp

SDL_DIR = C:/Users/Malcolm/comp_stuff/sdl_mingw/SDL-1.2.15

LIBS += -L$${SDL_DIR}/lib -lmingw32 -lSDLmain -lSDL

INCLUDEPATH += $${SDL_DIR}/include/SDL
DEPENDPATH += $${SDL_DIR}/include/SDL

@

should compile:

@/*
*SDL_TEST.cpp. do not use this file under any circumstances. it will probably blow up
*your computer.
*
*/

#include <cstdio>
#include <Windows.h>
#include <SDL.h>
#include <gl/GL.h>
#include <gl/GLU.h>

using namespace std;

int main(int argc, char **argv)
{
SDL_Surface *screen;

/* Initialize defaults, Video and Audio */ if((SDL_Init(SDL_INIT_VIDEO|SDL_INIT_AUDIO)==-1)) { printf("Could not initialize SDL: %s.\n", SDL_GetError()); exit(-1); }

SDL_GL_SetAttribute( SDL_GL_DOUBLEBUFFER, 0 );
screen = SDL_SetVideoMode(1920, 1080, 32, SDL_HWSURFACE | /SDL_FULLSCREEN |/ SDL_OPENGL /| SDL_DOUBLEBUF/);

SDL_Delay(1000);

SDL_Quit();

return 0;
}

@

anyhow that worked for me. If you're not using mingw, I would think it shouldn't be too tough. btw, mingw and directx FTW.

Finally solved this issue !

I kept the #version 120 and found what was missing for it to work as it does on device. On desktop with qt(5.0 now) you have to activate following gl functions that seem to be default on iOS:

@ glEnable(GL_POINT_SPRITE);
glEnable(GL_VERTEX_PROGRAM_POINT_SIZE);@

It is certainly possible, however, I am not willing to bet QML will play nicely in a scenario involving high count game objects. And while I've seen a case of a significantly big QML project, it wasn't as big as an RPG game might go, and it wasn't performance critical as an RPG game would be. QML can easily be brought down to its knees, especially by extensive bindings.

Typically, what you would want to do is have as much C++ game logic as possible, and only use QML to markup structure or to script. That doesn't apply to trivial games, which are the primary intended target for QML, where the level of complexity is very low compared to a typical RPG game.

There are some ways to evade the overheads of QML, like making heavy use of lazy loading, make use of OpenGL geometry instancing, which I don't think is being used by the QML scenegraph, since it is unsupported in GLES2.

For a more complex game, I'd rather use Unreal engine or Unity or some other more specialized and mature engine, providing a wide range of game related features, but if it is a more trivial and simple game, QML will probably do the trick, especially if you avoid QMLs pitfalls, something that is not hard to learn if you become friends with the QML profiler.

Hi,

Thanks for the reply. I checked my code and it seems I forgot to register the class. Registering the class solved my problem :)

[quote author="feldifux" date="1358884071"]There was a blog post today from the Woboq team about correct thread usage:
http://woboq.com/blog/qthread-you-were-not-doing-so-wrong.html
[/quote]

I don't agree with the argumentation the author of the article mentioned by you above uses. Especially the example which is given. For the use cases he presents it would make much more sense to subclass QRunnable then to subclass QThread. In my opinion in the use cases where he says its ok to subclass QThread, QRunnable would actually be the first choice.

I'm not saying that there are no valid reasons for subclassing QThread, but in most cases you'd be better of using the worker object approach, even though it might be 10 lines of code more.

Hey, I'm working on a similar project and I'm using more or less the same approach, a grid of QGraphicsPixmapItems drawn on a QGraphicsScene. What seems to be working for me is defining an array of QGraphicsPixmapItems, and having a struct located elsewhere which stores references to the pixmaps for each tile type, making a 30x30 grid of persistent QGraphicsPixmapItems. When an event happens that causes the map to be redrawn, the map data itself, stored in a 400x400 array, is accessed by the QGraphicsScene, which keeps track of what tile the top left corner currently is, and then it requests the integer that represents the tile type for each QGraphicsPixmapItem that is currently displayed. It then calls setPixmap on each QGraphicsPixmapItem, getting the pixmap from the struct that stores it, calling setPixmap on the corresponding QGraphicsPixmapItem which discards the previous pixmap and causes it to be redrawn. By iterating over the entire series of tiles in the view, you can just swap out the pixmaps each time you need to change the view and it's far, far more efficient than managing the entire map at once, I haven't had any performance issues with it so far.

As for putting other content on top of it...that's what I'm trying to figure out right now. I'm thinking of wrapping the tile QGraphicsPixmapItems with another class, maybe a QGraphicsItemGroup, so the items can easily have their position set relative to the tile they currently inhabit.

The post is very good ,i like you said .