Game appears fully black

[Martmists-GH]

When trying to run this, the application is simply black.

Context: OS: Arch Linux (up to date) Branch: master @ 82fe643f5b34f5ab0a3f414c331cdc3ba6b93e27 cmake: 3.12.3 compiler: /usr/bin/c++ (GNU 8.2.1) SFML: 2.5.0-2 GLM: 0.9.9.2-1

Hardware:

• Ryzen 5 1600
• 16G RAM DDR4
• Nvidia GTX 1050 Ti

In-Game Screenshot:

Method used to compile:

$ sudo pacman -S sfml glm
$ git clone ... && cd ...
$ cmake .
$ make

Output:

$ ./MCOneWeek
Config: Render Distance: 8
Config: Full screen mode: false
Config: Window Size: 1280 x 720
Config: Field of Vision: 105

============WELCOME TO MINECRAFT IN A WEEK============
This is a very simple Minecraft clone (mostly) created in one week

Because it was made in a week, some major features were missing:
-Level loading (Chunks do not save! So, I wouldn't commit to a build here for now)
-Caves
-Mobs
-Crafting

However, I did manage to implement some other important things:
-World generation
-Simple resource collection
-Biomes
-Collision detection
-Block breaking/ placing

For now, the game it pretty much entirely a community-driven project.
Source code can be found at https://github.com/Hopson97/MineCraft-One-Week-Challenge
Feel free to contribute!

Please view 'controls.txt for controls!

============Press enter to begin ============

Loading game...
Seed: 273621
making noise
Searching for spawn...
Spawn found! Attempts: 2 Time Taken: 0.030344 seconds

[Hopson97]

this is a known issue. The same happens for me when compiling on Ubuntu using the same settings as you, but it works on windows using MSVC as far as I know.

I might know why one day, but for now I do not :(

[EKashpersky]

Which platform the source code is originally written for?

[EKashpersky]

Haven't noticed sentence about windows, sorry. I fixed init of a matrix which contains Nan by default, unfortunately, it hasn't changed a lot.

[Eraden]

My output from GDB

Thread 2 "MCOneWeek" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffef644700 (LWP 13396)]
0x00005555555bf790 in std::_Hashtable<VectorXZ, std::pair<VectorXZ const, Chunk>, std::allocator<std::pair<VectorXZ const, Chunk> >, std::__detail::_Select1st, std::equal_to<VectorXZ>, std::hash<VectorXZ>, std::__detail::_Mod_range_hashing, std::__detail::_Default_ranged_hash, std::__detail::_Prime_rehash_policy, std::__detail::_Hashtable_traits<false, false, true> >::_M_bucket_index (this=0x0, __k=..., __c=0) at /usr/include/c++/7/bits/hashtable.h:631
631           { return __hash_code_base::_M_bucket_index(__k, __c, _M_bucket_count); }

[EKashpersky]

@Eraden I tried to figure out what is going on here a month ago, but I had not enough luck. BTW, it occurs from time to time, and I can't notice the pattern when it is crashed.

[Eraden]

Yes, this occurs here:

Chunk& ChunkManager::getChunk(int x, int z)

and stack is showing that it's directly related with void StatePlaying::handleInput() so I think this is when player clicked in non-existing chunk. I have feeling player was spawn in bad position.

There is guard which create chunk if it's not exists but for some reason this is not working.

[EKashpersky]

@Eraden Could you, please, write the file:line of guard you spoke about?

Thanks in advance.

[Eraden]

Source/World/Chunk/ChunkManager.cpp:18 (master)

Chunk& ChunkManager::getChunk(int x, int z)
{
    VectorXZ key {x, z};
    if (!chunkExistsAt(x, z))

This seems to help:

return m_chunks->emplace(key, Chunk(*m_world, {x, z})).first->second;

But screen is still black.

[Eraden]

I'm trying to dig to hearth of problem but code became much more complex than it was after first week of challenge and I didn't follow changes :/

[EKashpersky]

@Eraden it's like a month since I started the digging. Welcome to the club, bro :grinning:

[EKashpersky]

@Hopson97 @Eraden Well, I did manage to get some info.

Some important things:

• The coords are changed insanely fast. Something changes them every moment(it's not even 0.25sec);

• Grounded is changed hundred times per second;

• Y coord has strange value (I don't think it was designed to be that value);

• Z is always 0;

Any ideas?

[EKashpersky]

Strange, I've remade it with both cmake & make from the beginning(fresh sources) and now it's fine.

But Grounded is still changed some times per second.

[Hopson97]

Grounded tends to jump around when you are grounded, and only is "false" when in the air. idk why, but it is nothing to worry about

[EKashpersky]

@Hopson97 I understand, the thing is it's changed some times per second even if I don't press space.

[Hopson97]

Yes, but like I said that is nothing to worry about lol, it is just a side-effect of a quickly put together collision detection system for something quickly made :P

Regardless if you are grounded or not, I always switch to "not grounded" so the player can always fall in the event of walking off an edge or digging below themselves, but if there is a block it quickly switches back to true, hence it appears to quickly switch between the two when you are on the ground.

[Martmists-GH]

Sadly I don't have any debug text nor inventory visible, so my issue may lie somewhere else. I'll check with GDB later today.

[Eraden]

I also strongly suggest to avoid using std::map::operator[], it's not save. For example here: Source/World/Chunk/ChunkManager.cpp:23

Please use at instead.

[EKashpersky]

@martmists I believe it's same issue as mine and others people. Tried to comment glEnable(GL_BLEND), but it changes nothing for me.

[EKashpersky]

@Hopson97 well, me I have empty string at ChunkManager.cpp:23

Inside getChunk(), Just before return statement.

I'm on revision when you added cmake to the project.

[Hopson97]

the issue with .at is it has a slight performance hit (as far as I know) as it does bounds checking, hence [] + I make sure it can't go OOB as far as I remember (this was over a year ago now)

[Hopson97]

Windows version appears to run using WINE, but pressing F3 (to see the inventory and FPS etc) causes a crash

[Eraden]

And how [] does not check bounds? If entries does not exists it creates new. So it needs to check if something exists at this place :|

[EKashpersky]

I saw that after glGetUniforLocation is called, the variable which stores the result contains 2^32-1 instead of -1. Changed GLuint to GLint, still black screen. Digging...

[Eraden]

This is only for modelMatrix and only for shaders which does not have one. I found this yesterday and it's nothing important

[Eraden]

@EKashpersky On my PC

void ChunkRenderer::render(const Camera& camera)
{
    if (m_chunks.empty())
    {
        return;
    }

This is always empty

[Hopson97]

Oh good point, I was probably thinking of vector @Eraden

[EKashpersky]

@Eraden are you sure? It's empty for "first time" it's like one-two secs. I tried to put break after the if statement and it worked.

[Eraden]

I was waiting for ~1min and nothing.

[Eraden]

Also camera position is changing constantly by huge values. I seen changes for 4k or 8k each time ChunkRenderer::render was called.

Also player velocity is raising rapidly for y axis, for rest it's static. I think I'm spamming too much here so I'll write when I'll have something more interesting.

[Martmists-GH]

it seems I can move around just right (except grounded switches every frame or so) and my coordinates stay the same when I don't move. I'll see what I can find about the rendering.

[EKashpersky]

@martmists me I too. I believe everyone who has black screen also can move around. I can even dig sand/stone/dirt, you may force enabling info panel at PlayingState.cpp:97

Be sure you're using the latest master revision.

[Martmists-GH]

Able to do so. Inspection and additional logging of OpenGL methods didn't yield any useful results, possibly an issue with OpenGL itself? I'll look into rewriting under Vulkan and report back.

[EKashpersky]

@martmists it will take a bit more than 5 min...

[Martmists-GH]

I've got a couple weeks of spare time, don't worry about that.

[EKashpersky]

Tried with just openGL libs instead of glad loader, but it's same.

[EKashpersky]

@martmists @Eraden Well guys, I believe this one can be closed as we have merge request here: https://github.com/Hopson97/MineCraft-One-Week-Challenge/pull/123

I guess @Hopson97 just doesn't like to initialize variables :p

[Martmists-GH]

Neat, I'll close this issue and wait for it to be merged.

[Hopson97]

Ah that makes sense.

The library GLM used to, including at the time I created this project, default initialize variables. This was later changed for some dumb reason, I didn't think that would be the issue though.

Thanks!