OGS-Main
/
ogs-site
2
0
Fork 0
Code Issues 0 Pull-Requests 0 Releases 0 Wiki Aktivität
Du kannst nicht mehr als 25 Themen auswählen Themen müssen entweder mit einem Buchstaben oder einer Ziffer beginnen. Sie können Bindestriche („-“) enthalten und bis zu 35 Zeichen lang sein.
20 Commits
2 Branches
257MB
Struktur: e567d92541
Branches Tags
${ item.name }
Erstelle Branch ${ searchTerm }
von „e567d92541“
${ noResults }
ogs-site/feeds/news.atom.xml

news.atom.xml 14KB
Originalformat Normale Ansicht Verlauf

Add iOS tutorial june 17 article
vor 7 Jahren
Add 2017-08 scripting research to public
vor 7 Jahren
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
Add 2017-07 article
vor 7 Jahren
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
Add 2017-08 scripting research to public
vor 7 Jahren
Add iOS tutorial june 17 article
vor 7 Jahren
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
Add 2017-08 scripting research to public
vor 7 Jahren
 1234567891011121314151617181920212223242526272829303132333435363738394041424344454647484950515253545556575859606162636465666768697071727374757677787980818283848586878889 
  1. <?xml version="1.0" encoding="utf-8"?>

  2. <feed xmlns="http://www.w3.org/2005/Atom"><title>Opensource Game Studio</title><link href="https://ogstudio.github.io/" rel="alternate"></link><link href="https://ogstudio.github.io/feeds/news.atom.xml" rel="self"></link><id>https://ogstudio.github.io/</id><updated>2017-08-16T00:00:00+07:00</updated><entry><title>Scripting research</title><link href="https://ogstudio.github.io/scripting-research.html" rel="alternate"></link><updated>2017-08-16T00:00:00+07:00</updated><author><name>Opensource Game Studio</name></author><id>tag:ogstudio.github.io,2017-08-16:scripting-research.html</id><summary type="html">&lt;p&gt;&lt;img alt="Scripting research" src="https://ogstudio.github.io/2017-08-scripting-research.png" /&gt;&lt;/p&gt;

  3. &lt;p&gt;This article describes scripting research in July 2017.&lt;/p&gt;

  4. &lt;p&gt;&lt;strong&gt;Our first goal of using a scripting language was to have a platform-independent code that runs unchanged on every supported platform.&lt;/strong&gt;&lt;/p&gt;

  5. &lt;p&gt;OGS Editor 0.10 supports Python for such a code thanks to &lt;a href="http://swig.org/"&gt;SWIG&lt;/a&gt;. SWIG provides a way to wrap almost any C/C++ code and use it in dozens of languages like Python, Ruby, Lua, Java, C#, etc.. SWIG really helped us taste the beauty of platform-independent code. However, SWIG only works one way: from C/C++ to a target language. This means the main application must be in the target language, and C/C++ code can only be used as a library.&lt;/p&gt;

  6. &lt;p&gt;Having the main application in Python works fine for the desktop, but not so great for mobile and web, where C and C++ are the only natively supported cross-platform languages. There are projects like &lt;a href="https://kivy.org"&gt;Kivy&lt;/a&gt;, which allow you to develop cross-platform applications in Python, but they are not supported natively. This means it's a lot of headaches when Android and iOS APIs change.&lt;/p&gt;

  7. &lt;p&gt;Having the main application in C/C++ and the need to support scripting means that a scripting language should be interpreted by the application. This is what SWIG, Kivy, and similar projects are not meant to fulfill.&lt;/p&gt;

  8. &lt;p&gt;&lt;strong&gt;Our secondary goal for using a scripting language was to allow to extend C++ code.&lt;/strong&gt;&lt;/p&gt;

  9. &lt;p&gt;OGS Editor 0.10 has some modules written in C++, and some in Python. The modules are equal from the perspective of the main application; it doesn't care what language the module is written in.&lt;/p&gt;

  10. &lt;p&gt;To achieve such flexibility, we introduced a so-called Environment. Each module would register the keys it responds to, and Environment would deliver corresponding messages. 

  11. Technically such behaviour is achieved by inheriting a base class and overriding its methods in both C++ and a scripting language.&lt;/p&gt;

  12. &lt;p&gt;&lt;strong&gt;First, we evaluated Python for the role of cross-platform scripting language.&lt;/strong&gt;&lt;/p&gt;

  13. &lt;p&gt;Since we already used Python, we started to research the possibility to run Python code on every supported platform. The result was disappointing because CPython (the default Python implementation used on the desktop) does not mention mobile and web platforms. We only found some years old forks of CPython that were claimed to work either on Android or iOS. Such a disarray was not suitable for us.

  14. We also had a look at &lt;a href="http://pypy.org"&gt;PyPy&lt;/a&gt;, another Python implementation. It also did not mention support for mobile and web platforms.&lt;/p&gt;

  15. &lt;p&gt;This was a clear indication that Python community doesn't care for mobile and web platforms. Or that nobody had time to provide the information about building Python on such platforms. Either way, it was not acceptable for us.&lt;/p&gt;

  16. &lt;p&gt;&lt;strong&gt;Second, we evaluated &lt;a href="http://wren.io"&gt;Wren&lt;/a&gt; for the role of cross-platform scripting language.&lt;/strong&gt;&lt;/p&gt;

  17. &lt;p&gt;Wren was the first scripting language we stumbled upon in the long list of non-mainstream scripting languages.&lt;/p&gt;

  18. &lt;p&gt;Wren claimed to be small and easy to learn. Wren also claimed to be intended for embedding in applications. Ironically, the author &lt;a href="http://wren.io/embedding-api.html"&gt;had no time to document how to do the embedding in the first place&lt;/a&gt;. When &lt;a href="https://github.com/munificent/wren/issues/465"&gt;we asked for the time estimates of publishing&lt;/a&gt; the critical part of the documentation, &lt;a href="https://github.com/munificent/wren/issues/402"&gt;we just got a reference to another issue&lt;/a&gt; where the other guy was asking the same question half a year ago!&lt;/p&gt;

  19. &lt;p&gt;That's when we ended our relationship with Wren.&lt;/p&gt;

  20. &lt;p&gt;&lt;strong&gt;Third, we evaluated &lt;a href="http://chaiscript.com"&gt;Chai&lt;/a&gt; for the role of cross-platform scripting language.&lt;/strong&gt;&lt;/p&gt;

  21. &lt;p&gt;Chai was in the long list of non-mainstream scripting languages, too. Chai was promising because it claimed to be specifically tailored for embedding in a C++ application.

  22. We successfully managed to call a C++ function from inside Chai but failed to call a member function. &lt;a href="http://discourse.chaiscript.com/t/cannot-call-a-function-that-accepts-a-string-and-a-vector/334"&gt;We asked for help&lt;/a&gt;, but nobody replied.&lt;/p&gt;

  23. &lt;p&gt;We had to end our relationship with Chai.&lt;/p&gt;

  24. &lt;p&gt;&lt;strong&gt;Fourth, we evaluated Lua for the role of cross-platform scripting language.&lt;/strong&gt;&lt;/p&gt;

  25. &lt;p&gt;Lua is the mainstream language for embedding. So we decided to try the obvious choice. Documentation looked promising, too. However, by the end of reading the &lt;a href="https://www.lua.org/pil/24.html"&gt;C API&lt;/a&gt; chapter we had no clue how to inherit a class inside Lua.&lt;/p&gt;

  26. &lt;p&gt;This led us to search for libraries that wrap Lua C API syntax into something more meaningful for C++. That's how we found &lt;a href="http://sol2.rtfd.io"&gt;Sol2&lt;/a&gt;. Just as before, the first attempt to call a C++ member function from Lua failed. But unlike before, we asked for help and &lt;a href="https://github.com/ThePhD/sol2/issues/465"&gt;got the help&lt;/a&gt;! This was a refreshing surprise for us.

  27. Next, we tried to inherit a class in Lua and override the class methods. We failed, but &lt;a href="https://github.com/ThePhD/sol2/issues/468"&gt;the author helped us out again&lt;/a&gt;. In the end, we succeeded in inheriting a class and overriding its behaviour.&lt;/p&gt;

  28. &lt;p&gt;That's when we understood it's a start for a long and mutual relationship with Sol2/Lua.&lt;/p&gt;

  29. &lt;p&gt;&lt;strong&gt;This search for a scripting language taught us one important lesson: people matter, not technologies.&lt;/strong&gt;&lt;/p&gt;

  30. &lt;p&gt;There are lots of scripting languages that look shiny on the outside but are dead. Why? Because some authors don't have time for users. In return, users don't have time for the authors' projects.&lt;/p&gt;

  31. &lt;p&gt;That's it for describing scripting research in July 2017.&lt;/p&gt;</summary></entry><entry><title>OpenSceneGraph cross-platform guide</title><link href="https://ogstudio.github.io/openscenegraph-cross-platform-guide.html" rel="alternate"></link><updated>2017-07-17T00:00:00+07:00</updated><author><name>Opensource Game Studio</name></author><id>tag:ogstudio.github.io,2017-07-17:openscenegraph-cross-platform-guide.html</id><summary type="html">&lt;p&gt;&lt;img alt="OpenSceneGraph guide" src="https://ogstudio.github.io/2017-07-openscenegraph-guide.png" /&gt;&lt;/p&gt;

  32. &lt;p&gt;This article summarizes the work we did to produce OpenSceneGraph cross-platform guide.&lt;/p&gt;

  33. &lt;p&gt;June marked the finish of &lt;a href="https://github.com/OGStudio/openscenegraph-cross-platform-guide"&gt;OpenSceneGraph cross-platform guide&lt;/a&gt; with the publishing of the last (initially planned) tutorial. The tutorial describes &lt;a href="https://github.com/OGStudio/openscenegraph-cross-platform-guide/tree/master/1.10.SampleWeb"&gt;how to build and run sample OpenSceneGraph application in Web&lt;/a&gt; using Emscripten.

  34. In case you missed it, here's a &lt;a href="https://ogstudio.github.io/openscenegraph-cross-platform-guide/"&gt;link to the final application&lt;/a&gt;. Open it in your web browser.&lt;/p&gt;

  35. &lt;p&gt;We started to compose the guide in February when we successfully managed to render a simple model on mobile and web.

  36. We spent 120 hours in five months to produce ten tutorials of the guide.&lt;/p&gt;

  37. &lt;p&gt;We have been doing OpenSceneGraph cross-platform guide for two main reasons:&lt;/p&gt;

  38. &lt;ol&gt;

  39. &lt;li&gt;Keep OpenSceneGraph cross-platform knowledge in easily accessible and reproducible form&lt;/li&gt;

  40. &lt;li&gt;Share the knowledge with OpenSceneGraph community to make it stronger&lt;/li&gt;

  41. &lt;/ol&gt;

  42. &lt;p&gt;We believe we succeeded in both. Here's why:&lt;/p&gt;

  43. &lt;ol&gt;

  44. &lt;li&gt;The guide repository has more &lt;a href="https://github.com/OGStudio/openscenegraph-cross-platform-guide/stargazers"&gt;stars&lt;/a&gt; (aka "likes") than any other repository of ours&lt;/li&gt;

  45. &lt;li&gt;OpenSceneGraph project leader Robert Osfield said &lt;a href="http://www.mail-archive.com/osg-users@lists.openscenegraph.org/msg74815.html"&gt;"Great work"&lt;/a&gt;, which means a lot&lt;/li&gt;

  46. &lt;li&gt;The guide already has &lt;a href="https://github.com/OGStudio/openscenegraph-cross-platform-guide/issues"&gt;two issues&lt;/a&gt;&lt;/li&gt;

  47. &lt;/ol&gt;

  48. &lt;p&gt;Reaching our goal of researching OpenSceneGraph cross-platform development and providing the knowledge back to the community just made us happier.&lt;/p&gt;

  49. &lt;p&gt;However, our journey does not stop here. Using the knowledge of the guide, we now continue to work on bringing our tools to support mobile and web, just as we &lt;a href="http://opengamestudio.org/lang/en/news/2456"&gt;promised in January&lt;/a&gt;.&lt;/p&gt;

  50. &lt;p&gt;That's it for summarizing the work we did to produce OpenSceneGraph cross-platform guide.&lt;/p&gt;</summary></entry><entry><title>iOS tutorial</title><link href="https://ogstudio.github.io/ios-tutorial.html" rel="alternate"></link><updated>2017-06-08T10:00:00+07:00</updated><author><name>Opensource Game Studio</name></author><id>tag:ogstudio.github.io,2017-06-08:ios-tutorial.html</id><summary type="html">&lt;p&gt;&lt;img alt="iOS tutorial" src="https://ogstudio.github.io/2017-06-08-ios-refactoring.png" /&gt;&lt;/p&gt;

  51. &lt;p&gt;This article describes problems we faced during the creation of iOS tutorial in May 2017.&lt;/p&gt;

  52. &lt;p&gt;&lt;a href="https://twitter.com/OpenGameStudio/status/826816343433498627"&gt;This February&lt;/a&gt; we managed to get simple model rendered under iOS in just a few days. We expected to finish iOS tutorial in no time. However, the reality reminded us: it's easy to come up with a hackish demo that works for one person, but it's hard to create a concise example that works for everyone.&lt;/p&gt;

  53. &lt;h3&gt;Native library&lt;/h3&gt;

  54. &lt;p&gt;The first question we had to answer was: should the sample application be part of Xcode project or be a separately built library?&lt;/p&gt;

  55. &lt;p&gt;We had to consider the following facts:&lt;/p&gt;

  56. &lt;ol&gt;

  57. &lt;li&gt;Xcode project can use C++ directly (thanks to Objective-C++) without stuff like JNI&lt;ul&gt;

  58. &lt;li&gt;There's no need for a separate library (+ application)&lt;/li&gt;

  59. &lt;li&gt;Creating a separate library is an additional work (- library)&lt;/li&gt;

  60. &lt;/ul&gt;

  61. &lt;/li&gt;

  62. &lt;li&gt;OpenSceneGraph builds libraries&lt;ul&gt;

  63. &lt;li&gt;It's easier to use standard build process (+ library)&lt;/li&gt;

  64. &lt;li&gt;It's harder to create custom build process just for a single platform (- application)&lt;/li&gt;

  65. &lt;/ul&gt;

  66. &lt;/li&gt;

  67. &lt;li&gt;OpenSceneGraph uses CMake build system, which is not supported by Xcode&lt;ul&gt;

  68. &lt;li&gt;Xcode project can't include CMake files (- application)&lt;/li&gt;

  69. &lt;li&gt;It's easy to create custom CMake file that includes OpenSceneGraph CMake file to build a single library (+ library)&lt;/li&gt;

  70. &lt;/ul&gt;

  71. &lt;/li&gt;

  72. &lt;li&gt;CMake can generate Xcode project&lt;ul&gt;

  73. &lt;li&gt;It's possible to create a CMake file that builds both OpenSceneGraph and the sample application (+ application)&lt;/li&gt;

  74. &lt;li&gt;Xcode is the de-facto tool to create Xcode projects; it's easier to use standard build process (+ library)&lt;/li&gt;

  75. &lt;/ul&gt;

  76. &lt;/li&gt;

  77. &lt;/ol&gt;

  78. &lt;p&gt;After evaluating the pros and cons of each approach, we decided to turn the sample application into a library and include it in Xcode project. The downside of this approach is that simulator and real device builds need separate library builds.&lt;/p&gt;

  79. &lt;h3&gt;Refactoring&lt;/h3&gt;

  80. &lt;p&gt;The second question we had to answer was: should there be a single source code base for all platforms or several ones, one for each platform?&lt;/p&gt;

  81. &lt;p&gt;While doing Android tutorial we used single source code base because it worked fine for desktop and Android. As we started to work through iOS tutorial, it became apparent that particular features may or may not work on some platforms. For example, one feature may work on desktop and iOS, but not Android. Another feature may work on iOS and Android, but not desktop. Since we didn't want to pollute the code with #ifdefs, we started to put each platform combination into a separate file. The number of files grew rapidly. The files were reusable, but it became extremely hard to see the whole picture.&lt;/p&gt;

  82. &lt;p&gt;At this point, we realized there's the second question. We reminded ourselves that the main purpose of the sample source code is to teach how to do basic OpenSceneGraph things, not create a reusable library with API that is stable across several years.&lt;/p&gt;

  83. &lt;p&gt;That's when our home grown feature tool came into play. With its help, we separated the code into several parts, which in the end produce just two files for each platform:&lt;/p&gt;

  84. &lt;ol&gt;

  85. &lt;li&gt;functions.h - contains reusable classless functions&lt;/li&gt;

  86. &lt;li&gt;main.h - contains the rest of the sample application code&lt;/li&gt;

  87. &lt;/ol&gt;

  88. &lt;p&gt;Their contents differ slightly for each platform, but it's easy to see the whole picture now.&lt;/p&gt;

  89. &lt;p&gt;That's it for describing problems we faced during the creation of iOS tutorial in May 2017.&lt;/p&gt;</summary></entry></feed>