Graphics standards

[Kurilka]

As of questions:
Q1.* seem to be up to designers (to you targon) and from my point of view big size (rgb vs palette) is not so scary thing in our time, so RGB (or +alpha?) will be simple and good enough...
Q2.3 - what are you familiar with? And what are the alternatives?
I don't think that we need very complex animation as our units won't be very large, but it should be not very primitive and the best option is to have something extensible (at first no anim, then primitive one and then more and more cool)

[Vultur]

Vultur Strikes Back

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:

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.

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)

Q1.3 Texture color scheme.

No idea.

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.

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.

[Jeremy Buloch]

Thanks Vultur.
-J.B.-

[targon]

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.

[Kurilka]

targon - what about animation?
it there something good enough?

[targon]

Of course, there are a plenty of choices.
For example, we may employ Open Dynamics Engine (http://opende.sourceforge.net), but I think it may be way too big for strategic game (while good simulation of movements is really attractive. Just remember how good was unit movement in TotAn). There are several other opensource collision detection and animation toolkits, and almost any "fat" scenegraph offers some support for animation.
On other hand, we may simply write it by hand... we needn't any spectacular, simple keyframing or script animation may be OK.

[targon]

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]

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.

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.

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.

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.

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.

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?

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]

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.)

Other features will be added if we need them.

This is exactly the attitude I'm expecting from the StPDT coder team!

[DeathByTheSword]

just one Q: i just would like to know what kind of minium requirements is everyone thinking of when making this game?

[Rasbelin]

The old requirements for the StP client (Windows version) were around PII 300 MHz (or equivalent) and 32/64 Mb RAM. The server has much lower sys. requirements. But as the graphics have changed to OpenGL, you will need a graphics accelerator that supports OpenGL (or actually the drivers are the crucial issue). Keyboard, mouse and sound card/APU, plus a monitor that can display a resolution of 800x600 (or more). OS requirements: Win 9x/ME/2000/XP or Linux with kernel 2.1.x (not sure about it yet, depends very much if you have all the necessary libraries). Generally speaking I would say that the system requirements for the StP client recall of Civ III's sys. requirements.

[Jeremy Buloch]

AHH! thats a problem one of my computers cant support OpenGL. At least my 2000, XP one can.
-J.B.-

[Rasbelin]

It's your problem, not our.

[Jeremy Buloch]

Haha Very funny Rasbey.
-J.B.-

[Rasbelin]

I'm simply stating that we can't ensure the game works with every graphics accelerator out there. If your GPU is outdated, get a new one or don't play. The system requirement for the graphics accelerator isn't that high after all as OpenGL hardware/driver support isn't that new anymore. I could also whine that the StP client won't work with my old Matrox Millenium 4 Mb, but I don't see any reason to do so.