Welcome Guest! To enable all features please Login or Register.

Notification

Icon
Error

Options
Go to last post Go to first unread
Offline elasto  
#1 Posted : Friday, September 9, 2011 7:08:31 AM(UTC)
elasto

Joined: 8/23/2011(UTC)
Posts: 245

Thanks: 6 times
Was thanked: 12 time(s) in 11 post(s)
Hi guys. Looks to be a great engine you guys have put together - have been following it with great interest for a little while now :)

My question is about shaders - and what support there will be in the early stages and then later down the road.

Will it be possible in the early days to do any direct OpenGL ES and HLSL coding? Will we be able to create a version of the shader in each language and have the engine pick up the appropriate one for the target platform? Or is it only and always going to be through some intermediate interface?

(If there's any slots still going in the private Beta, an invite would be greatly appreciated :) I'm part of a small team that's been putting together some projects in XNA this year, and we think DeltaEngine would be an excellent road to translate our work into. But if slots are full we've got plenty to be getting on with in the meantime :) )

Wanna join the discussion?! Login to your forum accountregister a new account. Or Connect via Facebook Twitter Google

Offline Amer  
#2 Posted : Friday, September 9, 2011 8:33:16 AM(UTC)
Amer

Joined: 8/21/2011(UTC)
Posts: 28

Thanks: 1 times
Originally Posted by: PG Go to Quoted Post
Hi guys. Looks to be a great engine you guys have put together - have been following it with great interest for a little while now :)

My question is about shaders - and what support there will be in the early stages and then later down the road.

Will it be possible in the early days to do any direct OpenGL ES and HLSL coding? Will we be able to create a version of the shader in each language and have the engine pick up the appropriate one for the target platform? Or is it only and always going to be through some intermediate interface?

(If there's any slots still going in the private Beta, an invite would be greatly appreciated :) I'm part of a small team that's been putting together some projects in XNA this year, and we think DeltaEngine would be an excellent road to translate our work into. But if slots are full we've got plenty to be getting on with in the meantime :) )


At the moment shader creation is done using the content manager tool, but in the future there will be the ShaderEditor which is node based system and allow cross platform shader generation, but i think we'll add support for directly generate shader from pure HLSL, GLSL, OpenGLES code too.

Correct me if i'm wrong Benjamin.

Cheers
Offline elasto  
#3 Posted : Friday, September 9, 2011 8:54:25 AM(UTC)
elasto

Joined: 8/23/2011(UTC)
Posts: 245

Thanks: 6 times
Was thanked: 12 time(s) in 11 post(s)
For example, if I wanted to be able to do something simple like texture splatting, would I be able to achieve that? For example I've got some simple HLSL code like the following - would there be an equivalent through the content manager tool or ShaderEditor?

Code:
//------- Technique: Multitextured --------
struct MTVertexToPixel
{
    float4 Position         : POSITION;    
    float4 TextureWeights1  : TEXCOORD0;
    float2 TextureWeights2  : TEXCOORD1;
    float2 TextureCoords    : TEXCOORD2;
};

struct MTPixelToFrame
{
    float4 Color : COLOR0;
};

MTVertexToPixel MultiTexturedVS(float4 inPos : POSITION, float4 inTextureWeights1: TEXCOORD0, float2 inTextureWeights2: TEXCOORD1, float2 inTextureCoords: TEXCOORD2)
{    
    MTVertexToPixel Output = (MTVertexToPixel)0;
    
    float4x4 preViewProjection = mul (xView, xProjection);
    float4x4 preWorldViewProjection = mul (xWorld, preViewProjection);
    
    Output.Position = mul(inPos, preWorldViewProjection);
    Output.TextureWeights1 = inTextureWeights1;
    Output.TextureWeights2 = inTextureWeights2;
    Output.TextureCoords = inTextureCoords;

    return Output;    
}

MTPixelToFrame MultiTexturedPS(MTVertexToPixel PSIn)
{
    MTPixelToFrame Output = (MTPixelToFrame)0;        
    
    Output.Color = tex2D(TextureSampler0, PSIn.TextureCoords)*PSIn.TextureWeights1.x;
    Output.Color += tex2D(TextureSampler1, PSIn.TextureCoords)*PSIn.TextureWeights1.y;
    Output.Color += tex2D(TextureSampler2, PSIn.TextureCoords)*PSIn.TextureWeights1.z;
    Output.Color += tex2D(TextureSampler3, PSIn.TextureCoords)*PSIn.TextureWeights1.w;
    Output.Color += tex2D(TextureSampler4, PSIn.TextureCoords)*PSIn.TextureWeights2.x;
    Output.Color += tex2D(TextureSampler5, PSIn.TextureCoords)*PSIn.TextureWeights2.y;

    return Output;
}


Or would I be able to do texture splatting using textures stored in a texture atlas?

Code:
TAPixelToFrame TextureAtlasPS(TAVertexToPixel PSIn)
{
    TAPixelToFrame Output = (TAPixelToFrame)0;        
    
    float2 textureCoords0 = PSIn.TextureCoords;
    float2 textureCoords1 = PSIn.TextureCoords; textureCoords1.x+=0.25f;
    float2 textureCoords2 = PSIn.TextureCoords; textureCoords2.x+=0.5f;
    float2 textureCoords3 = PSIn.TextureCoords; textureCoords3.x+=0.75f;
    float2 textureCoords4 = PSIn.TextureCoords; textureCoords4.y+=0.25f;
    float2 textureCoords5 = PSIn.TextureCoords; textureCoords5.x+=0.25f; textureCoords5.y+=0.25f;

    Output.Color = tex2D(TextureSampler0, textureCoords0)*PSIn.TextureWeights1.x;
    Output.Color += tex2D(TextureSampler0, textureCoords1)*PSIn.TextureWeights1.y;
    Output.Color += tex2D(TextureSampler0, textureCoords2)*PSIn.TextureWeights1.z;
    Output.Color += tex2D(TextureSampler0, textureCoords3)*PSIn.TextureWeights1.w;
    Output.Color += tex2D(TextureSampler0, textureCoords4)*PSIn.TextureWeights2.x;
    Output.Color += tex2D(TextureSampler0, textureCoords5)*PSIn.TextureWeights2.y;

    return Output;
}

As you can see, nothing very advanced, but I'm trying to keep it simple while I judge what's going to be available to me.

Edited by user Friday, September 9, 2011 8:56:24 AM(UTC)  | Reason: Not specified

Offline Benjamin  
#4 Posted : Friday, September 9, 2011 11:36:48 AM(UTC)
Benjamin

Medals: Admin

Joined: 8/20/2011(UTC)
Posts: 1,421
Location: Hannover

Thanks: 18 times
Was thanked: 97 time(s) in 92 post(s)
Well, in the current version we only allow Shader Feature Flags and as Amer has said you can use the new Shader Node Editor in the future.

Of course you can also directly hack in your native shader code (in your example it would be DirectX/XNA), but then you lose all multiplatform compatibility because that shader runs only on hardware that can read and compile this shader. This is okay if you only care about DirectX compatible platforms (not many ^^ basically it would just run on PC and Xbox 360, it is up to you if you hack in more platforms for this specific shader, then it would work on others too), but you won't get full compatibility with even platforms that can't do shaders at all or that are very slow. WP7 does not allow custom shaders yet, many mobile devices have slow GPUs + slow memory bandwidth and a complex shader like this with 6 texture reads will not run in any acceptable speed. Instead you have to use either the Shader Feature Flags or the Shader Node Editor to provide some kind of fallback and to allow us to optimize your shaders the best way possible.
Offline Benjamin  
#5 Posted : Friday, September 9, 2011 11:41:32 AM(UTC)
Benjamin

Medals: Admin

Joined: 8/20/2011(UTC)
Posts: 1,421
Location: Hannover

Thanks: 18 times
Was thanked: 97 time(s) in 92 post(s)
Originally Posted by: PG Go to Quoted Post
Will it be possible in the early days to do any direct OpenGL ES and HLSL coding? Will we be able to create a version of the shader in each language and have the engine pick up the appropriate one for the target platform? Or is it only and always going to be through some intermediate interface?


Anything is possible since you have all the code for the shader classes, you can change the way shader content is loaded or add your own functionality. But what I said in the other post still holds true, some changes won't run on many platforms anymore and we highly recommend using our Shader Node Editor in the future (or the Shader Feature Editor currently, coming with v0.8.7).

Originally Posted by: PG Go to Quoted Post

(If there's any slots still going in the private Beta, an invite would be greatly appreciated :) I'm part of a small team that's been putting together some projects in XNA this year, and we think DeltaEngine would be an excellent road to translate our work into. But if slots are full we've got plenty to be getting on with in the meantime :) )


Sorry, the private beta is closed. I added more and more people last month, but it is too much overhead to get constantly asked and adding people. The public beta is not that far away (3 more weeks) and remember: Just focus on your game and code it in whatever you feel comfortable with (XNA, OpenTK, DirectX), porting it later to the Delta Engine is easy enough.
Offline elasto  
#6 Posted : Friday, September 9, 2011 1:31:48 PM(UTC)
elasto

Joined: 8/23/2011(UTC)
Posts: 245

Thanks: 6 times
Was thanked: 12 time(s) in 11 post(s)
Originally Posted by: Benjamin Nitschke Go to Quoted Post
Originally Posted by: PG Go to Quoted Post
Will it be possible in the early days to do any direct OpenGL ES and HLSL coding? Will we be able to create a version of the shader in each language and have the engine pick up the appropriate one for the target platform? Or is it only and always going to be through some intermediate interface?


Anything is possible since you have all the code for the shader classes, you can change the way shader content is loaded or add your own functionality. But what I said in the other post still holds true, some changes won't run on many platforms anymore and we highly recommend using our Shader Node Editor in the future (or the Shader Feature Editor currently, coming with v0.8.7).

Ok cool. From outside the Beta it's not obvious which bits are client side and which bits server side in terms of what's under my control. Sounds like you're saying even something as 'under the hood' as the shader is ultimately within my reach code-wise - that there's no 'secret sauce' server-side - which is good to know. :)

Quote:
Of course you can also directly hack in your native shader code (in your example it would be DirectX/XNA), but then you lose all multiplatform compatibility because that shader runs only on hardware that can read and compile this shader.

Well, I tried to keep my opening post brief but it's possible I overdid it. The idea if possible would be to make an HLSL version and one or two OpenGL versions and that should tick all the major boxes (iPhone/iPad/Android/Mac/PC). Any hardware for which this would be a 'complex shader' as you describe it (the second shader being little more than six reads from a single texture) would be too slow to run our game full stop (it's a fairly demanding 3d game with potentially tens of thousands of vertices).

Quote:
Instead you have to use either the Shader Feature Flags or the Shader Node Editor to provide some kind of fallback and to allow us to optimize your shaders the best way possible.

Yeah. Was just hoping for a heads-up as to whether the Shader Feature Flags and/or Shader Node Editor would have something like, say, texture splatting (or be able to look for myself). Just basically trying not to go too far down the road in terms of building stuff into our game if it all has to be engineered back out again. I can wait 3 weeks though :)

Thanks again, it all looks great :)

Edited by user Friday, September 9, 2011 1:54:33 PM(UTC)  | Reason: Not specified

Offline elasto  
#7 Posted : Friday, September 9, 2011 5:54:47 PM(UTC)
elasto

Joined: 8/23/2011(UTC)
Posts: 245

Thanks: 6 times
Was thanked: 12 time(s) in 11 post(s)
Ok, maybe I'm not expressing myself as well as I could. Let me ask it this way instead:

It seems to me that access to the shader subsystem is via BaseShader, and it appears to operate a bit like BasicEffect in XNA; That is to say, a lot of very advanced features built into and optimised within it. Are you saying that when I get hold of Delta Engine's source code it will include the code behind BaseShader to the point of also having all the HLSL/GLSL/etc code along with it - such that I could look to extend this class myself?

I realise that I might extend it in ways that might only be viable on faster hardware - or might not work on older hardware at all (eg perhaps I might not bother doing anything with OpenGL ES 1.x) - but I don't see that as all that different from the fact that DeltaEngine is looking to incorporate advanced things like ragdoll physics. Ok, so advanced physics models incorporated into DE might technically work on any hardware - but in practice it might run too slow on older hardware to really do all that much with... :)

(And I don't mean to be critical of BaseShader in asking this. Clearly from seeing SoulCraft and the like it's extremely capable. It's just that I'm a programmer with a maths background and love getting my hands dirty with stuff like low level shader tricks :))

Edited by user Friday, September 9, 2011 5:56:16 PM(UTC)  | Reason: Not specified

Offline Benjamin  
#8 Posted : Friday, September 9, 2011 6:56:18 PM(UTC)
Benjamin

Medals: Admin

Joined: 8/20/2011(UTC)
Posts: 1,421
Location: Hannover

Thanks: 18 times
Was thanked: 97 time(s) in 92 post(s)
Hi PG.

Good questions. There is obviously lots of "secret source" going on in the Content System on the Server, but what comes out are just simple .DeltaShader files, which mostly consists of the Shader Code in plain text form (you can see all the code in the Delta.ContentSystem.Rendering.ShaderData class).

For example the simplest shader we have in the fallback Engine content is LineShader2D.DeltaShader, which just contains these two text blocks (vertex and pixel shader, here in the OpenGL version). You can just modify them in code or load anything else if you want to roll it all on your own.

Code:

uniform mat4 WorldViewProj;
attribute vec4 vPosition;
attribute vec4 vColor;
varying vec4 VertexColor;
void main( )
{
	gl_Position = WorldViewProj * vPosition;
	VertexColor = vColor;
}


And for the pixel shader (remember this is all generated code and might sometimes look confusing, but it is all optimized and tested and reduced to the bare minimum):
Code:

varying vec4 VertexColor;
void main( )
{
	vec4 Diffuse = VertexColor;
	gl_FragColor = Diffuse;
}


And finally here is the Shader Feature Editor how to build any shader with a few clicks right now (remember that we don't ship our Shader Node Editor yet as it is not fully implemented, tested or complete):
Benjamin attached the following image(s):
ShaderFeatureEditor.png (41kb) downloaded 27 time(s).

You cannot view/download attachments. Try to login or register.
Offline Benjamin  
#9 Posted : Friday, September 9, 2011 7:13:15 PM(UTC)
Benjamin

Medals: Admin

Joined: 8/20/2011(UTC)
Posts: 1,421
Location: Hannover

Thanks: 18 times
Was thanked: 97 time(s) in 92 post(s)
Originally Posted by: PG Go to Quoted Post
It seems to me that access to the shader subsystem is via BaseShader, and it appears to operate a bit like BasicEffect in XNA; That is to say, a lot of very advanced features built into and optimised within it. Are you saying that when I get hold of Delta Engine's source code it will include the code behind BaseShader to the point of also having all the HLSL/GLSL/etc code along with it - such that I could look to extend this class myself?


There are not many similarities between BasicEffect and BaseShader. BaseShader is just the base class and you can derive from it (via the Shader class in Delta.Graphics.Basics) and add whatever you want.

As you can see from my screenshot, yes currently it is all based on Shader Feature Flags, but there is also the possibility to add Shader Nodes with our new editor coming soon (still backward compatible with the Shader Feature Flags) and if you don't like it or just want to quickly add an advanced shader for your platform, you can do so (just call LoadShaderCode(string shaderCode) with your own shader code (works on all platforms) or do it on your own in each platform implementation (like for DirectX 11 you might want way more complex code with geometry shaders, tesslation, pixel and vertex shaders, etc.).

Originally Posted by: PG Go to Quoted Post
I realise that I might extend it in ways that might only be viable on faster hardware - or might not work on older hardware at all (eg perhaps I might not bother doing anything with OpenGL ES 1.x) - but I don't see that as all that different from the fact that DeltaEngine is looking to incorporate advanced things like ragdoll physics. Ok, so advanced physics models incorporated into DE might technically work on any hardware - but in practice it might run too slow on older hardware to really do all that much with... :)


Well, that is hard to answer. If you just use the engine with all the default settings and limitations we put in place, you really have an easy time to write a game that runs great on all platforms. But of course you will have to live with the limitations (e.g. polygon limits or number of meshes allowed per level). Now since the engine is so open you can easily change any of these limitations (both in your content project and of course in the engine code), then things get more complicated.

So in your example: If you use the Shader Feature Flags or Shader Node Editor you can build whatever shader you like, it will still ran fast even on the most limited platforms (like WP7 with no custom shader support) or on crappy old hardware (ES 1.1). It might not look as great as you expect because some fallback will be used, but at least it works and it is fast. And it all happened without you having to optimize for all those platforms yourself.

Another example would be particle effects, you create the best looking effects, but the limitations will reduce your complexity on slower platforms (again, won't look so great there, but still work). Now you have great looking effects on fast platforms and not so great looking, but still very nicely performing particle effects on older slower platforms.

And finally things like Physics or slow Game Code are covered by the limitation how many game updates you can do on slow platforms. So even if Ragdoll is eating up a lot of the CPU cycles, it will only do so a few times per second, the rest of the game will still run fast. As long as you use Physics via the interfaces we provide we can put all these optimizations and more in place, but if you go on your own road and do not use our interfaces and helper classes, you game will still run fine, but you are on your own optimizing it :)

Originally Posted by: PG Go to Quoted Post

(And I don't mean to be critical of BaseShader in asking this. Clearly from seeing SoulCraft and the like it's extremely capable. It's just that I'm a programmer with a maths background and love getting my hands dirty with stuff like low level shader tricks :))


As I just said, you can do whatever you want. We might be a little more closed in the beginning and we probably will keep some things protected in the beta (like the base classes, which should not change too often, it would break everything), but when we have a stable v1.0 release everything will be available and changeable. You can get your hands as dirty as you want.

Currently some things are easy to change (adding stuff on top), other things are a little closed of (like content related classes) because we need to finish our tools and the basics first before all hell can brake lose and people start changing the engine in different directions (we don't want 50 different versions of the Delta Engine in the beta, one is enough to maintain ^^).
Offline elasto  
#10 Posted : Saturday, September 10, 2011 2:40:25 AM(UTC)
elasto

Joined: 8/23/2011(UTC)
Posts: 245

Thanks: 6 times
Was thanked: 12 time(s) in 11 post(s)
Thanks for taking the time to reply (I feel a bit guilty seeing all these verbose posts from you, I don't want to take your time away from getting the engine shipped!)

It seems to me that these two quotes are the crux of the matter:

Quote:
what comes out are just simple .DeltaShader files, which mostly consists of the Shader Code in plain text form (you can see all the code in the Delta.ContentSystem.Rendering.ShaderData class).

For example the simplest shader we have in the fallback Engine content is LineShader2D.DeltaShader, which just contains these two text blocks (vertex and pixel shader, here in the OpenGL version). You can just modify them in code or load anything else if you want to roll it all on your own.
Quote:
and if you don't like it or just want to quickly add an advanced shader for your platform, you can do so (just call LoadShaderCode(string shaderCode) with your own shader code (works on all platforms) or do it on your own in each platform implementation (like for DirectX 11 you might want way more complex code with geometry shaders, tesslation, pixel and vertex shaders, etc.).


Obviously both statements give me a lot of confidence.

There doesn't seem to be anything in the way of public documentation on Delta.ContentSystem.Rendering.ShaderData. Is there anywhere with any more detail on it than http://help.deltaengine.net? Is Shader Code sort of like your own bespoke, slightly higher-level shader language - superseding HLSL/GLSL/etc - and, if so, is there detailed documentation on it publicly available? Or is Shader Code just lots of blocks of code, one for each platform, written in platform specific native code (eg HLSL in one section, GLSL in another etc)?

Edited by user Saturday, September 10, 2011 2:50:17 AM(UTC)  | Reason: Not specified

Offline Benjamin  
#11 Posted : Saturday, September 10, 2011 2:57:53 AM(UTC)
Benjamin

Medals: Admin

Joined: 8/20/2011(UTC)
Posts: 1,421
Location: Hannover

Thanks: 18 times
Was thanked: 97 time(s) in 92 post(s)
No worries, since the ShaderFeatureEditor is now part of v0.8.7 I had to fix it up anyway (we have not used it for many months).

About the documentation, there is quite a bit in the wiki (several pages about the editors, shader data and shader optimization and profiling), which will be ported over to the public wiki in the next few weeks.

Actually the ShaderFeatureEditor saves just out what is in ShaderData, which is just a bunch simple values (flags, vertex format, etc.). This is all visible in the ShaderData class and easily extensible. Here you also have the possibility to "hack" in your own ShaderCode. Normally you will get the optimized shader code back from the content system based on the feature flags (or shader nodes in the future) giving us the opportunity to optimize and fix shaders on the server side plus allow optimizations for teams in need for help.

But again, this is not rocket science, you can just look at the code and in 95% of the shaders you will need it will all work out nicely. If you still want to create some custom stuff outside our system, you kind of on your own (I suggest using something like FX Composer to test your shaders, then put them into the ShaderData and test with some unit tests). But testing shaders in general is easy with all the unit tests (we did the same for the SoulCraftTechDemo in December 2010, but back then we had less tools obviously).

If you want more detailed documentation (in the future ^^) just look at the source code, this is the Save method, which explains the structure of .ShaderData files (in the future additionally to the features there is a list of nodes at the end too). Remember that all of this data is just used for the editors and content servers, the shader implementation classes do not really care about most of this except for the ShaderCode to be send to the GPU:
Code:

			writer.Write(VersionNumber);

			// Save combination of all flags (most important)
			writer.Write((int)Flags);

			// Save the shader code.
			writer.Write(ShaderCode);

			// Save the vertex format
			VertexFormat.Save(writer);

			// And finally the features (they might change from time to time)
			writer.Write(features.Count);
			foreach (IShaderFeature feature in features)
			{
				writer.Write((int)feature.ShaderFeature);
				feature.Save(writer);
			}

			// Shader nodes go here ^^
thanks 1 user thanked Benjamin for this useful post.
elasto on 9/10/2011(UTC)
Offline elasto  
#12 Posted : Saturday, September 10, 2011 3:09:14 AM(UTC)
elasto

Joined: 8/23/2011(UTC)
Posts: 245

Thanks: 6 times
Was thanked: 12 time(s) in 11 post(s)
Ok, I'll keep an eye on the public wiki for when it appears.

Final question: Do you ever sleep? It's 3am there and you're still browsing the boards and being helpful :D

Edited by user Saturday, September 10, 2011 3:11:06 AM(UTC)  | Reason: Not specified

Offline Benjamin  
#13 Posted : Saturday, September 10, 2011 3:24:21 AM(UTC)
Benjamin

Medals: Admin

Joined: 8/20/2011(UTC)
Posts: 1,421
Location: Hannover

Thanks: 18 times
Was thanked: 97 time(s) in 92 post(s)
Still working ^^ Don't sleep much these days .. can sleep when I am dead.

Btw: I am not really browsing in the Forum much, 99% of the time I just get an email (notification feature) and just click on it. Pretty useful feature. Most of the time I do not react on emails quickly (e.g. when I am in the middle of something).

Just made WPF code about 5 times shorter and to celebrate I checked my emails :D This is the whole ExampleWPF tool now, basically 2 lines of code with one extra line for the rendering code:
Code:

		public MainWindow()
		{
			InitializeComponent();

			// Setup the WPF window and create a panel in the ViewportHoster for us
			WindowsApplication.SetEditorWPFWindow(this, ViewportHoster);

			// And finally start the Delta Engine like you normally would
			Application.Start(delegate
			{
				// Line from top left up to bottom right in quadratic space
				Line.Draw(new Point(0, 0), new Point(1, 1), Color.Red);
			});
		}

Offline elasto  
#14 Posted : Saturday, September 10, 2011 3:39:51 AM(UTC)
elasto

Joined: 8/23/2011(UTC)
Posts: 245

Thanks: 6 times
Was thanked: 12 time(s) in 11 post(s)
Aye, I'm signed up to watch all the forums too (except the foreign language ones!)

Really surprises me how quiet these forums are really - and the previous ones. Actually, that was my biggest worry in the beginning when I first came across DE: "This engine seems too good to be true - why isn't it a much much higher profile?!"

My conclusion was that I just really lucked out and have got in on something great right at the ground floor! Hopefully I can do my part in publicizing DE by turning out a top-drawer game for you to showcase :D

Edited by user Saturday, September 10, 2011 3:41:40 AM(UTC)  | Reason: Not specified

Offline Benjamin  
#15 Posted : Saturday, September 10, 2011 3:59:05 AM(UTC)
Benjamin

Medals: Admin

Joined: 8/20/2011(UTC)
Posts: 1,421
Location: Hannover

Thanks: 18 times
Was thanked: 97 time(s) in 92 post(s)
Well in the past there was not much to talk about and the main reason there is not much going on in any of the forums is that no one is moderating it or doing something to produce activity (this forum is only 2 weeks old and we have surpassed the number of posts of the old 2-year old forum 3 times already).

Few years ago I was forum mod of Coding4Fun.de, a bit site hosted by Microsoft Germany with quite a lot of visitors, but the forum never kicked off (I stopped looking there after a while because of inactivity) and then it was closed down.

Few years before that I was in a Starcraft Broodwar clan with just a bunch of people (like 5 active ones), but everyone was in the forum every single day for hours. Few months later everyone had thousands of posts. Remember, no facebook, twitter, social networks crap back then, all you could do on the internet was surf and go in forums ^^

So it all depends on the community. There is not many active users of the engine yet (most just look and don't do anything productive with it yet). Also most game developers are quiet people just lurking around until there is a question they need answered (that is probably why StackOverflow is working so well). I think we will have more than enough activity when the public beta starts and you can do more stuff with the engine each month, we probably need more people helping with support then ..
Rss Feed  Atom Feed
Users browsing this topic
OceanSpiders 2.0
Forum Jump  
You cannot post new topics in this forum.
You cannot reply to topics in this forum.
You cannot delete your posts in this forum.
You cannot edit your posts in this forum.
You cannot create polls in this forum.
You cannot vote in polls in this forum.

Powered by YAF.NET | YAF.NET © 2003-2023, Yet Another Forum.NET
This page was generated in 0.221 seconds.