 |
|  |
 |
|
targon
|
|
Dolgoprudny, Moscow region
Nov 2002 time: 08:25
|
|
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!).
|
|
|  |
 |
|  |
 |
|
targon
|
|
Dolgoprudny, Moscow region
Nov 2002 time: 08:25
|
|
Hello, is anybody out there
People can't you hear
Can't you hear my cry
Forevermore, Iron Savior
We have 9 "developers" at our sourceforge page (counting Blake), and there is still no feedback concerning vital parts of the game. I hope they're too busy rather then ignorant.
|
|
|  |
 |
|
targon
|
|
Dolgoprudny, Moscow region
Nov 2002 time: 08:25
|
|
BTW, I recomend StPDT developers to hang on game developer community sites, such is gamasutra and some others. Among usual advertizing and scrap, it does contain some interesing articles about game design and development.
|
|
|  |
 |
|  |
 |
|  |
 |
|  |
 |
|  |
 |
|
Vultur
|
 |
Milan
Jun 2000 time: 06:25
|
|
quote: Originally posted by Rasbelin
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. |
ehm... yes I've a couple of big exams, but today I've 10 minutes to this reply thread so these are my ideas:
quote: 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. |
I suggest to keep .PNG format, for many reason: it is a light format and it's opensource. With SDL/SDL_image it's possible to load any 2D thing w/out problems.
quote: Q1.2 Texture bpp. RGB ws. palette. The later is much more compact while requires additional work for loading. |
I think that 32bpp it would be ok. 16 doesn't look good and 24bpp are not supported by all programs, if I remember well. I suggest RGB for coding reason (it's possible to code shadows, flags etc. with few commands)
quote: Q1.3 Texture color scheme. |
No idea.
quote: 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. |
To be designed. I suggest to don't do them too little for obvious reasons. Please try to put the same image with texture different size, so we can decide.
quote: 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!).
|
We need a format that can be manipulated easly by C++ coding.
So if you find a model that works well, with an opensource code for "Mysterious Graphic Actions", please put tell us the references.
I think it's all.
Last edited by Vultur on 31-01-2003 at 00:54
|
|
|  |
 |
|  |
 |
|
targon
|
|
Dolgoprudny, Moscow region
Nov 2002 time: 08:25
|
|
OK, Vultur. I can't say your strike was unstopable, yet it's better than nothing. The only wondering thing is "composite" suggestion about items 2.x 'till end. OK, you said you're too busy. Good luck with your exams.
|
|
|  |
 |
|
targon
|
|
Dolgoprudny, Moscow region
Nov 2002 time: 08:25
|
|
BTW, can't our beloved Coder Team say that graphics engine they plan to (ab)use. The only word may settle ~75% of my questions.
|
|
|  |
 |
|
Vultur
|
 |
Milan
Jun 2000 time: 06:25
|
|
quote:
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. |
.3DS Format it's ok.
quote: 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. |
1000 triangles for any unit is more than enogh, I'think. Remember that is not a simulation game, but a strategy one.
quote: Q2.3 Model animation, i.e. legs motion for soldiers, turrets rotation etc. |
25-30 frames/second per unit. I think we don't need 50-60 frames... For the model:choose your favourite one and use it.
quote: Q2.4 Additonal model info, like particle emitters (dust, fire etc), death sequences, dead units etc. |
Sequences needed:
Fast movement (Run etc.)
Slow movement (Sneak etc.)
Fight - attack
Fight - damaged (optional)
Fight - death
Special Action (depend on the unit: i.e. infantry that dig trenches etc)
Other Optional Sequences:
Surrender
Escape
Mind Probed
Defect
For all animation 1 suggest a sequence of 2-3 seconds.
quote: Q2.5 Unit identification (player colors, player flags, player logo on units etc.) |
Put one common color to each unit (like transparency color of sprites), than it's possible to implement in the game a function that change that color into the player's one.
Player logo... sound interesting. I think it's possible to paste a texture with a logo on a specified part of the unit.
quote: Q2.6 Various stuff directly not related to graphics yet useful (BB for collision etc.) |
If we draw sequences like "unit damaged" we don't need a collision detection, but if you think it's useful to implement it why not?
quote: 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 think Multitexturing will be very usefull for the map drawing, so it's ok.
Other features will be added if we need them.
|
|
|  |
 |
|
targon
|
|
Dolgoprudny, Moscow region
Nov 2002 time: 08:25
|
|
quote: Originally posted by Vultur
I think Multitexturing will be very usefull for the map drawing, so it's ok.
|
Yes, we'll have several advantages:
- free game detail with the same poly count
- eye-candy, modern look
- faster rendering, as programmable vertex/pixel shaders (or "programs") may be used to transfer some features from CPU to 3D card (like env. mapping, skinning etc.)
quote:
Other features will be added if we need them. |
This is exactly the attitude I'm expecting from the StPDT coder team!
|
|
|  |
 |
|  |
All times are GMT. The time now is 05:25. Apolyton Time is 00:25. |
top of page
|
|
|
Forum Rules:
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts
|
HTML code is ON
vB code is ON
Smilies are ON
[IMG] code is ON
|
|
|
|
|
|