Basically I want to get bezier control points from a ttf font and then draw them. I was basically wondering 2 things.
Does it return an array of points or is it more complex?
How can you tell the points of 1 contour from another ex: the letter O which has 2 contours?
Thanks
Found it:
The native buffer returned by GetGlyphOutline when GGO_NATIVE is specified is a glyph outline. A glyph outline is returned as a series of one or more contours defined by a TTPOLYGONHEADER structure followed by one or more curves. Each curve in the contour is defined by a TTPOLYCURVE structure followed by a number of POINTFX data points. POINTFX points are absolute positions, not relative moves. The starting point of a contour is given by the pfxStart member of the TTPOLYGONHEADER structure. The starting point of each curve is the last point of the previous curve or the starting point of the contour. The count of data points in a curve is stored in the cpfx member of TTPOLYCURVE structure. The size of each contour in the buffer, in bytes, is stored in the cb member of TTPOLYGONHEADER structure. Additional curve definitions are packed into the buffer following preceding curves and additional contours are packed into the buffer following preceding contours. The buffer contains as many contours as fit within the buffer returned by GetGlyphOutline.
#Milo:
A void pointer is where you define a pointer to any memory location regardless of that locations defined "type" (basically, it's similiar to the "pointers" used in assembly). The problem is, it's usually not portable between different machine architectures and if you want to do anything with arrays you have to a) Manually implement boundries between each member and keep track of byte sizes (which is usually even more architecture dependant) or b) Cast it to a predefined struct or series of structs, and generally if you have to do this, you could likely just use a pointer to the struct and avoid the use of void pointers entirely.
The reason I say usually, is because there are certain circumstances when the drawbacks of using void pointers don't apply. Also, I know assembly dosen't use "pointers" per se, but it is still very similiar and I just used the term to help clarify my explanation. Remember, many things aren't set in stone.
Related
I am working on a game which has a map of 16000 X 9000 units, If I am at any point X,Y on map, I can see upto a radius of 2000 units. I wanted something from which I could manage whether I've visited a particular region or not. The main question is Should I take an array of bools? It will be too large bool visited[16000*9000]. So wanted advise, thanks. I am new to stackoverflow, sorry if I am not to the point.
If you need the discovered region to be circular (which your use of 'radius' implies) you have to use this huge arry, yes.
If it does not have to be a perfect circle, then you can simply downsample: say you use a roughness of 10 blocks - then you only need an array of 1600x90 size - a factor 100 reduction compared to the perfect circle.
It would indeed be inefficient to use an array of bool types. Mainly because the size of a bool in C++ can be luxuriously big. (On my platform, it's 8 bits long which means that 7 bits of it are not used.) The C++ standard does not specify the value of sizeof(bool).
Do consider using a std::vector<bool> instead: this is an explicit specialisation of std::vector and the C++ standard guarantees this is tightly packed: i.e. there is no wasted space. You might need a std::vector<std::vector<bool>> if you have difficultly acquiring one contiguous block of memory. This all said, some folk dislike the bool vector specialisation with a vengeance so do consider this carefully before diving in. (There is a movement to consider scheduling it for deprecation!)
Or you could lump areas of your graph together yourself into a set of integral types such as unsigned.
I am having a hard time to match up the OpenGL specification (version 3.1, page 27) with common example usage all over the internet.
The OpenGL spec version 3.1 states for DrawElements:
The command
void DrawElements(enum mode, sizei count, enum type, void *indices);
constructs a sequence of geometric primitives by successively transferring the
count elements whose indices are stored in the currently bound element array
buffer (see section 2.9.5) at the offset defined by indices to the GL. The i-th element transferred by DrawElements will be taken from element indices[i] of
each enabled array.
I tend to interpret this as follows:
The indices parameter holds at least count values of type type. Its elements serve as offsets into the actual element buffer. Since for every usage of DrawElements an element buffer must be currently bound, we actually have 2 obligatory sets of indices here: one in the element buffer and another in the indices array.
This would seem somehow wasting for most situations. Unless one has to draw a model which is defined with an element array buffer but needs to sort its elements back to front due to transparency or so. But how would we achieve to render with the plain element array buffer (no sorting) than ?
Now, strange enough, most examples and tutorials in the internet (here,here half page down 'Indexed drawing'.) give a single integer as indices parameter, mostly it is 0. Sometimes (void*)0. It is always only a single integer offset - clearly no array for the indices parameter!
I have used the last variant (giving a single pointerized integer for indices) successfully with some NVIDIA graphics. But I get crashes on Intel on board chips. And I am wondering, who is wrong: me, the spec or thousands of examples. What are the correct parameter and usage of DrawElements? If the single integer is allowed, how does this go along with the spec?
You're tripping over the legacy glDrawElements has ever since OpenGL-1.1. Back then there were no VBOs, but just client side arrays, and the program would actually give a pointer (=array in C terms) of indices into the buffer/array set with the gl…Pointer functions.
Now with index buffers, the parameter is actually just an offset into the server side buffer. You might be very interested in this SO Question: What is the result of NULL + int?
Also I gave an exhaustive answer there, I strongly recommend reading https://stackoverflow.com/a/8284829/524368
What I wrote about function signatures and typecasts also applies to glDraw… calls.
I'm profiling the code that I have developed, and I see a bottleneck in my code when I use cvSet2D.
Is there some alternative to cvSet2D more efficient?
How can I write that pixels?
I recommend you to use the C++ functions and not the old C style functions.
The most efficient way to write to pixels is the following.
cv::Mat frame;
// load your img to your Mat
uchar* p = frame.ptr(row); // returns a row pointer
p[column] = x; // accesses value in the given column
One thing to note is that you might have more columns than you have pixel columns, e.g. on a 3 channel image you have 3 times the number of actual pixel columns you can access.
For more information on different ways to iterate over pixels, check this tutorial.
You need to get a pointer to the data field of the structure.
(C API) The IplImage structure has a char* field called data. Access (your_type*)image->data for the first element, and then use it like a regular C 1D array, but be careful to use the field stepWidth to jump from a line to the next (because lines of data may be aligned on multiples of 16 bits for memory access optimization).
(C++ API) Use T* cv::Mat::ptr<T>(int i) to get a pointer to the first element of the line you want to access. Then use as a regular C++ 1D array.
This should be the faster access pattern (see the book OpenCV2 Cookbook for a comparison of the different access patterns).
I have a class MyClass that stores a collection of PixelDescriptor* objects. MyClass uses a function specified by a Strategy pattern style object (call it DescriptorFunction) to do something for each descriptor:
void MyFunction()
{
descriptorA = DescriptorCollection[0];
for_each descriptor in DescriptorCollection
{
DescriptorFunction->DoSomething(descriptor)
}
}
However, this only makes sense if the descriptors are of a type that the DescriptorFunction knows how to handle. That is, not all DescriptorFunction's know how to handle all descriptor types, but as long as the descriptors that are stored are of the type that the visitor that is specified knows about, all is well.
How would you ensure the right type of descriptors are computed? Even worse, what if the strategy object needs more than one type of descriptor?
I was thinking about making a composite descriptor type, something like:
class CompositeDescriptor
{
std::vector<PixelDescriptor*> Descriptors;
}
Then a CompositeDescriptor could be passed to the DescriptorFunction. But again, how would I ensure that the correct descriptors are present in the CompositeDescriptor?
As a more concrete example, say one descriptor is Color and another is Intensity. One Strategy may be to average Colors. Another strategy may be to average Intensities. A third strategy may be to pick the larger of the average color or the average intensity.
I've thought about having another Strategy style class called DescriptorCreator that the client would be responsible for setting up. If a ColorDescriptorCreator was provided, then the ColorDescriptorFunction would have everything it needs. But making the client responsible for getting this pairing correct seems like a bad idea.
Any thoughts/suggestions?
EDIT: In response to Tom's comments, a bit more information:
Essentially DescriptorFunction is comparing two pixels in an image. These comparisons can be done in many ways (besides just finding the absolute difference between the pixels themseles). For example 1) Compute the average of corresponding pixels in regions around the pixels (centered at the pixels). 2) Compute a fancier "descriptor" which typically produces a vector at each pixel and average the difference of the two vectors element-wise. 3) compare 3D points corresponding to the pixel locations in external data, etc etc.
I've run into two problems.
1) I don't want to compute everything inside the strategy (if the strategy just took the 2 pixels to compare as arguments) because then the strategy has to store lots of other data (the image, there is a mask involved describing some invalid regions, etc etc) and I don't think it should be responsible for that.
2) Some of these things are expensive to compute. I have to do this millions of times (the pixels being compared are always difference, but the features at each pixel do not change), so I don't want to compute any feature more than once. For example, consider the strategy function compares the fancy descriptors. In each iteration, one pixels is compared to all other pixels. This means in the second iteration, all of the features would have to be computed again, which is extremely redundant. This data needs to be stored somewhere that all of the strategies can access it - this is why I was trying to keep a vector in the main client.
Does this clarify the problem? Thanks for the help so far!
The first part sounds like a visitor pattern could be appropriate. A visitor can ignore any types it doesn't want to handle.
If they require more than one descriptor type, then it is a different abstraction entirely. Your description is somewhat vague, so it's hard to say exactly what to do. I suspect that you are over thinking it. I say that because generally choosing arguments for an algorithm is a high level concern.
I think the best advice is to try it out.
I would write each algorithm with the concrete arguments (or stubs if its well understood). Write code to translate the collection into the concrete arguments. If there is an abstraction to be made, it should be apparent while writing your translations. Writing a few choice helper functions for these translations is usually the bulk of the work.
Giving a concrete example of the descriptors and a few example declarations might give enough information to offer more guidance.
This is quite a long introduction to a simple question, but otherwise there will be questions of the type "Why do you want to handle void pointers in C++? You horrible person!". Which I'd rather (a)void. :)
I'm using an C library from which I intially retrieve a list of polygons which it will operate on. The function I use gives me an array of pointers (PolygonType**), from which I create a std::vector<MyPolyType> of my own polygon class MyPolyType. This is in turn used to create a boost::graph with node identifiers given by the index in the vector.
At a later time in execution, I want to calculate a path between two polygons. These polygons are given to me in form of two PolygonType*, but I want to find the corresponding nodes in my graph. I can find these if I know the index they had in the previous vector form.
Now, the question: The PolygonType struct has a void* to an "internal identifier" which it seems I cannot know the type of. I do know however that the pointer increases with a fixed step (120 bytes). And I know the value of the pointer, which would be the offset of the first object. Can I use this to calculate my index with (p-p0)/120, where p is the address of the Polygon I want to find, and p0 is the offset of the first polygon? I'd have to cast the adresses to ints, is this portable? (The application can be used on windows and linux)
You cannot substract two void pointers. The compiler will shout that it doesn't know the size. You must first cast them to char pointers (char*) and then substract them and then divide them by 120. If you are dead sure that your object's size is actually 120, then it is safe( though ugly) provided that p and p0 point to objects within the same array
I still don't understand why p0 is the offset? I'd say p is the address of your Polygon, and p0 is the address of the first polygon... Am I misunderstanding something?
Given that the pointer is pointing to an "internal identifier" I don't think you can make any assumptions about the actual values stored in it. If the pointer can point into the heap you may be just seeing one possible set of values and it will subtly (or obviously) break in the future.
Why not just create a one-time reverse mapping of PolygonType* -> index and use that?