How do I find out what sub system an SDL function belongs to? On the Wiki they treat all of them as SDL functions, and the code examples don't show initialization of the sub systems at all.
Related
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
i am creating a library for game development, it uses directx 2d, however i want that some variables (ID2D1Factory, ID2D1HwndRenderTarget and others) be invisible to the end user. for example, the SDL library even using the directdraw (i guess), the directdraw classes are invisible for the end user of the SDL, and the user don't need to have the ddraw header in the includes folder of the compiler.
how can i turn these members independent(some way that the end user don't need to install the DirectX SDK for use my library), and turn these members invisible for the end user?
You don't need to install the DirectX SDK to link against a DLL .lib, or to compile with a .h, as long as you don't expose any DirectX objects (which you don't want to do).
Also SDL doesn't use DirectDraw. In fact it doesn't even exist since DirectX 7 (12 is coming out this September, so you're really out of the loop).
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 currently working on a cross-platform application (Win/OSX/iOS) which has a C++ (with Boost) back end. On iOS and OSX I'm using the Cocoa Net Service Browser Delegate functions to discover an embedded device via mDNS, then pass the information to the back end to create the objects it needs to communicate with it.
I wanted to take a similar approach with my Windows MFC front end and I found this article which seemed to do exactly what I want. However, it seems that using the Bonjour SDK has some really nasty side effects - forcing you to static link to MFC and in my case the only way I can get it to link properly is to not use debug DLLs at all, which is not ideal.
So, the Bonjour SDK isn't really any good for me because it imposes too many restrictions on my project. With Cocoa I'm actually using very little of the functionality - just didFindService and netServiceDidResolveAddress really. All I want to do is find the devices of a given type and get their IP addresses.
Can anyone suggest another way around this that will work with an MFC front end on Windows?
From what I have been able to gather from researching this topic just goto http://www.opensource.apple.com/source/mDNSResponder/mDNSResponder-333.10/ and grab the source. There is a VC project file which will let you build the dll how you want.
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.