I'm writing a multithreaded C++ library that uses SDL, and I can't call TTF_SizeText while calling any other SDL method. All other SDL methods are either graphics functions (only on one thread) or basic window functions (not used often and locked).
I was going to cache the font glyphs and the kerning between each
letter but neither TTF_GetFontKerningSize or
TTF_GetFontKerningSizeGlyphs work.
I believe the only reason they can't run is because of basic SDL
functions like SDL_strlen. I attempted to rewrite the method
TTF_SizeText (Can be viewed here:
https://github.com/limbahq/example-neverball/blob/master/SDL2-full/SDL2-ttf/SDL_ttf.c)
but I have mostly developed in Java and I'm not sure if it's even
possible.
Another option might be to only load string widths on the
graphics thread but I have to load a lot of various strings and it
would be messy to code
One last idea I had was loading freetype seperately and using that,
but it could be messy as well.
Any insight into my problem is appreciated
Related
I need to extract audio from video and save it. FFmpeg has command for this purpose. I wonder if it is a right way to execute ffmpeg from my code and not to write code with their API functions.
The lack of this approach is that I use Qt Framework and need cross-platform application. Sometimes (especially in windows, because PATH variable doesn't set up automatically so call ffmpeg won't work) a user will need to indicate path to executable file to run in command line.
So both variants are possible to realize, but which is the best and correct one?
I don't really want to use their API because it is not so easy to understand and will take time to write my own code.
Thanks for any advice!
Using standalone ffmpeg seems to be preferred in your case. You will have to bundle ffmpeg and it's dependencies along with your application. However there is no need to set or use PATH or other environment variables to launch ffmpeg. You should do it by supplying full path to ffmpeg executable.
Using libav API is indeed rather tricky. And I would like to mention that in general (depending on codec) ffmpeg and libav should not be considered stable and you should spawn a separate process to protect main executable from potential crash in this case as well. So complexity of this approach is much higher compared to first one.
Disclaim: I never used Qt with ffmpeg together myself, but have much experience with Qt especially.
Qt tends to try having everything in their library, wrapping many other content for convenience. Most of the time (All those I tested), it is still possible quite easily to use the original library without troubles, but the Qt facilitate integration.
As an example: QOpenGLWidget is a wrapper for OpenGL with their widget system, adding signals and slots, etc. I made some test using normal OpenGL and it worked fine.
In another project, we(my team, not me particularly) used ffmpeg to display video on a QtWidget. It works with limited problems (due to other architectural requirements).
Considering your use case, and especially that you are using ffmpeg for background processing and not for displaying video, you may IMO go ahead with high probability of success.
Is there some basic way to draw something in C++?
I know there are lot of engines, libraries etc. But these libraries have to use some most basic drawing function or whatever it is. I mean normally without any non-standart c++ libraries you are only able to make console applications. But the new libraries that can draw something, or atleast show something different than standard command line, have to use some basic function that allows to make something different without commandline.
I've heard about WIN32 API (I'm not targeting just Windows platform,vbut I'm using windows, still have Ubuntu(Wubi)). I just can't belive that the only way is to use WIN32 API.
So I guess my questions are as follows:
Are all GUI(or non-console) libraries using WIN32 API as basic?
Are linux developers required use some linux API for GUI?
(Sorry for my English, it's not my native language)
The operating system (on a modern computer) is in charge of the screen so you have to use it's functions to draw on the screen.
There are a whole range of libraries from very high level ones, where displaying a video is a single line of code, to low level ones where you can determine the details of every pixel.
As well as drawing on the screen a GUI library, or toolkit, is also responsible for handling keyboard and mouse, for dealing with other windows going over your window and for drawing all the standard controls such as file open boxes etc - that's why it's a bit complex.
See minimal cross-platform gui lib? fro some examples
I'm working on a project to show an overlay on any DirectX11 games. Now the overaly can show in some DX11 games but cannot in some others.
I hooked the DX11 API IDXGISwapChain::Present() using the MS Detour. In the function Present(), I setup each pipeline, call the DrawIndex and ResourceCopy update my overlay texture to GPU's memory, then call the original Present to bring the back buffer to front buffer. It works fine in some games like Unigene and DIRT2 but it doesn't work on some others like LostPlanet2 and DragonAge2.
Doing some logging with hooking all DX11 functions, I found an interesting things - those not working games call ResourceCopy and ResourceCopyRegion before calling Present.
Like I said previously, I also called the ResourceCopy in my Present(). Is it the reason why it doesn't work? How can I workarround it?
Thanks,
Marshall
I am also developing a similar D3D11 proxy hook. However, I begin from the entrypoints D3D11CreateDevice and D3D11CreateDeviceAndSwapChain. Then use replacement classes as hooks to my own. I found that some cases Detours cannot actually perform the detour properly:
Error detouring EntryPoint(): 6
I worked around this by actually modifying the Detours 3.0 source code to trampoline the function correctly.
I am working with 64 bit Windows 7 but compiled for x86 Detours 3.0. I can try out those binaries to work. It's quite hard to explain where ResourceCopy can influence the call path other than rendering style used by the programmer. If you like, you can send me your project code and I might be able to help.
Yes, I hate Objective-c, plus my project will be portable, so I'd like to code as much of it in C++ as possible, ideally 100%.
So I have a regular C++ project made with Xcode, and want to open some OpenGL windows.
edit: Damn, Glut takes over the app's control with glutMainLoop() and I'll like to have more control over the loop.
Will try freeglut, although I can't find OSX binaries, and I always have such bad luck trying to compile someone else's code.
Update:
I tried yet again to link to SDL 1.3 and this time I could get it to work! yoo-hoo!
I always wanted to work with SDL, but using more than one window was mandatory, and that's a feature of version 1.3 which is under development and I never could get it working.
As it is portable to a zillion OSes, and handles 2D graphics as well as OpenGL I'm going with it. Thanks to all!
If you don't want to use objective-c you're going to have to use either the deprecated carbon libraries, X11, or another library like GLUT to create the window. If portability is a concern either go the GLUT route, or you'll need to write your own window management code for each platform you want to support.
If you don't go the GLUT route you will need to write window management code fore each operating system so I strongly suggest you bite the bullet and write the window management in objective-c++. The only thing you really need to know is that a pointer is always a pointer no matter which language it is in, so just store objective-c ids as void* and cast them back to ids, it actually works out pretty easy.
i guess NeHe tutorials could help;
GLUT works fine for your stated purpose, although you will probably wish for a nice C++ wrapper for it. I ended up hacking my own, and although GLUT isn't friendly to wrapping, it was doable.
EDIT: Since you have a problem with glutMainLoop(), you may be trying to do more than GLUT was designed to do -- it is mainly intended for hacks, one-off projects and opengl demos. And freeglut doesn't compile OOB on the mac, at least that was my experience.
For a portable, fuller featured app, Qt may be the way to go for you. Otherwise, design your C++ for portability and use a thin GUI layer on each platform. If getting something running on each platform is most important, go for the former. If the best user experience on each platform is most important, go for the latter. You may find that "thin" is not the most descriptive term for what is involved.
I found this demo to be useful for getting a simple Cocoa/OpenGL window working, even though the code has a number of ridiculous bugs: http://developer.apple.com/library/mac/#samplecode/CocoaGL/Introduction/Intro.html
This question has been asked over 3 years ago, yet remain quite fresh. I just recently went through similar exercise for planning school curriculum, and trying to figure out what's the best portable library to work with on Mac/Windows/Linux/mobile with OpenGL projects. Perhaps my notes will help someone make a decision. I only mention the main options that I've considered.
Higher level APIs, for window management plus additional goodies, like sprites, fonts, sounds, event handling, etc:
SFML and github repo: nice&tidy, C++, object oriented library that integrates with OpenGL natively. Portability for managing windows and OpenGL 3.3 contexts out of the box on MacOS, Win and Linux. Mobile support provided in the 2.2 branch (github).
SDL2: all major platforms, including mobile, supported. The OpenGL context needs to be manually managed somewhat, so use of GLEW for example comes really handy (see below). A bit lower level than SFML.
Lower level APIs, mostly for window and OpenGL context management:
GLWF: This is pretty much a GLUT replacement for modern OpenGL. Rather low level, but portable across: Win, OSX, Lin. In active development.
GLEW: I only mention it for completness. It doesn't manage windows, but helps managing OpenGL contexts and you might use it together with GLWF or SDL for example.
Others:
Freeglut: Open source continuation of GLUT. Suitable for small demo projects. I have not used it myself, but seen good docs and demo code. In active development.
GLUT: old one, discontinued. Legacy demos and code around the net.
The scenario is such: there's a program which loads my .dll/.so and calls a function from within it, possibly multiple times, each time expecting a different pointer to state. It uses the different states later in other calls into the dll. (It's a game AI, if you need context; each state is a AI player.)
What I want is a cross-platform way of creating a canvas window for each of those states (for visualization, debugging, etc.) I tried wx, but put it on hold, since it didn't appear to be easy at all. Are there any neat and small libraries that could do that or should I just go with WinAPI/X...?
Edit: Assume I cannot modify the host program.
Qt is simpler to set up and drive than Wx, in my experience. It's very cross platform too.
If you want to render some graphics from inside your DLL function without passing in any pointers to QImage or QWidget type things, probably the thing to do is use OpenGL. Your DLL should just render to the current OpenGL context, which is global state and can just be setup outside the DLL (maybe using QGLWidget).
Update: Ah, I just noticed your edit re not being able to modify the host code. This is a problem: any windows you create really need to be plugged into the host apps' event loop to work properly (e.g receive WM_PAINT when exposed/resized). It's certainly possible in win32 for any old code (e.g your library) to just CreateWindow and draw its contents with GDI whenever it gets the chance, but the general window behaviour may be pretty broken (it may not work at all with Vista's double buffering; I haven't tried). What I typically find easiest in this situation is simply to dump out image files and review then afterwards with image viewer of choice. IMHO this is actually more useful for debugging than a "live" window because you can step backwards and forwards, zoom in, apply image-enhancement to highlight various issues, compare against previous runs for regression testing etc etc. (If you really want the "live" views, write an image displayer which monitors a directory for new images, or streams them through a named pipe or something).
If you just want simple graphics, no widgets, SDL is very easy to use. If you do need complex controls, use Qt, as timday said.
You might check out IUP. It interfaces really well with Lua, and can be used entirely from an extension DLL there so it seems plausible that its C API could be used from a DLL plugged into something else.
IUP will get you a framework for opening a window containing the usual suspect kinds of controls, including a canvas. Its related library CD will give you the usual drawing operations in that canvas.
Current releases are portable between Windows and *nix. The next major release will support MacOSX too.