FTGL 3D Text issues - c++

I am currently working on an engine that involves creating 3D objects such as boxes and spheres. My next task is to create 3D Text inside as an object. I am using Visual Studio 2012, OpenGL, Qt, FreeType2, and FTGL in C++ on a Windows 7 computer.
I have been able to import everything fine and get some things to render, but not the way I would like. If I create a box, the text jumps to the box I created. If I create another one, it jumps to that. If I move the camera, it jumps to the center of the scene. On top of that, all the letters in my string appear right on top of each other and I cannot position them.
What I want is for the text to be at whatever 3D location I tell it and for it to stay on the screen (so have multiple strings rendering) and for the letters to actually be able to make words. I have tried using glRasterPos3f as well to move it but it still stays latched onto whatever object it is. I have tried a lot to get a decent result but I keep running into the same thing. Please give me an idea of what the problem could be. Here is a sample of how I am rendering it to give an example:
glPushMatrix();
FTExtrudeFont* font = new FTExtrudeFont("Arial.ttf");
font->Depth(.5);
font->FaceSize(10);
glRasterPos3f(10,10,10);
font->Render("Text");
glPopMatrix();

Related

X11 - Change String contents after draw?

I just started creating a X11 application.
I am rendering text to the display using XDrawString(...).
Now, given I'd like to add something like a clock, some counter or something that changes constantly, how would I "override" the already rendered text?
The way it currently is that it just renders again and leaves the old contents behind.
From Java I know "BufferedImages", where I would render everything before transferring it to the actual screen. With this, the old contents on the display would be overwritten.
Is there a similar mechanism in X11 or do I have to paint the whole screen white and then render everything again on top of it?
I am using C++ along the X11 libs with the gcc compiler.
Thanks!
I think the only option is to use the X11-DoubleBuffer Library for C++. I now settled with SDL instead.

Text deleted by backspace is not being updated on my arduino tft display (adafruit gfx library)

For university, we need to make a game in Unity that is controlled with an Arduino. My idea was a hacking game where the Arduino acts as the 'hacking device' when hacking something in the game. The arduino would have a screen and on that screen would be a basic command-line interface that lets me input simple commands to 'hack' but I've been having trouble regarding text and clearing it.
I've been able to use unity to send typed characters to the display as-well as a backspace function (pressing backspace would remove last character in the string)
I first had issue with clearing all the text when writing (calling tft.print doesn't clear any previous text). I was using fillScreen which was slow. I found out setTextColor had a second argument that let me just set all certain colored text to a different color. Setting it to black would essentially clear it.
This made it update pretty much instantly when writing to the screen but I now had a new issue, backspace would no longer would.
My understand is that when removing the character, it's color won't be updated when calling setTextColor leaving it on the screen until a restart/fillScreen is called.
I'm not really sure how to solve this and all google searches turn up little to no help.
Here's my code for updating the text:
void updateString(char c){
tft.setTextColor(WHITE,BLACK);
if(c!='<'){
//Add new character to end of string
str.concat(String(c));
}
else if(c=='<' && str.length()>2){
//Remove last character in string
str.remove(str.length()-1);
}
//Set cursor back to 0,0
tft.setCursor(0,0);
//Display text
tft.print(str);
}
I'd appreciate any help.
Maybe, use a similar function to tft.clear() each time you refresh the screen or you can draw a filled square of the background on the text so it looks like it has been erased then you rewrite the text.
Sounds like you are using proportionally-spaced fonts instead of the original classic fonts that ships with Adafruit_GFX. Historically, when using the default classic fonts one could set the background color option of the text to the same color as the background of the screen (usually black). This would overwrite the old screen contents with new data and work because the characters using the classic fonts are a uniform size. When using proportionally-spaced fonts, the background color option for the font is disabled by design.
This was presumably because of memory requirements and speed on slower AVR's. Regardless, when using proportionally-spaced fonts the background color feature won't work due to non-uniform sized characters overlapping the same regions as adjacent characters.
There are two work-arounds to this. Adafruit says in order to replace previously drawn text when using custom fonts you can either:
Use getTextBounds() to determine the smallest rectangle that encloses a
string and then erase that area using fillRect() prior to drawing
the new text. OR
Create an offscreen bitmap using GFXcanvas1 for a fixed size area,
draw the text in the GFXcanvas1 object and then copy to the screen
using drawBitmap().
Note that options 1 & 2 above are mutually exclusive. The second method requires more memory. The first method isn't perfect and produces some small amount of flicker, but is in general acceptable if coded carefully.
I hope that I have understood what the nature of your problem is and answered it in a satisfactory manner. If nothing else, at least now you know why custom font's will not work with the so called background color feature that works with the original 'classic' Adafruit fonts.
Nikki Cooper

Cutting of parts of sf::Text, sf::Texture, etc?

I'm creating a simple chat client and server and I'm having some issues with how sf::Text is rendered. Say in the chat history for example. When users type their messages, the old messages will be pushed up. Eventually the message hits the top and I'll want to only display the part of the message that is still within the chat history. This is where I'm lost.
The element containing the text has two visible objects - sf::RectangleShape (the background for the text) and a sf::Text. I can easily adjust the size of the shape once it hits the top so it's not visible outside the chat history, but I can't adjust the size of the text without distorting the contents. Changing the character size obviously isn't ideal either.
What I want is to cut the text in half horizontally if half of the text is outside the chat history. My first thought was to mask it somehow but it seems like SFML has no support for that.
The reason I'm mentioning sf::Texture in the title as well is because I've had the same issue with that in the past. I just couldn't find a way to cut off parts of it, I only managed to distort it.
Is this possible at all in SFML?
One way of doing this is to draw the chat history to a sf::RenderTexture, which is the tool used for off-screen rendering.
Once you've drawn the chat history to your render texture, you can draw the texture on to the screen.
So if you place text that is half on the render texture and half outside, only the part that actually fits on there will be drawn.
Be aware though that render_texture are fairly expensive to construct, so you you want to re-use them and not create new ones all the time.

Drawing text over/in a Process/Game

I'm currently working on a C++ DLL project.
This DLL will be injected into a game.
All I'm looking to do for now is draw some text like "Active" or "Working" in the bottom right or left hand corner of the screen when in game.
Just to give me something visual to show that the DLL is working and active/injected.
I haven't done this myself and this is an amalgamation of resources. First of all, since you're targeting GTA San Andreas, you should know that it's running using DirectX 9. I'm not aware of any OpenGL rendering version, so correct me if I'm wrong. Now about how to 'inject' make a draw call to render an overlay, please look in here: Hooking DirectX EndScene from an injected DLL. So, basically you change DirectX function EndScene() with your custom function that draws the text you need and then calls the actual EndScene(). Let me know if you want to know more.
Helpful links:
Draw text in Direct3D 9
What is the most efficient way to draw text in DirectX 9?

OpenGL window draws fine, but all the windows on top of my OpenGL window go black

I have an app that mixes OpenGL with Motif. The big main window that has OpenGL in it redraws fine. But, the sub windows sitting on top of it all go black. Specifically, just the parts of those subwindows that are right on top of the main window. Those subwindows all have just Motif code in them (except for one).
The app doesn't freeze up or dump core. Data is still flowing, and as text fields, etcetera of various subwindows get updated, those parts redraw. Dragging windows across each other or minimizing/unminimizing also trigger redraws. The timing of the "blackout" is random. I run the same 1-hour dataset every time and sometimes the blackout happens 5 minutes into the run and sometimes 30 minutes in, etc.
I went through the process of turning off sections of code until the problem stopped. Narrowed it down more and more and found it had to do with the use of the depth buffer. In other words, when I comment out the glEnable(GL_ENABLE_DEPTH_TEST), the problem goes away. So the problem seems to have something do with the use of the depth buffer.
As far as I can tell, the depth buffer is being cleared before redrawing is done, as it should. There's if-statements wrapped around the glClear calls, so I put messages in there and confirmed that the glClear of the depth buffer is indeed happening even when the blackout happens. Also, glGetError didn't return anything.
UPDATE 6/30/2014
Looks like there's still at least one person looking at this (thanks, UltraJoe). If I remember correctly, it turned out that it was sometimes swapping buffers without first defining the back buffer and drawing anything to it. It wasn't obvious to me before because it's such a long routine. There were some other minor things I had to clean-up, but I think that was the main cause.
How did you create the OpenGL window/context. Did you just get the X11 Window handle of your Motif main window and created the OpenGL context on that one? Or did you create a own subwindow within that Motif window for OpenGL?
You should not use any window managed by a toolkit directly, unless this was some widget for exclusive OpenGL use. The reason is, that most toolkits don't create a own sub-window for each an every element and also reuse parts of their graphics resources.
Thus you should create a own sub-window for OpenGL, and maybe a further subwindow using glXCreateWindow as well.
This is an old question, I know, but the answer may help someone else.
This sounds like you're selecting a bad visual for your OpenGL window, or you're creating a new colormap that's overriding the default. If at all possible, choose a DirectColor 24-plane visual for everything in your application. DirectColor visuals use read-only color cells, but 24 planes will allow every supported color to be available to every window without having to overwrite color cells.