Jump to content

  • Log In with Google      Sign In   
  • Create Account

Big Muscle

Member Since 13 Feb 2013
Offline Last Active Oct 25 2013 12:34 PM

Posts I've Made

In Topic: Optimize overlapping rectangles

17 October 2013 - 08:18 AM

If I describe a bit the original problem - I need to write a C++ function which receives an array of rectangles which do not overlap and look similary to the picture #2:



It is simply rectangular description of the geometry which results from subtraction of two overlapped rectangles. Overlapping can be arbitrary, the size of any rectangle can be arbitrary. I cannot influence the subtraction nor the format which I receive. My task is to inflate this geometry by some number and return it (in the same format - array of 0-4 rectangles). The problem is that returned (inflated) rectangles mustn't overlap - they can touch but not overlap.

In Topic: Optimize overlapping rectangles

16 October 2013 - 04:06 PM

I used A,B,C,D marks only to specify their order. If array contains e.g. 3 items only I cannot say whether it is ABC, BCD, ACD or ABD.

In Topic: Drawing surface plot in C++ using GDI

11 June 2013 - 09:17 AM

Weird, I can't sometimes log in to this forum properly...


Does LGPL allow distributing without the source code? If it does not then it is still not suitable...


However, I noticed that there are two important functions in MathGL - rotate and calcScr which seem to be enough to correctly render 3D plot via my own algorithm, i.e. calling calcScr on each of p0,p1,p2,p3 (mentioned above) and it seems to be much faster then using MathGL completely. Both function just do some matrix operations and point scaling.

In Topic: Drawing surface plot in C++ using GDI

06 June 2013 - 01:10 PM

Our goal was to make it as simple as possible. It does not have to be pure GDI but we should be able to achieve by GDI-like functions (i.e. DrawPolygon, FillPolygon etc.). I tried MathGL and it generates nice plot but its license (GPL) does not serve our purpose so it is probably unusable. Current 2D (bird eye) view is generated very simply as:

for(int i = 0; i < x.size() - 1; ++i)
  for(int j = 0; j < y.size() - 1; ++j)
   POINT points[4];
   p[0] = x[i], y[j];
   p[1] = x[i+1], y[j];
   p[2] = x[i+1], y[j+1];
   p[3] = x[i], y[j+1];

  Polygon(points, 4);


I was thinking about function Project(x, y, z) which is called for each p0, p1, p2, p3 and just transforms the coordinate to the screen_x and screen_y and Polygon function will draw this transformed points then. But my expectance was probably too simple to make it work this way. Or maybe only the implementation of Project function was incorrect and transformation was wrong? I don't have much experience in this so I just tried what I remember from school - multiplying vector (x,y,z,1) by rotation matrix and scaling "x" and "y" by "z".

In Topic: Resizing primitives in vertex buffer

17 March 2013 - 02:27 PM

Yeah, vertex layout is known. Draw is classic device->Draw. I have no problem to modify the vertex buffer. The only problem is how to correctly and fastly compute the new coordinates (the request is to add 8 pixels to each edge of rendered primitive).