opengl

[michal]

I've seen openxcom build for amiga. But probably there are not many users.

Btw, you may be interested in this (visits on openxcom page in august):

[Daiky]

SDL/Software is probably still the way to go until 1.0 where all standard features are implemented.
And then people wanting to port to other devices can do so branching of from 1.0, while openxcom itself switches to opengl after 1.0 - given that I will have the opengl engine finished by that time to replace the SDL/Software engine?
No need to support both this way.

[SupSuper]

Graphics bitdepth converting could be done on-the-fly during resource loading. Paletted/not paletted actually doesn't matter.
Actually UFO1/2 doesn't have any of palette "scrolling" effects. DogFight stage done with simple re-drawing, battlescape "alien entertainment" tiles or any other animated things - same. Game palette is absolutely stable.

Whether you're doing the effects through palette manipulation or texture manipulation on the fly, it's not very efficient on hardware, unless you use shaders or something.

I agree with michal that in the end it would probably be best to have everything rendered in OpenGL (once it has no disadvantages over SDL rendering), both retro and modern. Supporting various graphics APIs would become a maintenance nightmare.

Shouldn't there be a backup option if your system does not support OpenGL (properly)?

Also if switching entirely to OpenGL is the way to go, there is no reason to first waste time on implementing a system that can support both and then throwing all that code away to go back to a system that only supports one of them...

Well optimally SDL would be doing the whole "pick the best graphic API based on the platform" job for us, but... we can keep waiting for the mythical 1.3?

I just think that there's no advantage in supporting SDL software rendering in the long-run when it's nothing but slow and clunky, and the few platforms that don't support OpenGL probably can't take the performance hit from SDL either. Plus the differences between SDL software rendering and OpenGL rendering are big enough that you'd basically be splitting the codebase in two.

SDL/Software is probably still the way to go until 1.0 where all standard features are implemented.
And then people wanting to port to other devices can do so branching of from 1.0, while openxcom itself switches to opengl after 1.0 - given that I will have the opengl engine finished by that time to replace the SDL/Software engine?
No need to support both this way.

That sounds good.

[Volutar]

Whether you're doing the effects through palette manipulation or texture manipulation on the fly, it's not very efficient on hardware, unless you use shaders or something.

What for? Even original XCOM doesn't have palette effects.
I said about palette converting on-the-fly during resource loading, and not about converting each frame.

[SupSuper]

Whether you're doing the effects through palette manipulation or texture manipulation on the fly, it's not very efficient on hardware, unless you use shaders or something.

What for? Even original XCOM doesn't have palette effects.
I said about palette converting on-the-fly during resource loading, and not about converting each frame.

I was referring to this: "DogFight stage done with simple re-drawing, battlescape "alien entertainment" tiles or any other animated things - same."
Redrawing textures isn't very efficient hardware-wise AFAIK.

[Volutar]

And I was talking about redrawing whole screen in original xcom!
Palette technique involves palette-only modification without touching screen bytes. It's not the case.

[Daiky]

Shaders is the only way I know how to do this on hardware. You don't want to transfer textures back and forward from video memory to system memory, then you loose the advantage of using video acceleration all together.

I'm reading up on how to do isometric tile drawing entirely on the GPU with shaders:
You got one texture buffer which holds all the sprite sheets needed for the specific type of terrain.
You got one texture buffer which holds the data of which sprite to draw where on the screen and how dark (and maybe opacity?)
Just one call renders the whole battlescape.

[Volutar]

Shaders???  
Excuse me, but what for???
What's wrong with drawing quads with game graphics as textures? Even Z-buffer could be disabled, if tiles will be rendered in proper z-order (as they are at the moment).

"Texture sheet" actually called texture atlas, and can be used with classic quad-rendering tech. These atlases have to be built at graphics loading stage, because one GPU supports 4096x4096 texture maximum, another - 1024x1024, pre-building isn't an option. And... no need of massive texture transfer each frame!!!


Gosh...

Going shaders will instantly kill possibilitiy of porting application to other platforms, like ios or android...

[Daiky]

Sorry, I don't have a lot of OpenGL knowledge yet. But how does lighting and shadows work with just drawing quads then?

PS. I'm just looking into other popular opensource isometric engines that work with OpenGL (there are not *that* many). Because I don't want to re-invent the wheel from scratch...

[michal]

Just wanted to say, that Ufo: TTS also uses rendering using quads. Shaders are only used for buffer outside map (that gray area).

[Daiky]

yes, the grey area is a nice example.
But also having smooth lighting/shadows (instead of lighting per tile) is an example.

I will not mention the word "shaders" again - as it seems to be cursed :p
You know lots of 2D games use them right? Smooth fog of war is another example.

[michal]

Well, i guess usage of shaders could be nice for extra effects. But maybe it should be optional?

[Daiky]

Sure, I just found it interesting to read actually because I did not know it was possible, but it probably has a lot of limits - I was not that far into it yet.

[Volutar]

Obviously shaders used for visual effects only. Battlescape lighting is part of gameplay, and cannot be just "redone" without consequences. So "classic" tiled xcom should use textured quads (tiles) with lighting without any shade "smoothing". Vertex lighting is possible only in real 3D with 3D tiles. If you try to use shadowmap lighting, a number of challenges will occur, which will heavily affect gameplay.

Options that could be achieved:
1. Classic: Quad rendering of tile textures (from atlas) with "flat" shading of each tile (maximum possible fps).
2. Easy: "Smoothed" vertex shading of 3D textured tiles (low or mid-poly models) plus shadow blobs under units/objects. IMHO very nice option, with neat cartoon-like appearence very close to original.
3. Hard: High-detailed 3D scene with hard/soft shadow maps from sun and different light sources. This will lead to deep gameplay modification, AI and LOS calculation. IMHO it will be quite huge step away from original xcom, though could be done nice. And apparently will exclude platforms which aint capable to handle such details and shading.

[Daiky]

Yeah, implementing realistic shadow/lighting results in a change of gameplay. We noticed this when I implemented the light blocking.
It might not be wanted in a strategic game.
We probably don't want to add in eye candy just for the sake of making prettier screenshot. Got to keep focus on gameplay.

Some kind of shadow blobs is already there for bullets, so it wouldn't be too hard to have the same kind of shadow blobs below units, especially for flying units this might be interesting. Because they give a better idea of a unit that is standing on the ground, or it is floating in the air.