CCing the list again, as your previous answer went directly to me only.<br><br>Den lørdag 19. mars 2016 skrev chenbo li <<a href="mailto:lichenbo1949@gmail.com">lichenbo1949@gmail.com</a>> følgende:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div>Thank you, Einar and Thierry. That makes a lot of sense for the upcoming work. </div><div><br></div><div>Since the translation-related work might not fill the project, do you think adding the GUI or the HW blitting work (or part of it) could be a reasonable add-up for the summer? </div></div></blockquote><div><br></div><div>The gui task has more direct relation to the i18n task, but yeah. </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><br></div><div>Also for the hardware blitting project, since different platforms might have different GL features supported, it has to be a lot of detail works of each platform rather than just a wrapper which can work for all, right? And maybe that’s the where most time spent in this task (tuning for different platforms)?</div></div></blockquote><div><br></div><div>Not all platforms have GL either, but they may have some platform specific api for HW accelleration of 2d. So much of the task is research into how such an interface would be designed in a way that allows it to be implemented on as wide an array of backends as possible. The exact implementation for the backends might not be in scope, I.e it would suffice to implement a GL implementation and demonstrate that it is designed to be feasible to implement on some of the other backends.<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><br></div><div>Then for the testing, since I don’t have that much devices, the testing could be another problem especially for the hardware blitting task. How would that go for the project?</div></div></blockquote><div><br></div><div>The interesting question is what devices you DO have available, and then we can work from there. At least some desktop testing would obviously be required.</div><div><span></span> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><br></div><div>Thank you.</div><div><br></div><div>Best regards,</div><div>Chenbo Li</div><br><div><blockquote type="cite"><div>On Mar 19, 2016, at 5:17 AM, Einar Johan Trøan Sømåen <<a href="javascript:_e(%7B%7D,'cvml','einarjohants@gmail.com');" target="_blank">einarjohants@gmail.com</a>> wrote:</div><br><div><br><br>Den lørdag 19. mars 2016 skrev chenbo li <<a href="javascript:_e(%7B%7D,'cvml','lichenbo1949@gmail.com');" target="_blank">lichenbo1949@gmail.com</a>>:<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
So I joined the IRC and have some simple discussion with the developers. Then I knew that the reason is because some of the retro machine has strict memory limit, and it’s unlikely to store the whole UTF-8 or other font file (or it would be a huge waste). But it would’t be a problem with relatively modern platform like Windows or OS X. So we came up with the idea that we could use compiler flag to built in different platform with different language profiles. And that’s just my first idea on how to do it. In order to get familiar with the translation related work, I’ve already translated the GUI of ScummVM into Romanized Chinese with use the standard English alphabets and could fit into the current system. (Pull Request #712)<br>
<br><br></blockquote><div>As far as I know we have some degree of utf32 support available for engines, when they are using TTF fonts, but I have no clue how extensible that is to the launcher and GUI in general. It might not be quite enough work to fill 12 weeks though.<span></span></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
* Improve GUI - I like to make nice looking GUI (Are we reconstructing the GUI system?)<br>
* Hardware accelerated blitting - I have experience in C++ and OpenGL (Actually I don’t quite get it, I guess you just draw a quad filling the window with bitmap textures and blit it?)</blockquote><div><br></div>Well, the challenge is somewhat more complex than that. The point of the task would be to implement an interface for HW accelerated blitting that can be implemented on a variety of platforms, beyond what GL offers (AmigaOS 4, PSP etc). The interface can thus not expose GL itself, but it could wrap it.<div><br></div><div>There is a rather large possibility for speeding up some of the newer games a fair amount with this.<br><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
* Native OS X port - I have a Mac, but no Obj-C experience (But I’d like to do the transport from SDL to SDL2, if that’s still part of the plan)<br>
<br></blockquote><div>The point of this task is to have an OS X backend that doesn't use SDL(2) at all. So the implementation would be in native APIs (Cocoa)</div><div><br></div><div> Hope that clears up a few of your questions.</div></div><div><br></div><div>Kind regards</div><div>Einar Johan Trøan Sømåen </div>
</div></blockquote></div><br></div></blockquote>