Ancurio / mkxp

Free Software implementation of the Ruby Game Scripting System (RGSS)
GNU General Public License v2.0
523 stars 135 forks source link

OpenGL side roadblocks to GLES2 port #43

Closed Ancurio closed 10 years ago

Ancurio commented 10 years ago

Let me preface this with mentioning that I have zero experience working with ES / on mobile. These are just observations I made while looking at the GLES2 specification and docs.

No 32bit index buffers (only 16 supported on ES2) (_DONE:_ 295e0e5b1578301a983f1b3d279035d0575b5906)

The main user of that is Tilemap, where vertex counts often reach multiples of the 16bit limit. This should be resolved with the rewrite to only upload vertices that are on screen.

No PixelStorei(GL_PACK_ROW_LENGTH / SKIP_PIXELS / SKIP_ROWS) support (_DONE:_ b73461721c98c288a85f9fb47858b6e9dd73dddb) (Allowed when GL_EXT_unpack_subimage present)

Easy to work around, create temporary SDL_Surface as intermediate and SubImage from that.

No VAO support (_DONE:_ efb2fd2695f0f205c8e6a9dbc32f0d6b53736741) (Allowed when GL_OES_vertex_array_object present)

Creating a meta path that uses VAOs on desktop GL and BindBuffer/AttribPointer calls on ES is probably not worth it. Just use the latter on both platforms.

No framebuffer blits (_DONE:_ a26c73930d36d79e6080ac0116b42d863ae350ef)

This is a big one. Obviously this will have to be emulated on the ES side via quad draws. There's one place (transition rendering) that draws to a renderbuffer, that needs to be converted to texture too.

Npot textures don't support wrapped sampling (GL_REPEAT) (_DONE:_ 20e46a98dd25ddbc41023be97b7f7ee7f58dfa7d) (Allowed when GL_OES_texture_npot present)

Used in Plane class. Maybe reuse TileQuads utilities?


If you have any other observations / comments / additions, feel free to add them.

moocow1452 commented 10 years ago

These guys seems to have something figured out. https://play.google.com/store/apps/details?id=net.kernys.rgss

Ancurio commented 10 years ago

Figured out what? =)

moocow1452 commented 10 years ago

Some sort of mobile compatibility later with playing MKXP games in Android. Is that not what you were looking for, or would a full GLES2 port be more involved? On Jul 10, 2014 12:49 PM, "Jonas Kulla" notifications@github.com wrote:

Figured out what? =)

— Reply to this email directly or view it on GitHub https://github.com/Ancurio/mkxp/issues/43#issuecomment-48631627.

Ancurio commented 10 years ago

I've known the neko player for quite some time; however, I'm not sure how it's related to the OpenGL usage in mkxp?

moocow1452 commented 10 years ago

Nvm, thought it might have been useful as a reference, but If the architectures are entirely different, guess it doesn't work as a ted of concept. On Jul 10, 2014 2:15 PM, "Jonas Kulla" notifications@github.com wrote:

I've known the neko player for quite some time; however, I'm not sure how it's related to the OpenGL usage in mkxp?

— Reply to this email directly or view it on GitHub https://github.com/Ancurio/mkxp/issues/43#issuecomment-48642708.

Ancurio commented 10 years ago

Well, the neko player is closed source, so we'll never know if it had good reference material in it :D

Ancurio commented 10 years ago

Halfway there =)

Ancurio commented 10 years ago

I now have mkxp running on my Raspberry Pi on a pure OpenGL ES 2.0; some things like text rendering aren't working correctly yet.

moocow1452 commented 10 years ago

Neat. Can we just compile the dependancies on our own then, and put it all together, or is there still work to be done?

Ancurio commented 10 years ago

There's definitely work left to be done.

Of course you're free to compile it on other GLES2 platforms and experimenting.

Ancurio commented 10 years ago

Note that the current code still requires OpenGL headers (GL/gl.h) to compile.

Can be compiled with purely GLES2 headers now.

moocow1452 commented 10 years ago

Building on Beaglebone Black gives me a error when it comes to file binding on the makefile. Any ideas?

http://pastebin.com/L1xbfRZr

Ancurio commented 10 years ago

Looks like libruby is not being linked correctly? Please give me the full compilation output (use make VERBOSE="1" if you're using cmake).

Also, how did you setup ruby? Did you install it from the distribution repository, or did you compile it yourself?

moocow1452 commented 10 years ago

Compiled it myself, can you even download over repos on Raspbian? Also, the build is for beaglebone if that makes a difference over the Pi.

http://pastebin.com/5p4FRs0t

Ancurio commented 10 years ago

Compiled it myself, can you even download over repos on Raspbian?

Yeah sure, it's just debian, apt-get install works fine.

Ok, from the output you've posted, the Makefile is indeed missing a -lruby.. hmm. What's the output you get when you run pkg-config --libs --cflags ruby-2.0?

moocow1452 commented 10 years ago

debian@beaglebone:~$ pkg-config --libs --cflags ruby-2.0 -I/usr/local/include/ruby-2.0.0/armv7l-linux-eabihf -I/usr/local/include/ruby-2.0.0 -Wl,-R -Wl,/usr/local/lib -L/usr/local/lib -lpthread -lrt -ldl -lcrypt -lm

Ancurio commented 10 years ago

(Looks like I accidentally deleted by previous post)

The only explanation I have for this is that you compiled ruby without the shared library, is there even a libruby.so like file in /usr/local/lib/ for you?

moocow1452 commented 10 years ago

There is libruby-static.a and a ruby folder. EDIT: Gotcha, gonna recompile, see what new things happen after enabling shared.

Ancurio commented 10 years ago

Yeah, no dynamic library there. You have two options: 1) Recompile ruby with dynamic library enabled (I think the option is --enable-shared), or 2) just link with the existing static library instead by adding this to the bottom of your CMakeLists.txt:

target_link_libraries(${PROJECT_NAME} /usr/local/lib/libruby-static.a) (http://stackoverflow.com/questions/14077611/how-do-i-tell-cmake-to-link-in-a-static-library-in-the-source-directory)

moocow1452 commented 10 years ago

Built, and runs pretty well. Could this be used to further port it to something like Emscripten or NaCl?

Ancurio commented 10 years ago

Built, and runs pretty well.

You should test how it runs on maps with large amounts of events (>20), that's where performance completely crashed for me due to the Pi's slow CPU.

Could this be used to further port it to something like Emscripten or NaCl?

No idea, that kinda stuff lies outside my knowledge/interest zone. I seem to recall that those environments strictly require applications to be single threaded, which would make a port non trivial.

khkramer commented 10 years ago

Emscripten

Doesn't support code that is multithreaded and uses shared state. JS has threads - web workers - but they cannot share state, instead they pass messages.

NaCI

Does support multithreading with shared memory afaik.