[jr2]

It's HLP.  C'mon, now.

[Polpolion]

Was changing the thread title really necessary?

personally I really hope this project succeeds just so they can rub it in whoever changed the title's face and laugh at them.

edit: not enough to actually help or anything, though

[Iss Mneur]

Was changing the thread title really necessary?

personally I really hope this project succeeds just so they can rub it in whoever changed the title's face and laugh at them.

As I stated before.  I nor anyone else in SCP hold any ill will about this.  The more platforms FSO is on the better, however, it doesn't change the reality of the problems (the very fundamental problems) that will be faced to make this work, never mind the question of why bother, especially assuming the original premise of making FSO "handheld".  The modified premise of using a tablet or phone in a dock with a joystick and keyboard, does make some sense especially with the way that technology is going though, I still don't really see the point of doing that when you can get a proper mini-tower that will do a much better job for the same price of the special phone/tablet specific kit.

The moderator that changed the title signed the first post saying that he did it.

Also, there is some context missing in this thread about why the title was changed.  When this thread was first posted the SCP had just finished trying explain the exact same problem of doing this for an iPad or other iThing.  The first few posts of this thread (when the title was changed) was shaping up to be the same thing, "but a what about in java?" The OP has since clarified his question, not that it really changed the answer.  Also, note that the OP can change the title of the thread at any time but for whatever reason has not.

[ShivanSpS]

Actually is not only tablets... take a look at this for example.
http://www.youtube.com/watch?feature=player_embedded&v=TsDK0-4dTvE
AllWinner A10 can run Linux easily too, so if the "OpenGL ES port" is ever done...

From now on ARM cpus will be invading the netbook and laptop markets, and the pc low end market as well...

Ive started to see new ARM gpus to include desktops APIs, like OpenGL 3/4, DX11, DX9, but not sure if we will be ever able to use OpenGL under Android, thats why the "touch" UI can wait or not even be done EVER, but i really think it will come alone, thats the kind of thing that someone will do eventually.

Anyway, if the GL ES port is done, i dont think android support will be far away.
BTW, java, dalvik and wharever, are not needed, NDK compiles native C++ apps... and android support run from framebuffer.

XBMC was ported to android, it uses the NDK gcc to compile, and then it runs from framebuffer, the app its still a c++ file, there is a "dummy" app in order to execute the file to launch it... no java, dalvik or wharever is involved.

[Mikes]

The Surface Pro (and similar Tabs, Asus even has a Wintel Tab with a dedicated graphic card in the pipeline I believe) will run Freespace just fine, comes with a keyboard and has a USB port for a joystick.

So the problem of Freespace on a Tablet will kinda solve itself with Tablets that are also fully featured PCs lol.

[Luis Dias]

Just don't try to run it on Windows RT.

[ShivanSpS]

I bet Windows RT support will be a lot easier than Android...

Im still unsure how WinRT works on graphic APIs

[Luis Dias]

LOL, good luck with the ARM build.

[ShivanSpS]

Whats wrong with the ARM build? as long as the gpu supports OpenGL 1 should work, but i think any arm gpu supports it, ive see OpenGL 2, 3 and 4 support but not 1.x .

The Surface with RT has a Tegra 3 and only supports OpenGL ES, so, no. But if the OpenGL ES support is ever done, it should work.

What im not sure if the RT has any kind of DX9 wrapper on it, if so, maybe using the old DX7...

[KyadCK]

Actually is not only tablets... take a look at this for example.
http://www.youtube.com/watch?feature=player_embedded&v=TsDK0-4dTvE
AllWinner A10 can run Linux easily too, so if the "OpenGL ES port" is ever done...

Even my Inspire 4G can run Linux.


And so can my Nexus7.


And even older devices then that can too. The ability to run Linux on Android isn't a new one by any means.

[ShivanSpS]

Yeah this too.

Thats running on software opengl.
Im dual booting Linux and Android on my tablet.

Anyway, thats looking for trouble, FS2 should already work on ARM linux that has OpenGL 1.x support(not so sure about WinRT trought), once FS2 has OpenGL ES support the rest will come by itselft, Android, WinRT, its open source, but someone will have the do the hard part

[z64555]

uh, tell me again what's the major difference in the ES API versus their respective OpenGL APIs?

[Nuke]

it has all the legacy cruft removed.

i wish i knew more. i want to do some opengles programming on my raspberry pi at some point, but i still need to resolve some other issues (like finding a screen with an hdmi interface so i dont have to use ****ty composite monitors, not to mention making linux do what i want it to do).

[z64555]

Quick research into it tells me that OpenGL ES, although written against the OpenGL 1.5, 2.0, and 3.0 standards, are not full implementations of them, especially the lack of glBegin() and glEnd() (and I'm pretty sure that FSO uses a large portion of glBegin() and glEnd() 's as its fallback graphic engine). Ironically enough, the "legacy cruft" that Nuke mentioned would seem to be exactly what an embedded graphics platform would need.

I also noticed that OpenGL ES provides a duplicate set of functions that take fixed-point numbers instead of float32's, as well as come across documentation that suggests that some OS's convert the fixed-point numbers into float32's so it can be passed to the embedded GPU.

Now, unless the fixed-point GPU's are specifically fabricated against the GLfixed type, I would have to say that there is absolutely no gain to be had from this method, especially when they're going to be converted to and from float32's. The end result is that you may end up with an app that gets half to a quarter of the frame rate of that of an app written against the full OpenGL standard.

I see that you've managed to run an instance of FSO, and that tells me that you're probably running it on a machine that supports float32's, and if not, it's already doing the fixed->float->fixed madness.

P.S. I think it would also help if we knew exactly what kind of fixed point representation it's messing with...


ShivanSpS, which tablet did you run that on?

[Nuke]

that cruft was already obsolete long before arm processors really took off. opengl was still more or less a state machine without support for shaders of any kind. eventually came shaders, which were asm at first and then used shading languages later on, and the concept of the fixed function pipeline went bye bye (this was around the time 3dfx was going under and the geforce 2 reigned suppreme, and long before arm was big buisness). shaders made a lot of those state machine features rather useless. and you are expected to use shaders instead of legacy things. even the modest graphics core on the raspberry pi supports opengl es2 (where shaders are mandatory).

[ShivanSpS]

Novo 7 Aurora, but every AllWinner A10 tablet/netbook/laptop/wharever can boot a Linux from the SDcard... anyway a single core mali-400 is unlikely to run FS2, ever, is short on the performance side.

As for FS2 on Android, well all lib dependencys exist on android, at most it will need a static link to be sure, as for compile, well, it just need to use android toolchain gcc instead of normal gcc, that SHOULD work, all that can be done using comand line arguments while running the configure file. But in order to work it will need to run from framebuffer, use EGL to get an device and OpenGL ES 2 to render.
Thst should be all the requeriments, there should be no need to port anything to java or run anything on dalvik, at most a "launcher/downloader" app as a normal android app.

It does not seem to be that hard, but nothing is ever that simple either , the hardest part is porting it intro OpenGL ES first. As for a "touch ui" is not even needed, but if needed someone will do it someday.

[z64555]

The touch-screen support is probably the easier one to realize, graphics support is going to need a fork of its own.

Touch-screen could be realized by creating a new HUD gauge that provides key input, simplest support would be of course a bool pressed/not pressed and full-featured would have pressure sensitivity in there as well. In the beginning, the gauge could just run a script that emulates a key or axis control, later on as the controls code matures we could directly map the gauge to a control action.

Accelerometer controls by themselves are not good for tilt sensing, they must also include gyro data and some software filtering to be of any real use. If the embedded OS doesn't provide this function, and SDL doesn't provide it either, then FSO will have to.

[Nuke]

just do a software on screen joystick control. make things like the comm menu, shield, and ets gauges touch capable. you might also create other touch screen interfaces. im not really big on touch screens myself, i dont like looking at a screen covered in finger prints. i get the windex every time i see a smudge on my monitor. i presume most of these devices either have built in bluetooth for keyboards/mice/gamepads/etc or at least usb ports for joysticks. i would just support those interfaces.

[chief1983]

I believe at one point, the steps to get ES compatibility were written out, into the individual things that have to be done?  As far as I know, no one single step was impossible, we just need people to do them.  Plus, I think that most of those changes also move us towards supporting the Core profile on OS X which allows us to support the newer OpenGL versions on that platform as well, instead of being stuck with the old stuff there.

[ShivanSpS]

I starting to wonder right now what happens with all those devices now coming with OpenGL capable GPUs running on Android? still i don't think it has support for OpenGL 1.x, but OpenGL 3 and 4. But can desktop OpenGL be used on Android? i cant get a answer anywhere.

Also Windows RT is now here, it runs on DX9.3C compatible devices, i wonder if old DX code may be used for support, as far i how, a DX9 device should be able to run DX7 and 8 games.