nxPascal

[User137]

Hmm.. it is fixed for both of you now i guess. Left texture files as NPOT but used tex.Options:=[toFitScale];
JC_'s notice was little different. It is not permanent framerate loss for me even if i moved window, but it piled up frametime to execute fast. I changed physics timing logic slightly and added new feature to game handler, SetMaxTick() which is now 100 by default. It depends on application i guess, if it's necessary to execute all lost ticks. But now it can be reverted with SetMaxTick(0) to ignore it.
edit: On my computer this version is drawing over 1500 walkers without slowdown at 60+ fps. They squeeze way out of the screen

[SilverWarior]

On my Acer Aspire 6530g laptop I'm getting between 20-30 fps with about 1500 walkers.
Moving window does cause temporary framerate (longer the time I use for moving windows langer tha framerate drop).
I also noticed that you don't handle window resizing so whole sceene simply gets stretched which could lead to image distortion as the asect ratio isn't maintained.

[hwnd]

Works fine now.
626 walkers, 26FPS.

Should be more on my PC, how is the collision made? Some intelligent stuff or just basic stuff?
They seem to avoid each other like peds in GTA_2. Although in GTA_2 they step back a bit if they collide with each other.
But your demo is almost same.

[User137]

Yeah, nxPascal doesn't have real physics engine at the moment, so i made them "manually", using my little knowledge of physics. First lets take a look at the source code, as i finally got the shaders working and uploaded all to SVN. (I was sending array index to glUniform, when i should have sent index variable from that array's data... That's the point of using GLint type where header types are wanted, i just missed it.)

https://code.google.com/p/nxpascal/s...meUnit.pas#114
The program runs in single thread for simplicity. It gets vector that is from 1 walker position to other, and then pushes them both away from eachother by amount that is half of movement speed. Then sets function result true, meaning that collision happened. Main program will then check if there's time to count it again and runs the physics again and again until there are no collisions, or the 10ms that was allocated to each frame has elapsed.

I know i could've used syntax like:
position:=position+v;
... for vector math. But operator overloading is not Delphi 5-7 compatible, so i don't use them in the demos or engine internals.

edit: I added both versions, shader and non-shader to dropbox link too. Shader version is unsurprisingly slower because of increasing amount of GL program changes as walker amount goes higher. The demo uses 6 different programs per frame, changing frequently.
(It doesn't mean shaders are bad, the opposite. They're just not meant to be changed that much )

[azrael11]

Runs great to me...
The Walkers_shader.exe demo with 1000 wallkers shows me 33 fps... in
An old Pentium 4 3Ghz with 1Gb ram...

Great good work...


Thank you...

[hwnd]

Azrael, you call that old? I wish i had PC with such specs.

User137. Thanks, tried shader version, just throws me access violations at 00000000 constantly.
But nevermind, its a old laptop here and i will try how it runs on my home PC (which is not near me atm).
Home PC supported shader 2.0 if i remember correctly.

I will have to take some shader tutorial one day and start to experiment with them.

[azrael11]

Azrael, you call that old? I wish i had PC with such specs.

Compare to the quad core Ivy Bridge with 16 gb rams and latest graphic cards....
I think is bit old...

But i like it...

Thank you...

[SilverWarior]

Compare to the quad core Ivy Bridge with 16 gb rams and latest graphic cards....
I think is bit old...

Based on the fact that many games still doesn't support multithreading (most Indie games doesn't) having i5 or i7 processor doesn't guarantee you perfect performance in those games.
Infact I know of several games which actually, due to being single threaded, perform worse on some i5 and i7 processors than on some older Pentium4 or single cored Athlons.
Why is that? That is becouse the processing power of the single core of a multicored processor is sometimes lower than the processing power of some older singlecore processor.

[hwnd]

What was the reason to not to add sphere-plane (plain, polygon) collision to nxPascal?

I want to use it for collision and ofc i have working C++ code that i will convert to Delphi, but anyway?

[User137]

You can do sphere-plane collision with nxPascal. I'll explain the math using nxMath3D:

function RayPlaneIntersect(const rayOrigin, rayDirection,
  planeOrigin, planeNormal: TVector; intersection: PVector): single;

First imagine that the sphere casts a ray directly towards the plane. rayDirection is inverse of planeNormal (or we could use equal too, it might not matter). If function result is >= 0, we get value stored in intersection vector. This means nearest point on the plane towards sphere's center.

Next we need to check if distance between intersection point and sphere is smaller than sphere radius. For that we could use Hypot3D(), but unless you plan to do something with the distance (such as manual physics), it may do more than you need. For simplicity's sake, you could place sphere back to where it was before collision. So instead of Hypot3D(), it will be faster to use PointInSphere():

function PointInSphere(const p,sphere: TVector; const radius: single): boolean;

PointInSphere is a truncated Hypot3D() without sqrt() call, and only tells if it collides or not.

Finally assuming that the sphere is moving in some direction, it will bounce off to other direction from the plane.

function Reflect(const rayStart, rayDir, wallPoint: TVector): TVector;

RayStart = Sphere current position.
RayDir = Sphere movement direction.
wallPoint = Plane intersection point calculated above.
Function gives as a result the new movement direction for sphere.