-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 07.02.2010 21:57, schrieb Mark de Wever: > On Sat, Feb 06, 2010 at 05:27:50PM +0100, Nils Kneuper wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 > >> * One huge topic of discussion was the possible migration to OpenGL. > <snip> >> To find out the current status we tested Frogatto (a sidescrolling game Dave >> is >> currently working on) which uses OpenGL. We tested on these systems: >> - - Gentoo (unstable) with mesa 7.7, Intel 945GM graphics, Core2Duo 1.5GHz >> - - Debian stable with mesa 7.6, Intel 915M graphics, PentiumM 1.6GHz >> - - Ubuntu 9.10, *no* 3D hardware accell!, Intel 500, Atom Z520 1.33GHz > > - Debian stable Radeon HD 3200 on board, AMD 905E quad core 20 fps. > > So pure software rendering with an older distribution and fast CPU is > slow, but frogatto is playable on it.
Okay, I tested frogatto on two more systems at home. 1) Desktop rig with an Intel Core2Quad 9300 (2.5GHz) and a Radeon HD3580 running Gentoo AMD64 unstable series with mesa, libdrm and xf86-video-ati right out of git and kernel 2.6.33-rc7. That one currently suffers under a bug / missing feature and thus basically just shows a black background. If you apply the patch attached in the report I submitted at [1] frogatto plays basically perfectly. Everything smooth and the likes. Though in pure software mode (possible to enforce) it is not really playable. With other words: hardware accel on r6xx/r7xx is fine for the OpenGL needs we have. 2) My old laptop with an Intel Pentium 4 2.8GHz and a Mobility Radeon 9000 (r200 based) running archlinux x86 with mesa 7.7, the whole open source graphics stack and kernel 2.6.32.x. The game runs 100% perfect on this box. No issues observed at all and framerate is fine all the time. Enough with testing speed of opengl on different systems using the open source drivers! Lets get over to the next level: I think by now we basically verified that users should be fine with opengl from a driver perspective. If there are bugs with the drivers we should just report them and be done. The next point is now to see how to implement things. In #wesnoth-dev basically two possibilities were discussed: 1) Using opengl (almost) "directly" via a rather tiny wrapper lib like glew. 2) Using a more complete framework like cairo with their gl backend or glitz or the likes. The benefit of "2" would probably be that we would still have a software mode provided by the render engine without really much overhead on our side. That is I do not know if it will be more work or more difficult relying eg on cairo-gl and if there is a (significant) speed impact. Though I think that software mode via cairo (when everything is switched there and we don't have extra code for invalidating ourselves) might be slower than our current software implementation though probably still faster than opengl via a pure software pipe. So what shall we do now? Any volunteers on checking which way is probably best suited for us? Fendrin already mentioned in #wesnoth-dev that he had a short look at cairo-gl. Sirp on the other hand (plus Jetrel) already know a little about using glew since that is used for frogatto. Feel free to discuss this stuff and propose how to continue. Cheers, Nils Kneuper aka Ivanovic -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (GNU/Linux) iEYEARECAAYFAkt0ApMACgkQfFda9thizwWc2ACdGI6ZwgSPZqSiGCyVFovfaTyg v1YAn2uC9PlmnRQu7Cx2iVIBL4nGifHZ =XPa9 -----END PGP SIGNATURE----- _______________________________________________ Wesnoth-dev mailing list [email protected] https://mail.gna.org/listinfo/wesnoth-dev
