Closed Ancurio closed 10 years ago
These guys seems to have something figured out. https://play.google.com/store/apps/details?id=net.kernys.rgss
Figured out what? =)
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.
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?
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.
Well, the neko player is closed source, so we'll never know if it had good reference material in it :D
Halfway there =)
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.
Neat. Can we just compile the dependancies on our own then, and put it all together, or is there still work to be done?
There's definitely work left to be done.
Of course you're free to compile it on other GLES2 platforms and experimenting.
Note that the current code still requires OpenGL headers (GL/gl.h) to compile.
Can be compiled with purely GLES2 headers now.
Building on Beaglebone Black gives me a error when it comes to file binding on the makefile. Any ideas?
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?
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.
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
?
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
(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?
There is libruby-static.a and a ruby folder. EDIT: Gotcha, gonna recompile, see what new things happen after enabling shared.
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)
Built, and runs pretty well. Could this be used to further port it to something like Emscripten or NaCl?
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.
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.
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.