Page 11 of 13 FirstFirst ... 910111213 LastLast
Results 101 to 110 of 121

Thread: G.T.A.2 Map Editor

  1. #101
    EDIT: Nvm, got it working it seems. Was looking over my code, thinked a bit and removed one line: pnlRenderMouseMove(Sender, [ssLeft], X, Y);
    from MouseDown.. event. Because it messed up some things and i just now discovered that i actually implemented better thing in MouseDown.

    Basically calling "pnlRenderMouseMove" even in MouseDown was needed for selectionboxes to clean up, so after single click anywhere on map there will be only one selectorbox.

    Strike that all.
    Working on this thing again after very long break.
    I have some problems with selectorboxes. It basically works, but it picks the objects behind the selectorboxes.
    It probably has to do with objects Z ordering or something.

    It goes through the selectorobjects and picks the tiles behind it.
    I can detect the coordinates of the picked selectorbox cube and face of it but for some reason it goes through the selectorboxes. I tried to "pick" them first (by moving code for picking on the top of the code for picking map cubes) and then actual map cubes but it didnt change anything.

    I tried to set glDepthMask(FALSE); and true, nothing changed. Just worse.

    Im doing the picking like in nxPascal picking demo. Spheres at specific position, if ray touches spheres i loop through selector vertex coords.

    Any ideas what should i try? So if ray hits the selectorboxes it will not go behind them.
    Here is pic with arrow, behind the arrow it picks the map cubes (the blue / yellow ones). But it shouldn't.

    Last edited by hwnd; 08-03-2014 at 09:20 PM.

  2. #102
    I did find in some apps that calling mousemove in mousedown is acceptable solution. But it has to be last line of the MouseDown event, and you would change it to
    pnlRenderMouseMove(Sender, Shift, X, Y);
    But you got it working without it so i would not suggest re-adding

  3. #103
    Ok, but still i have problems with selectorblocks.
    I have some ideas why it goes through the main tiles, probably because of that selectorblocks "spheres" and map blocks "spheres" that i use for picking are in same place.

    I can detect if selectorblock is under mouse and when its not, but its not enough. I guess i have to check if selectorblocks are the first ones under mouse or are they "lower".
    Some kind of Z sorting is needed or something.

    Im not sure.

  4. #104
    How about splitting picking code into two stages:
    1. You do checking to see if your mouse is over selectorblock (only checking those sphere that are used for detecting selecboxes. If your mouse is over selectorblock you end here else you go to second stage. In order to achieve better optimizatio you may add aditional logic check to see if secetor block colision is even needed (depending on your editor implementation you probably won't need this at all times) if not you simply skip to second stage.
    2. Here you do checking to see above which map cell is your mouse.

  5. #105
    Well if you look at this that way then its already is 2 stage. Well kinda...

    One piece of code is picking map blocks and second below it is picking selector blocks.
    Its just copy/ paste of picking code with slight modifications for selector blocks.

    I dont know if you meant that but if not then i should try it. Have to think a bit.
    Its almost perfectly working atm but just 1 (ok in worst case 2) problem(s) still exist.

    I will devote more time to this today, maybe whole night and will try different things.

  6. #106
    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
                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!
    Last edited by hwnd; 14-03-2014 at 10:16 PM.

  7. #107
    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:
    also tried this in MouseMove event:
    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:

    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
    Last edited by hwnd; 21-03-2014 at 11:17 PM.

  8. #108
    Whats the proper way to draw objects with vertex arrays?
    Is it better to do this before every single object drawn:
    // draw my single object here
    // gldrawarrays
    Or just do once this at the beginning of drawing every object (all objects)?
    for i:=0 to num_objects do begin
    // draw all my objects
    // gldrawarrays

    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.
    Last edited by hwnd; 03-05-2014 at 05:06 PM.

  9. #109
    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?

  10. #110
    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.

Page 11 of 13 FirstFirst ... 910111213 LastLast

Tags for this Thread


Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts