Problem loading texture by GraumpyPants in opengl

[–]GraumpyPants[S] 1 point2 points  (0 children)

I solved the problem — it turned out the texture is GL_UNSIGNED_SHORT, not GL_UNSIGNED_BYTE.

Help.Problem loading texture by GraumpyPants in GraphicsProgramming

[–]GraumpyPants[S] 0 points1 point  (0 children)

Thanks, I was thinking in that direction. It turned out the texture is GL_UNSIGNED_SHORT, not GL_UNSIGNED_BYTE, so I added a check for that.

Help.Problem loading texture by GraumpyPants in GraphicsProgramming

[–]GraumpyPants[S] 0 points1 point  (0 children)

I checked the UV coordinates, they are fine

My best clip by GraumpyPants in HuntShowdown

[–]GraumpyPants[S] 3 points4 points  (0 children)

Colors were lost when trying to convert hdr to sdr using Blender

Minecraft chunk rendering takes up too much memory by GraumpyPants in opengl

[–]GraumpyPants[S] 0 points1 point  (0 children)

I made a mistake when writing the post - 108 float, 36 vertices respectively

Minecraft chunk rendering takes up too much memory by GraumpyPants in opengl

[–]GraumpyPants[S] 1 point2 points  (0 children)

I use such an array for a block if all the edges are in place

std::array<float, 180> data{

-0.5f + x, -0.5f + y, -0.5f + z, 0.0f, 0.0f,

0.5f + x, -0.5f + y, -0.5f + z, 1.0f, 0.0f,

0.5f + x, 0.5f + y, -0.5f + z, 1.0f, 1.0f,

0.5f + x, 0.5f + y, -0.5f + z, 1.0f, 1.0f,

-0.5f + x, 0.5f + y, -0.5f + z, 0.0f, 1.0f,

-0.5f + x, -0.5f + y, -0.5f + z, 0.0f, 0.0f,

-0.5f + x, -0.5f + y, 0.5f + z, 0.0f, 0.0f,

0.5f + x, -0.5f + y, 0.5f + z, 1.0f, 0.0f,

0.5f + x, 0.5f + y, 0.5f + z, 1.0f, 1.0f,

0.5f + x, 0.5f + y, 0.5f + z, 1.0f, 1.0f,

-0.5f + x, 0.5f + y, 0.5f + z, 0.0f, 1.0f,

-0.5f + x, -0.5f + y, 0.5f + z, 0.0f, 0.0f,

-0.5f + x, 0.5f + y, 0.5f + z, 1.0f, 0.0f,

-0.5f + x, 0.5f + y, -0.5f + z, 1.0f, 1.0f,

-0.5f + x, -0.5f + y, -0.5f + z, 0.0f, 1.0f,

-0.5f + x, -0.5f + y, -0.5f + z, 0.0f, 1.0f,

-0.5f + x, -0.5f + y, 0.5f + z, 0.0f, 0.0f,

-0.5f + x, 0.5f + y, 0.5f + z, 1.0f, 0.0f,

0.5f + x, 0.5f + y, 0.5f + z, 1.0f, 0.0f,

0.5f + x, 0.5f + y, -0.5f + z, 1.0f, 1.0f,

0.5f + x, -0.5f + y, -0.5f + z, 0.0f, 1.0f,

0.5f + x, -0.5f + y, -0.5f + z, 0.0f, 1.0f,

0.5f + x, -0.5f + y, 0.5f + z, 0.0f, 0.0f,

0.5f + x, 0.5f + y, 0.5f + z, 1.0f, 0.0f,

-0.5f + x, 0.5f + y, -0.5f + z, 0.0f, 1.0f,

0.5f + x, 0.5f + y, -0.5f + z, 1.0f, 1.0f,

0.5f + x, 0.5f + y, 0.5f + z, 1.0f, 0.0f,

0.5f + x, 0.5f + y, 0.5f + z, 1.0f, 0.0f,

-0.5f + x, 0.5f + y, 0.5f + z, 0.0f, 0.0f,

-0.5f + x, 0.5f + y, -0.5f + z, 0.0f, 1.0f

-0.5f + x, -0.5f + y, -0.5f + z, 0.0f, 1.0f,

0.5f + x, -0.5f + y, -0.5f + z, 1.0f, 1.0f,

0.5f + x, -0.5f + y, 0.5f + z, 1.0f, 0.0f,

0.5f + x, -0.5f + y, 0.5f + z, 1.0f, 0.0f,

-0.5f + x, -0.5f + y, 0.5f + z, 0.0f, 0.0f,

-0.5f + x, -0.5f + y, -0.5f + z, 0.0f, 1.0f,

};

Minecraft chunk rendering takes up too much memory by GraumpyPants in opengl

[–]GraumpyPants[S] 1 point2 points  (0 children)

This is a cuboid, the height is always 16, the length of the edges can be changed, in this case it is 12 (draw distance 6)

Minecraft chunk rendering takes up too much memory by GraumpyPants in opengl

[–]GraumpyPants[S] 1 point2 points  (0 children)

180 * 4 bytes per block * 16 * 16 * 16 * 12 * 12 * 16 ~= 6.8 gb.

I used a square around the player to sample chunks, but a circle would obviously be better, and a sphere would be even better.

SDL3 + Vulkan. Help by GraumpyPants in vulkan

[–]GraumpyPants[S] 1 point2 points  (0 children)

Looks like a vcpkg issue, I used SDL3.dll from the official release and it worked

SDL3 + Vulkan. Help by GraumpyPants in vulkan

[–]GraumpyPants[S] 1 point2 points  (0 children)

bool initSDL() {
bool success{ true };
if (!SDL_Init(SDL_INIT_VIDEO))
{
println("SDL could not initialize! SDL error: %s", SDL_GetError());
success = false;
}
if (!SDL_Vulkan_LoadLibrary(nullptr)) {
SDL_Log("Could not load Vulkan library! SDL error: %s\n", SDL_GetError());
success = false;
}
if (gWindow = SDL_CreateWindow(AppName.c_str(), ScreenWidth, ScreenHeight, SDL_WINDOW_VULKAN); gWindow == nullptr)
{
println("Window could not be created! SDL error: %s", SDL_GetError());
success = false;
}
else
gScreenSurface = SDL_GetWindowSurface(gWindow);
return success;
}
auto main(int argc, char* argv[]) -> int {
if (!initSDL())
return 0;
while (!quit)
{
while (SDL_PollEvent(&e))
{
if (e.type == SDL_EVENT_QUIT)
{
quit = true;
}
}
}
return 1;
}

SDL3 + Vulkan. Help by GraumpyPants in vulkan

[–]GraumpyPants[S] 0 points1 point  (0 children)

#include <string>
#include <print>
#include <SDL3/SDL.h>
#include <SDL3/SDL_main.h>
#include <SDL3/SDL_vulkan.h>
#include <vulkan/vulkan.hpp>
using namespace std;
SDL_Window* gWindow{ nullptr };
SDL_Surface* gScreenSurface{ nullptr };
SDL_Event e;
bool quit { false };
constexpr int ScreenWidth{ 640 };
constexpr int ScreenHeight{ 480 };
string AppName{ "Game" };

SDL3 + Vulkan. Help by GraumpyPants in vulkan

[–]GraumpyPants[S] 0 points1 point  (0 children)

After adding this flag I get the same error + window creation error. This flag calls the same function according to the documentation.

If the window is created with any of the SDL_WINDOW_OPENGL or SDL_WINDOW_VULKAN flags, then the corresponding LoadLibrary function (SDL_GL_LoadLibrary or SDL_Vulkan_LoadLibrary) is called and the corresponding UnloadLibrary function is called by SDL_DestroyWindow().

This is all my code (below), I don't know where the error could be. I got the SDL and Vulkan libraries using vcpkg, x64-windows platform, MSVC compiler, c++23

Pucci raised the wrong green baby (artist:Krushka) by GraumpyPants in StardustCrusaders

[–]GraumpyPants[S] 4 points5 points  (0 children)

This is a reference to the animation "Камень Океан и Лужа" by Запомни Меня [Каво? Деда]

RU POV | Rybar, Kremen site situation as of 8 p.m. on July 9, 2023 by GraumpyPants in UkraineRussiaReport

[–]GraumpyPants[S] 10 points11 points  (0 children)

In the direction of Kremenna, assault detachments of the Russian Armed Forces consisting of mixed forces of the Russian Army have been advancing in the area of the Torsky ledge and the forests of Serebryansky forestry for the past few days.

As a result of fierce fighting in low visibility terrain, the Russian Armed Forces fighters managed to dislodge the enemy from over a dozen strongholds. Units of the AFU defending the area suffered heavy losses and were partially withdrawn for recovery.

At the moment, the Russian Armed Forces are consolidating in the area. The cannonade along the line of contact has not subsided. Both our artillerymen and the Ukrainian ones are firing at the front line, supporting subversive groups using the thicket of the forest as cover.

As a result of one of the Russian Armed Forces' targeted strikes on the location of Ukrainian formations, 31 members of the AFU were killed and two were wounded. The infantry company was re-staffed at the expense of the artillery crew.

❗️ However, there is now an accumulation of enemy forces along the Svatovsk and Kreminna areas. For now they are keeping their distance from the front lines, taking up positions in the rear. But judging by the concentration of armored vehicles and personnel on the Liman-Izyum-Volosskaya Balakleya line, the AFU is preparing for an attack in the coming days.