GuiSpeedometerHud problems

Expanding and utilizing the engine via C++.
3 posts Page 1 of 1
kent
Posts: 35
Joined: Sun Sep 04, 2016 11:54 pm
by kent » Mon Sep 05, 2016 12:37 am
I have finally started porting some game functionality from TGE and ran into a few problems trying to implement the T3D version of GUISpeedometerHud (./engine/source/t3d/vehicles/guiSpeedometer.cpp). The GFX system is completely new to me, so I'm stabbing at this a bit blind.

One issue - that seemed to be causing a crash - is a missing GFX->popWorldMatrix(); call to close out the render routine. After adding this call, the control no longer crashes the game but the needle still does not render.

Going through the code, it looks like the needle position/rotation is properly calculated and rolled into a matrix, but the matrix is never applied to the GFX object when the routine builds the needle's lineloop - which I am guessing is why the needle is not rendering.

In the TGE version, needle position/rotation is applied using the glTranslatef() and glRotatef() functions. Can anyone help me out with the T3D equivalent?
Bloodknight
Posts: 94
Joined: Tue Feb 03, 2015 8:58 pm
by Bloodknight » Mon Sep 05, 2016 1:13 pm
the matrix functions are all inside source/math/mMatrixF.h-cpp, but a quick search for matrixF should find you some examples, as of yet i have not looked into how either GL or DX implement these, youd have to ask one of the smarter guys.

As a side note, even opengl removed these functions from their implemntations, there is currently some hapless attempt to add the glm library to the engine, which adds these functions independently https://github.com/Bloodknight/Torque3D/tree/add_GLM/Engine/lib/glm if this is more useful
kent
Posts: 35
Joined: Sun Sep 04, 2016 11:54 pm
by kent » Wed Sep 07, 2016 2:57 am
Thanks for the reply. That GLM library certainly opens up a whole different can of worms, donnit.

I figured the implementation was obsolete, I was wondering if there is new accepted equivalent methodology. Setting up a vertex shader might be one approach - but I'm not even sure where to begin with that. I don't think it is correct to try and access GL/DX directly.

For now, I just modified the function to do it w/ the CPU by setting up a vertex array, looping through and manually translating the points before feeding them to the gpu. Probably a bit slower but it appears to work.
3 posts Page 1 of 1

Who is online

Users browsing this forum: No registered users and 1 guest