Advertisement Jump to content
  • Advertisement


  • Content Count

  • Joined

  • Last visited

Community Reputation

7097 Excellent

About Juliean

  • Rank

Personal Information

Recent Profile Visitors

30513 profile views
  1. You can try to compile with _ITERATOR_DEBUG_LEVEL set to 0 (or 1), ie. /D_ITERATOR_DEBUG_LEVEL=0 This is one of the main reasons why MSVC can be abysmally slow in debug config, and while certainly handy, iterator debugging is not required in most cases.
  2. No, obviously, employees for a large-scale company never work 9 to 5 jobs, only hobbyists are capable of doing that. That what they call Separation of Duties. While say, 250 people were doing mundean research tasks, the other 750 can still be productive. And you are going to be prototyping, changing and tweaking as well, no? Unity is no quarantee for anything. Its capable, but its not gonna do the work for you. Its also a constraint in and off itself - working professionally in a company that uses Unity for > 5 years, we all agree that its both a blessing and a curse.. and will definately limit you there and again, as well as cost you time on its own; especially the more you move from "indie game" to "AAA".
  3. According to his portfolio, he did 21 games within 11 years, none of which even comes close to being AAA. You want to do 28 in less than 5 years, with "many" being AAA quality. And thats why they are not even remotely close to "professional quality". AAA/professional games shine with being polished, large in scale, with a certain look and feel to them that screams "yep, this was made by professionals". None of the games you referenced is remotely close to that (which doesn't mean they are bad in any way). ;TL;DR; you are claiming you want to make AAA-quality games, but disregard every bit of AAA aspect on the way. Good luck on your journey.
  4. Its bad practice if not only for the fact that you can and should use std::unique_ptr instead of new/delete 99,999% of the time. In destructors, it would be not only unncessary but also helping in hiding criticial errors created by multiple deletions.
  5. Juliean

    use class

    You're trying to assing something to the class-type "FontHandle". MichaelNS::FontHandle handle = m.drawString(FontInfo_t, color, 1600, 660, 1, "FPLN\n");
  6. Juliean

    Running x86 build crashes

    Its part of the Windows SDK, so you should probably have it installed already. Otherwise, here is a direct download: I can't give you the technical reason, sorry. Had it happen multiple times similarly to what you describe though. Alright, then thats out of the way.
  7. Juliean

    Running x86 build crashes

    Did you really make sure thats the exact line where the data is corrupt? You should make sure that its valid every step of the way (ie. before the method is called) until that very line. If thats really sure and with: Eigther you do have any kind of memory corruption at a firmer point as I suggested, then the only thing you can do is figure that one out. As an alternative possible explanation, did you try a full clean-build & recompile? Seeing as this is a template method, if you modified it somewhere along the lines, there's some issue in VS2017 that sometimes won't recompile the template-method properly. It will then procceed to use some older variant of the code, while showing you the variables and all, possibly resulting in the random garbage you get to see. I had stuff like this happen multiple time in template-heavy code, which was fixed by a recompile. Otherwise, use Application Verifier on your programm (just turn it on for the exe and then run the debugger with Basics->Heaps checked). Does this result in a crash/break at some other point in the code?
  8. Also, some notes for improval on this very method: std::vector<SDL_Rect*> ObstacleManager::getCollisionRectVector() { std::vector<SDL_Rect*> collisionRects; collisionRects.reserve(m_Pillars.size()); // #1 for(auto* pillar : m_Pillars) // #2 { collisionRects.push_back(pillar->getCollisionRect()); } return collisionRects; } #1: You should always call reserve on a vector if you know how many elements you are going to put in, since otherwise you'll have unnecessary allocations/copies. Its a great optimization with little overhead if applied globally. #2: If possible, you should use this "range-based for loop" style over manual index-counting (C++11 required). Its less to type/easier to read and harder to mess up.
  9. Juliean

    Running x86 build crashes

    Not sure if thats already been suggested or tested, but this totally sounds like a memory-misaccess happening at some earlier point, resulting at a crash later with a corrupted call stack. Try the usual tools for finding heap-corruptions (ie. microsoft application verifier) or turn on the debug pageheap ( if all else fails.
  10. Juliean

    Win32 Clang c++98 vs c++11

    The standard int-types in stdint.h are an C++11 feature. If you want to use them for C++98, you have to define them yourself. What is the value of __cplusplus? You should be able to view/output it to see whats going wrong. Even so, it seems that clang rather uses a check for each indivdual feature instead (
  11. Juliean

    Running x86 build crashes

    Did you check the call stack that is shown with your minidump? That seems to point to a very concrete location, and should probably allow you to spot the error (which seems to relate to eigther vector pushback or your ModelPart-move-ctor).
  12. Juliean

    Nested namespaces useless typing?

    Note that in C++17, there is a feature actually called "nested namespaces", which can make such code way easier to read/write: // might be worth a discussion if this is actually better when there are multiple nested namespaces in one file namespace my::paths { const char *ExtractFileName(const char *path); namespace my::strings { size_t GetAnsiStringLength(const char *str); }; // could instead look like this: namespace my { namespace system::io::path { const char *ExtractFileName(const char *path); }; namespace strings { size_t GetAnsiLength(const char *str); }; }; They are also a better alternative for "smurf naming convention". I worked at a project where every class was prefixed with proj_module_nested_ ... you could argue that this is already an iditiotic naming scheme, but in multi-million line projects, its important to be able to quickly see to which module a certain method/class belongs. I'd actually prefer IO::Paths::GetHome() etc... I tend to group my global methods in a static class instead of a namespace, so I'm just used to seeing multiple levels of nested :: without a problem. I also tend to not using namespace, but instead put all implementations in their respective namespace as well: namespace my::strings { const char* something(const char* path) { IO::Paths::GetHomePath(); // my is implicitely available, as well as my::strings. } } But thats just my sense, in case you want to get some different ideas.
  13. Juliean


    Appearently it ensures COMDAT-folding:
  14. Ah, I didn't even notice the alloca. This perfectly explains whats happening here, and I'm even wondering that the compiler isn't optimizing it more aggressively than it already is. Lets recap what you are telling the compiler here: 1: You want some memory off the stack. Unlike _malloca or equivalents, alloca will always be stack based, so the compiler can be sure about that. 2: You are returning a pointer to this memory, which is only valid inside this function. So that tells the compiler that the return-statement, while being able to return the current pointer of the allocation as-is would be valid, the caller of the function would then point to invalid memory, so this should be undefined behaviour. 3: Furthermore, you are not using the destBuffer outside of strncpy-ing to it in the end. Since the compiler can assume that the value of destBuffer is not going to be used after strncpy for return being undefined behaviour, I belive it can optimize it away (at least thats the case for memcpy, so don't hang me if I'm wrong about that). 4. So that means that the compiler is left with an allocation that is literally unused, which means it can probably just remove it (though from what you describe thats not happening, so maybe it is pretenting to allocate, but just generates the address that the allocation would be at, so that i can return *something* at the end?) So maybe thats whats already happening (hard to tell w/o the assembly), but a compiler could just turn that whole code into: If(destBuf != nullptr) // execute function code; return destBuf; else // do nothing return WHATEVER_VALUE. // probably eigther garbage or a pointer along the stack where the allocation would start I'm no expert on compilers but I'm pretty sure thats exactly whats happening. The compiler usually is not allowed to alter the visible behaviour of the program, unless you are, as in your case, relying on undefined behaviour - so the lesson is, never invoke undefined behaviour
  15. In your original code, "destLen" isn't used outside of assignment and the assert though, so the compiler will totally optimize that away. It should still enter the branch and assign the destBuffer though, are you sure that didn't happen as well?
  • Advertisement

Important Information

By using, you agree to our community Guidelines, Terms of Use, and Privacy Policy. is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!