Show Posts

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 - Goombert

2596
General ENIGMA / Re: Delusions of Grandeur
« on: August 02, 2013, 04:26:49 PM »
*fixes

2597
General ENIGMA / Re: Delusions of Grandeur
« on: August 02, 2013, 01:31:12 AM »
Everything looks fine to me :P Josh, please lay down the crack pipe, stop smoking pcp, and seek professional help.

2598
General ENIGMA / Half Pixel Alignment, OpenGL and DirectX
« on: August 01, 2013, 02:27:16 AM »
As some of you may not be aware, vector graphics require a half pixel align or else there are edge artifacts, anybody who has worked with SVG's knows about this. Anyway, DX and OGL require you do the half pixel alignment yourself for 2D rendering. Now Josh's original proposal to me was to just shift the ortho projection function by (-0.5,-0.5) and that appeared to work because I was using draw_rectangle. Now this does not fix it for every draw function, as x and y are by default float because of gs_scalar and what both graphics API's use internally. This means if you call say draw_sprite(random(room_width), random(room_height)); you'll end up with half the sprites half pixel aligned and the other half of them not. The only way I could resolve it locally was to cast to integer before passing the coordinates to the draw functions and then letting the projection matrix shift (-0.5, -0.5)

The only solution to this I can think of is to either explicitly require integer for x and y with 2D drawing functions (which breaks them for transforming say a sprite into a 3D billboard as float is still the highest precision allowed). We could create a separate scalar for 2D x and y drawing functions so people can easily choose their cast. Or we can manually enter (-0.5, -0.5) to every single 2D drawing function. Looking for input on this you guys, specifically you, Josh Dreamyland.

2599
Proposals / Re: GL3 changes from immediate to retained mode
« on: August 01, 2013, 02:21:56 AM »
Quote
Only vertex shaders could help there.
Exactly, it is OpenGL 3, the goal was to rewrite all of it to use shaders. In fact, just Google, I found all the basic immediate mode functions recreated into shaders yesterday somewhere, lost the link :/, but it was open source.

2600
General ENIGMA / DirectX Models and Primitives
« on: August 01, 2013, 02:19:21 AM »
Yes, I already spoke on this a bit before, but Direct3D offers an internal mesh class that can do optimization and has interfaces for dynamic level of detail (LOD), and can also by default load (*.x) model files, which models can be exported from Blender in.
http://msdn.microsoft.com/en-us/library/windows/desktop/bb147196%28v=vs.85%29.aspx

From what I can gather however, the mesh class works with triangle lists internally, however you can get a pointer and control locking and unlocking of its index and vertex buffer, however I was looking at the specification for DrawSubet()
Quote
D3DX Meshes use indexed triangle lists, and are therefore drawn with IDirect3DDevice9::DrawIndexedPrimitive.

So I am unsure if we can use this to create models that can have other primitive types. It is however possible for us to make it so that people only thing they are using the other primitive types and just hack them all into triangle lists, after all that is the fastest way to do it, that is *the* primitive of the GPU. Quads all that shit are on there way out and are already software processed in OpenGL 3 and later.

Also, when the base mesh interface loads a (*.x) model file it also gives you the file name from its material telling you where its texture is located. The base mesh interface holds transformation, texture, and material information, so we would also need to add a d3d_model_get_texture() function to avoid having inaccessible textures in memory. Just looking for some input guys... I want to say just go ahead and use it but idk, I would have to hack in and fake other primitive types, which albeit would be really fast anyway, but idk if you guys are ok with me doing that or what or if we should just write our own mesh interface like I did with OpenGL 3.

2601
Proposals / Re: GL3 changes from immediate to retained mode
« on: July 31, 2013, 08:31:27 PM »
Well I would also like to mention that contrary to Josh's belief the D3D9 sprite batcher can also render tiled sprites by simply setting the source rectangle larger than the bounds and enabling texture repetition render state...

The only thing I don't know about is, whether I should force texture repetition on and leave it on in the sampler when these functions get called or implement a perplexed system for checking whether its enabled and then disable it again.

2602
Proposals / Re: GL3 changes from immediate to retained mode
« on: July 31, 2013, 05:41:18 PM »
Code: [Select]
d3d_transform_set_identity();
d3d_transform_add_rotation_x(90);
draw_sprite(spr_wall, 0, 0);

:P

That is possible in Game Maker and using the DX batching class. DX can also outperform this with different textured sprites, I presume because of batching, and it must be mixing it with a shader. If we add all that to the OpenGL one Harri committed, we could make it a LOT faster than what he has right now.

2603
General ENIGMA / Re: Scalar Types
« on: July 31, 2013, 05:36:49 PM »
Do you mean why didn't I? I thought I avoided making alpha gs_scalar like the plague.

2604
I am using the zip installer which comes with MinGW64 Harri, if that is the case, first try to install the DX runtime, then try to install the DX SDK and see which of those fixes it, but do it in that order, as I'd rather have people download the runtime than the SDK.

d3d9.h contains most of the rendering headers
d3dx9.h contains math functions, vector classes, and matrix transformation stuffs

There is also a lib for both of those which is linked, -ld3d9 and -ld3dx9

Quote
And why can't you do this now in OGL? Do you mean just using d3d_transform functions to rotate sprites?
No I was just ensuring everyone that the behavior has not been lost with this new sprite batching class.

2605
Proposals / Re: GL3 changes from immediate to retained mode
« on: July 31, 2013, 09:21:42 AM »
Harri, yup, exactly what I was thinking.

2606
Proposals / Re: GL3 changes from immediate to retained mode
« on: July 31, 2013, 07:34:13 AM »
Yes, these were all the things I was originally planning to do with OpenGL 3. But Harri, for that I was thinking of a common interface for vertex formats of all the basic shapes like a plane and what not, and include them from a common header, thats what those GLshapes.cpp and GL3shapes.cpp files are about. I just didn't have the energy to do it. Also, that is why there's a shaders folder, we need to rewrote all the behavior expected into GPU programs as well. Especially for particle effects.

2607
Me and Josh did a few test cases and the sprite batch does properly organize depths, and in fact transformations can be applied to the sprites/backgrounds/text to turn them into 3D billboards like many people do in Game Maker.

2608
Proposals / Re: Vertex color
« on: July 31, 2013, 04:42:49 AM »
Quote
We use VBO's instead of lists as it is just better usually. But even lists cannot be changed. So if you turn this into a list:
It was in response to that :P I was not sure if you were aware that OpenGL 1 still uses call lists.

2609
Guys, hey I got the #1 reason we are going to use DX now, look at the updated screen shot, that is 50,000 draw_sprite calls at 30fps, OpenGL can't handle 15,000 on my pc at more than 12fps. That is utilizing DX's internal sprite batching class, please proceed with the DirectX vs. OpenGL debates. :P

Please merge pull request....
https://github.com/enigma-dev/enigma-dev/pull/283

Also to prove my point, this is the d3d blend modes and their OpenGL and Direct3D equivalents.
Code: [Select]
  bm_zero             =  1,  // GL_ZERO                  D3DBLEND_ZERO
  bm_one              =  2,  // GL_ONE                   D3DBLEND_ONE
  bm_src_color        =  3,  // GL_SRC_COLOR             D3DBLEND_SRCCOLOR    //only for dest
  bm_inv_src_color    =  4,  // GL_ONE_MINUS_SRC_COLOR   D3DBLEND_INVSRCCOLOR //only for dest
  bm_src_alpha        =  5,  // GL_SRC_ALPHA             D3DBLEND_SRCALPHA
  bm_inv_src_alpha    =  6,  // GL_ONE_MINUS_SRC_ALPHA   D3DBLEND_INVSRCALPHA
  bm_dest_alpha       =  7,  // GL_DST_ALPHA             D3DBLEND_DESTALPHA
  bm_inv_dest_alpha   =  8,  // GL_ONE_MINUS_DST_ALPHA   D3DBLEND_INVDESTALPHA
  bm_dest_color       =  9,  // GL_DST_COLOR             D3DBLEND_DESTCOLOR     //only for src
  bm_inv_dest_color   = 10,  // GL_ONE_MINUS_DST_COLOR   D3DBLEND_INVDESTCOLOR  //only for src
  bm_src_alpha_sat    = 11   // GL_SRC_ALPHA_SATURATE    D3DBLEND_SRCALPHASAT   //only for src

So like I said the graphics portion of Game Maker was designed around D3D, obviously because of the function naming as well, so this definitely will cut down on visual anomalies in games. I've also noticed the transform functions have the same behavior as one would expect in Game Maker.

2610
Proposals / Re: Vertex color
« on: July 30, 2013, 04:14:46 PM »
Harri, OpenGL3 uses VBO's, OpenGL 1 still uses call lists, and it is likely to remain that way.