SoC2014 lipkab SDL2

This page is related to Summer of Code 2014

See the list of Summer of Code 2014 Ideas

This is a Summer of Code 2014 student page

Description

lipkab - SDL2 transition

I propose to help with the SDL2 transition.

I'd like to work on implementing hardware accelerated rendering for Wesnoth and enabling it for the map/unit rendering system.

IRC

lipkab

Questionnaire

1) Basics

1.1) Write a small introduction to yourself.

I'm a university student from Budapest, Hungary. I've been an OSS user since my Vista installation committed harakiri somewhen in mid-2009. Although I took a few courses in programming, I'm mostly an autodidact. Besides programming, I like origami, furry animals and pancakes.

1.2) State your preferred email address.

lipkab zoho com

1.3) If you have chosen a nick for IRC and Wesnoth forums, what is it?

lipkab and lipk, respectively.

1.4) Why do you want to participate in summer of code?

I have a number of reasons:

• Do something useful during the summer holiday.
• Get a nice reference in my CV.
• Earn money.

1.5) What are you studying, subject, level and school?

I'm doing my second year on Computer Science BSc at the Pázmány Péter University (Faculty for Information Technology). Well, in fact, I'm formally a Molecular Bionics student, however, in practice I take CS courses and next year I'll be able to officially switch majors.

1.6) What country are you from, at what time are you most likely to be able to join IRC?

I'm Hungarian, I usually join IRC at CET nights on weekdays and at unpredictable times during weekends/holidays.

1.7) Do you have other commitments for the summer period ? Do you plan to take any vacations ? If yes, when.

I don't have other commitments. TODO: vacations?

2) Experience

2.1) What programs/software have you worked on before?

I have written a large number of small programs over the years as school work, or practice. As for bigger ones, I've been contributing to Wesnoth since 2012, and I produced a visual editor for Apertium's transfer rule format during last year's GSoC. That project is put on hold, though, since the concept (converting Apertium's declarative semantic to procedural) made further development very difficult. I'm semi-working on a replacement program for Visruled designed with a slightly different approach to avoid the structural problems of the former.

2.2) Have you developed software in a team environment before? (As opposed to hacking on something on your own)

If Wesnoth development is considered a team environment, yes...

2.3) Have you participated to the Google Summer of Code before? As a mentor or a student? In what project? Were you successful? If not, why?

I successfully participated in GSoC 2013 as a student, see 2.1 for details.

2.4) Are you already involved with any open source development projects? If yes, please describe the project and the scope of your involvement.

I worked with the Apertium folks during last summer and I remained more or less active in the project maintaining and developing the software component I worked on during GSoC (again, see 2.1). I'm also a semi-active Wesnoth developer, my contributions include:

• New storyscreen background WML (was required for the new bigmaps)
• Multiplayer features (modifications, custom add-on options, dependencies)
• MP interface redesign (in collaboration with thunderstruck and Coffee)
• Various bugfixes and PRs

SDL2 related commits:

• Commits 821b009 to 37c7100: fix mouse wheel for SDL2.
• Commit 7b6c125: sdl2 option for SCons.

2.5) Gaming experience - Are you a gamer?

2.5.1) What type of gamer are you?

I don't consider myself a gamer, although there're a few games I can play quite a lot of with.

2.5.2) What type of games?

I prefer brain-working ones like strategy or puzzle games. Some of my favorites are Trine 2, Civilization V and Splice. I also like LEGO games!

2.5.3) What type of opponents do you prefer?

Ones that are challenging to beat but can be beated, so roughly the same skill level.

2.5.4) Are you more interested in story or gameplay?

As above, I mostly play with strategy and puzzle games and there gameplay definitely weighs more than the plot. That being said, I do appreciate an interesting and thoughtful story.

2.5.5) Have you played Wesnoth? If so, tell us roughly for how long and whether you lean towards single player or multiplayer.

I've been playing Wesnoth for roughly 3 years now. I was an SP player initially, but nowadays I play MP almost exclusively partly because I've run out of good campaigns and partly for the greater challenge.

2.6) If you have contributed any patches to Wesnoth, please list them below. You can also list patches that have been submitted but not committed yet and patches that have not been specifically written for GSoC. If you have gained commit access to our repository (during the evaluation period or earlier) please state so.

I have commit access since 2012. I made approximately 100 commits since then, see 2.4 for an overview on their scope.

3) Communication skills

3.1) Though most of our developers are not native English speakers, English is the project's working language. Describe your fluency level in written English.

I had no problem communicating with the team in the last 3 years :)

3.2) What spoken languages are you fluent in?

Hungarian (native) and English. I'd like to believe that I'm also capable of communicating in French.

3.3) Are you good at interacting with other players? Our developer community is friendly, but the player community can be a bit rough.

I can get along with sane people with different opinions reasonably well but I'm not good at handling idiots.

3.4) Do you give constructive advice?

Well, at least I try to.

3.5) Do you receive advice well?

I usually listen to and consider any advice but I tend to be rather insistant on my own ideas.

3.6) Are you good at sorting useful criticisms from useless ones?

I believe so, although I have gotten very little feedback on my contributions for both Wesnoth and Apertium and none of my other works were subject to critique from a wider audience.

3.7) How autonomous are you when developing ? Would you rather discuss intensively changes and not start coding until you know what you want to do or would you rather code a proof of concept to "see how it turn out", taking the risk of having it thrown away if it doesn't match what the project want.

That depends on how confident I'm about what I'm doing and also the impacts of a possible failure. I'm much more careful when risking wasting other people's time than my own.

4) Project

4.1) Did you select a project from our list? If that is the case, what project did you select? What do you want to especially concentrate on?

I've chosen the SDL2 transition project. I'd like to concentrate on revamping the rendering system to make use of SDL2's hardware acceleration facilities.

4.2) If you have invented your own project, please describe the project and the scope.

-

4.3) Why did you choose this project?

I wanted to work on this anyways, getting help and payment for it made it even more appealing.

4.4) Include an estimated timeline for your work on the project. Don't forget to mention special things like "I booked holidays between A and B" and "I got an exam at ABC and won't be doing much then".

Week	Task	Notes	Status
1	Working on ttexture	I'll have exams during this period	Done!
2	Finish ttexture and add texture siblings for any function in sdl_utils that doesn't have an equivalent in ttexture	I'll have exams during this period	Done!
3	Add texture loading to twindow (if it's not yet be there by then), start converting the image cache	No more exams! (I hope)	Done!
4	Finish converting the image cache, and do a lot of testing	If both I and a spritesheet student get accepted, we might have some interference at this part	Done!
5	Start working on the storyscreen. Plan the conversion (semantical changes might be necessary, see below), start implementation
6	Finish the storyscreen	Since this will be the first occasion to put ttexture into real use, I expect that these two weeks will include some bugfixing as well
7	Plan the conversion for display and game_display. Convert the minimap
8	Change function calls in display and game display to use textures instead of surfaces, make it compile
9	Fix any problems with dispay and game_display
10	Write documentation for display & game_display
11	Buffer for delays OR start planning the conversion for the textinput API
12	Buffer for delays OR convert GUI1 and GUI2 to use the textinput API

4.5) Include as much technical detail about your implementation as you can

The first task and one of the cornerstones of the project is a wrapper class for SDL_Texture. This class should encapsulate all functionality related to rendering and manipulating textures. The following functions are required:

1) Load a texture from a file. 2) Rotate the texture. 3) Scale the texture with a given algorithm (BI or NPS). 4) Flip the texture. 5) Set alpha or color blend. 6) Render the texture. 7) Return a surface containing the image data corresponding to the texture's contents.

sdl::ttexture already implements 1 and 6. SDL provides functionality for 2-5, but not necessarily through separate functions; for that reason, the parameters will need to be stored for rotate, scale and flip to be later passed to SDL_RenderCopyEx.

I'd prefer the texture to remember which renderer it's attached to and put the render function into ttexture instead of twindow. This way it's impossible that the user will ever try to render a texture with the wrong renderer.

ttexture will also have to store the dimensions of the image because that needs to be passed to SDL_RenderCopy (the texture is stretched to the window's size otherwise).

Some of the current functionality of sdl_utils can't be (or more precisely shouldn't be) wrapped in ttexture, for example draw_rectangle or draw_solid_tinted_rectangle. These functions will have counterparts providing the same functionality for textures/renderers. A convenience shortcut for rendering text onto a texture instead of drawing it onto a surface then manually converting would be nice, too.

When ttexture is complete, we'll have to make sure that other parts of the program can access it through the established codepaths. Loading textures will happen through twindow.

image.?pp is the other domain which has to be updated. The image cache API need not change too much, but the internals will need some work. The most important change is that with textures lighting, scaling, etc. are all cheap operations so there's no need to flush the caches when for e.g. the zoom factor changes.

I think the storyscreen code is the ideal place to first put ttexture in use. It is rather isolated and simple, still it uses a lot of SDL functionality. The major difficulty with the storyscreen is that the surfaces that are blitted on the screen are assembled from many other surfaces. This behavior could be preserved with SDL2 either by using a software renderer or simply sticking to SDL_Surface, but we'd lose hardware acceleration either way (which is especially important here, because story screen background scaling is currently one of the most noticeable performance bottlenecks of Wesnoth). So, the semantics must be changed to render directly on the screen.

Last but not least the main interface components, display, game_display and the minimap have to be adjusted. The minimap has the same problem as the storyscreen: it assembles a map image from tiles, and then scales the result. The only difference is that scaling isn't required in any intermediate step, so using a software renderer and then creating a texture from the result could be a viable technique here.

I couldn't yet read through display and game_display in detail, but from my researches so far their semantics don't need to be changed, provided the texture API implemented so far behaves similarly to the old surface-based code. It'll still require quite some work to adjust all the calls, though.

When working on display and game_display, I'd like to spare time to write a comprehensive document on these classes to make future modifications easier.

In any extra time left, I could work on updating the event handler to support SDL2's textinput API.

4.6) What do you expect to gain from this project?

A deeper understanding of both SDL2 and Wesnoth's rendering and event handling system. Plus a T-shirt.

4.7) What would make you stay in the Wesnoth community after the conclusion of SOC?

My affiliation with Wesnoth didn't begin with GSoC, so I don't expect it to end with it.

5) Practical considerations

5.1) Are you familiar with any of the following tools or languages?

• Git (used for all commits) yes
• C++ (language used for all the normal source code) yes
• STL, Boost, Sdl (C++ libraries used by Wesnoth) SDL, STL: yes, Boost: somewhat
• Python (optional, mainly used for tools) at a basic level only
• build environments (eg cmake/scons) yes
• WML (the wesnoth specific scenario language) yes
• Lua (used in combination with WML to create scenarios) yes

5.2) Which tools do you normally use for development? Why do you use them?

I use Vim/GVim for smaller projects because of the almost perfect code completion and error detecting features I can get from YCM (a clang integration plugin). For bigger and/or Qt related stuff I use Qt Creator, which I like in particular for its friendly debugger interface and code navigation capabilities.

5.3) What programming languages are you fluent in?

C++, Java, Lua.

5.4) Would you mind talking with your mentor on telephone / internet phone? We would like to have a backup way for communications for the case that somehow emails and IRC do fail. If you are willing to do so, please do list a phone number (including international code) so that we are able to contact you. You should probably *only* add this number in the application for you submit to google since the info in the wiki is available in public. We will *not* make any use of your number unless some case of "there is no way to contact you" does arise!