-
Posts
4,127 -
Joined
-
Last visited
Content Type
Blogs
Forums
Store
Gallery
Videos
Blog Comments posted by Canardia
-
-
Does Vulkan render quads or are they divided into triangles when rendering and does this triangulation take GPU time?
-
I would use 7zip's source code and integrate it into the engine.
-
My vision is to have Ultra Engine work like Visual Studio.
Create a new project and it's already a running executable.
Write a Story and let the game shape up.
Fire up the Editor and drag & drop stuff into your world.
Watch in real-time how your game lives.
Publish the game with the click of a button. -
4 hours ago, Josh said:
"Story"
Story it is, thank you Josh and a long time guild member. <3
- 1
-
9 hours ago, Josh said:
Other name ideas:
- Comment
- Chitchat
- Remark
More name ideas:
- Director's Commentary
- Storyteller
- Ghostwriter
- Demiurge
- God
- Script
- 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.
- 1
-
4 hours ago, Josh said:
That is so cool. It's even simpler than Dark Basic. You could call it "Human" if you wanted to.
Yeah, I've thought of that name too. I think the final name will shape when I get deeper into this tool.
I want to make a game with this. -
I think the user should only debug his own game code related bugs, and rest assured that the engine is bug free
Yes, for engine level debugging such LLVM debugger is better than gdb, but that's what unit tests are invented for also.
-
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.
-
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.
-
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.
-
Yay, finally LE works with Code::Blocks and GNU C++ again!
-
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?
-
I guess it's just a question of taste and elegancy. Most people don't do things very elegant, because their taste is stronger than elegancy
- 1
-
One big benefit is that you can do object specific typedefs, like first using a an int for some id, and later needing a long long because you got more players.
-
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.
-
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.
-
mingw64 and gnu c++ has also std::bind, indeed they have the best C++11 implementation of all C++ compilers.
- 1
-
Can they also jump/climb/crouch over/under obstacles? Is there any way to influence the pathfinding process, or is it always hardcoded like go from point A to point B?
-
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.
-
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.
- 1
-
VS and mingw does not do the constant-in-beginning-of-expression and loop-variable-closest-to-loop optimizations. Every time I make a test program I get the same results.
-
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.
-
Always use sizeof() with memcpy(), else your code cannot be compiled as 64-bit and on other platforms which have different type sizes.
- 1
UltraEnglish
in Canardian's Blog
A blog by Canardia in General
Posted
I've been developing it every day and will publish a first version soon.