Remove software rendering as an "official" option
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
widelands |
Fix Released
|
Medium
|
Unassigned |
Bug Description
Software rendering must die! This bug discusses if it can die now.
Here are some reasons:
1) It is SLOW, so slow. It cannot keep up with the ever increasing resolutions of displays. Playing Widelands on 1280x800 at 60fps takes nearly a full CPU in software mode. That leaves no room for logic, AI ....
2) It holds us back with implementing new features. For example, I had a zoom implementation running on my machine for the OpenGL renderer already, but implementing it in the software renderer was too cumbersome and would have been too slow, so I decided to throw it away.
3) It dictates design: The OpenGL implementation could be much more efficient if we bunch up many textures in one big one, the software renderer relies on a texture being one continuous block of memory. Changing the design only for the GL renderer is hard if the other one is still around.
4) It complicates the code. One renderer == simpler, less bugs, less options.
5) It is not necessary: We now use Open GL 2.1 for rendering (Release date: July 2, 2006), no extensions, no magic. This should literally work on any computer that can display graphics. Software rendering was sometimes still needed because we used extensions to the (much older) Open GL 1.1 which some devices did not even bother to implement anymore.
Caveats: we render the minimaps on the homepage using the software renderer (through src/logic/
Thoughts, opinions?
Related branches
- GunChleoc: Approve
-
Diff: 3423 lines (+409/-2210)39 files modifiedsrc/graphic/CMakeLists.txt (+9/-13)
src/graphic/gl/game_renderer.cc (+2/-2)
src/graphic/gl/road_program.cc (+2/-2)
src/graphic/gl/road_program.h (+3/-3)
src/graphic/gl/surface.cc (+0/-171)
src/graphic/gl/surface.h (+0/-68)
src/graphic/gl/surface_screen.cc (+0/-8)
src/graphic/gl/surface_screen.h (+2/-4)
src/graphic/gl/surface_texture.cc (+7/-15)
src/graphic/gl/surface_texture.h (+5/-6)
src/graphic/graphic.cc (+53/-112)
src/graphic/graphic.h (+1/-7)
src/graphic/image_transformations.cc (+1/-9)
src/graphic/sdl/game_renderer.cc (+0/-279)
src/graphic/sdl/game_renderer.h (+0/-55)
src/graphic/sdl/surface.cc (+0/-355)
src/graphic/sdl/surface.h (+0/-77)
src/graphic/sdl/terrain.cc (+0/-34)
src/graphic/sdl/terrain.h (+0/-668)
src/graphic/sdl/utils.cc (+0/-30)
src/graphic/sdl/utils.h (+0/-29)
src/graphic/sdl/vertex.h (+0/-39)
src/graphic/sdl_utils.cc (+28/-0)
src/graphic/sdl_utils.h (+29/-0)
src/graphic/surface.cc (+163/-31)
src/graphic/surface.h (+50/-36)
src/graphic/text/CMakeLists.txt (+1/-0)
src/graphic/text/sdl_ttf_font.cc (+1/-1)
src/graphic/text/test/CMakeLists.txt (+1/-0)
src/graphic/text/test/render_richtext.cc (+19/-5)
src/graphic/texture.cc (+8/-79)
src/graphic/texture.h (+9/-17)
src/logic/map_info.cc (+4/-16)
src/ui_fsmenu/options.cc (+0/-12)
src/ui_fsmenu/options.h (+0/-3)
src/wlapplication.cc (+8/-14)
src/wlapplication.h (+1/-1)
src/wlapplication_messages.cc (+1/-2)
src/wui/mapview.cc (+1/-7)
Changed in widelands: | |
status: | New → Incomplete |
Changed in widelands: | |
importance: | Undecided → Medium |
assignee: | nobody → SirVer (sirver) |
status: | Incomplete → In Progress |
milestone: | none → build19-rc1 |
Changed in widelands: | |
status: | Fix Committed → Fix Released |
I agree.
Regarding the minimaps: What about putting a small render image (png) of the map into the wmf container?
The widelands editor could do this on a save using the opengl renderer (screenshot functionality?).