openGL | Those are some of my openGL projects

You missed to set the alignment. By default OpenGL assumes that the start of each row of the raster is aligned to 4 bytes. This is because the GL_UNPACK_ALIGNMENT parameter by default is 4. Each row in the raster has 5 bytes (40 / 8 = 5). Therefore you need to change the alignment to 1:

One way to determine what section of your terrain should be culled is to use a quadtree (for a heightmap) or an octree (for a voxel map). Basically, you divide your terrain into little chunks that then get divided further accordingly. You can then test if these chunks are in your viewing frustum and cull them if necessary. This technique was already discussed in great detail:

• Efficient (and well explained) implementation of a Quadtree for 2D collision detection
• https://www.rastertek.com/tertut05.html
• https://gamedev.stackexchange.com/questions/15697/quadtree-terrain-splitting-i-dont-get-it

I saw some websites saying to use GL_DYNAMIC_DRAW instead of GL_STATIC_DRAW, but I did not understand it.

These are usage hints to OpenGL on how the data will be accessed so the implementation has the ability to apply certain optimizations on how to store/use it.

usage is a hint to the GL implementation as to how a buffer object's data store will be accessed. This enables the GL implementation to make more intelligent decisions that may significantly impact buffer object performance. (https://www.khronos.org/registry/OpenGL-Refpages/gl4/html/glBufferData.xhtml)

Please note that these are only indications, no restrictions:

It does not, however, constrain the actual usage of the data store.

Because you will likely update your VBO's and IBO's constantly (see culling) and only want to draw them GL_DYNAMIC_DRAW would be a good choice:

The data store contents will be modified repeatedly (because of culling) and used many times. The data store contents are modified by the application and used as the source for GL drawing and image specification commands.

as I have googled that it can affect the performance of the game

Well, it will cost some performance to cull your terrain but in the end, it will likely gain performance because many vertices (triangles) can be discarded. This performance gain may grow with larger terrains.

The cryptic error message is of little help, but the stack trace shows that the error occurs in the line:

Check your imports which are missing from that snippet. Also if you’re not enabling the enable-glwindow feature, you should, try changing your Cargo.toml to include the missing feature:

You must set glutDisplayFunc callback. The glut main loop invokes the display call back.

Minimal example:

Raster or bitmap fonts are represented in a number of different ways and there are bitmap font file standards that have been developed for both Linux and Windows. However raw data representation of bitmap fonts in programming language source code seems to vary depending on:

• the memory architecture of the target computer,
• the architecture and communication pathways to the display controller,
• character glyph height and width in pixels and
• the amount of memory for bitmap storage and what measures are taken to make that as small as possible.

A brief overview of bitmap fonts

A generic bitmap is a block of data in which individual bits are used to indicate a state of either on or off. One use of a bitmap is to store image data. Character glyphs can be created and stored as a collection of images, one for each character in the character set, so using a bitmap to encode and store each character image is a natural fit.

Bitmap fonts are bitmaps used to indicate how to display or print characters by turning on or off pixels or printing or not printing dots on a page. See Wikipedia Bitmap fonts

A bitmap font is one that stores each glyph as an array of pixels (that is, a bitmap). It is less commonly known as a raster font or a pixel font. Bitmap fonts are simply collections of raster images of glyphs. For each variant of the font, there is a complete set of glyph images, with each set containing an image for each character. For example, if a font has three sizes, and any combination of bold and italic, then there must be 12 complete sets of images.

A brief history of using bitmap fonts

The earliest user interface terminals such as teletype terminals used dot matrix printer mechanisms to print on rolls of paper. With the development of Cathode Ray Tube terminals bitmap fonts were readily transferable to that technology as dots of luminescence turned on and off by a scanning electron gun.

Earliest bitmap fonts were of a fixed height and width with the bitmap acting as a kind of stamp or pattern to print characters on the output medium, paper or display tube, with a fixed line height and a fixed line width such as the 80 columns and 24 lines of the DEC VT-100 terminal.

With increasing processing power, a more sophisticated typographical approach became available with vector fonts used to improve displayed text quality and provide improved scaling while also reducing memory required to describe the character glyphs.

In addition, while a matrix of dots or pixels worked fairly well for languages such as English, written languages with complex glyph forms were poorly served by bitmap fonts.

Representation of bitmap fonts in source code

There are a number of bitmap font file formats which provide a way to represent a bitmap font in a device independent description. For an example see Wikipedia topic - Glyph Bitmap Distribution Format

The Glyph Bitmap Distribution Format (BDF) by Adobe is a file format for storing bitmap fonts. The content takes the form of a text file intended to be human- and computer-readable. BDF is typically used in Unix X Window environments. It has largely been replaced by the PCF font format which is somewhat more efficient, and by scalable fonts such as OpenType and TrueType fonts.

Other bitmap standards such as XBM, Wikipedia topic - X BitMap, or XPM, Wikipedia topic - X PixMap, are source code components that describe bitmaps however many of these are not meant for bitmap fonts specifically but rather other graphical images such as icons, cursors, etc.

As bitmap fonts are an older format many times bitmap fonts are wrapped within another font standard such as TrueType in order to be compatible with the standard font subsystems of modern operating systems such as Linux and Windows.

However embedded systems that are running on the bare metal or using an RTOS will normally need the raw bitmap character image data in the form similar to the XBM format. See Encyclopedia of Graphics File Formats which has this example:

Following is an example of a 16x16 bitmap stored using both its X10 and X11 variations. Note that each array contains exactly the same data, but is stored using different data word types:

The sphere is clipped by the near and far plane of the viewing volume (Orthographic projection). Use glOrtho instead of gluOrtho2D and increase the distance to the near and far plane:

gluOrtho2D(-5.0, 5.0, -5.0, 5.0);

You can fix this by choosing your desired OpenGL version

You can achieve this by pressing F6, and on the right bottom corner there is a list, choose raylib_source_compile. And on line 4, choose the desired OpenGL version (GRAPHICS_API_OPENGL_33, GRAPHICS_API_OPENGL_21 and GRAPHICS_API_OPENGL_11) then press enter for it to recompile the Raylib library.

If it still doesnt work, go to C:\raylib\raylib\src\config.h, uncomment line 47 and recompile Raylib (which worked for me)

As the error message states: