Tweet
The purpose of this thread is to elaborate current state of Stella Polaris graphics workshop. While I can't currently spot any code development, I still hope it's temporary state.
Currently I can see just two persons willing to do somethng with StP graphics design. Namely, Jeremy Buloch and me. While the current work in the Graphics Sections seems to be not too tight and fast paced, I think that we must negotiate with coders so our work will remain useful rather than lost in time like paper in loo.
I've got several questions while thinking about and working around unit models.
1. Texture matters.
Q1.1 Texture format. Long-long ago, PNG was accepted for sprite graphics. It may be still good, as it's loseless and has alpha.
Q1.2 Texture bpp. RGB ws. palette. The later is much more compact while requires additional work for loading.
Q1.3 Texture color scheme.
Q1.4 Texture size. Standards are nxm where n, m must be 2^(some integer). Usualy n==m. Obviously, it's download size/quality tradeof.
2. Model meshes.
Q2.1 Model format. .3ds is good as interchange, but even inside .3ds there are two flavors: binary .3ds and text .asc. Other formats may be reviewed, too.
Q2.2 Model size. I currently estimate reasonable model size around 500-1000 triangles. It isn't any big for reasonable modern (1-2 yrs. old) graphics boards. Modern ones may easily support 10x.
Q2.3 Model animation, i.e. legs motion for soldiers, turrets rotation etc.
Q2.4 Additonal model info, like particle emitters (dust, fire etc), death sequences, dead units etc.
Q2.5 Unit identification (player colors, player flags, player logo on units etc.)
Q2.6 Various stuff directly not related to graphics yet useful (BB for collision etc.)
Q2.7 Model optimization (fans, strips etc.)
3. General and misc.
Q3.1 Multitexturing support, i.e.
Q3.2 Bump mapping,
Q3.3 Cubic environment mapping.
Q3.4 Vertex and pixel shaders (register combiners are junk!).
Currently I can see just two persons willing to do somethng with StP graphics design. Namely, Jeremy Buloch and me. While the current work in the Graphics Sections seems to be not too tight and fast paced, I think that we must negotiate with coders so our work will remain useful rather than lost in time like paper in loo.
I've got several questions while thinking about and working around unit models.
1. Texture matters.
Q1.1 Texture format. Long-long ago, PNG was accepted for sprite graphics. It may be still good, as it's loseless and has alpha.
Q1.2 Texture bpp. RGB ws. palette. The later is much more compact while requires additional work for loading.
Q1.3 Texture color scheme.
Q1.4 Texture size. Standards are nxm where n, m must be 2^(some integer). Usualy n==m. Obviously, it's download size/quality tradeof.
2. Model meshes.
Q2.1 Model format. .3ds is good as interchange, but even inside .3ds there are two flavors: binary .3ds and text .asc. Other formats may be reviewed, too.
Q2.2 Model size. I currently estimate reasonable model size around 500-1000 triangles. It isn't any big for reasonable modern (1-2 yrs. old) graphics boards. Modern ones may easily support 10x.
Q2.3 Model animation, i.e. legs motion for soldiers, turrets rotation etc.
Q2.4 Additonal model info, like particle emitters (dust, fire etc), death sequences, dead units etc.
Q2.5 Unit identification (player colors, player flags, player logo on units etc.)
Q2.6 Various stuff directly not related to graphics yet useful (BB for collision etc.)
Q2.7 Model optimization (fans, strips etc.)
3. General and misc.
Q3.1 Multitexturing support, i.e.
Q3.2 Bump mapping,
Q3.3 Cubic environment mapping.
Q3.4 Vertex and pixel shaders (register combiners are junk!).
I don't have anything to say really about the questions. I hope that you can together settle the issues so that we don't get something that doesn't work or is a bad solution.
I think I'm registered on Gamasutra, but I've never used that account. I usually read news and articles. 
As for Vultur, I could say that he has at least one larger exam at the polytechnic school now, so he won't have time to comment, I suppose. I agree that we would need an experienced developer, but the problem is that Blake has disappeared and none of the earlier attempts resulted in contacts from any experienced C++ developers (if we mean ones that are almost pro). Anyway, Kurilka and Gowyn came from SourceForge, which is something positive.
Comment