User:Kozmo
From Unknown Horizons - Wiki
Contents |
An introduction
Hi, I'm a student of Automatics and Robotic, currently 3rd year, from Poland. Just an ordinary guy with the interest to code. I speak in English and of course natively in Polish. Google Summer of Code would be my first chance to work on something bigger with a group of people that have at least one thing in common - they do it for fun, not just for money. I also am looking forward to learn a few things from group work. And I've never taken part in GSoC before.
Contact
I can be found by the nick kozmo or a combination of 'o' with '0' if that's already taken. Poland, Europe so GMT+2 (summer time). I don't have any plans which would change that time zone. I can allocate at least 10 hours per week to work on SoC tasks. My upper bound would be 20 hours. So the average would be something like 15 hours which I think is reasonable time for me to implement the requested features and tasks.
Coding experience
My experience with python consists of: making simple parsers using regexp, generators from .spec file for my personal use and a simple apps. For everything else C++ is my language of choice. I had few mid-sized projects like application for solving the Job Shop Problem using various genetic algorithms or the ECG - which consisted of designing and making the PCB with discrete elements (operational amps, active filters) and a microcontroller on it to sample and send the data, making the home-brew probes and of course the application to see the ECG signal itself. There was also an application for MATLAB to generate the artificial signal from the set of parameters with a nice GUI. My job was to make a PCB, programme uC and make the application (scope). It was a 3-guy projects and that was probably my the biggest group I work with. We used the git as a control version system.
At present I work on a OpenGL 3.3 framework with a friend of mine - also using a git. I'm pretty happy with results so far - we only use the core stuff without the deprecated ones and try to make it optimized. From all my projects I could learn how to cooperate with a small group of people and how to divide the job across them. I also polished my coding experience. I don't consider myself as a c++ mastah and I think I can learn very much from different kind of coders. However I can honestly say my programming skills (especially C++) are pretty good.
Feeling fine
Mailing lists - currently signed up in one, dedicated for our science club which work on Embedded systems. As for IRC, I have a simple opera bundled client to use. It's got all I needed so far. I used a git for few of my projects with a co-workers so far. Recently I also tried the TortoiseGit which really make it easy. Never really needed to use trac and like-ones app, we simply use a TODO list. Had to use wiki stuff, especially to describe the end product of the projects. Normally I work on Windows and use here Visual Studio or QtCreator. VS has a great debugger but QtCreator which uses gdb isn't that bad. From version to version its debugger capabilities and user-friendly interface is getting better and better. In linux, which I work from time to time, I use gdb from codeblocks or directly from console if it's pretty simple program. For python apps only gdb since I've never bothered to make VS works with python. As for c++ and its binding to any other language I just know it's pretty hard and can be messy in the contrary to his older brother, c. But there are some toolkits to make it easier, like SWIG. To be honest I really like the 2.5D engines since it reminds me the good old days (SimCity 2000, first anno, transport tycoon, *craft series, AoE). Will remain active after GSoC is over since I love the idea of open source projects. Maybe even try to port it to OpenGL ES 1.1 and make it work on embedded devices
Game genre
Mostly I really like the RTS and FPS to a certain extent. As for Anno series, only the first part since I had have oldie PC for some time. My recent RTS'es was Warcraft III and World in Conflict. And also I like to play OpenTTD in spare moments.
Implementing own solutions, creativity
When in secondary school, I was interested with Deplhi and its Omega components (2D/3D rendering) and made few simple mini-games. Currently I'm creating fairly advanced, OpenGL based framework. I got already few pretty advanced-topic demos running slim. Have in mind to make it work on growing market which is android.
Only out of interest
I'd be honest. About UH I've only heard on that page http://www.lingames.cba.pl/Unknown_Horizons,gra,337.html. There was a time I was interest in some free games, mostly on linux so I took a peak. Then, after a GSoc list of organizations was announced I saw your position and it kinda striked me. I really want to work, directed or only related, on OpenGL stuff. There was a few positions that needed opengl coder too, but none of them was about izometric engine.
Prerequisites
I have Windows 7 and linux (arch) currently installed on my machine - laptop. I work on both, depending on the type of work to be done and the mood. Every day I have at least 4 hour window in which I can access pc with projects I'm working on (at home). On university I have access to internet via Wi-Fi and for the most of the time I carry laptop with me. The machine is exclusively mine so I can mess with it without any constraints.
Self-assessment
If the criticism is constructive then it's a good criticism. A whole point of being a student is to ask and make mistakes so he wouldn't make it in real life. I like to have just a tiny starting point, code and then evaluate how it turned out. I believe you can't really foresee everything and plan it in details, there's always gonna be things you didn't consider. And if all that you did is a trash, you learn it the hard way.
Your task
I would like to take the part in improving overall performance of the FIFE. I discussed extensively on IRC channel what could and what should be done in that matter. Few things that need to be stressed up are:
- Make the use of multi texturing (hardware accelerated) instead of simply modifying all pixels manually on CPU (colored tile sets). I showed a simple demo how it can be done to vtchill, if there's a will to stick to actual formula (0.5 * texture + 0.5 * color) that 1.3 OpenGL is required. If that formula can be changed 1.2 or even lower depending on used feature. It's the most visible performance killer, at least for me. Already have a proof of concept, should be done in one week, two at most.
- Implement Atlases - preferably one for each of layers, consisting of animations (like fishes or deers) and tile sets also. Currently the greatest drawback from using atlases - mipmaps - isn't used in the engine so introducing it to engine would be pretty straight forward. Atlases would be made on-the-fly (so transparent to end-user) and saved on disk to further usage (with some control sum to check if it's need to be reproduced). If there would be a will to start using mipmaps (which I believe, depends on getting rid off of modifying textures software - really slow + mips reproduction on-the-fly = horrible slow) then few additional constraints should need to be introduced (same size textures on one atlas) or just make the implementation more robust (already have few ideas which simply rely on one condition - no usage of repeat addressing of textures - it's currently used nowhere in the engine). In the basic form which is generating atlases per layer at run-time and saving it for next game runs without mipmaps supported should take 2 weeks, with few issues - 3. The mipmap cases is doable but it needs a bit more attention (week or so)
- Instead of locking SDL surface, write to it simple polygons (CPU job), unlock and send it to the driver, better render directly to backbuffer and copy its contents to designated texture (or better - FBO for cards that support it). Also I think that GUI controls could benefit from it the most - you render to texture and then simply draw whole UI with one command. If the gui needs to be updated (user interacted) you render to the same texture again and use it again for n frames. I believe that's how it's done in most current version of CEGUI and other open-source gui libraries. Should be pretty easy to add/change, even with the fallback features for older cards. One week should be enough.
- Batching - Make as few as possible draw calls and state changes (performance killer). The best case would be one draw call for each of the layers (needs atlases or texture_arrays, but that's G80+) and then draw GUI controls as last. Using VBO with dynamic data is the same as VA so it isn't really a must-have (especially with less than few thousand vertices). That's a bit tricky, could take even a month but it's worth the time. This and all before should be done just in time for midterm evaluation (at least the working version without the final polishing).
- Make the OpenGL renderbackend simply independent of SDL (but leave the SDL_image stuff, somehow .png or other images must be loaded). I believe the point of using opengl is to get the best performance you can by using hardware accelerated rendering. That would include some code refactoring to get rid off of dependencies since most of the changes should be already done (previous 2 points and the first one). After it's done most of the currently features and optimizations should be implemented (milestone).
- If everything would go slim, try to take care of GUI module - make it independent of used GUI library and more OpenGL states friendly - perfectly designed GUI libraries only need one state and few draw calls for each frame (some even cache it to texture).
To summarize, make the renderbackend better and faster in every aspects and staying with low requirements (OpenGL 1.2 or 1.3 at most) at the same time.
As for the expected time line I roughly estimate the first two things done in one month (+- a week). Next ones can be done in similar time frame (maybe bit longer). The first two aspects of improvement are the first milestone as currently it looks like the greatest bottleneck and performance killer (on the UH example). I believe making it done would be the most visible change.
Timeline
May 24 - June 1
- adding the multi texture feature for tile sets coloring.
June 2 - June 31
- implementing atlases and texture caching.
- coding a render to texture feature.
- using framebuffer extension and a OpenGL 1.1 method of copying backbuffer directly to texture as a fallback for older cards.
July 1 - July 31
- implementing batching.
- completely cut loose the OpenGL renderer class of SDL.
August
- if the time allows - making the GUI rendering (text and UI controls) more OpenGL friendly.
- polishing and documenting the code.
