Author Topic: Port Request: Cube  (Read 3820 times)

xXFrostXx (OP)

  • * Former Staff
  • Posts: 234
Port Request: Cube
« on: May 31, 2015, 03:32:12 am »
I'm curious as to if this is possible to port. It's a game called Cube. It uses OpenGL ES already as far as I know, or at least it was ported to OpenGL ES. I believe it uses the same engine as Quake at its core, which means it should be able to run on the GCW-Zero.

Here is a link to the homepage: http://cubeengine.com/cube.php
Dingoonity is the place to be!

Aeter

  • *
  • Posts: 322
Re: Port Request: Cube
« Reply #1 on: May 31, 2015, 05:53:51 pm »
This seriously looks pretty damn cool.
~cucullus non facit monachum~

xXFrostXx (OP)

  • * Former Staff
  • Posts: 234
Re: Port Request: Cube
« Reply #2 on: May 31, 2015, 11:03:10 pm »
This seriously looks pretty damn cool.

You should give the PC version a try until someone looks at this. ;D
Camera movement shouldn't be an issue on the GCW-Zero, because the game doesn't use very many controls, so camera could be mapped to A, B, X, Y... similar to what a PSP does.

The level editor uses many controls however, so it may need to be removed from the GCW-Zero version.
Dingoonity is the place to be!

alexei_gp

  • *
  • Posts: 236
Re: Port Request: Cube
« Reply #3 on: September 28, 2015, 06:28:56 am »
I want so badly to see this game ported to the gcw zero,i dont mind to be beta tester of this game on the gcw zero  ;D.I hope cube 2 and the flare port get a good conversion for our little handheld :) .

Ryvan

  • *
  • Posts: 52
Re: Port Request: Cube
« Reply #4 on: September 28, 2015, 02:56:27 pm »
Provided it could be done, this seems like a good idea.

I've played AssaultCube before, which can be quite fun once you get the hang of it. I doubt it would be too hard for any developer to port. Based on a quick look through the source code for it, the cube engine (not cube2) seems to only require SDL (main, image, mixer), zlib, and fmod.

David Knight

  • **
  • Posts: 577
Re: Port Request: Cube
« Reply #5 on: September 28, 2015, 04:06:16 pm »
Provided it could be done, this seems like a good idea.

I've played AssaultCube before, which can be quite fun once you get the hang of it. I doubt it would be too hard for any developer to port. Based on a quick look through the source code for it, the cube engine (not cube2) seems to only require SDL (main, image, mixer), zlib, and fmod.

And X11 and OpenGL. Not possible to port without a conversion to OpenGLES2.

Ryvan

  • *
  • Posts: 52
Re: Port Request: Cube
« Reply #6 on: September 28, 2015, 04:29:11 pm »
That's nasty.

Is there a reason the GCW can't cope with OpenGL ES(1)? Their site says Cube got ported to OpenGL ES (presumably 1/1.1) at some point (http://cubeengine.com/cube_intel_pda/). Granted that it wasn't for this platform, but I can't see why that would be a major hurdle. I thought the point of using OpenGL and whatever else was, at least partially, for cross-platform compatibility. The link on that page goes to the same sourceforge page as elsewhere for Cube(1).

Why do you need X11 here? I won't pretend to be well informed, but based on http://wiki.libsdl.org/FAQUsingSDL  I would imagine that unless Cube uses SDL2 that you have options other than X11. Is that (X11) the only setup the GCW can use/supports? Or are you simply pointing out that the current firmware doesn't provide any windowing options?
« Last Edit: September 28, 2015, 04:31:53 pm by Ryvan »

David Knight

  • **
  • Posts: 577
Re: Port Request: Cube
« Reply #7 on: September 28, 2015, 04:57:10 pm »
Those are the libs required at the linking stage according to the makefile.

I do not know the technical reasons for why the GCW0 does not support OpenGLES1 for certain although I assume it's to do with the immaturity of etna_viv, the open source 3D driver for the Vivante chip.

Converting one form of code to another is not necessarily a major hurdle, but as I am not experienced in OpenGL or OpenGLES1/2 I cannot say how difficult. I imagine a conversion from SDL 1 to SDL 2 would also be required.

So not impossible but a decent amount of work is required to get it to run. And then of course there's no guarantee that it will render at the right speed.

pcercuei

  • ***
  • Posts: 1427
    • My devblog
Re: Port Request: Cube
« Reply #8 on: September 28, 2015, 04:59:12 pm »
The Zero and etnaviv support OpenGL ES 1/2.
Not desktop OpenGL.

Ryvan

  • *
  • Posts: 52
Re: Port Request: Cube
« Reply #9 on: September 28, 2015, 05:25:16 pm »
Hmm.

That said, I'd guess that one route to this would be something like:
- get it to compile and run on Linux from source
- figure out how to make it use the framebuffer rather than X11 which apparently is the only video driver other than X11 that SDL 1 & 2 support (http://wiki.libsdl.org/FAQUsingSDL -> directfb)
* I'm interpreting this (https://github.com/laanwj/etna_viv/wiki ) as saying the framebuffer should work fine
- try to build it for the gcw zero, working on the assumption that the code may already work with OpenGL ES 1 and see if it will run

Given that AssaultCube (based on the Cube(1) engine) is claimed to run even on Pentium III hardware with the 'correct settings', it seems like a fair assumption that the gcw zero should be able to manage an acceptable rate of rendering. (http://assault.cubers.net/)



Correct me if I'm wrong, but unless something strange happened, it looks like the Griffon Legend source is plain SDL 1.2, which I presume to mean that the gcw zero should be fine without needing code to moved SDL2 unless there's some other quirk.
« Last Edit: September 28, 2015, 05:31:13 pm by Ryvan »

alexei_gp

  • *
  • Posts: 236
Re: Port Request: Cube
« Reply #10 on: September 29, 2015, 02:32:05 am »
The Zero and etnaviv support OpenGL ES 1/2.
Not desktop OpenGL.

So we cant have this nice homebrew for our GCW Zero :(...thanks for the explanation.

David Knight

  • **
  • Posts: 577
Re: Port Request: Cube
« Reply #11 on: September 29, 2015, 07:25:10 am »
So we cant have this nice homebrew for our GCW Zero :(...thanks for the explanation.
So not impossible but a decent amount of work is required to get it to run.