Molehill 2D study 2

The molehill2d study, which had been put on hold for half a month, was restarted because today, while studying 3D, we found that there was a problem with the previous approach.

After understanding this problem, starm2d is much less efficient than bitmap rendering.

 

 

Context3d. setvertexbufferat (0, vertexbuffer, 0, context3dvertexbufferformat. float_3 );

Context3d. setvertexbufferat (1, vertexbuffer, 3, context3dvertexbufferformat. float_2 );

 

Context3d. setprogramconstantsfrommatrix (context3dprogramtype. vertex, 0, matrix, true );

 

The focus is simply as follows:

The previous practice was to execute vertexbuffer. uploadfromvector (vertices, 0, 4) every time the render was executed );

Vertices is calculated based on coordinates. At present, it seems that the problem with this practice is that the actually displayed vertex coordinates are calculated by the CPU, so the efficiency is very low.

The current practice is that vertexbuffer is saved. Generally, vertexbuffer. uploadfromvector (vertices, 0, 4) is executed only once after the first creation );

All coordinate transformations are processed using a corresponding matrix. Therefore, when you render, you only need to pass in the saved vertexbuffer and the corresponding matrix.

 

Let's look at the abnormal efficiency:

 

25*25 = 625 frames of animation simultaneously displayed

625*2 = 1250 triangles displayed simultaneously

About 30 stable Frame Rate

 

It is far more efficient than the previous bitmap rendering method.

 

With this efficiency, the idea of continuing starm2d burst instantly.

The next step is to gradually implement other functions along the path of the bitmap rendering engine.

 

From various aspects, the development of the molehill2d engine is much simpler than that of the molehill3d engine, and the development time is much shorter.

Therefore, the research on molehill3d was put on hold in May to achieve a molehill2d engine with complete basic functions!