• Advertisement
  • Popular Tags

  • Popular Now

  • Advertisement
  • Similar Content

    • By fleissi
      Hey guys!

      I'm new here and I recently started developing my own rendering engine. It's open source, based on OpenGL/DirectX and C++.
      The full source code is hosted on github:
      https://github.com/fleissna/flyEngine

      I would appreciate if people with experience in game development / engine desgin could take a look at my source code. I'm looking for honest, constructive criticism on how to improve the engine.
      I'm currently writing my master's thesis in computer science and in the recent year I've gone through all the basics about graphics programming, learned DirectX and OpenGL, read some articles on Nvidia GPU Gems, read books and integrated some of this stuff step by step into the engine.

      I know about the basics, but I feel like there is some missing link that I didn't get yet to merge all those little pieces together.

      Features I have so far:
      - Dynamic shader generation based on material properties
      - Dynamic sorting of meshes to be renderd based on shader and material
      - Rendering large amounts of static meshes
      - Hierarchical culling (detail + view frustum)
      - Limited support for dynamic (i.e. moving) meshes
      - Normal, Parallax and Relief Mapping implementations
      - Wind animations based on vertex displacement
      - A very basic integration of the Bullet physics engine
      - Procedural Grass generation
      - Some post processing effects (Depth of Field, Light Volumes, Screen Space Reflections, God Rays)
      - Caching mechanisms for textures, shaders, materials and meshes

      Features I would like to have:
      - Global illumination methods
      - Scalable physics
      - Occlusion culling
      - A nice procedural terrain generator
      - Scripting
      - Level Editing
      - Sound system
      - Optimization techniques

      Books I have so far:
      - Real-Time Rendering Third Edition
      - 3D Game Programming with DirectX 11
      - Vulkan Cookbook (not started yet)

      I hope you guys can take a look at my source code and if you're really motivated, feel free to contribute :-)
      There are some videos on youtube that demonstrate some of the features:
      Procedural grass on the GPU
      Procedural Terrain Engine
      Quadtree detail and view frustum culling

      The long term goal is to turn this into a commercial game engine. I'm aware that this is a very ambitious goal, but I'm sure it's possible if you work hard for it.

      Bye,

      Phil
    • By tj8146
      I have attached my project in a .zip file if you wish to run it for yourself.
      I am making a simple 2d top-down game and I am trying to run my code to see if my window creation is working and to see if my timer is also working with it. Every time I run it though I get errors. And when I fix those errors, more come, then the same errors keep appearing. I end up just going round in circles.  Is there anyone who could help with this? 
       
      Errors when I build my code:
      1>Renderer.cpp 1>c:\users\documents\opengl\game\game\renderer.h(15): error C2039: 'string': is not a member of 'std' 1>c:\program files (x86)\windows kits\10\include\10.0.16299.0\ucrt\stddef.h(18): note: see declaration of 'std' 1>c:\users\documents\opengl\game\game\renderer.h(15): error C2061: syntax error: identifier 'string' 1>c:\users\documents\opengl\game\game\renderer.cpp(28): error C2511: 'bool Game::Rendering::initialize(int,int,bool,std::string)': overloaded member function not found in 'Game::Rendering' 1>c:\users\documents\opengl\game\game\renderer.h(9): note: see declaration of 'Game::Rendering' 1>c:\users\documents\opengl\game\game\renderer.cpp(35): error C2597: illegal reference to non-static member 'Game::Rendering::window' 1>c:\users\documents\opengl\game\game\renderer.cpp(36): error C2597: illegal reference to non-static member 'Game::Rendering::window' 1>c:\users\documents\opengl\game\game\renderer.cpp(43): error C2597: illegal reference to non-static member 'Game::Rendering::window' 1>Done building project "Game.vcxproj" -- FAILED. ========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========  
       
      Renderer.cpp
      #include <GL/glew.h> #include <GLFW/glfw3.h> #include "Renderer.h" #include "Timer.h" #include <iostream> namespace Game { GLFWwindow* window; /* Initialize the library */ Rendering::Rendering() { mClock = new Clock; } Rendering::~Rendering() { shutdown(); } bool Rendering::initialize(uint width, uint height, bool fullscreen, std::string window_title) { if (!glfwInit()) { return -1; } /* Create a windowed mode window and its OpenGL context */ window = glfwCreateWindow(640, 480, "Hello World", NULL, NULL); if (!window) { glfwTerminate(); return -1; } /* Make the window's context current */ glfwMakeContextCurrent(window); glViewport(0, 0, (GLsizei)width, (GLsizei)height); glOrtho(0, (GLsizei)width, (GLsizei)height, 0, 1, -1); glMatrixMode(GL_PROJECTION); glLoadIdentity(); glfwSwapInterval(1); glEnable(GL_SMOOTH); glEnable(GL_DEPTH_TEST); glEnable(GL_BLEND); glDepthFunc(GL_LEQUAL); glHint(GL_PERSPECTIVE_CORRECTION_HINT, GL_NICEST); glEnable(GL_TEXTURE_2D); glLoadIdentity(); return true; } bool Rendering::render() { /* Loop until the user closes the window */ if (!glfwWindowShouldClose(window)) return false; /* Render here */ mClock->reset(); glfwPollEvents(); if (mClock->step()) { glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT); glfwSwapBuffers(window); mClock->update(); } return true; } void Rendering::shutdown() { glfwDestroyWindow(window); glfwTerminate(); } GLFWwindow* Rendering::getCurrentWindow() { return window; } } Renderer.h
      #pragma once namespace Game { class Clock; class Rendering { public: Rendering(); ~Rendering(); bool initialize(uint width, uint height, bool fullscreen, std::string window_title = "Rendering window"); void shutdown(); bool render(); GLFWwindow* getCurrentWindow(); private: GLFWwindow * window; Clock* mClock; }; } Timer.cpp
      #include <GL/glew.h> #include <GLFW/glfw3.h> #include <time.h> #include "Timer.h" namespace Game { Clock::Clock() : mTicksPerSecond(50), mSkipTics(1000 / mTicksPerSecond), mMaxFrameSkip(10), mLoops(0) { mLastTick = tick(); } Clock::~Clock() { } bool Clock::step() { if (tick() > mLastTick && mLoops < mMaxFrameSkip) return true; return false; } void Clock::reset() { mLoops = 0; } void Clock::update() { mLastTick += mSkipTics; mLoops++; } clock_t Clock::tick() { return clock(); } } TImer.h
      #pragma once #include "Common.h" namespace Game { class Clock { public: Clock(); ~Clock(); void update(); bool step(); void reset(); clock_t tick(); private: uint mTicksPerSecond; ufloat mSkipTics; uint mMaxFrameSkip; uint mLoops; uint mLastTick; }; } Common.h
      #pragma once #include <cstdio> #include <cstdlib> #include <ctime> #include <cstring> #include <cmath> #include <iostream> namespace Game { typedef unsigned char uchar; typedef unsigned short ushort; typedef unsigned int uint; typedef unsigned long ulong; typedef float ufloat; }  
      Game.zip
    • By oranssi
      This is an adult psychedelic fighting game with spirits of the natural elements. 
      Choose your character to represent an anthropomorphic version of the different elements. 
      Earth, fire, air, water and more. There are 28 Archelemental spirits to unlock. 
      Take on challenges to earn more goodies such as sexy content, story modes and even make your own Archelemental to play and to share it with others.
      Download here :
      https://oranssi.itch.io/archelementals-of-eiss

      Trailer :
      https://www.youtube.com/watch?v=SmBNu_dPN_Y

    • By oranssi
      This is an adult psychedelic fighting game with spirits of the natural elements. 
      Choose your character to represent an anthropomorphic version of the different elements. 
      Earth, fire, air, water and more. There are 28 Archelemental spirits to unlock. 
      Take on challenges to earn more goodies such as sexy content, story modes and even make your own Archelemental to play and to share it with others.
      Download here :
      https://oranssi.itch.io/archelementals-of-eiss

      Trailer :
      https://www.youtube.com/watch?v=SmBNu_dPN_Y

    • By Ricardo3Ddev
      Hi guys!
      This is a independent game being produced by me and my brother. We’ve been working on it for about 6 months and we’ve already done a good part of the game. We hope to finalize and make it available on Steam by the end of this year.
      We are using Blender 3D and Gimp software for production.
       
      About the Game: Dongo Adventure will be a 3D platform style game, where the main character (Dongo) is a mouse that ventures through various scenarios (sewers, culverts, streets, electric grid, etc.) and faces several enemies along the way (cockroaches, mosquitoes, spiders, toxic gases, electrical wires, etc.). He carries a basket / backpack with cheeses that he uses to throw and defend himself from enemies, as well as being able to push objects that helps him to overcome obstacles. The ultimate goal will be a surprise!
       
      Now we are developing new scenarios and enemies. We hope to publish news soon...
      Game page on Steam: http://store.steampowered.com/app/811450/Dongo_Adventure/ - (Teaser UPDATED)
      Dongo Adventure - Indie Game Project (First Teaser) https://www.youtube.com/watch?v=X2nmxtkE0xk
       
      Thanks for following the project!

  • Advertisement
  • Advertisement
Sign in to follow this  

C++ How to check the peak stack size of all thread in a process.

Recommended Posts

Hi, guys!

             My prograss crashs with a stackoverflow exception in some pcs.  I changed the stacksize of thread from default(1M) to (2M) for fixing this problem. But  I have got confused with some doubts.

1、Why this exception happens in some pcs not all?  I think the logic is the same ,so the stack used must be identified too.

2、Why the default stack size is 1M? Just for saving the memory of process or have some other reasons?

3、Can there any tools or methods for me to find the logic where using so much stack?

Share this post


Link to post
Share on other sites
Advertisement

1 - Normal stack size is around 4mb if I recall correctly, but that doesn't mean it can't be deviated from, hence you sometimes get a crash (though someone more knowledgeable on this may know of other reasons). Also if you're not sure if the stack is the same, there lies an explanation as well, you should compare the actual data on the stack, because this may be a cause as well. If it's not the exact same playthrough, this is more likely the reason I'd say.

2. 1 mb is kind of a safe bet to start out with and afaik will be the minimum supported by (modern) CPU's. 

3 - Just take a look at the stack. You can attach a debugger like visual studio or just run it in that environment in the first place (after all, you're hitting it pretty consistently). Once it hits any exception, it should break and you can view the current stack. Such high stack usage is quite worrisome. It can indicate a high amount of recursion (i.e. a function calling itself), with the stop condition perhaps being incorrect (pretty common), large stack allocations such as by large arrays or simply huge objects (but I'd consider this less likely) and even less likely, you can have a lot of indirection, but I'd consider that it's very unlikely you will hit stack limit by just regular function calls, especially in release.

Regardless, having to increase the default stack size is something I'd definitely not consider a decent solution at all, so you should definitely look into the cause

Share this post


Link to post
Share on other sites

The default stack size on Windows is 1MB.

1. The stack size doesn't change on different computers. Maybe some people don't use the feature that consumes lots of stack space, or its stack consumption depends on the input data? 64-bit code will also consume more stack space than 32-bit.

2. Windows supports any stack size that will fit in RAM. You can change it in the linker settings, or as a parameter when creating a thread. I guess 1MB is a reasonable trade off between how much space the program gets to use, and the memory that's consumed by creating a thread, but if you have different requirements you can change it. Also if your stack is too big buggy recursive functions could take a long time before they fail with a stack overflow.

3. When it's crashed in the debugger add the esp (or rsp for x64) register to the watch window. That's the stack pointer, and you can watch it change as you move up and down the call stack in the debugger. Looking at how much it changes by will tell you how much stack is used. Alternatively just look at the size of the local variables in each function on the call stack until you find the big ones - you can use sizeof(variableName) in the watch window to see how big something is.

Edited by Adam_42

Share this post


Link to post
Share on other sites

Thanks ,you guys give me some inspire, I will try it.

13 hours ago, Adam_42 said:

The default stack size on Windows is 1MB.

1. The stack size doesn't change on different computers. Maybe some people don't use the feature that consumes lots of stack space, or its stack consumption depends on the input data? 64-bit code will also consume more stack space than 32-bit.

2. Windows supports any stack size that will fit in RAM. You can change it in the linker settings, or as a parameter when creating a thread. I guess 1MB is a reasonable trade off between how much space the program gets to use, and the memory that's consumed by creating a thread, but if you have different requirements you can change it. Also if your stack is too big buggy recursive functions could take a long time before they fail with a stack overflow.

3. When it's crashed in the debugger add the esp (or rsp for x64) register to the watch window. That's the stack pointer, and you can watch it change as you move up and down the call stack in the debugger. Looking at how much it changes by will tell you how much stack is used. Alternatively just look at the size of the local variables in each function on the call stack until you find the big ones - you can use sizeof(variableName) in the watch window to see how big something is.

 

On 2017/6/26 at 5:11 PM, AthosVG said:

1 - Normal stack size is around 4mb if I recall correctly, but that doesn't mean it can't be deviated from, hence you sometimes get a crash (though someone more knowledgeable on this may know of other reasons). Also if you're not sure if the stack is the same, there lies an explanation as well, you should compare the actual data on the stack, because this may be a cause as well. If it's not the exact same playthrough, this is more likely the reason I'd say.

2. 1 mb is kind of a safe bet to start out with and afaik will be the minimum supported by (modern) CPU's. 

3 - Just take a look at the stack. You can attach a debugger like visual studio or just run it in that environment in the first place (after all, you're hitting it pretty consistently). Once it hits any exception, it should break and you can view the current stack. Such high stack usage is quite worrisome. It can indicate a high amount of recursion (i.e. a function calling itself), with the stop condition perhaps being incorrect (pretty common), large stack allocations such as by large arrays or simply huge objects (but I'd consider this less likely) and even less likely, you can have a lot of indirection, but I'd consider that it's very unlikely you will hit stack limit by just regular function calls, especially in release.

Regardless, having to increase the default stack size is something I'd definitely not consider a decent solution at all, so you should definitely look into the cause

 

Just now, laiyierjiangsu said:

Thanks ,you guys give me some inspire, I will try it.

 

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this  

  • Advertisement