Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 05 Jul 2013
Online Last Active Today, 01:44 AM

Posts I've Made

In Topic: Compile shaders in build time with common functions

03 September 2014 - 05:10 AM

So easy.. Shame on me ;)


Thank you both !!

In Topic: About fixed points

23 April 2014 - 01:09 AM

Whoah ! Thank you all so much for all your help !
I start to understand. There is just some things to learn more...
For the moment, I will concentrate myself on only a planet, I will see later for solar system, galaxies, etc.
For very high precision, you say it's better to use int64. I think I need to create a class for converting it to better readable numbers (for coding) ?
If not, with micrometers precision, I will deal with very very big numbers (without digits as it's integer), not very convenient.. ? Some tips ?
I understand the concept of  using camera position as the center, for more precision when converting to float.
But subtracting the vertices x,y,z from the camera position in the CPU will be huge ?! There is lot of vertices in the node's grid (x 6 faces)...
Better to do that in the vertex shader, no ? But if I do that, how to send the coordinates to the shader ? 
As the max input is R32B32G32 and I will use 3 x int64... ?
My grids are allways the same, they are offseting and scaling in vertex shader based on node position and LOD.
In conclusion, when to convert to float and where ? What format to send to the shaders ? 
Again, thank you for all your help ;)
PS : I know it's a hard concept for a beginner, but I'm here for learning and not affraid to spend hours on that.

In Topic: About fixed points

21 April 2014 - 11:13 PM

Thank you all for your answers !


Frob, you talk about mixing numbers. It's one of my doubts, do I need to convert the fixed point back to float ? Float to Integer => no loss.

If don't need to convert back, how will work the shaders, as the numbers will be to much big... 

I read, a lot of engine are using fixed points, there must be a solution.. 


Stainless, thank you for the links, I will read them now.


Vortez, I read that it's a bad solution to use double, I tried to get my idea about. There was too much loss of performances.

In Topic: Help for gameplay's ideas about a little space demo game

10 February 2014 - 01:41 AM

Hello Xenobrain,


Thank you very much for your post. You helping so much... 

I'm now in holidays, but I will post some resulting ideas latter.

In Topic: Help for gameplay's ideas about a little space demo game

06 February 2014 - 03:46 AM

Hello Acharis and thank you for your answer ;)
Perhaps, I have not explained correctly...
- My first goal was learning.. Learning how a full game engine works and how make my own.
I don't want the best one, like Unreal, Unity and others.. Just mine.
- The demo game I want, is for making something with the actual engine, not a big real indie game.. It will be a little, short, playable demo.
- My engine is pretty complet, separated in libraries, graphics, physics, scripting, inputs, etc. It is very flexible.
But ! All the dev was thought from start in the goal of the procedural space game. So it's already exactly what I wanted. Why restarting with a technology I don't know ?
- I started with OpenGL, but (cannot remember why) I moved to DX later. Perhaps you right, but I'm very happy with DX and it's too late..
My request is to help me to find some attractive stuffs for playing the little demo.