next »

[Areku]

Spent most of today trying to fix intermittent but very noticeable timestep fluctuations.
After no success, decided to run the engine on a little winXP netbook I have lying around. It worked fine.

As it turns out, it's not that the timestep code is buggy, but that my laptop's CPU fan is fried and it was running at over 100C while I was testing, with the processor clock itself stuttering.

Well, it lasted for a good while without maintenance, I suppose.

[Eendhoorn]

Unity just turns every inherited type into it's base class in my list. I understand that the solution is to use components to add additional functionality, but I'm not going to do that for tiles, which might have thousands of instances

[ThemsAllTook]

As it turns out, it's not that the timestep code is buggy, but that my laptop's CPU fan is fried and it was running at over 100C while I was testing, with the processor clock itself stuttering.

That's amazing. Of all the possible things to go wrong, I never would have imagined that. I guess I usually expect hardware failures to break stuff in a more obvious and catastrophic way.

[InfiniteStateMachine]

yeah kudos on figuring that out. Hardware issues bwaaaar

[Areku]

Well, crap happens. Now it won't even turn on, but yesterday I managed to at least back up my files by opening the case up and holding a fan over the whole thing.

Oh, and the old netbook I tried the program on? Hard drive died this morning. The 1.8" ZIF model from 2009 didn't age well.

In other words, seems like the universe is trying really hard to tell me to code on a desktop.

[surt]

Grah! Blending when render to texture just wont work!  
Texture gots alpha. Blend, func, equation all set. Still just overwrites destination alpha.  

EDIT: Double grah! It looks like blending isn't supported for integer textures.

[KaynSD]

I'm making the fool mistake of starting a procedural infinite world generation system as a precursor to actually making a game. While I'm intending to do the final product in Unity, I started the prototype of the World-gen in Flash since I wanted to get the algorithm down pat first in a language I use on a daily basis since it's not exactly a routine undertaking. Throughout this process, my housemate tells me that it's probably a good idea just to do all my stuff in Unity to reacquaint myself with C#'s foibles (as well as to actually make a game demo first rather than teh kewlz procedural stuffs). I make the fool mistake of ignoring him.

Initial runs of the prototype looked good at least, according to this prototype, so I started porting it over to C#. Aside from getting annoyed with MonoDevelop's lousy handling of tab stops, and the much stricter requirements on semicolon placement I'm used to ignoring, the thing starts to compile nicely. But it starts to look a little deformed, and all the fancy region boundary code I'm making messes up

A few minutes later I come to the shockingly basic realisation that ActionScript treats X-Y as Left-Right, Top Bottom while Unity treats it's X-Z as Left-Right, Bottom-Top and all my square chunk building blocks for my map have their top borders flipped upside down. I spend half an hour trying to reverse it all, promptly miss half of them in a poorly commented, recently ported thousand line world gen prototype and literally have no idea which way is Up any more.

It created the beautiful failure I posted in that thread while I was half way through debugging it. My housemate has already given me the appropriate words of encouragement. Hunted down the last bastion of the thing throwing the reversing errors now (which was a custom Concat method I'd stupidly put inside the value object of the classes it was concatenating), but it's still been two solid evenings of tearing at my hair shouting "WHY DON'T YOU WORK ANY MORE!" to code that was previously giving me such pretty results...

[ProgramGamer]

I'm making the fool mistake of starting a procedural infinite world generation system as a precursor to actually making a game. While I'm intending to do the final product in Unity, I started the prototype of the World-gen in Flash since I wanted to get the algorithm down pat first in a language I use on a daily basis since it's not exactly a routine undertaking. Throughout this process, my housemate tells me that it's probably a good idea just to do all my stuff in Unity to reacquaint myself with C#'s foibles (as well as to actually make a game demo first rather than teh kewlz procedural stuffs). I make the fool mistake of ignoring him.

Initial runs of the prototype looked good at least, according to this prototype, so I started porting it over to C#. Aside from getting annoyed with MonoDevelop's lousy handling of tab stops, and the much stricter requirements on semicolon placement I'm used to ignoring, the thing starts to compile nicely. But it starts to look a little deformed, and all the fancy region boundary code I'm making messes up

A few minutes later I come to the shockingly basic realisation that ActionScript treats X-Y as Left-Right, Top Bottom while Unity treats it's X-Z as Left-Right, Bottom-Top and all my square chunk building blocks for my map have their top borders flipped upside down. I spend half an hour trying to reverse it all, promptly miss half of them in a poorly commented, recently ported thousand line world gen prototype and literally have no idea which way is Up any more.

It created the beautiful failure I posted in that thread while I was half way through debugging it. My housemate has already given me the appropriate words of encouragement. Hunted down the last bastion of the thing throwing the reversing errors now (which was a custom Concat method I'd stupidly put inside the value object of the classes it was concatenating), but it's still been two solid evenings of tearing at my hair shouting "WHY DON'T YOU WORK ANY MORE!" to code that was previously giving me such pretty results...

Never copy and paste anything with an x, y, z or w. Just don't. Not worth the hunt

I think these two quotes are appropriate together. And on the same thread at that.

[BorisTheBrave]

it's still been two solid evenings of tearing at my hair shouting "WHY DON'T YOU WORK ANY MORE!" to code that was previously giving me such pretty results...

Sounds like someone isn't using source control. You should. 'Nuff said.

[oahda]

Never copy and paste anything with an x, y, z or w. Just don't. Not worth the hunt

This happened to me just the other day. t-t

[KaynSD]

Sounds like someone isn't using source control. You should. 'Nuff said.

Version control is being used. It's more the fact the places where it was needing changes were numerous, myriad, and needed to all be changed simultaneously; and missing one scuppered the entire program. Religiously committing changes to Git ain't gonna help there

Never copy and paste anything with an x, y, z or w. Just don't. Not worth the hunt

It's pretty much just this.

[BorisTheBrave]

Version control is being used. It's more the fact the places where it was needing changes were numerous, myriad, and needed to all be changed simultaneously; and missing one scuppered the entire program. Religiously committing changes to Git ain't gonna help there

Alright, fair enough. One technique I sometimes do for wide semi-systematic is to deliberately rename member variables, so it is clear what is updated code and what is unchanged, and (ideally) so that the compiler will complain if I've left anything untouched.

[Schrompf]

Random findings from porting my game to Linux:

- GCC is remarkably slow. The Release build needs 45 minutes, where Visual Studio produces a comparably fast executable in under 2 minutes.
- Debug is not as bad, but still.
- QMake as a build system does not automatically consider statically linked libraries a dependency.
- OpenGL Nvidia drivers under Linux do not initialize video ram resources with zero, while both Direct3D9 and OpenGL NVidia drivers on Windows do.
- GCC reorders operations such as "*pointer++ = *pointer + *(pointer + offset);" to let the ++ happen somewhere inbetween, not at the end. And this is correct behaviour according to the specification.
- GCC has only one overload of abs(), namely int, while CLANG and Visual Studio also have abs(float) and abs(double). No warning on highest warn settings, it silently casted all floats to ints and broke half of my monster movements.
- GCC claims to support C++11, but its std::async() implementation seriously NEVER EXECUTES the given code if the code returns void.
- GDB with any frontend I tried is a horrible user experience, in comparision to Visual Studio debugger

To avoid sounding like a bitter old man, some positive at the end:

- valgrind is a really cool tool, once you learned how to read its reports.
- The OpenGL performance of the NVidia driver is as good as, if not even better than, the Windows counterpart.

[oahda]

I use std::abs and so on instead of just abs. From <cmath> rather than <math.h>. They're templated.

[Schrompf]

Yes, I replaced all with std::abs(). fabs() would have been ok, too.

[InfiniteStateMachine]

Random findings from porting my game to Linux:

- GCC is remarkably slow. The Release build needs 45 minutes, where Visual Studio produces a comparably fast executable in under 2 minutes.
- Debug is not as bad, but still.
- QMake as a build system does not automatically consider statically linked libraries a dependency.
- OpenGL Nvidia drivers under Linux do not initialize video ram resources with zero, while both Direct3D9 and OpenGL NVidia drivers on Windows do.
- GCC reorders operations such as "*pointer++ = *pointer + *(pointer + offset);" to let the ++ happen somewhere inbetween, not at the end. And this is correct behaviour according to the specification.
- GCC has only one overload of abs(), namely int, while CLANG and Visual Studio also have abs(float) and abs(double). No warning on highest warn settings, it silently casted all floats to ints and broke half of my monster movements.
- GCC claims to support C++11, but its std::async() implementation seriously NEVER EXECUTES the given code if the code returns void.
- GDB with any frontend I tried is a horrible user experience, in comparision to Visual Studio debugger

To avoid sounding like a bitter old man, some positive at the end:

- valgrind is a really cool tool, once you learned how to read its reports.
- The OpenGL performance of the NVidia driver is as good as, if not even better than, the Windows counterpart.

yikes 45 mins? That's crazy

[surt]

If you are building with make then make sure you've got a "-j number-of-processor-cores" in the parameters.

[powly]

- OpenGL Nvidia drivers under Linux do not initialize video ram resources with zero, while both Direct3D9 and OpenGL NVidia drivers on Windows do.

At least for teximage and bufferdata, the specification explicitly states that the values will be undefined so it might be a good idea in general to not rely on them being zero.

[Sik]

- GCC has only one overload of abs(), namely int, while CLANG and Visual Studio also have abs(float) and abs(double). No warning on highest warn settings, it silently casted all floats to ints and broke half of my monster movements.

Just to make it clear, this is the standard library, not GCC (the portion of the library that GCC includes is only the compiler-specific stuff, abs is provided by Linux's own library).

- valgrind is a really cool tool, once you learned how to read its reports.

In my experience, valgrind is a better debugger than the actual debugger... (no, seriously, it will nearly always pinpoint to the exact location where the program went awry)

[Schrompf]

- GCC is remarkably slow. The Release build needs 45 minutes, where Visual Studio produces a comparably fast executable in under 2 minutes.

yikes 45 mins? That's crazy

To be fair on that: I use Precompiled Headers heavily on Windows / Visual Studio. I tried to enable them in Linux / Qt Creator / QMake, too, but I didn't notice any change. Maybe I did something wrong. GCC is a bit slower, but not THAT bad.