Sigma

About the actual programming of the game.

Sigma

Postby adam » Wed Sep 25, 2013 4:07 am

So what is all this talk about Sigma? Sigma Github

Sigma is a game creation framework. It is what the engine will use to create components from various systems. This means the Trillek engine will, for example, load up Sigma and tell it to add some mesh components. Sigma will take care of the dirty work under the hood. All the Trillek engine has to do is sit there and be pretty.

Sigma is closer to SDL than a game engine. As such it could be used by the Trillek engine as its underlying boilerplate code. Sigma will remain its own entity and contribution is encouraged. This will allow others to practice the coding style and become familiar with the coding habits of others in an established project.
adam
 
Posts: 113
Joined: Tue Aug 20, 2013 11:58 am

Re: Sigma

Postby Andrew » Wed Sep 25, 2013 4:21 am

Why go with a custom route when there are already much more active, mature & stable alternatives such as SDL or SFML?
IRC: |Andy|
Andrew
 
Posts: 110
Joined: Wed Aug 21, 2013 7:16 am
Location: Melbourne, Australia

Re: Sigma

Postby adam » Wed Sep 25, 2013 4:29 am

They provide the OS interface yes. But the component based approach they fail at.
SDL is in fact in use in Sigma for the OS interface. That is how it runs on Linux right now.

Sigma is separate is is more own project remember. It is a possibility for the Trillek engine.
adam
 
Posts: 113
Joined: Tue Aug 20, 2013 11:58 am

Re: Sigma

Postby danix111 » Wed Sep 25, 2013 4:39 am

The only problem I have with Sigma at the moment is that its code is a bit messy, which may make its integration into Trillek more difficult.
User avatar
danix111
 
Posts: 61
Joined: Mon Aug 12, 2013 2:05 pm
Location: Gdynia, Poland

Re: Sigma

Postby adam » Wed Sep 25, 2013 4:40 am

Feel free to contribute if you want to help the clean up.
adam
 
Posts: 113
Joined: Tue Aug 20, 2013 11:58 am

Re: Sigma

Postby catageek » Sat Oct 26, 2013 7:53 am

A technical question:

SIMD paradigm imposes us to have SIMD-friendly data structures.

In Sigma, you define a Vertex as (x,y,z), then create a Vector<Vertex> to store the vertices. The data layout is in memory: x, y, z, x, y ,z, etc.

A SIMD-friendly structure would be to create 3 Vector<float> named x, y and z, and define the vertices as the elements of each vector x, y, z. The data layout is: x, x, x, etc.
y, y, y, etc.
z, z, z, etc.

This layout allows to vectorize the operations on the Vertices.

Am I right when I think that making the vertices data structure "SIMD-friendly" will improve performance ?
catageek
 
Posts: 39
Joined: Tue Oct 15, 2013 2:23 pm

Re: Sigma

Postby ghillie » Sat Oct 26, 2013 9:27 am

What would your glVertexAttribPointer() call look like?
ghillie
 
Posts: 12
Joined: Thu Aug 15, 2013 4:53 pm

Re: Sigma

Postby catageek » Sat Oct 26, 2013 9:51 am

ghillie wrote:What would your glVertexAttribPointer() call look like?


I think 3 successive calls for x, y and z. Of course, the shader must be modified to extract the x, y and z in a different way.
catageek
 
Posts: 39
Joined: Tue Oct 15, 2013 2:23 pm

Re: Sigma

Postby ghillie » Sat Oct 26, 2013 10:32 am

I'm no expert, so take this with a grain of salt. Right away the fact that I personally have never seen it done that way makes me uneasy. My hunch would be you would see worse performance. Interleaved data formats should cause less GPU cache pressure because the vertex coordinates aren't scattered all over in memory.
ghillie
 
Posts: 12
Joined: Thu Aug 15, 2013 4:53 pm

Re: Sigma

Postby Krarl » Sat Oct 26, 2013 11:04 am

If i remember correctly when reading about this, interleaved data is faster on some graphic cards and slower on others. I'd just go for a vector<Vertex> since it's easy to work with.
Krarl
 
Posts: 86
Joined: Tue Aug 13, 2013 5:39 pm
Location: Sweden

Next

Return to Code

Who is online

Users browsing this forum: No registered users and 1 guest

cron