nxPascal

[hwnd]

Ok, good point.

Now i have found my old editor sources which use glLoadName methods for picking and TTimer with interval of 2ms for drawing map. I have 0 CPU most of the time, and goes up to 20-60 maybe when drawing something or rotating or something else.
Of course 1-2 is too quick and standard ttimer cant even handle that properly but if i will use threadedtimer with interval 16-17 for example, dunno if that will make ray picking slower? I guess not.

Again, why i have timer with 2ms (ie. drawing map each 2ms) its because of the picking method i use and because of the "tile painting" in my editor. User can "paint" tiles on terrain. If i set timer to 20-30ms then this picking and drawing gets very slow. The painted tiles will appear with very big delay on terrain and may even not appear at all. Because if user moves mouse too fast then it cant even catch all these coordinates so quickly because low timer interval.

This is how i did things before (~2007-~2011) i found nxPascal.

Im talking about the old editor from my backups.
The current one uses game loop but eats cpu always, even if its minimized or not active at all.

Dunno how it would be with TTimer or threadedtimer with interval of 30ms and ray picking from nxPascal.
I have to test.

[SilverWarior]

You should split the drawing code and picking code into two sections.
Drawing code gets executed every 16-17 ms. No need to execute it more often as your monitor is probably not able to render more frames per second which means that anything beyond that is just waste of computational power.
But picking code gets executed more often to alow smoth pickings.

I disadvise you from using standard TTimer as it relies on Windows messages. This means it has great of achieveing smal tme intervals (lers than 5 ms) and it would probably have ocasional problems even when dealing with higher time intervals (ocasional delays which could reach even to 1s).

[hwnd]

I just typed long text into here on my Android phone and it just restarted for unknown reason. I hate that.
Ok starting over.

I will use ThreadedTimer or similar. Atm i have Draw function which has the ray picking code at the beginning, actual drawing code in the middle and SwapBuffers at the end.

But how i could split them? Use another timer for picking and set its interval to something like 5-6ms?
While main drawing timer will be 16-17ms?

I will have to try. It would be really nice to have rendering code use 0 cpu most of the time and at the same time picking to be smooth.

Btw, yesterday i quickly copy pasted together small test opengl app with raypicking and thdtimer, rendering was 0% and when i moved mouse around and did a ray picking very often (timer interval) cpu usage didnt even go up.
Seems that ray picking is so fast.
There is also small optimization, before even checking triangles it checks if ray even collided with bounding sphere of the object, if not it will not even check the object.

While with Opengl name stack it goes up significantly.

[hwnd]

Ok, i tried with thdtimer and Application.OnIdle := Idle;
It works in both. Speed seems fine but i dont understand why the picking has offset to the left when at the right i must move mouse cursor almost to the center of the tile for it to disappear. Down seems also bad. Especially when moving mouse slowly i can see how it almost goes to the center of the tile and then tile disappears.

When i move to the left, tile disappears even without touching it. Very big offset. same with UP.

Strange. I have to drink some coffee, maybe im sleepy. Just woke up.

[User137]

You can use onMouseMove event on form for the tile-painting, then it doesn't matter if you are using 16+ interval. Actually that could be the reason for high cpu use in the first place. Game template-based programs run same speed on all machines, but it's important that you put game mechanics into GameLoop, and rendering into Rendering procedure. If you would mix game mechanics with rendering code, frameskipping could mess up the sync.

Also keep in mind that you have another thread specifically for the GTA editor, this is about the engine alone.