C# demoes with source or other frame works
category: code [glöplog]
Engine is a synonym for procrastination.
Its nice to read your story of progress.
I opengl is moving, then it is moving slow :)
And for me there is only nvidia, since they seem to be the ones pushing on with new tech.
as I remember that store about valve, it was more like the engine optimazations. not as much opengl in itself. And it is really biased when they compared a newly optimized game from valve to the older unopdated implementation in directx.
I is not because I think OpenGL is slower than D3D that I choose D3D but because of an OOP aproach rather than the state machine one of OpenGL.
Nvidia btw is support d3d much more than opengl also. and then you have all these games on pc using ...directx11.
I guess if I was on a mac, which I am not, then it would be opengl.
Its cool you have something running I hope I will too very soon :)
I opengl is moving, then it is moving slow :)
And for me there is only nvidia, since they seem to be the ones pushing on with new tech.
as I remember that store about valve, it was more like the engine optimazations. not as much opengl in itself. And it is really biased when they compared a newly optimized game from valve to the older unopdated implementation in directx.
I is not because I think OpenGL is slower than D3D that I choose D3D but because of an OOP aproach rather than the state machine one of OpenGL.
Nvidia btw is support d3d much more than opengl also. and then you have all these games on pc using ...directx11.
I guess if I was on a mac, which I am not, then it would be opengl.
Its cool you have something running I hope I will too very soon :)
Probably fairly irrelevant now, but did you consider pypy?
As long as you don't need embedding, it's plenty fast :)
As long as you don't need embedding, it's plenty fast :)
Quote:
@xoofx: While we have your attention: Did you ever come up with a way to do 64k D3D or OGL comfortably in C# ?
Not really. The main problem is that pure C# assemblies are embedding lots of metadata necessary to describe all the classes present in the DLL as well as all the imported classes, dll import... etc. So a C# assembly is loosing lots of data just to describe itself (It would be like packing a demo with their .h header files). There are some workarounds like trying to embed only the C# sourcecode on the fly (correctly minified), but I haven't tried this, as It would take much more time to bring down the size in C# than to develop the intro directly in C/minimalistic-C++. Plus, usually, .NET is not allowed in 64k compos, so...
@jaw
I have been looking at pypy for nummerical programming. But Numpy does not have a compelete implementation in pypy yet.
And yes pypy is fast :) but what should I consider pypy for did you have in mind?
@xoofx
I had a peek at the source code in toolkit, and it is huge. Off course I do not need all there is in toolkit, but does toolkit, have sort of a main file, where I can see how things are build up?
I looks like you use C# event handlers, but is wont that slow down the program or is it just me?
I have been looking at pypy for nummerical programming. But Numpy does not have a compelete implementation in pypy yet.
And yes pypy is fast :) but what should I consider pypy for did you have in mind?
@xoofx
I had a peek at the source code in toolkit, and it is huge. Off course I do not need all there is in toolkit, but does toolkit, have sort of a main file, where I can see how things are build up?
I looks like you use C# event handlers, but is wont that slow down the program or is it just me?
Quote:
I looks like you use C# event handlers, but is wont that slow down the program or is it just me?
Event handlers are used for non critical part of the toolkit (like GraphicsDevice disposed..etc.). And even if it was use for some critical part, they are absolutely not a reason for slowing down an application.
Quote:
I had a peek at the source code in toolkit, and it is huge. Off course I do not need all there is in toolkit, but does toolkit, have sort of a main file, where I can see how things are build up?
What the hell do you mean by main file? This is a framework, where each classes has a specific scope/function. Really, you should start coding instead of asking never ending questions. :p
Quote:
Not really. The main problem is that pure C# assemblies are embedding lots of metadata necessary to describe all the classes present in the DLL as well as all the imported classes, dll import... etc. So a C# assembly is loosing lots of data just to describe itself (It would be like packing a demo with their .h header files). There are some workarounds like trying to embed only the C# sourcecode on the fly (correctly minified), but I haven't tried this, as It would take much more time to bring down the size in C# than to develop the intro directly in C/minimalistic-C++. Plus, usually, .NET is not allowed in 64k compos, so...
Revision 64k rules states: "DotNet entries are allowed when they follow the rules listed above." which comes down to:
"We will not install any additional Runtimes, SDKs, codecs, drivers etc. on the compo machine.".
Which means .NET 3.5 in Windows7 and later versions if they have done Windows Update.
Embedded source, hmm. Somebody should try it just for the hell of it. :)
@xoofx
Cool about the event handlers
What I meant by main file was the place where you use parts of the framework, to see the connection. That would be some of the examples i guess, then.
about coding. Who said I was not :)
Cool about the event handlers
What I meant by main file was the place where you use parts of the framework, to see the connection. That would be some of the examples i guess, then.
about coding. Who said I was not :)
Quote:
What I meant by main file was the place where you use parts of the framework, to see the connection. That would be some of the examples i guess, then.
In "Samples" you have a SharpDXToolkitSamples.sln and sources are under "Samples\Toolkit". How did you not find them?
xoofx, btw, congrats on SharpDX. Used it at work for a small internal DX11/C# project and found it brilliant. :)
Quote:
In "Samples" you have a SharpDXToolkitSamples.sln and sources are under "Samples\Toolkit". How did you not find them?
Thank you.
sometimes when studying a framework, I found there can other ways to study it.
i.e. just looking a what you need. That was the intention of the question.
Quote:
xoofx, btw, congrats on SharpDX. Used it at work for a small internal DX11/C# project and found it brilliant. :)
Hey, thanks kb_ for the kind feedback!