G.T.A.2 Map Editor

[hwnd]

Seems that i got it:
Here is the small pic (thanks to Greenshot and Paint.NET for neat features):


You see arrow and dotted lines. The dotted lines just show how the selectorblock looks like below (!) main map block(s) tiles.
If you could see through that (ER) tile below mouse cursor you could see one of the faces of the selectorblock (in this case BOTTOM face).

And the problem was, it "picked" or detected that face and didnt move selectorblock to the position where this white mouse cursor actually is.
Because it "picked" that bottom face, it "saw" that coordinates are same and didnt move it.

Now i used nxPascal picking demo pieces to actually make it work. I was thinking about distances and surprisingly it seems to work fine. Tried different angles and stuff..

          with intersect do
            d:=hypot3d(rayPos.x-x, rayPos.y-y, rayPos.z-z);
          if d < nearD then
          begin
            nearest:=i; nearD:=d;

I use value of "d". I take one "d" (D1) value from picking of main map blocks and second (D2) from the picking of selectorblocks.
So if D1 < D2 then cursor is probably on some side of the selectorblock and not on the top (LID face) of it. If D1=D2 then its on the top of the LID face.

I will do some more checks to really make sure it works in all cases.
Then i can continue with other stuff.

EDIT: I could just move selectorblock to the actual clicked position, no problem. But this way i cannot "pick" selectorblocks from any position (air or ground). This now works and the above stuff i explained seems to work.

2 weeks and finally, working solution. Again thanks to nxPascal. I couldnt do anything without it. Thank you User137!

[hwnd]

In original editor when you hold down Shift key and right mouse button at the same time and move your mouse either up and down or left and right then you can zoom camera in and out.

I move mouse up, camera zooming IN, i move mouse down, its zooming OUT.
Also if i move mouse to the left its zooming in and if i move to the right, its zooming out.

I tried to implement this in my editor but i dont understand how it calculates the zoom value according to mouse X,Y coords.
I can make it work for either up/down or left/right but not for the both of them.

Atm i can zoom in and out with mousewheel, but i would like to make it possible to zoom in / out without mousewheel also.
Because i cant say something like:

camera.z=camera.z-mousex
camera.z=camera.z-mousey

also tried this in MouseMove event:

Editor.ZTranslate:=(editor.mx-x-y);

Not good and not correct at all.
Any ideas? How hard it can be?

EDIT: Nvm, as usual, after posting question, the solution comes by "itself".
mouse.c code here helped me:
http://www.sgi.com/products/software...in32_tutorial/

ZOOM feature was unused, i tried it and it did exactly what i needed. Ported the mouse coord saving (oldmousex, mousemove, mousedown etc ) to my editor and it works.

How i found it? Googled for: zoom := zoom + mx; gltranslatef

[hwnd]

Whats the proper way to draw objects with vertex arrays?
Is it better to do this before every single object drawn:

    glEnableClientState(GL_VERTEX_ARRAY);
    glEnableClientState(GL_TEXTURE_COORD_ARRAY);
// draw my single object here
// gldrawarrays

   glDisableClientState(GL_VERTEX_ARRAY);
    glDisableClientState(GL_TEXTURE_COORD_ARRAY);

Or just do once this at the beginning of drawing every object (all objects)?

    

glEnableClientState(GL_VERTEX_ARRAY);
    glEnableClientState(GL_TEXTURE_COORD_ARRAY);
for i:=0 to num_objects do begin
// draw all my objects
// gldrawarrays
end;

   glDisableClientState(GL_VERTEX_ARRAY);
    glDisableClientState(GL_TEXTURE_COORD_ARRAY);

Whats the better (in performance) to do this?

Im currently using vertex arrays and not drawing that much of objects but still i get 25% CPU usage.
I dont know what causes this CPU usage.

I will try to pinpoint this of course in the meantime, but maybe the vertex array "order" is important.
Thats why i asked


EDIT: one thing i noticed, sometimes CPU usage is 25% sometimes 0.
In the same place of map.

I dont have any antivirus or something. But i do have enabled debug info and stuff.
I decreased visible range by 1, will see if that reduced the CPU usage.

[User137]

You should change the states just once in that code. All called gl commands slow program down if only a nanosecond, but if constantly repeated they can build up larger lag. But that doesn't seem to be reason for your fps issue, as i assume you already tried both ways?

[hwnd]

I actually tried "once" method. This seems faster i guess because i call these only once. I also dont see the point enabling/disabling them for every block.

But now i discovered that my vertex array version of DrawBlock eats up my RAM. And it gets very slow.
I will restore the DrawBlock from backup and will test if that removes the "memory eating". If yes, then i did something wrong (with sleepy head).

I thought its the map saving procedures that writes invalid map and when loaded damages memory somewhere etc. But the maps are binary equal to original editor maps.
Commented out "DrawBlock" and bug went away. So it is somewhere inside it.