This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
Messages - TheMachine02
Pages: 1 ... 6 7 [8] 9 10 ... 32
106
« on: January 11, 2014, 09:41:11 am »
finally achieve *perfect* 3D cliping ! however, it's kinda more slow than only doing z plane cliping so, I have to still work on it. Some pic who will speak better than me  BEFORE : AFTER:  
107
« on: January 08, 2014, 12:41:57 pm »
who  it's a super great menu !
108
« on: January 07, 2014, 02:00:24 pm »
After some test, seem that VBO is almost as fast as "classic" code. So I will keep that  . I have to try with dot point, though cause acessing it will be more slow EDIT : ok so it seem that with dot , VBO run at 53-54fps (classic cube) ; and without it run between 55-56 fps (without any super secret settings :p). However, I didn't optimize *yet* the VBO's code
109
« on: January 07, 2014, 12:45:00 pm »
using custom camera, yes. Basically , you create a new camera ; rotate point around this camera , go back to the classic camera , and render point.
For example ; if I want rotate point 10,10,10 around X,Y,Z, with angle A B and have a world camera, I could do something like that :
GNewCam(°GWORLDVIEW)
While 1
GNewCam(Data(Ar,Br,Xr,Yr,Zr,0r))
GRotate(10,10,10)
GDelCam()
GVertex({°GVertex}r,{°GVertex+2}r,{°GVertex+4}r)
Pxl-on(,{°Gvertex+2}r)
GGetkey()
DispgraphClrdraw
EndIf getkey(15)
however ; in the next version of GCORE , the format of the camera will slighty change (nothing big) ; that why I still doesn't made a tuto about it.
The engine in itself can handle 2 different camera.
EDIT this code work for the "old" version though
110
« on: January 07, 2014, 12:32:55 pm »
exactly that cause handling remplacement woud be a way to much difficult (and heavy).
111
« on: January 07, 2014, 12:30:04 pm »
yep, you can generate up to 255 VBO, and choice wich one to activate with id . You can also delete them - but this only free memory ; meaning that even if you have suppress some VBO ; you will not be able to generate other if in total you have generated 255 VBO. Hope you will understand me
112
« on: January 07, 2014, 12:25:40 pm »
indeed, I didn't think about this. So something like :
GBufferUpdate(id, start_update,end_update)
with start_update the first vertex to update, to end_update ?
113
« on: January 07, 2014, 06:29:01 am »
program example of vertex buffer object or VBO for short. Does syntax is good ? It is cleaner ?
.TEST
prgmGCORE
Data(40r,-40r,40r)→GDB1
Data(40r,40r,40r
Data(-40r,-40r,40r
Data(-40r,40r,40r
Data(40r,-40r,-40r
Data(40r,40r,-40r
Data(-40r,-40r,-40r
Data(-40r,40r,-40r
Data(0,1,2,3,4,5,6,7)->°LinkList
Data(0,2,2,4,4,6,6,0
Data(1,3,3,5,5,7,7,1
GNewCam(°GMODELVIEW)
GGenBuffer(8)→G //take in argument number of vertices and return an id OR 0 if fail
Return!If
GBufferData(GDB1,G,8) //data to copy, id, size in vertices.
While 1
GUpdateBuffer(G) //take id
For(M,0,11) .there is 12 line to draw in a cube
GClipLine({M*2+°LinkList},{M*2+1+°LinkList}
End
GGetkey()
DispgraphClrdraw
EndIf getkey(15)
note too that I have slighty change GGetkey() syntax.
114
« on: January 06, 2014, 01:02:31 pm »
baf . The scene complexity on this calc is not so high so z ordering is enough. Z buffer couldn't be achieve, cause it require a way to much ressource (per pixel check , and a big ram buffer (+-12000 bytes for 16-bit precision...) ben_g : I will add that then  Since 3D clipping and z-ordering require caching vertices, I guess I will do that
115
« on: January 05, 2014, 10:40:30 am »
well backface culling work well, but sorting is pretty difficult due to data structure - and so I have a buggy routine, but it doesn't work
116
« on: January 05, 2014, 08:58:35 am »
per vertex lighting wouldn't be *that* slow. I guess you can use a vertex shader (or geometry shader) / combine with a texture shader to achieve per vertex lightning. I could also implement this directly in the lib, but the total weight will become even more big . Shader is good though.
117
« on: January 04, 2014, 12:36:01 pm »
That looks really good. It seems like a great effect to make a dark environement.
Would it be hard to do lights at a different position as the camera, and multiple lights?
well, with the way I calculate the illumination, only directionnal light can be defined ; but mutiple and different light are not so difficult
would it be slow/hard to recalculate the light direction based of a certain point for every vertex or for every 4*4 pixel area?
I am not sure for what you mean, but if you think of a sort of per-vertex lightning ; a modification of the texture routine allow me to do some sort of gouraud shading. Would it be practical inside a game?
I guess it would be better than texture, as it is faster ; and a bit cleaner anyway, since cliping reallly annoy me, I decide to go to the hard way perfect 3D clipping : many improvement expected : -2D commands won't need clipping anymore -I am thinking of a new way to do it, so it *may* be faster than the actual clipping routine -all overflow due to this will be remove -command will clip in a much more agressive way, cutting lot more of geometry
118
« on: January 02, 2014, 11:31:46 am »
That looks really good. It seems like a great effect to make a dark environement.
Would it be hard to do lights at a different position as the camera, and multiple lights?
well, with the way I calculate the illumination, only directionnal light can be defined ; but mutiple and different light are not so difficult
119
« on: January 02, 2014, 11:14:23 am »
combinaison of both dithering and texturing. Note that this is at 15MHz. 6MHz is not *that* slow, but the screen is faster and look better like this  and thanks Xeda !
120
« on: January 02, 2014, 10:59:33 am »
Well, me I'll say С Новым Годом ! (russian) and happy new year !
Pages: 1 ... 6 7 [8] 9 10 ... 32
|
Show Posts