nxPascal

[hwnd]

Ok and if i need to test / debug player sphere radius i just change the radius value for PointInSphere and thats same as changing player sphere radius? Im correct?

It tests for the sphere with specified radius. If i supply him radius 2, which is for ex. radius of the player sphere and this function will check that radius as if it was real sphere with that radius. I know im confuse things up but this is the way i understand it.

Anyways, thank you for the help. I will try.
But what about sliding / non sliding collision? I would like sliding more than sticking in wall.

[User137]

I did sliding collision on the FPS demo.
https://code.google.com/p/nxpascal/s...meUnit.pas#151
The physics part in that is 11 lines long loop. It takes use of TGLModel.FindNearest() which scans nearest wall point of all nearest polygons, and then the loop pushes player away from it. It is similar logic as in the walker demo, only applied in 3D space. (*Similar*, not *same* because this version is much more optimal and accurate).

change the radius value for PointInSphere and thats same as changing player sphere radius? Im correct?

Yes that sounds same.

[hwnd]

Sorry, forgot this FPS demo completely. Should have look it before.
Well, thats the coding / thinking in 4 AM when one should sleep.

Why 9(10) times loop?

Hmm, lots of good stuff there which i completely forgot. Bullets, weapon picking etc i could use.

[User137]

Sometimes when you find nearest point and push player at its level, it can still be inside some other wall, especially when it comes to corners. Normally it finishes the loop on 1 or 2 rounds at max (maybe 4 times in worst case, of hitting cubic room bottom or top corner), but it just does the collision work looped, so that it doesn't have to do that on next frame. It makes the collision look much smoother.

[hwnd]

I just executed the shader demo (GLSL test) on my pc and it works fine, but whats important is that CPU usage is 0 or between 1-2% if you move mouse a bit over the window.

So im wondering, is it possible for me to still make the map editor to use timer (DxTimer, threadedtimer) with "onidle" with interval 16-17ms or something but still somehow run it on same speed on every pc if i do for example camera movement, rotation, animation?

Like i said in old messages, before even discovering the nxpascal i used timer with interval 1, because i used some akward picking code that got too slow when timer interval was like 16-20, in tile painting mode the tiles appeared with big delay.
How the ray picking is affected on timer interval?

I dont know even if i said that correctly. Im not good with english.

Can i do same without actually using that game loop? Which eats CPU always, even if i dont do anything in editor.

I really would like CPU usage 0 rather than 20-30, i really dont like that. Tried to setframeinterval() to different values, still CPU usage is too high.

I really like how original editor sits on 0 always, until you do something (it can get really high) but when just nothing is done, it sits at 0. No lag or anything on other apps.

EDIT: also why you init stuff in OnPaint? Why not somewhere else (in own Init function, FormCreate or something) ? Any particular reason?

[SilverWarior]

EDIT: also why you init stuff in OnPaint? Why not somewhere else (in own Init function, FormCreate or something) ? Any particular reason?

Not sure for that example but I saw that many graphical engines contain necessary code for initialization in OnPaint routine.
In most cases this code is there to alow recovering from display device handle loss (switching between internal and dedicated GPU, VPU recover which might be caused by some error in shaders or due to hardware problems, etc.).

[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.