MineCraft-One-Week-Challenge icon indicating copy to clipboard operation
MineCraft-One-Week-Challenge copied to clipboard

Lagging bad on high end hardware

Open larch13 opened this issue 5 years ago • 22 comments

so I have finally got this to work with visual studio but when I run it, it completely freezes every time it loads a chunk and lags and stutters really bad even though I have good hardware

my specs OS: Windows 10 Home 64bit Processor: Intel I7 8700k 6 core @ 3.7GHZ GPU: Geforce RTX 2070 8G RAM: 16G DDR4 dual channel

larch13 avatar Jul 03 '19 17:07 larch13

It tends to lag for a bit on startup, but once the world has loaded it should be ok. Also make sure you are running via the release build and not in debugging mode.

Hopson97 avatar Jul 03 '19 17:07 Hopson97

i had left it running for a good five minutes and it still lagged bad

larch13 avatar Jul 03 '19 17:07 larch13

oh just realized you told me to be in release and i realised i was in debug but thats because running it release visual studio gives me errors

larch13 avatar Jul 03 '19 17:07 larch13

image this is what i get

larch13 avatar Jul 03 '19 17:07 larch13

That is an interesting error :thinking: I'll look into that, I do not have this issue on Ubuntu.

For now, you could simply comment out the of this function I believe, and it should still work, you just won't have a skybox.

Hopson97 avatar Jul 03 '19 18:07 Hopson97

when i comment this out i get this image

larch13 avatar Jul 03 '19 18:07 larch13

Ok maybe uncomment :smile:

Try commenting these line:

https://github.com/Hopson97/MineCraft-One-Week-Challenge/blob/ad6c101b38b6fab6a518b3098956caef864d7bd8/Source/Renderer/RenderMaster.h#L32

https://github.com/Hopson97/MineCraft-One-Week-Challenge/blob/ad6c101b38b6fab6a518b3098956caef864d7bd8/Source/Renderer/RenderMaster.cpp#L52

This should make the skybox code not ever run, supposedly """fixing"""" the crash as a temporary work around for this issue

Hopson97 avatar Jul 03 '19 18:07 Hopson97

shit i just commented out all the sky box lines

larch13 avatar Jul 03 '19 18:07 larch13

now im getting the same error with the texture atles

larch13 avatar Jul 03 '19 18:07 larch13

do you have a discord?

larch13 avatar Jul 03 '19 18:07 larch13

I'm really confused, it seems you cannot access any of files?

Hopson97 avatar Jul 03 '19 18:07 Hopson97

https://discord.gg/DeEhUXY

Hopson97 avatar Jul 03 '19 18:07 Hopson97

ok can you add me so we can work this out

larch13 avatar Jul 03 '19 18:07 larch13

Join the server and you'll find a bunch of people willing to help

Hopson97 avatar Jul 03 '19 18:07 Hopson97

damn i was hopeing i could talk to you

larch13 avatar Jul 03 '19 18:07 larch13

i have a video idea for you though, its Minecraft in i millisecond and then its just a macro typing all the code

larch13 avatar Jul 03 '19 18:07 larch13

I'll happily continue to help on the server, but for now I am sure what the issue is (It is not a code issue, it seems to be a visual studio or windows issue), but other people on the server might have an idea of what the issue is, and how to resolve it

Hopson97 avatar Jul 03 '19 18:07 Hopson97

thats what i was thinking

larch13 avatar Jul 03 '19 18:07 larch13

Will you be joining the server?

Hopson97 avatar Jul 03 '19 19:07 Hopson97

im in the server

larch13 avatar Jul 03 '19 20:07 larch13

Hi, I'm not really sure about this but I've played with a similar project on Visual Studio 2019. By similar I mean I use SFML, GLSL, glad, glm and cmake. I figured out the cmake cache often get mad in VS2019 and it causes stranged/undefined behavior on some memory allocation/desallocation when running the debugger. The error you had when loading your texture is exactly that, I had it too. Try to right click on the CMakeLists.txt "top" file then ->Cmake Cache -> Delete the cache. But it's not enough : shutdown VS2019 then delete the out/build folder if you didn't changed the VS default target folder. Launch VS2019 and try again, it should works like a charm ! I do this every time I add or remove a new source file in the project, or when you change some header (that might change the "link process" too). As an example, it happened to me to have an exception on a std::vector destructor which is normally defined as "noexcept".

Maghin avatar Aug 24 '19 08:08 Maghin

Did anyone ever manage to get this to work? Also the code has been rewritten in a way that compiling it shouldn't be as big of a problem now.

Please let people know if the problem is solved, this issue is a few years old now.

DreamHollow avatar Jun 01 '23 19:06 DreamHollow