Jump to content

Canardia

Developers
  • Posts

    4,127
  • Joined

  • Last visited

Blog Comments posted by Canardia

  1. I came up with a new idea for this editor: an realtime interpreter which rewrites the running game code each time a change occurs in the input text. This way you could see in realtime how your game looks.

    The running game would not be recompiled with C++ but it reads the input text from memory, disk or even over network. Multiple people could watch as you remotely write the code.

    • Like 1
  2. If you do a google search on "how to debug games", the first answer is this:

    http://en.wikipedia.org/wiki/Debug_menu

     

    There are some really nice benefits of using a in-game debug menu:

    1) You can debug the game even with rarely occuring bugs, when the remote user sends you a screenshot of the menu (or presses some button to send the error report to you).

    2) You have the same debug menu on every platform, and don't need to setup complicated debuggers for mobile and other platforms.

    3) You can be sure that you are debugging the same code which caused the error, and not some debug compiled version which lacks usually of all compiler optimizations and other settings which often prevent the bug to occur.

  3. I wouldn't say so, because that's what most game developers do: they add a debug hug (which actually was also in LE2 built-in into Framewerk), so they can see the behaviour of different variables in difference scenarios and over longer time. Can't do that by looking at single-step debug code.

  4. I haven't had any problems using a Notify() (SDL_MessageBox) function in GNU C++ as debugging too. Usually debug code behaves differently then release code (often debug code does not show the error at all), so there is no point debugging something different than what is having the problem.

  5. If possible, I would add some estimated time frames for each version also. They can be rough, like Q2/2013. Also I would add a future version block, which lists all the ideas which might be implemented, but are not confirmed yet, like version 3.3+.

     

    For example Voxel->Mesh terrain should be implemented in some future version, because 2.5D terrains are a bit obsolete. Or maybe have some completely new approach: CSG terrain?

  6. That's why I suggested also to use cpufloat and gpufloat typedefs, so you can use maximum accuracy and speed where it's possible: cpufloat would be double, and gpufloat would be float by default, but you could change it to double when 64-bit gpus come out.

  7. You should have used own types for everything, like:

    typedef const float& constfloatref;

    That's what basically every C++ library does too.

     

    However, int& and float& are still better than copying the value, because if your original value changes, it is also reflected in the function. By copying you have to manually set the new value to each function which copied it.

  8. There is no excuse in good programming practice to not use a faster method when it is as easy to implement as a slow method. When systems grow bigger, all the little speed differences will exponentially sum of, when one function is calling another function multiple times per loop.

  9. The problem with putting functions which are not connected to the context, except that they use the current context, is that when a user makes multiple contexts, then for example context3->DrawImage() will still draw to context1, if it's the current context. Of course you could fix this by doing a context3->Activate() if it's not the current context, but that will make things slower, because a if() check is slower than a integer assignment.

    • Upvote 1
  10. I think I can make LE3 much faster, when I even find lots of things to optimize in those samples.

     

    For example:

    ++x instead of x++ uses CPU registers to speed up a lot (however mingw and vs already does this optimization themselves)

    4*(y+x*texture->GetWidth()) instead (constants make a big speed different when placed in front, loop variables closer to loop statement allow registers

    if(y<128)if(x<128) same here, loop variables closer to loop to utilize registers

     

    In most places it won't matter much, if there are no big loops. But when there are big loops, like going through all vertices of a scene, then it might make some notifiable difference.

×
×
  • Create New...