Jump to content

Canardian

Members
  • Content Count

    4,033
  • Joined

  • Last visited

Blog Comments posted by Canardian


  1. I think the user should only debug his own game code related bugs, and rest assured that the engine is bug free smile.png

     

    Yes, for engine level debugging such LLVM debugger is better than gdb, but that's what unit tests are invented for also.


  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.


  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.


  11. Heck, it must be good enough, because even huge professional companies like Yamaha deliver their electronic documentations as PDF, they do it for example for their Music Workstations, and I'm quite happy with Foxit Reader: fast browsing and searching, convenient page layouts and zooming, and bookmarks. And the printed books in several languages which come with the Workstations are exactly the same as the PDFs.


  12. My approach would be to get the game testable and playable as first priority. The assets and game logic can be very simple in the first release, but it's important that you get people to try and and give feedback, because they help you getting things right, so you don't waste any time on doing things wrong for long time, and then have to undo everything.

     

    The people might even offer you some assets when they see what kind of game it is, and what kind of assets would fit in.

     

    Start with versioin 0.0.0.0, then raise the 4th last number for every bug fix, and the 3rd number for every new feature, 2nd number for new minor release, and 1st number for new major releases.

     

    It could be like this:

    GameA 0.0.0.0: Testing if the game works at all, and simple player controller walking around.

    GameA 0.0.0.1: Bug fix with player getting stuck somewhere.

    GameA 0.0.1.0: Added crafting of simple items found on the ground.

    GameA 0.0.1.1: Fixed some bug with crafted items not being saved correctly.

    GameA 0.0.1.2: Fixed a bug with items not respawning.

    GameA 0.0.2.0: Added skill advancements in crafting.

    GameA 0.0.3.0: Added melee fighting and melee skills advancement.

    GameA 0.1.0.0: Added multiplayer networking.

    GameA 1.0.0.0: Game is finished and available for public download via PayPal.


  13. Got a feature list of the first release? I guess you must have such list for testing each feature anyway smile.png

     

    Or maybe publish and keep updated the feature list with a status if it's tested and if it has bugs to be fixed, shouldn't be any additional work. That's what all Linux and GNU developers do too.


  14. I want to compile LE3 as full 64-bit version with 64-bit doubles. However I'm not sure if Newton is available as source code, and if not, then I might need to use Bullet which comes as source code and can use 64-bit doubles also.


  15. A prefab or script allows that, without requiring that I hard-code a bunch of special requests into the core engine.

    Yes of course it should be done using existing engine commands, and not part of the core engine .lib, but it could be still bundled with the engine, for example as a seperate .lib or C++ file, which the user can use if he wants. For example I find the oildrum and firepit scripts very useful, because they have sounds, particles and everything ready to drag and drop.

     

    Like in LE 2.5, there is also a smoke emitter, which uses its own shader and texture. An explosion would probably need a shader too, sounds, textures, breakable physics logic, and damage indication to other objects. In addition to those difficult to implement things, the user could add some camera shaking, consequences of the damage to living objects, sound reflections (echo).

×
×
  • Create New...