nxPascal

[hwnd]

Real flat tiles is ok for now. I just want to test some of my ideas.
2D is (almost) always simpler to start with.
If i cant make 2D to work, there is no point for me to try 3D.
Thanks.

I will let you know if i will work out something.

[hwnd]

Let's say i have two cones in the scene and one of them must point to another cone.
And it should do this smoothly ( i mean turning ).

If i understand it correctly i need a way to find angle (difference) or something between 2 points (X,Y) and then rotate until one cone is pointed "looking" at (to) another cone. I must somehow align one vector to another.

Is there any command that makes these things easier?

[User137]

In the unit nxMath, 2 overloaded versions of Angle():

  function Angle(const px1,py1,px2,py2: single): single; overload;
  function Angle(srcRadian, destRadian: single): single; overload;

First one finds angle from source point to target point, and the other function tells which way to turn.

PS. You could use Skype/MSN chat for these small questions too.

[User137]

I figured how i could combine 2 things i have wanted, firstly making a FPS game demo. And secondly generating some or all textures to it on the fly, and loading them in using new data pointer. I still have no real tool for 3D animation so i'm going to have to use my old Edit3D and frame animation, if needed. I expect no less from the demo, than being able to run around on a triangle map with collisions, and bullets leaving particles on the walls. Could try some collectibles and interactable objects such as door button.

[hwnd]

Wow, that demo would be awesome.
I think you have read my mind with this. I had a plan to do something similar.
Actually porting one C++ fps tutorial code to nxPascal.

Go ahead, you can do it better. Hopefully you will not use a lot of shaders.
I personally don't like them.

Your Edit3D allows to do frame animation?

BTW, thanks for the tip above.

[User137]

With the old Edit3D it's possible to first create for example humanoid, and then copy/paste it multiple times. Then move vertices to make it seem like animation. Frame animation is much simpler than joints, and i have used that some year ago. Difficult to say its current status. Interpolated rendering functions seem to exist, and W3D loading automatically loads and fills the frame array for TTriModel, by quick glance.

Created quick and dirty level screenshot

And added first ingame screen. Now it's pretty safe to say that model loading could use some tweaking... Either way, moving without collision, jumping and aiming works. Laser sight on the rifle looks also pretty cool, it's large dot on close wall, and tiny dot at distant. And that gun there is rotating and floating, rendered after a glowing sprite which turns towards camera.

edit2: Collisions finally working right. Custom made "physics simulation" sort of. Gravity is constantly affecting the character, and he is pushed away from nearest wall point, be it floor most of the time. This makes it possible to simply walk on top of that pile of rocks, or in other terms you could climb stairs with this. I can't wait to give you a video out, but there's still more things to do.

[hwnd]

Interesting way for collisions. Ok gravity for floors but for walls, never heard about this. Interesting.
Will wait for the video.

[SilverWarior]

Gravity is constantly affecting the character, and he is pushed away from nearest wall point, be it floor most of the time.

Wouldn't this mean that when you are on the slope you would also be pushed back at the same time and not only up? Wouldn't this prevent you from standing on the slope?

[User137]

Yes it kind of does, player slides down slowly. Now it's good enough to publish a video. I also released it on SVN, both Lazarus and Delphi demos:

Collisions, sounds, pickable objects (player starts without weapon), jump, crouch. Pretty happy for 1 day's work

That texture bug still bothers though. It is not renderer's fault, it's just that my W3D format saves unique texture indices per face vertex. nxModel loader attempts to merge and group mainly based on smoothing groups. The texture coordinates are sort of right, some of them should just duplicate the vertices, to use the unique texture coords. The way these textures repeat in my world model makes it calculate them wrong. It really won't be easy to fix i think.

edit: Well, i uncommented some older code and the texture bug was gone with it. I'll keep it that way but hope that other issues won't rise by it.

[SilverWarior]

Nice work. You made all this just in one day?