Freeciv-web now has a 3D WebGL/Three.js version. It is playable in beta on the production server. More details here.
Freeciv-web uses the Three.js 3d engine. The units are from Cimpletoon . Please contact Andreas R. if you are intersted in contributing to this WebGL version of Freeciv-web.
"Many have tried."
"They tried and failed?"
"They tried and died."
- Reverend Mother Helen Moah'im, Dune
There were many efforts to try to produce a Freeciv OpenGL client. This page lists some of these:
#1 
Edit
Discussion, Code and screenshots
#2 Edit
Discussion, Screenshot Source code
#3 Edit
#4 Edit
#5 Edit
Buckyball, The experimental buckyball map viewer project
Summary Edit
These all died because they were too complex. The authors collapsed under the workload quite soon.
If you still wish to do an OpenGL client, my suggestion to you is that you start with just the map, in either the gui-gtk-2.0 or gui-win32 clients, and go for flat terrain and units. (Or you can help out with the buckyball project above...)
- What, no 3D?
- No 3D. 3D graphics on this kind of game are more of a nuisance than anything. None of the top players I know use isometric view for this reason. We only have it for eyecandy. 3D models may be useful for generating the bitmaps however.
- So is it futile to try to do an OpenGL client?
- I did not say that. Zoom is an often requested (and quite useful) feature, which enables you to see more of the map. Rotation may be useful to evaluate a certain tactical situation better (although some also claim this is more nuisance than useful). Alpha blending would be very useful too, but none of our clients does it properly. Not to mention that the OpenGL map backend would be truly multiplatform.
- So why has no one done this yet?
- FYI, I did manage to do a simple OpenGL client just like this in a couple of days(!) But I never managed to get it fast enough. I suspect the common client map core would need deep changes to get top notch OpenGL performance. The current client map core uses (and abuses) offscreen drawing surfaces for buffering. Some OpenGL implementation have really slow offscreen drawing. Another problem is that our terrain is basically multitextured, with many textures per tile (base terrain, with or without blending to adjacent tiles, irrigation, roads, units, etc). Heavy multitexturing with transparent textures is usually pretty slow.
If you have any questions, please feel free to ask them at the freeciv-dev mailing list.
Good luck!
-Vasc.
I have also looked at making a (real) OpenGL mapview. This is harder than it looks. Rotating a flat map would look odd. Adding elevation makes it very hard to add units, cities, terrain improvement and so on. Not to mention that doing the elevation in any sane way is difficult, as well, since you are pretty restricted as to how you can do it (use only existing freeciv maps). A lot of other games (SimCity eg) of elevation by sacrificing some tiles to slopes. We cannot do that. SMAC has smooth slopes but no mountains. We can't do that. One person tried to make a mapview that had rugged mountains that had sharp mountaintops. We can't do that - we might have to draw cities, mines, and so on on it. Some games solve this by having mountains (and rivers) as items between tiles. We can't do that. So if you manage to jump through all those difficulties, can you make it look good? I somehow doubt this. So before you jump into coding a full client - try making a mapview demo, like Bauman's above, that shows how it would look. Per 10:42, 9 Jan 2005 (PST)
A simple solution to mountains with sharp tops having cities on them - turn them into plateaus when they have cities. OpenGL would also allow a nice way to have both mountains and real elevation: have a base height for a tile, so that a mountain on a high elevation would start higher and jut up higher than a mountain next to the see. Inland areas could "bow" upwards. These are just possibilities, and it they certainly don't solve all the problems of making a real 3d terrain.- John Bauman
I am working on a flat (2D) OpenGL client, based on the demo in example 4 above. Work is progressing in a glacial speed. Help would be appreciated. Per 07:41, 14 Mar 2005 (PST)
- reinventing the wheel?
Geez, I'm not intending to flame here, but I checked out the demo and I can't help but think you're trying to reinvent the wheel. Why not use a higher-level OpenGL toolkit? I'm familiar with Open Scene Graph, http://www.openscenegraph.org/, but there are many others.
A higher-level toolkit will not solve the problems mentioned above. They are interface issues, not technical issues. The other issue not mentioned is GUI widgets, and few (if any) OpenGL toolkit have much to offer there. Oh, and they are all (but one) in C++, not C... Per 07:22, 13 Aug 2005 (PDT)
Cairo + Glitz Edit
Now with Cairo, the 2d graphics library, and Glitz, a library that uses OpenGL to accelerate Cairo, it seems like it might be better to use Cairo for the graphics than to make an OpenGL client. It would probably be easier to translate our current methods, it works well with Gtk+, it can do fancy zooms and alphablending, and it can be accelerated using the 3D hardware. If you don't have good 3D hardware, or you can't get cairo to use glitz (very hard/impossible on Windows at this point), it will fall back on software rendering. JohnB 18:25, 11 Feb 2006 (PST)
From Freeciv, a Wikia wiki.
