PureBasic Forums - English

I'm incredibly short on time these days, but I will take a peek later. Creating tools is important, you will spend more time with these than with the actual game

Does the shader code runs faster, if I change this downwards? For simpler models, where theres only 1-2 weighted bones? (I assume the answer is yes)

I find this project interesting, I'm following your posts.

For 6.21 sprites:
InitSprite()
InitKeyboard()
InitMouse()

OpenWindow(0,0,0,500,100,"SPH_Entertainment",#PB_Window_ScreenCentered);|#PB_Window_SystemMenu)
OpenWindowedScreen(WindowID(0),0,0,500,100,1,0,0)

CreateSprite(0,40,40,#PB_Sprite_AlphaBlending)
StartDrawing(SpriteOutput(0))
DrawingMode(#PB ...

This should be fixed for cases used with the #PB_Engine3D_Adjusted parameter.

But I'm not sure, that the new meshid will correspond to existing entitites. Positioning 1000 individual vertices should be fast even with every loop. (If thats the main feature you will show on screen)

1 big mesh with 1 texture is probably better than a lot of small ones. It depends on a lot of things. Selecting what to hide and what to show with best performance can be done with a data structure that is called quadtree. (Octree if 3D, but a topview game can be considered as a 2d field I think ...

aerial perspective (false isometric) perspective to limit view zone
Still has some similarity, not the camera collide is the one I find hard. For example, the camera is centered at the player character.
It can take into account the facing for example, to show more what is in the front, and show ...

Looks solid, as always. I will follow the improvements on this project. (you choosed the camera type (TPS) that is hardest to do well, so I'm interested in seeing your future solutions. But there are many other.)

I'm not sure, how would I do this. If I understand well, you want to animate the springs. With UpdateMesh(), you can move the vertices to a new position.
(that will update all entities using that mesh.) If different moving parts are made as different submeshes, you can update those parts even ...

Its an offset for the arrowsprite to put it a little bit to the right and down compared to the middle of the boxsprite. Seemed better that way. If you change *0.75 to *1.75, the transformation will be more visible. Though not necessary.

(Also the sprite creation method in that code is not 6.21 ...

I think I have a good description:

You have a sprite, and have a \x \y as position coordinates. You always draw the sprites there, and do not manipulate the values directly.
You have a \targetx and \targety as coordinates of a point. You want to move the sprite toward this position. You only change ...

@pfshadoko:
Regarding the normals, I was testing with a bad normal map. That caused the artifacts at the edges and not your shader code.

Don't mention it, your welcome. I'm glad if I was able to help a little. I'm learning also with these.

There is no main mesh. A mesh is composed of submeshes, and it has at least 1. All the 31 item is a submesh in your model. Some of them are textured, some of them are not. (but they have color in their mesh data, and they are visible. Those just do not need a textured material.)

The material name ...