Game Development

@Sachin-Bhatt
QSqlQuery::prepare() returns a result. Check it, especially while developing and you don't know what is going on.
Change your query first to SELECT * FROM mytable WHERE id = 1 and then to SELECT * FROM mytable. If the latter does not work maybe you don't have mytable.

@JonB said in How to replace `connect(this, SIGNAL(frameSwapped())...` with modern version:

@jeremy_k said in How to replace `connect(this, SIGNAL(frameSwapped())...` with modern version:

Detection of a nonexistant signal or slot doesn't happen until the initial runtime parse, and detection of incompatible arguments in the slot is delayed until slot invocation.

Which is how Python works compared against C++, regardless of Qt.

I agree. This is more like the string based connect.

My comment about Python signal connections was just intended as an observation, about how it works at coding time using function (or whatever) calls rather than strings. User gets a language check that signal and slot functions exists (at runtime in Python, and hopefully something at editing time too).

That's an IDE feature. My browser tells me when things that I type in a text input aren't in its dictionary. The words are still more like free strings than function pointers.

The development of Urho3D has been discontinued. The official repository was archived by the owner on 01/25/2023. The official forum has been removed and moved to archive. In readme on the official repository it is written that two active forks were formed from Urho3D: Dviglo and Turso3D:

Active work on the engine without maintaining backward compatibility is being done in the fork Dviglo.

The founder of Urho3D (Lasse Öörni) is currently working on Turso3D.

@cpr0gr4mm3r Maybe my next topic will help you: Problems with Ogre in Qt Creator

@JoeCFD Thank you for having tested the sample on Linux!
The Qt examples of custom shaders work fine on both Qt6.2 and Qt6.3. However, I notice that the rendering of the "advanced custom shader" is different with Qt6.3 although they haven't logged changes in Qt3D for this version of Qt (only the Qt Quick 3D module has changed but it is unlinked to Qt3D).
https://doc.qt.io/qt-6/whatsnew63.html

I will continue to investigate on my side before submitting the bug to the Qt team if I cannot find any reason to it. No change in Qt3D should not break Qt3D apps.

@SGaist Perfect, thanks, I will take a look!

I reported the bug: https://bugreports.qt.io/browse/QTBUG-111016

AFAIK QPainter is not suitable to do that kind of lines. Take a look at this discussion, there are some hacks, but ... https://stackoverflow.com/questions/59591826/draw-a-line-and-curves-with-fading-edges-with-qpainter.
I think the proper way would be to use OpenGL ou Quick3D, or other low level library and make your own shaders. I have done something like that in Opengl, but it was just a just a fuzzy circle, check here. For lines, it should be the same concept, the proper way is to use a mix() function to mix the vertex colors in fragment shader as they "fade" way from the line. Using shaders is not trivial at all, sorry if this is not the answer you're looking for, but I just dont know a easy way to do that in QPainter, I think it is not the right tool for what you want to achieve.

@KH-219Design said in Musical MIDI game - is Qt right for my project?:

User base of precisely 2. Sounds pretty excellent :)

^^ indeed it does

I have next to zero free time these days. However, if your work is on github or gitlab (or similar), please share a link. I would definitely check it out and look in on it every couple weeks, and maybe share thoughts if anything strikes me.

When I have something to share, I will :-)

Here is another MIDI project that I found useful recently, and it sounds like it might belong in your bookmarks, too:

https://github.com/markc/midicomp

SWEET! I have plenty of stuff to learn from now. That should keep me busy for the foreseeable future. Thx

Added restart button:

edit-gravity-debug-drawer-opengl1-pyqt6.gif

Source code: https://github.com/8Observer8/edit-gravity-debug-drawer-opengl1-pyqt6

@nishithaa I have tried to do this for years to make a VR video player using Qt and I'm finally close to achieving it but without gstreamer. I don't know if gstreamer is a requirement to you but I use libvlc 4, based on this example : https://github.com/videolan/vlc/tree/master/doc/libvlc/QtGL .

It compiles and runs well but I don't want to use QOpenGLWidget (I use QWindows with manually-managed QOpenGLContexts) and somehow I can't make it to work in this setup.

@Chris-Kawa You know what I just realized... the QTimer::singleShot method doesn't even work because you won't know the remaining time if you pause again during the single shot.

appears to be a single precision floating point issue, as used by Qt3D internally

appears to have been due to single precision floating point used by Qt3D internally.

Ok, so I've added v-sync by using QOpenGLWindow and its frameSwapped signal. Some good news and some bad.

V-sync solved one issue. At first with v-sync was still measuring many delays, but I found that some of those were actually measurement errors. QDateTime::currentMSecsSinceEpoch() is not accurate enough, I'm using QElapsedTimer now. Also the code I used to test somehow interfered with the measurement. When I just printed qDebug() << elapsedTimer.elapsed() - lastUpdateRotation; without branch, and did the analysis in excel, I found that almost all frames took 16-17 ms, so exactly 60fps :)

It didn't solve the frame skips on the RTX 2060. I'm getting none on the surface's iGPU (ok, I got a few above 20, but all of these were still below 30ms), but for some reason the desktop with beefy GPU still skips 0.7% of frames. And these are above 40ms, so really noticeable, max is 100ms.

I'm measuring on the frameSwapped signal now, so I can't blame the qt event loop for doing something between frameSwapped and paint. It might be something between the driver and GPU, but I'm still somewhat lost on this part.

@uani No, you do not have to delete the events - those are handled by Qt.

@e2002e yes, this is how the mouse pointer y coordinate is delivered but when I use it to screenraycast it hits on the opposite vertical side of the entity.

I subtract the mouse pointer y from the viewport height now to have a QScreenRayCast hit as expected.

oh, i'm sorry, i was referring to https://forum.qt.io/topic/140839/qtexturematerial-error-unable-to-find-suitable-texture-unit-for-diffusetexture-ogl-sampler-diffusetexture-wasn-t-set-on-material-rendering-might-not-work-as-expected-dx by "texture issue" where I posted about an issue almost too embarassing to mention it again. This one here I would contribute more research to but i already used more time than i envisioned for my project and i desired to prorgress that.