Hard Light Productions Forums
General FreeSpace => FreeSpace Discussion => Topic started by: ShivanSpS on October 30, 2011, 12:55:23 am
-
I was thinking, if Android devices with GPU supports OpenGL, and Android itselft is based on linux, what keep us from running FS2 in an Android device? Need to compile binaries for ARM?
The E -- Edited to adjust thread title
-
Probably the same reasons that keep us from running FS2 on Iphones and such (http://www.hard-light.net/forums/index.php?topic=75271.0). Just replace "iOS" with "Android" and "Objective-C" with "Java".
-
Unless there have been some developments I am unaware of, the objections raised in the earlier thread are still valid.
Unless you, ShivanSPS, have gained some remarkable new insight into how to port a PC program to Android, IT IS NOT GOING TO HAPPEN.
-
well, while i cant do it myselft, yet, a few of my friends are android/java developers, im a C dev myselft, but i just work with C, not C++, so not objects, and only for DOS based apps.
So, what im asking is what whould be the minimum needed in order to work? as far i know OpenGL is already present on Android, so, i guess it whould take either to mod Android to run C/C++ apps or port FSO to java.
-
Minimum needed to get it to work? Let's see.
-Ability to load pof models
-Ability to interpret tables
-Ability to parse missions
-Ability to process player input
-Ability to load all file formats supported by FSO
-Ability to deliver playable framerates
-
you dont need to be rude, im not asking you guys to do anything, i was asking about the problems, so see if they can be workaround, there is a lot of people trying to get native C++ apps to run on Android.
maybe its easier to install Debian on parallel on the Android device and work it from there...
BTW, devices with embedded GPU (like Tegra based, Mali-400, and a few others) shouldt have fps problems with minimum mediavps.
-
How about a top-down FS2 Shooter? ;7
-
Someone did that already (the top-down that is). The search function should be able to find it for you.
-
ummm... you CAN run native apps on android, they have a complete secondary development chain for it called the NDK, and it compiles using C++, so porting FSO to android is more possible than most of these types of suggestions. now I am not saying it would be feasible, just potentially possible.
-
It would certainly make it difficult to control all the flight functions.
-
Alternative mouse control script (mouse as joystick) concept chained to a directional swipe. Swipe up, turn up.
Course let's not get into the whole inverted controls are better subject...
-
you dont need to be rude, im not asking you guys to do anything, i was asking about the problems, so see if they can be workaround, there is a lot of people trying to get native C++ apps to run on Android.
It's not really about being rude.
Basically this is a "if you have to ask, you're not even remotely qualified to do it" sort of thing. Which is why people get so annoyed at the question. The level of your understanding of the problem is so far below the level of anyone qualified to fix it that any answer beyond "It's very difficult to do" is a waste of time for the person responding. You're asking for someone to spend a lot of time figuring out exactly what pitfalls would exist in order to port FS2 when you're completely unable to be able to do anything with the answer.
The fact that this question has been asked and answered repeatedly is what is beginning to fray people's nerves. Go actually do some programming on a mobile platform. Then do some coding for FSO and get to understand how the engine works. Once you're in a position where people can see that you actually have a clue about what you're attempting to talk about, you might find them more amenable. But right now, you're just asking pointless questions.
-
Isn't FSO a patchwork of C and C++ or did I misunderstand? If so, ShivanSpS, I'm sure if you want to poke around with the engine, maybe you could find some useful things to do while you are getting familiar with it. At least, assuming you still wanted to investigate this..
-
Too much work.
Too little benefit.
:nervous:
-
Maybe its codethulhu and its scope perception manipulation again.
:shaking:
-
Wonder if my FS2BASIC code is still lying around here somewhere...
EDIT:
Just hunted through some of my four year old posts for this. Remind me not to do that ever again.
Pfft... I could port Freespace 2 to TrueBasic. :p
Then do it. :) I'd love to see the result.
I actually think I will. I mean, it won't be "good" and it'll be more of a "remake" than a "port", but...
EDIT:
The best I could do without being able to run true basic programs on my computer:
OPTION NOLET
SET WINDOW 0,1000,0,1000
RANDOMIZE
CALL Read_image("MS BMP",BAD$,"BAD.BMP")
CALL Read_image("MS BMP",BKGRND$,"BKGRND.BMP")
CALL Read_image("MS BMP",SUBF$,"SUBF.BMP")
CALL Read_image("MS BMP",PROMF$,"PROMF.BMP")
CALL Read_image("MS BMP",ROCKF$,"ROCKF.BMP")
CALL Read_image("MS BMP",HRPF$,"HRPF.BMP")
CALL Read_image("MS BMP",DIE$,"DIE.BMP")
CALL Read_image("MS BMP",HIT$,"HIT.BMP")
CALL Read_image("MS BMP",BFIRE$,"BFIRE.BMP")
DO
PRINT " FREESPACE"
PRINT " 1) Ready room"
PRINT " 2) Tech room"
PRINT " 3) Bath room"
PRINT " 4) Airlock"
PRINT
PRINT
PRINT "Where do you want to go? Input #"
INPUT GO
IF GO = 1 THEN
CALL PLAY
ELSE IF GO = 2 THEN
CALL WHAT
ELSE IF GO = 3 THEN
CALL POOP
ELSE IF GO = 4 THEN
STOP
ELSE
PRINT "Pick another number, idiot."
END IF
LOOP
END
!==================================================================
SUB PLAY
CLEAR
PRINT "What laser do you want?"
PRINT " 1) Subach HL-7 (Damage 8)"
PRINT " 2) Prometheus - S (Damage 12)"
PRINT " Input number"
INPUT GUN
CLEAR
PRINT "What missile do you want?"
PRINT " 1) Rockeye (10 missiles) (Damage 30)"
PRINT " 2) Harpoon (6 missiles) (Damage 50)"
PRINT " Input number"
INPUT MISS
PRINT "YOUR WEAPONS:";
IF GUN = 1 THEN
PRINT "Subach HL-7";
ELSE
PRINT "Prometheus - S";
END IF
IF MISS = 1 THEN
PRINT " and Rockeye"
ELSE
PRINT "and Harpoon."
END IF
PRINT
PRINT
PRINT "Press a key when you are ready."
GET KEY PSE
CLEAR
!=============================
PHLTH = 100
DO
BHLTH = 100
A=rnd*800
B=rnd*800
DO
FWB = FWB - 1
FW = FW-1
FWM = FWM-1
!BOX SHOW $ at ,
!32
!122
BOX SHOW BKGRND$ at 0,0
BOX SHOW BAD$ at A,B
GET MOUSE X,Y,S
GET KEY S
IF S=122 THEN
IF GUN = 1 AND FW >= 0 THEN
BOX SHOW SUBF$ at 0,0
ELSE
BOX SHOW PROMF$ at 0,0
END IF
IF X>A AND X<(A+200) AND Y>B AND Y<(B+200) THEN
BOX SHOW HIT$ at A,B
IF GUN = 1 THEN
BHLTH = (BHLTH-8)
FW = 6
ELSE
BHLTH = (BHLTH-12)
FW = 10
END IF
END IF
END IF
IF S=32 THEN
IF MISS = 1 AND FWM >= 0 THEN
BOX SHOW ROCKF$ at 0,0
ELSE
BOX SHOW HRPF$ at 0,0
END IF
IF X>A AND X<(A+200) AND Y>B AND Y<(B+200) THEN
BOX SHOW HIT$ at A,B
IF GUN = 1 THEN
BHLTH = (BHLTH-30)
FWM = 10
ELSE
BHLTH = (BHLTH-50)
FWM = 15
END IF
END IF
END IF
PAUSE 0.1
!PLOT TEXT, at x, y:
IF FWB >= 0 THEN
BOX SHOW BFIRE$ at A,B
PHLTH = PHLTH - (RND*4+6)
BAR =(100 - PHLTH)
SET COLOR "GREEN"
PLOT TEXT, AT BAR,10 : "|"
PLOT TEXT, AT 101,10 : "YOUR DAMAGE"
SET COLOR "BLACK"
FWB = (RND*5+4)
END IF
LOOP UNTIL BHLTH >=0 OR PHLTH >= 0
IF BHLTH >= 0 THEN
KILL = KILL + 1
END IF
IF PHLTH >= 0 THEN
CLEAR
PRINT " YOU SUCK AT THIS GAME! !! YOU LOSE!!"
END IF
LOOP UNTIL KILL = 10 OR PHLTH >= 0
IF KILL = 10 THEN
PRINT "YOU ROCK AT A GAME THAT TAKES NO SKILL WHATSOEVER TO PLAY! !"
END IF
END SUB
!======================================================================
SUB WHAT
PRINT " This is a 'port' of the most basic aspects of the game of Freespace 2 to True basic."
PRINT " When you go into play mode, you get to select guns. Some do more damage than others"
PRINT " Put your mouse pointer on the bad guys. 'Z' shoots your lasers, Spacebar shoots a missile"
PRINT " Click on bad guys to destroy them."
PRINT
PRINT " Back to the main hall! *press key"
GET KEY PSE
CLEAR
END SUB
!=====================================================================
SUB POOP
PRINT " You unzip your pants. Then you remember that this is a game"
PRINT " and you get up from your computer desk and walk to the real"
PRINT " bathroom. Thank goodness! *press key"
GET KEY PSE
CLEAR
END SUB
Truly an insult to Freespace. :nod:
I "stole" some screenshots off of here for a background, cropped an astaroth out of one, and added some cheezy ms paint effects.
EDIT2: For those of you that were around at the time I don't need to explain. For the rest of you, don't judge.
-
As someone who put some time into android... just forget it.
You'd spend hours over hours on end and still end up with an end product that is in every way the crappy little brother of the real FSO.
And for what? So you can play with your finger? (Which seriously is one of the worst parts of Android Games... touch controls just suck compared to any alternative.)
So you can play mobile? Can already do that with a 3-4 pound laptop and not be limited/crippled by Androids shortcomings.
Oh you mean truly mobile, without keyboard, without joystick, without monitor, without proper horsepower... etc... well if you attempt that, you will end up with a mobile game with all its limitations... i.e. you'd barely recognize FSO anymore and always wish you were playing the real thing instead.
I looked at the mobile gaming market because i travel a lot and this is what you get: True "mobile games" that always suck in comparison to real games and "ports" of real games that always suck due to horrible controls and/or lack of horsepower. After fiddling around for 2 months I noticed I just don't play mobile games anymore. There literally isn't ANYTHING on that platform worth the time... despite all the surely talented and brilliant people attempting to port everything and their grandmother, the end result is always so utterly inferior that it's well... kinda "cool" that it runs on a phone/tablet now... but utterly atroxious to actually play (especially when you always know how much better experience would be on a desktop/laptop). Bottomline: That time travelling is much much better spent otherwise (99% of my time on my Android device is taken up by the Kindle App now ;) )
Trust me on this. I know exactly where you are coming from. I know the Euphoria of "OMG I can play this on my cellphone/tablet now! OMG"... Been there, done that. After you actually finished 2-3 mobile games and have seen how shallow they are... you try the ports... and after you play them for a while and realize how utterly crappy the "experience" of playing them on Android is... you go back to making time for the real thing.
Too uncomfortable sitting in front of a desk? Well in that case, if it's about the "best" FSO experience... that money you'd need for an Android/iOS device is much better spent on a projector, so you can have Freespace literally all over your wall with a 2-4 meter picture and play from the couch or bed (which works perfectly with the proper furniture next to the Couch to support your controls, or with simply laying down in bed with a keyboard to your left and joystick to your right while you project onto the ceiling). :) :) :)
-
Something that will actually work, is to use an android tablet as an input device.
So you could have cool looking virtual ship controls you can really touch.
I have code here that allows you to input control actions via UDP, and some rudimentary android code.
If someone would come up with a cool looking and working android app.
I could try to get this patch trunk ready.
-
you dont need to be rude, im not asking you guys to do anything, i was asking about the problems, so see if they can be workaround, there is a lot of people trying to get native C++ apps to run on Android.
It's not really about being rude.
Basically this is a "if you have to ask, you're not even remotely qualified to do it" sort of thing. Which is why people get so annoyed at the question. The level of your understanding of the problem is so far below the level of anyone qualified to fix it that any answer beyond "It's very difficult to do" is a waste of time for the person responding. You're asking for someone to spend a lot of time figuring out exactly what pitfalls would exist in order to port FS2 when you're completely unable to be able to do anything with the answer.
The fact that this question has been asked and answered repeatedly is what is beginning to fray people's nerves. Go actually do some programming on a mobile platform. Then do some coding for FSO and get to understand how the engine works. Once you're in a position where people can see that you actually have a clue about what you're attempting to talk about, you might find them more amenable. But right now, you're just asking pointless questions.
I understand, BUT the older discusions are about porting the engine to a diferent language, like Java. Or try to run on Windows mobile or Iphone based OS.
Android is a diferent matter, first off, it does support OpenGL(in fact you can indeed run OpenGL games for x86 using Dosbox), and units with embedded GPU has enoght power to run the FSO graphics engine. Second, its Linux, and people have had some success in compiling C/C++ projects on it.
So its not imposible like trying to port the game to Java...
As for input discussions, this is not the time to discuss that.
Anyway, i think the first step will be trying to compile the bins for Linux ARM, maybe a Ubuntu running in parallel with Android on the tablet.
-
I understand, BUT the older discusions are about porting the engine to a diferent language, like Java. Or try to run on Windows mobile or Iphone based OS.
Android is a diferent matter, first off, it does support OpenGL(in fact you can indeed run OpenGL games for x86 using Dosbox), and units with embedded GPU has enoght power to run the FSO graphics engine. Second, its Linux, and people have had some success in compiling C/C++ projects on it.
So its not imposible like trying to port the game to Java...
As for input discussions, this is not the time to discuss that.
Anyway, i think the first step will be trying to compile the bins for Linux ARM, maybe a Ubuntu running in parallel with Android on the tablet.
No, you do not seem to be understanding what we are saying to you. Those previous discussions covered many of the same things, you seem to be focused exclusively on the apparent ability of the hardware and/or OS to run unmanaged C/C++ code, that is just one of many issues related to porting.
I will give you the different language bit, though if was the only problem it wouldn't be a deal breaker (though it will still be more than 4000 hours of work (that is, two years full time for one person)).
The iPhone uses OpenGL ES, in fact there is very little that uses 3D accelerated graphics but doesn't support OpenGL at all. With some quick googling the only platform that I can find that doesn't support OpenGL at all is the XBox (which really doesn't come a much of a surprise considering they are DirectX boxes :D); the PS3 supports ES, some of the Windows Mobile Phones actually use ES to implement the DirectX API, the Wii supports ES, so do the the DS and PSP.
OpenGL is never the problem with these ports. Having to rewrite everything to use the ES dialect of OpenGL is the first problem (which if I am remembering my OpenGL feature sheets correctly means you need to lose the shaders for one, which is basically the source of all of the "modern" graphical features of the engine). Next would be finding a GPU with enough grunt to render and enough bandwidth to push through the amount of data that we throw at the GPU is a different story. Third would be finding something that has storage that is fast enough to stream the data that we do. Fourth would be finding a CPU that could handle a mission full of physics/collision calcs. Also, finding enough RAM to run the game could be a bit of challenge as well.
Yes, Tegra can do some pretty nice things, but that is when you compare them to other embedded graphics cards. Even the lowly Intel GMA's are able to soundly trounce a Tegra 3.
This is the perfect time to discuss input because there is no point in porting anything to another platform if you can't use it. Remember the discussions about how to port FSO to a game console? Or even the, how do you map the 30+ controls of FSO onto a game console's controller? In this case you are likely going to a device that has no buttons just a touch screen, which means you have what? 1 (maybe 2 or 3 if you have an expensive multi-touch capable device) simultaneous "button" press (which btw would have be on a "keyboard" that covers half or more of the screen).
You would be much further ahead to do something that is Freespace themed like Polpolion's BASIC "port" or Nuke's top down mod for FSO. If you built/ported the engine that you use for Freespace correctly you could get the other TCs to help and/or do their own version.
Compiling for ARM will probably be least of your problems because the last confirmation that I heard that FSO still compiles and runs on PPC was about a year ago, which covers the endian issues. FSO also compiles for 64-bit on SCP_UNIX systems already which has also helped find quite a few CPU related portability issues.
Don't forget the tired old maxim of the computing world: high performance, low price, low power consumption; pick two.
Keep in mind this is the 40 minute high level overview (ie. I spent 35 minutes too much to explain this). This is not an exhaustive list because I don't know everything about how the engine works on all platforms.
Now don't get me wrong, I would love to see FSO on more platforms, but just porting the engine as is... it will be incredibly disappointing.
Its great that you have an plan of action now (even if it is only one step long). Please keep us posted on your progress.
-
Well, the imposible already happen, FS2 was a Windows only game, using Directx... now runs on OpenGL and work on Linux, Mac, Solaris... OSX?
But when someone says Android, then its impossible, its not going to happen, etc...
First off, OpenGL ES is not that diferent, yes it needs some modifications, but is based on OpenGL and definitaly there no need to rewrite everything...
Second, a single guy maded a Quake3 Arena port to Android in a few days, the part i dont like is he used Java for OpenGL and audio, there must be another way.
again, im not asking to do anything im just evaluating the odds.
About the interface, well, phones are out of the question, as always, but 7" tablets are another thing. I was thinking of something like this for 800x480
(http://i.imgur.com/G2aLE.png)
But is just an idea of how could be done, ship movements can be done by the g-sensor. But most people use a usb keyboard with its tablet anyway.
Right now im looking at the OpenGL/OpenGL ES differences, my tablet is returning of RMA and i hope to have it back next week so i can start trying to compile the bins on a linux arm.
EDIT: i see there is an OpenGL ES "emulator" for desktop eviroments... i gona start by there. It says it just maps OpenGL ES calls to OpenGL api...
OK, i had been checking a bit, the mayor diference it seems they removed all kinds of floats, and ES 1.1 is very very similar to the OGL been used in FSO.
in gl.h in FSO Source Code
typedef unsigned int GLenum;
typedef unsigned char GLboolean;
typedef unsigned int GLbitfield;
typedef signed char GLbyte;
typedef short GLshort;
typedef int GLint;
typedef int GLsizei;
typedef unsigned char GLubyte;
typedef unsigned short GLushort;
typedef unsigned int GLuint;
typedef float GLfloat;
typedef float GLclampf;
typedef double GLdouble;
typedef double GLclampd;
typedef void GLvoid;
gl.h for OpenGL ES 1.1
typedef void GLvoid;
typedef unsigned int GLenum;
typedef unsigned char GLboolean;
typedef unsigned int GLbitfield;
typedef khronos_int8_t GLbyte;
typedef short GLshort;
typedef int GLint;
typedef int GLsizei;
typedef khronos_uint8_t GLubyte;
typedef unsigned short GLushort;
typedef unsigned int GLuint;
typedef khronos_float_t GLfloat;
typedef khronos_float_t GLclampf;
typedef khronos_int32_t GLfixed;
typedef khronos_int32_t GLclampx;
typedef khronos_intptr_t GLintptr;
typedef khronos_ssize_t GLsizeiptr;
gl2.h in OpenGL 2.0
typedef void GLvoid;
typedef unsigned int GLenum;
typedef unsigned char GLboolean;
typedef unsigned int GLbitfield;
typedef khronos_int8_t GLbyte;
typedef short GLshort;
typedef int GLint;
typedef int GLsizei;
typedef khronos_uint8_t GLubyte;
typedef unsigned short GLushort;
typedef unsigned int GLuint;
typedef khronos_float_t GLfloat;
typedef khronos_float_t GLclampf;
typedef khronos_int32_t GLfixed;
/* GL types for handling large vertex buffer objects */
typedef khronos_intptr_t GLintptr;
typedef khronos_ssize_t GLsizeiptr;[code]
this was a quick peek, ill keep looking at it.
-
Yeah, people could hook their phones up to some docking station that is connected to a full-size keyboard, a mouse, a 24" monitor, surround speakers, and then use that to play... oh wait.
-
Eh, if it makes you happy, give it your all dude.
Some of the most famous inventors in history were put down frequently, and how many of their critics do we remember today....
-
Well, the imposible already happen, FS2 was a Windows only game, using Directx... now runs on OpenGL and work on Linux, Mac, Solaris... OSX?
Porting to Linux and MacOS was rather easy because: 1) They're both POSIX. 2) It was done practically before there was an SCP, meaning the codebase was a lot less complicated than it is now. 3) Even the retail code already had an abstratction framework for switching between graphics APIs, meaning the important part of abstracting stuff had already been done.
But when someone says Android, then its impossible, its not going to happen, etc...
First off, OpenGL ES is not that diferent, yes it needs some modifications, but is based on OpenGL and definitaly there no need to rewrite everything...
"Some" modifications soon become "a lot". As evidenced by this statement, and the following quotations from the headers, you haven't actually looked at the documentation to see where the real problems are.
Oh, and it's not like I'm saying "porting to Android is impossible". I'm saying "porting to a handheld device is severely impractical due to control issues, performance issues, and general amount of coding required".
Second, a single guy maded a Quake3 Arena port to Android in a few days, the part i dont like is he used Java for OpenGL and audio, there must be another way.
again, im not asking to do anything im just evaluating the odds.
Someone ported Quake 3. Yes. Someone ported one of the most well-studied, extensively documented, heaviliy developed on engines in the world. Note how FSO is neither of those things.
About the interface, well, phones are out of the question, as always, but 7" tablets are another thing. I was thinking of something like this for 800x480
But is just an idea of how could be done, ship movements can be done by the g-sensor. But most people use a usb keyboard with its tablet anyway.
Well, my little Android phone has a resolution of 854x480 pixels. Why wouldn't it be able to run it?
OK, i had been checking a bit, the mayor diference it seems they removed all kinds of floats, and ES 1.1 is very very similar to the OGL been used in FSO.
in gl.h in FSO Source Code
/*blabla snipped*/
this was a quick peek, ill keep looking at it.
This cements my point re: You not reading the documentation. Yes, the headers are identical, mostly. Which is like no surprise at all, and just indicates that you are looking at the wrong things. The major difference between the two, and one that will already cause some porting issues, is that OGL ES does not have the glBegin()/glEnd() commands, and relies on transferring vertex arrays instead.
-
Well, the imposible already happen, FS2 was a Windows only game, using Directx... now runs on OpenGL and work on Linux, Mac, Solaris... OSX?
Look its pretty easy: OpenGL and all the graphical improvements that followed were a step forward.
Android, no matter how you slice it, would be a giant leap backward... even on the most successful port you would have a game that a) looks way worse than what we got and b) is crippled by subpar input options.
(To elaborate on the input mess: Yes, there is a keyboard option. Have *you* actually played with one? I doubt it... because otherwise you would know that none of these keyboards have anti ghosting. They don't react well to multiple keypresses at all. Android is a touch OS really. Adding peripheries usually makes the experience worse, not better (i.e. a notebook blows any Android+keyboard combo out of the water), especially when you use some of these peripheries (i.e. Android keyboards) for purposes (i.e. gaming) that they were never designed for. Seriously... I tried some ports and even dosbox on android... and I actually dropped the keyboard and went back to touchscreen... thats how bad it is.)
In summary: In addition to the huge/prohibitive effort involved in such a project (are you willing to do it? lol) most (that is: pretty much all :p) people don't even see the point.
Android in its current form is a platform that works for mobile games that were specifically designed as mobile games on that platform. But for ports of fullblown Windows games Android (just like iOS) is just about the worst platform imaginable. Unless the game is 10-20 years old and takes well to touchscreen input (Point and Click adventures work about perfect for example, Freespace does not - at all.) it's just gonna be a huge unplayable mess.
You would do well to take a look at the space shooters that were actually designed for a Touchscreen device, like Galaxy on Fire 2. That game works on Android, it's designed for touchscreen... and gameplay is completely different from the spacesims we are used to on Windows for good reason .
Frankly... if you would actually get enough people willing to put the effort in for a Freespace port... *porting* the Engine would propably still be stupid. You would be much better off designing a Spacesim engine for Android from scratch and use Freespace ships (possibly from the Original game / otherwise you may have to tone down or recreate current assets). It wouldn t just be easier, it would also be quicker and most importantly: While it would have to (necessarily) play completely different from Windows FSO... it would actually "work" on Android: That is: Present a somewhat enjoyable gameplay experience.
i.e.: Good luck finding enough people for your Android game.
Don't take me wrong... I like my Android tablet. It works great for surfing the web on the couch and reading ebooks with kindle. But - after the newness wears off - the only situation where you would use an Android device for gaming is when you desperately want to game and there is no other hardware option available... however once you have gamed on your tablet for a while... you will actually realize that when you really have no other gaming options available... *gaming* is pretty much the worst way to spend your time on an Android device. ;)
If you want to play Freespace on the road we already have 3-4 pound gaming laptops that work just fine for FSO in the 700 to 1000$ bracket. They usually have a keyboard that supports multiple keypresses too. ;)
-
Im not looking for people or to play "freespace on the road" im playing with the code just because i like to, i never worked on a C++ project, at least not of this magnitude, even less with OpenGL, so now im messing with the code in my free time, i dont think i can make it, and i absolutely, dont care if i cant, but in this way at least i can learn.
There a lot of documentation about converting glBegin()/glEnd() to work with OpenGL ES around, glvertex is another one. FSO not using OpenGL 2.0 does not help either, since all work must be done on ES 1.1 and its a little abandoned now. Most of the documentation ive found its for 2.0. Actually im not sure of witch version is using, there is nothing on the documentation, but for what it says in the code i bet its the 1.5 with shader extensions.
Also FSO seems to be using lots of floats, and shader implementation is not posible on ES 1.1. So yes im actually starting to think it is imposible.
-
Don't take me wrong... I like my Android tablet. It works great for surfing the web on the couch and reading ebooks with kindle. But - after the newness wears off - the only situation where you would use an Android device for gaming is when you desperately want to game and there is no other hardware option available... however once you have gamed on your tablet for a while... you will actually realize that when you really have no other gaming options available... *gaming* is pretty much the worst way to spend your time on an Android device. ;)
You are using the damn thing for exactly the sort of thing i want to use it for. A nice little replacement for all the ****ty newspaper and books. Physical space is at a premium and i already have waaay too many books for my shelves.
Not counting the **** my parents desire to throw on my shelves either... -.-
-
"****ty" books? You wound me, sir!
-
"****ty" books? You wound me, sir!
"****ty" as in "I'VE GOT TOO MUCH OF THIS STUFF AAAAARFGLGFRLFL!!!"
-
OpenGL ES implementation seems more likely using the wes_gl_v2 wrapper lib thats was builded on top of OpenGL ES 2.0 to add the issing funtions of OpenGL 2.0, to act as a OGL 2.0 to OGL 2.0 ES wrapper.
its still missing several things, like gldrawbuffer, glReadBuffer, glVertex2i, matrix, anyway, so bad that the gl_wes project is abandoned now, a wrapper like that was the best chance.
-
I get it. So, ShivanSpS, you want to port FSO to Droid for the same reason one would make a model steam engine? Not to accomplish any practical amount of work, per se, but just to accomplish the feat itself?
-
I'm really not expecting to play War in Heaven on my X10.
I'm guessing a pof viewer (even a retail detail) pof viewer is a no-go?
-
I get it. So, ShivanSpS, you want to port FSO to Droid for the same reason one would make a model steam engine? Not to accomplish any practical amount of work, per se, but just to accomplish the feat itself?
yeah, but as today i dont have enoght knowledge in OpenGL or OpenGL ES to do any mayor conversion, but its something ill like to do, even if takes years.
Also, i belive this is a kind of game that will play ok on mobile platforms, yeah player input on interfase will need a mayor work, and maybe some of the missions will be not ideal to play on android device, but this is still a action based game that will do ok, still i dont belive it will be possible to play at all on a 3" screen, but it will do just fine on 7".
An example of a game that its imposible to play on a mobile device is X3TC for example, not FS2.
Addicionally dont forget that ARM will start invading most of netbook market soon, Windows 8 will bring a masive amount of ARM hardware intro netbook market, so at my stimation OpenGL ES support on FS2 will be done, sooner or later, and i bet someone else will beat me to do it.
So far, what ive investigated and tryied with the FS2 code, a direct implementation of OpenGL ES 2 will take a masive ammount of time rewriting almost everything related to graphics(as expected by everyone). But if instead of using OpenGL ES directly, we try using the gl-wes-v2 OpenGL 2 to OpenGL ES 2 wrapper, the amount of work is reduced drastically in comparison.
Those are the errors that pop up at this point
5>c:\fso\code\graphics\gropengl.h(278): error C2371: 'GLint' : redefinition; different basic types
5> c:\fso\code\graphics\gl-wes\wes_gl_defines.h(202) : see declaration of 'GLint'
5>c:\fso\code\graphics\gropengltnl.cpp(692): error C3861: 'glDrawBuffer': identifier not found
5>c:\fso\code\graphics\gropengltnl.cpp(696): error C2065: 'PFNGLDRAWRANGEELEMENTSPROC' : undeclared identifier
5>c:\fso\code\graphics\gropengltnl.cpp(696): error C2146: syntax error : missing ')' before identifier 'GL_Functions'
5>c:\fso\code\graphics\gropengltnl.cpp(696): error C2059: syntax error : ')'
5>c:\fso\code\graphics\gropengltnl.cpp(765): error C2065: 'PFNGLCLIENTACTIVETEXTUREARBPROC' : undeclared identifier
5>c:\fso\code\graphics\gropengltnl.cpp(765): error C2146: syntax error : missing ')' before identifier 'GL_Functions'
5>c:\fso\code\graphics\gropengltnl.cpp(765): error C2059: syntax error : ')'
5>c:\fso\code\graphics\gropengltnl.cpp(767): error C2065: 'PFNGLCLIENTACTIVETEXTUREARBPROC' : undeclared identifier
5>c:\fso\code\graphics\gropengltnl.cpp(767): error C2146: syntax error : missing ')' before identifier 'GL_Functions'
5>c:\fso\code\graphics\gropengltnl.cpp(767): error C2059: syntax error : ')'
5>c:\fso\code\graphics\gropengltnl.cpp(826): error C2065: 'GL_ELEMENT_ARRAY_BUFFER_ARB' : undeclared identifier
5>c:\fso\code\graphics\gropengltnl.cpp(843): error C2065: 'PFNGLCLIENTACTIVETEXTUREARBPROC' : undeclared identifier
5>c:\fso\code\graphics\gropengltnl.cpp(843): error C2146: syntax error : missing ')' before identifier 'GL_Functions'
5>c:\fso\code\graphics\gropengltnl.cpp(843): error C2059: syntax error : ')'
5>c:\fso\code\graphics\gropengltnl.cpp(855): error C2065: 'PFNGLCLIENTACTIVETEXTUREARBPROC' : undeclared identifier
5>c:\fso\code\graphics\gropengltnl.cpp(855): error C2146: syntax error : missing ')' before identifier 'GL_Functions'
5>c:\fso\code\graphics\gropengltnl.cpp(855): error C2059: syntax error : ')'
5>c:\fso\code\graphics\gropengltnl.cpp(869): error C2065: 'PFNGLDRAWRANGEELEMENTSPROC' : undeclared identifier
5>c:\fso\code\graphics\gropengltnl.cpp(869): error C2146: syntax error : missing ')' before identifier 'GL_Functions'
5>c:\fso\code\graphics\gropengltnl.cpp(869): error C2059: syntax error : ')'
5>c:\fso\code\graphics\gropengltnl.cpp(922): error C2065: 'PFNGLCLIENTACTIVETEXTUREARBPROC' : undeclared identifier
5>c:\fso\code\graphics\gropengltnl.cpp(922): error C2146: syntax error : missing ')' before identifier 'GL_Functions'
5>c:\fso\code\graphics\gropengltnl.cpp(922): error C2059: syntax error : ')'
5>c:\fso\code\graphics\gropengltnl.cpp(953): error C2065: 'PFNGLCLIENTACTIVETEXTUREARBPROC' : undeclared identifier
5>c:\fso\code\graphics\gropengltnl.cpp(953): error C2146: syntax error : missing ')' before identifier 'GL_Functions'
5>c:\fso\code\graphics\gropengltnl.cpp(953): error C2059: syntax error : ')'
5>c:\fso\code\graphics\gropengltnl.cpp(993): error C3861: 'glGetMaterialfv': identifier not found
5>c:\fso\code\graphics\gropengltnl.cpp(999): error C2065: 'PFNGLDRAWRANGEELEMENTSPROC' : undeclared identifier
5>c:\fso\code\graphics\gropengltnl.cpp(999): error C2146: syntax error : missing ')' before identifier 'GL_Functions'
5>c:\fso\code\graphics\gropengltnl.cpp(999): error C2059: syntax error : ')'
5>c:\fso\code\graphics\gropengltnl.cpp(1033): error C2065: 'PFNGLCLIENTACTIVETEXTUREARBPROC' : undeclared identifier
5>c:\fso\code\graphics\gropengltnl.cpp(1033): error C2146: syntax error : missing ')' before identifier 'GL_Functions'
5>c:\fso\code\graphics\gropengltnl.cpp(1033): error C2059: syntax error : ')'
5>c:\fso\code\graphics\gropengltnl.cpp(1038): error C2065: 'PFNGLCLIENTACTIVETEXTUREARBPROC' : undeclared identifier
5>c:\fso\code\graphics\gropengltnl.cpp(1038): error C2146: syntax error : missing ')' before identifier 'GL_Functions'
5>c:\fso\code\graphics\gropengltnl.cpp(1038): error C2059: syntax error : ')'
5>c:\fso\code\graphics\gropengltnl.cpp(1061): error C2065: 'PFNGLDRAWRANGEELEMENTSPROC' : undeclared identifier
5>c:\fso\code\graphics\gropengltnl.cpp(1061): error C2146: syntax error : missing ')' before identifier 'GL_Functions'
5>c:\fso\code\graphics\gropengltnl.cpp(1061): error C2059: syntax error : ')'
5>c:\fso\code\graphics\gropengltnl.cpp(1072): error C2065: 'PFNGLCLIENTACTIVETEXTUREARBPROC' : undeclared identifier
5>c:\fso\code\graphics\gropengltnl.cpp(1072): error C2146: syntax error : missing ')' before identifier 'GL_Functions'
5>c:\fso\code\graphics\gropengltnl.cpp(1072): error C2059: syntax error : ')'
5>c:\fso\code\graphics\gropengltnl.cpp(1078): error C2065: 'PFNGLCLIENTACTIVETEXTUREARBPROC' : undeclared identifier
5>c:\fso\code\graphics\gropengltnl.cpp(1078): error C2146: syntax error : missing ')' before identifier 'GL_Functions'
5>c:\fso\code\graphics\gropengltnl.cpp(1078): error C2059: syntax error : ')'
5>c:\fso\code\graphics\gropengltnl.cpp(1202): error C3861: 'glFrustum': identifier not found
5>c:\fso\code\graphics\gropengltnl.cpp(1204): error C3861: 'glFrustum': identifier not found
5>c:\fso\code\graphics\gropengltnl.cpp(1324): error C3861: 'glLoadMatrixd': identifier not found
5>c:\fso\code\graphics\gropengltnl.cpp(1339): error C2065: 'GL_MODELVIEW_MATRIX' : undeclared identifier
5>c:\fso\code\graphics\gropengltnl.cpp(1396): error C2065: 'GL_TRANSFORM_BIT' : undeclared identifier
5>c:\fso\code\graphics\gropengltnl.cpp(1396): error C3861: 'glPushAttrib': identifier not found
5>c:\fso\code\graphics\gropengltnl.cpp(1419): error C2065: 'GL_PROJECTION_STACK_DEPTH' : undeclared identifier
5>c:\fso\code\graphics\gropengltnl.cpp(1446): error C3861: 'glPopAttrib': identifier not found
5> gropengltexture.cpp
5>c:\fso\code\graphics\gropengl.h(278): error C2371: 'GLint' : redefinition; different basic types
5> c:\fso\code\graphics\gl-wes\wes_gl_defines.h(202) : see declaration of 'GLint'
5>c:\fso\code\graphics\gropengltexture.cpp(100): error C2065: 'GL_MAX_TEXTURE_MAX_ANISOTROPY_EXT' : undeclared identifier
5>c:\fso\code\graphics\gropengltexture.cpp(201): error C2065: 'GL_MAX_TEXTURE_UNITS' : undeclared identifier
5>c:\fso\code\graphics\gropengltexture.cpp(373): error C2065: 'GL_UNSIGNED_SHORT_1_5_5_5_REV' : undeclared identifier
5>c:\fso\code\graphics\gropengltexture.cpp(439): error C2065: 'GL_UNSIGNED_INT_8_8_8_8_REV' : undeclared identifier
5>c:\fso\code\graphics\gropengltexture.cpp(444): error C2065: 'GL_RGB8' : undeclared identifier
5>c:\fso\code\graphics\gropengltexture.cpp(444): error C2065: 'GL_RGB5' : undeclared identifier
5>c:\fso\code\graphics\gropengltexture.cpp(447): error C2065: 'GL_UNSIGNED_SHORT_1_5_5_5_REV' : undeclared identifier
5>c:\fso\code\graphics\gropengltexture.cpp(456): error C2065: 'GL_UNSIGNED_SHORT_1_5_5_5_REV' : undeclared identifier
5>c:\fso\code\graphics\gropengltexture.cpp(465): error C2065: 'GL_COMPRESSED_RGB_S3TC_DXT1_EXT' : undeclared identifier
5>c:\fso\code\graphics\gropengltexture.cpp(471): error C2065: 'GL_COMPRESSED_RGBA_S3TC_DXT3_EXT' : undeclared identifier
5>c:\fso\code\graphics\gropengltexture.cpp(477): error C2065: 'GL_COMPRESSED_RGBA_S3TC_DXT5_EXT' : undeclared identifier
5>c:\fso\code\graphics\gropengltexture.cpp(495): error C2065: 'GL_TEXTURE_MAX_ANISOTROPY_EXT' : undeclared identifier
5>c:\fso\code\graphics\gropengltexture.cpp(499): error C2065: 'GL_TEXTURE_MAX_LEVEL' : undeclared identifier
5>c:\fso\code\graphics\gropengltexture.cpp(504): error C2065: 'GL_TEXTURE_WRAP_R' : undeclared identifier
5>c:\fso\code\graphics\gropengltexture.cpp(538): error C2065: 'PFNGLCOMPRESSEDTEXIMAGE2DPROC' : undeclared identifier
5>c:\fso\code\graphics\gropengltexture.cpp(538): error C2146: syntax error : missing ')' before identifier 'GL_Functions'
5>c:\fso\code\graphics\gropengltexture.cpp(538): error C2059: syntax error : ')'
5>c:\fso\code\graphics\gropengltexture.cpp(540): error C2065: 'PFNGLCOMPRESSEDTEXSUBIMAGE2DPROC' : undeclared identifier
5>c:\fso\code\graphics\gropengltexture.cpp(540): error C2146: syntax error : missing ')' before identifier 'GL_Functions'
5>c:\fso\code\graphics\gropengltexture.cpp(540): error C2059: syntax error : ')'
5>c:\fso\code\graphics\gropengltexture.cpp(564): error C2065: 'PFNGLCOMPRESSEDTEXIMAGE2DPROC' : undeclared identifier
5>c:\fso\code\graphics\gropengltexture.cpp(564): error C2146: syntax error : missing ')' before identifier 'GL_Functions'
5>c:\fso\code\graphics\gropengltexture.cpp(564): error C2059: syntax error : ')'
5>c:\fso\code\graphics\gropengltexture.cpp(566): error C2065: 'PFNGLCOMPRESSEDTEXSUBIMAGE2DPROC' : undeclared identifier
5>c:\fso\code\graphics\gropengltexture.cpp(566): error C2146: syntax error : missing ')' before identifier 'GL_Functions'
5>c:\fso\code\graphics\gropengltexture.cpp(566): error C2059: syntax error : ')'
5>c:\fso\code\graphics\gropengltexture.cpp(676): error C2065: 'PFNGLCOMPRESSEDTEXIMAGE2DPROC' : undeclared identifier
5>c:\fso\code\graphics\gropengltexture.cpp(676): error C2146: syntax error : missing ')' before identifier 'GL_Functions'
5>c:\fso\code\graphics\gropengltexture.cpp(676): error C2059: syntax error : ')'
5>c:\fso\code\graphics\gropengltexture.cpp(678): error C2065: 'PFNGLCOMPRESSEDTEXSUBIMAGE2DPROC' : undeclared identifier
5>c:\fso\code\graphics\gropengltexture.cpp(678): error C2146: syntax error : missing ')' before identifier 'GL_Functions'
5>c:\fso\code\graphics\gropengltexture.cpp(678): error C2059: syntax error : ')'
5>c:\fso\code\graphics\gropengltexture.cpp(702): error C2065: 'PFNGLCOMPRESSEDTEXIMAGE2DPROC' : undeclared identifier
5>c:\fso\code\graphics\gropengltexture.cpp(702): error C2146: syntax error : missing ')' before identifier 'GL_Functions'
5>c:\fso\code\graphics\gropengltexture.cpp(702): error C2059: syntax error : ')'
5>c:\fso\code\graphics\gropengltexture.cpp(704): error C2065: 'PFNGLCOMPRESSEDTEXSUBIMAGE2DPROC' : undeclared identifier
5>c:\fso\code\graphics\gropengltexture.cpp(704): error C2146: syntax error : missing ')' before identifier 'GL_Functions'
5>c:\fso\code\graphics\gropengltexture.cpp(704): error C2059: syntax error : ')'
5>c:\fso\code\graphics\gropengltexture.cpp(1071): error C2065: 'GL_TEXTURE_WRAP_R' : undeclared identifier
5>c:\fso\code\graphics\gropengltexture.cpp(1157): error C2065: 'GL_MATRIX_MODE' : undeclared identifier
5>c:\fso\code\graphics\gropengltexture.cpp(1165): error C2065: 'GL_MATRIX_MODE' : undeclared identifier
5>c:\fso\code\graphics\gropengltexture.cpp(1189): error C2065: 'GL_MIRRORED_REPEAT_ARB' : undeclared identifier
5>c:\fso\code\graphics\gropengltexture.cpp(1220): error C2065: 'GL_COMPRESSED_RGB_S3TC_DXT1_EXT' : undeclared identifier
5>c:\fso\code\graphics\gropengltexture.cpp(1226): error C2065: 'GL_COMPRESSED_RGBA_S3TC_DXT5_EXT' : undeclared identifier
5>c:\fso\code\graphics\gropengltexture.cpp(1227): error C2065: 'GL_UNSIGNED_INT_8_8_8_8_REV' : undeclared identifier
5>c:\fso\code\graphics\gropengltexture.cpp(1238): error C2065: 'GL_PROXY_TEXTURE_2D' : undeclared identifier
5>c:\fso\code\graphics\gropengltexture.cpp(1240): error C2065: 'GL_PROXY_TEXTURE_2D' : undeclared identifier
5>c:\fso\code\graphics\gropengltexture.cpp(1240): error C2065: 'GL_TEXTURE_COMPRESSED_ARB' : undeclared identifier
5>c:\fso\code\graphics\gropengltexture.cpp(1240): error C3861: 'glGetTexLevelParameteriv': identifier not found
5>c:\fso\code\graphics\gropengltexture.cpp(1241): error C2065: 'GL_PROXY_TEXTURE_2D' : undeclared identifier
5>c:\fso\code\graphics\gropengltexture.cpp(1241): error C2065: 'GL_TEXTURE_WIDTH' : undeclared identifier
5>c:\fso\code\graphics\gropengltexture.cpp(1241): error C3861: 'glGetTexLevelParameteriv': identifier not found
5>c:\fso\code\graphics\gropengltexture.cpp(1244): error C2065: 'GL_PROXY_TEXTURE_2D' : undeclared identifier
5>c:\fso\code\graphics\gropengltexture.cpp(1244): error C2065: 'GL_TEXTURE_INTERNAL_FORMAT' : undeclared identifier
5>c:\fso\code\graphics\gropengltexture.cpp(1244): error C3861: 'glGetTexLevelParameteriv': identifier not found
5>c:\fso\code\graphics\gropengltexture.cpp(1256): error C2065: 'GL_GENERATE_MIPMAP_SGIS' : undeclared identifier
5>c:\fso\code\graphics\gropengltexture.cpp(1257): error C2065: 'GL_GENERATE_MIPMAP_HINT_SGIS' : undeclared identifier
5>c:\fso\code\graphics\gropengltexture.cpp(1261): error C2065: 'GL_TEXTURE_COMPRESSION_HINT' : undeclared identifier
5>c:\fso\code\graphics\gropengltexture.cpp(1267): error C2065: 'GL_TEXTURE_COMPRESSED_ARB' : undeclared identifier
5>c:\fso\code\graphics\gropengltexture.cpp(1267): error C3861: 'glGetTexLevelParameteriv': identifier not found
5>c:\fso\code\graphics\gropengltexture.cpp(1270): error C2065: 'GL_TEXTURE_INTERNAL_FORMAT' : undeclared identifier
5>c:\fso\code\graphics\gropengltexture.cpp(1270): error C3861: 'glGetTexLevelParameteriv': identifier not found
5>c:\fso\code\graphics\gropengltexture.cpp(1275): error C2065: 'GL_TEXTURE_COMPRESSED_IMAGE_SIZE_ARB' : undeclared identifier
5>c:\fso\code\graphics\gropengltexture.cpp(1275): error C3861: 'glGetTexLevelParameteriv': identifier not found
5>c:\fso\code\graphics\gropengltexture.cpp(1289): error C2065: 'GL_TEXTURE_COMPRESSED_IMAGE_SIZE_ARB' : undeclared identifier
5>c:\fso\code\graphics\gropengltexture.cpp(1289): error C3861: 'glGetTexLevelParameteriv': identifier not found
5>c:\fso\code\graphics\gropengltexture.cpp(1290): error C2065: 'PFNGLGETCOMPRESSEDTEXIMAGEARBPROC' : undeclared identifier
5>c:\fso\code\graphics\gropengltexture.cpp(1290): error C2146: syntax error : missing ')' before identifier 'GL_Functions'
5>c:\fso\code\graphics\gropengltexture.cpp(1290): error C2059: syntax error : ')'
5>c:\fso\code\graphics\gropengltexture.cpp(1296): error C2065: 'GL_GENERATE_MIPMAP_SGIS' : undeclared identifier
5>c:\fso\code\graphics\gropengltexture.cpp(1300): error C2065: 'GL_TEXTURE_COMPRESSION_HINT' : undeclared identifier
5>c:\fso\code\graphics\gropengltexture.cpp(1365): error C2065: 'GL_UNSIGNED_INT_8_8_8_8_REV' : undeclared identifier
5>c:\fso\code\graphics\gropengltexture.cpp(1365): error C3861: 'glGetTexImage': identifier not found
5> gropenglstate.cpp
5>c:\fso\code\graphics\gropengl.h(278): error C2371: 'GLint' : redefinition; different basic types
5> c:\fso\code\graphics\gl-wes\wes_gl_defines.h(202) : see declaration of 'GLint'
5>c:\fso\code\graphics\gropenglstate.cpp(47): error C2065: 'PFNGLACTIVETEXTUREARBPROC' : undeclared identifier
5>c:\fso\code\graphics\gropenglstate.cpp(47): error C2146: syntax error : missing ')' before identifier 'GL_Functions'
5>c:\fso\code\graphics\gropenglstate.cpp(47): error C2059: syntax error : ')'
5>c:\fso\code\graphics\gropenglstate.cpp(200): error C2065: 'PFNGLACTIVETEXTUREARBPROC' : undeclared identifier
5>c:\fso\code\graphics\gropenglstate.cpp(200): error C2146: syntax error : missing ')' before identifier 'GL_Functions'
5>c:\fso\code\graphics\gropenglstate.cpp(200): error C2059: syntax error : ')'
5> gropenglshader.cpp
5>c:\fso\code\graphics\gropengl.h(278): error C2371: 'GLint' : redefinition; different basic types
5> c:\fso\code\graphics\gl-wes\wes_gl_defines.h(202) : see declaration of 'GLint'
5>c:\fso\code\graphics\gropenglshader.cpp(496): error C2065: 'GL_TEXTURE_WRAP_R' : undeclared identifier
5>c:\fso\code\graphics\gropenglshader.cpp(498): error C2065: 'GL_UNSIGNED_INT_8_8_8_8_REV' : undeclared identifier
5>c:\fso\code\graphics\gropenglshader.cpp(716): error C2065: 'GL_OBJECT_LINK_STATUS' : undeclared identifier
5> gropenglpostprocessing.cpp
5>c:\fso\code\graphics\gropengl.h(278): error C2371: 'GLint' : redefinition; different basic types
5> c:\fso\code\graphics\gl-wes\wes_gl_defines.h(202) : see declaration of 'GLint'
5>c:\fso\code\graphics\gropenglpostprocessing.cpp(225): error C2065: 'PFNGLDRAWBUFFERSPROC' : undeclared identifier
5>c:\fso\code\graphics\gropenglpostprocessing.cpp(225): error C2146: syntax error : missing ')' before identifier 'GL_Functions'
5>c:\fso\code\graphics\gropenglpostprocessing.cpp(225): error C2059: syntax error : ')'
5>c:\fso\code\graphics\gropenglpostprocessing.cpp(996): error C2065: 'GL_TEXTURE_WRAP_R' : undeclared identifier
5>c:\fso\code\graphics\gropenglpostprocessing.cpp(998): error C2065: 'GL_UNSIGNED_INT_8_8_8_8_REV' : undeclared identifier
5> Generating Code...
5> Compiling...
5> gropengllight.cpp
5>c:\fso\code\graphics\gropengl.h(278): error C2371: 'GLint' : redefinition; different basic types
5> c:\fso\code\graphics\gl-wes\wes_gl_defines.h(202) : see declaration of 'GLint'
5>c:\fso\code\graphics\gropengllight.cpp(309): error C3861: 'glLoadMatrixd': identifier not found
5>c:\fso\code\graphics\gropengllight.cpp(502): error C2065: 'GL_MAX_LIGHTS' : undeclared identifier
5>c:\fso\code\graphics\gropengllight.cpp(523): error C2664: 'glMaterialfv' : cannot convert parameter 3 from 'const float [4]' to 'GLfloat *'
5> Conversion loses qualifiers
5>c:\fso\code\graphics\gropengllight.cpp(527): error C2664: 'glMaterialfv' : cannot convert parameter 3 from 'const float [4]' to 'GLfloat *'
5> Conversion loses qualifiers
5>c:\fso\code\graphics\gropengllight.cpp(529): error C2664: 'glMaterialfv' : cannot convert parameter 3 from 'const float [4]' to 'GLfloat *'
5> Conversion loses qualifiers
5>c:\fso\code\graphics\gropengllight.cpp(535): error C2664: 'glMaterialfv' : cannot convert parameter 3 from 'const float [4]' to 'GLfloat *'
5> Conversion loses qualifiers
5>c:\fso\code\graphics\gropengllight.cpp(537): error C2664: 'glMaterialfv' : cannot convert parameter 3 from 'const float [4]' to 'GLfloat *'
5> Conversion loses qualifiers
5>c:\fso\code\graphics\gropengllight.cpp(541): error C2664: 'glMaterialfv' : cannot convert parameter 3 from 'const float [4]' to 'GLfloat *'
5> Conversion loses qualifiers
5>c:\fso\code\graphics\gropengllight.cpp(543): error C2664: 'glMaterialfv' : cannot convert parameter 3 from 'const float [4]' to 'GLfloat *'
5> Conversion loses qualifiers
5> gropenglextension.cpp
5>c:\fso\code\graphics\gropengl.h(278): error C2371: 'GLint' : redefinition; different basic types
5> c:\fso\code\graphics\gl-wes\wes_gl_defines.h(202) : see declaration of 'GLint'
5>c:\fso\code\graphics\gropenglextension.cpp(422): error C2065: 'GL_MAX_TEXTURE_IMAGE_UNITS_ARB' : undeclared identifier
5> gropengldraw.cpp
5>c:\fso\code\graphics\gropengl.h(278): error C2371: 'GLint' : redefinition; different basic types
5> c:\fso\code\graphics\gl-wes\wes_gl_defines.h(202) : see declaration of 'GLint'
5>c:\fso\code\graphics\gropengldraw.cpp(481): error C3861: 'glVertex2i': identifier not found
5>c:\fso\code\graphics\gropengldraw.cpp(484): error C3861: 'glVertex2i': identifier not found
5>c:\fso\code\graphics\gropengldraw.cpp(487): error C3861: 'glVertex2i': identifier not found
5>c:\fso\code\graphics\gropengldraw.cpp(490): error C3861: 'glVertex2i': identifier not found
5>c:\fso\code\graphics\gropengldraw.cpp(972): error C2065: 'PFNGLMULTITEXCOORD2FARBPROC' : undeclared identifier
5>c:\fso\code\graphics\gropengldraw.cpp(972): error C2146: syntax error : missing ')' before identifier 'GL_Functions'
5>c:\fso\code\graphics\gropengldraw.cpp(972): error C2059: syntax error : ')'
5>c:\fso\code\graphics\gropengldraw.cpp(973): error C2065: 'PFNGLMULTITEXCOORD2FARBPROC' : undeclared identifier
5>c:\fso\code\graphics\gropengldraw.cpp(973): error C2146: syntax error : missing ')' before identifier 'GL_Functions'
5>c:\fso\code\graphics\gropengldraw.cpp(973): error C2059: syntax error : ')'
5>c:\fso\code\graphics\gropengldraw.cpp(1289): error C3861: 'glDrawBuffer': identifier not found
5>c:\fso\code\graphics\gropengldraw.cpp(1398): error C2065: 'PFNGLDRAWBUFFERSPROC' : undeclared identifier
5>c:\fso\code\graphics\gropengldraw.cpp(1398): error C2146: syntax error : missing ')' before identifier 'GL_Functions'
5>c:\fso\code\graphics\gropengldraw.cpp(1398): error C2059: syntax error : ')'
5>c:\fso\code\graphics\gropengldraw.cpp(1591): error C3861: 'glVertex2i': identifier not found
5>c:\fso\code\graphics\gropengldraw.cpp(1592): error C3861: 'glVertex2i': identifier not found
5>c:\fso\code\graphics\gropengldraw.cpp(1593): error C3861: 'glVertex2i': identifier not found
5>c:\fso\code\graphics\gropengldraw.cpp(1594): error C3861: 'glVertex2i': identifier not found
5>c:\fso\code\graphics\gropengldraw.cpp(1622): error C3861: 'glVertex2i': identifier not found
5>c:\fso\code\graphics\gropengldraw.cpp(1623): error C3861: 'glVertex2i': identifier not found
5>c:\fso\code\graphics\gropengldraw.cpp(1624): error C3861: 'glVertex2i': identifier not found
5>c:\fso\code\graphics\gropengldraw.cpp(1625): error C3861: 'glVertex2i': identifier not found
5>c:\fso\code\graphics\gropengldraw.cpp(1652): error C3861: 'glVertex2i': identifier not found
5>c:\fso\code\graphics\gropengldraw.cpp(1653): error C3861: 'glVertex2i': identifier not found
5>c:\fso\code\graphics\gropengldraw.cpp(1654): error C3861: 'glVertex2i': identifier not found
5>c:\fso\code\graphics\gropengldraw.cpp(1655): error C3861: 'glVertex2i': identifier not found
5>c:\fso\code\graphics\gropengldraw.cpp(1913): error C3861: 'glColor3fv': identifier not found
5>c:\fso\code\graphics\gropengldraw.cpp(1929): error C2065: 'GLUquadricObj' : undeclared identifier
5>c:\fso\code\graphics\gropengldraw.cpp(1929): error C2065: 'quad' : undeclared identifier
5>c:\fso\code\graphics\gropengldraw.cpp(1933): error C2065: 'quad' : undeclared identifier
5>c:\fso\code\graphics\gropengldraw.cpp(1933): error C3861: 'gluNewQuadric': identifier not found
5>c:\fso\code\graphics\gropengldraw.cpp(1935): error C2065: 'quad' : undeclared identifier
5>c:\fso\code\graphics\gropengldraw.cpp(1948): error C2065: 'quad' : undeclared identifier
5>c:\fso\code\graphics\gropengldraw.cpp(1948): error C2065: 'GLU_ERROR' : undeclared identifier
5>c:\fso\code\graphics\gropengldraw.cpp(1948): error C3861: 'gluQuadricCallback': identifier not found
5>c:\fso\code\graphics\gropengldraw.cpp(1951): error C2065: 'quad' : undeclared identifier
5>c:\fso\code\graphics\gropengldraw.cpp(1951): error C2065: 'GLU_FILL' : undeclared identifier
5>c:\fso\code\graphics\gropengldraw.cpp(1951): error C3861: 'gluQuadricDrawStyle': identifier not found
5>c:\fso\code\graphics\gropengldraw.cpp(1954): error C2065: 'quad' : undeclared identifier
5>c:\fso\code\graphics\gropengldraw.cpp(1954): error C2065: 'GLU_NONE' : undeclared identifier
5>c:\fso\code\graphics\gropengldraw.cpp(1954): error C3861: 'gluQuadricNormals': identifier not found
5>c:\fso\code\graphics\gropengldraw.cpp(1957): error C2065: 'quad' : undeclared identifier
5>c:\fso\code\graphics\gropengldraw.cpp(1957): error C3861: 'gluSphere': identifier not found
5>c:\fso\code\graphics\gropengldraw.cpp(1960): error C2065: 'quad' : undeclared identifier
5>c:\fso\code\graphics\gropengldraw.cpp(1960): error C3861: 'gluDeleteQuadric': identifier not found
5>c:\fso\code\graphics\gropengldraw.cpp(2026): error C2065: 'GL_TEXTURE_WRAP_R' : undeclared identifier
5>c:\fso\code\graphics\gropengldraw.cpp(2028): error C2065: 'GL_UNSIGNED_INT_8_8_8_8_REV' : undeclared identifier
5>c:\fso\code\graphics\gropengldraw.cpp(2044): error C2065: 'GL_TEXTURE_WRAP_R' : undeclared identifier
5>c:\fso\code\graphics\gropengldraw.cpp(2046): error C2065: 'GL_UNSIGNED_INT_8_8_8_8_REV' : undeclared identifier
5>c:\fso\code\graphics\gropengldraw.cpp(2061): error C2065: 'GL_TEXTURE_WRAP_R' : undeclared identifier
5>c:\fso\code\graphics\gropengldraw.cpp(2062): error C2065: 'GL_TEXTURE_COMPARE_MODE' : undeclared identifier
5>c:\fso\code\graphics\gropengldraw.cpp(2064): error C2065: 'GL_DEPTH_COMPONENT32' : undeclared identifier
5>c:\fso\code\graphics\gropengldraw.cpp(2103): error C2065: 'GL_TEXTURE_WRAP_R' : undeclared identifier
5>c:\fso\code\graphics\gropengldraw.cpp(2105): error C2065: 'GL_UNSIGNED_INT_8_8_8_8_REV' : undeclared identifier
5>c:\fso\code\graphics\gropengldraw.cpp(2113): error C2065: 'GL_TEXTURE_WRAP_R' : undeclared identifier
5>c:\fso\code\graphics\gropengldraw.cpp(2115): error C2065: 'GL_UNSIGNED_INT_8_8_8_8_REV' : undeclared identifier
5>c:\fso\code\graphics\gropengldraw.cpp(2202): error C2065: 'PFNGLDRAWBUFFERSPROC' : undeclared identifier
5>c:\fso\code\graphics\gropengldraw.cpp(2202): error C2146: syntax error : missing ')' before identifier 'GL_Functions'
5>c:\fso\code\graphics\gropengldraw.cpp(2202): error C2059: syntax error : ')'
5>c:\fso\code\graphics\gropengldraw.cpp(2282): error C3861: 'glDrawBuffer': identifier not found
5>c:\fso\code\graphics\gropengldraw.cpp(2321): error C2065: 'PFNGLDRAWBUFFERSPROC' : undeclared identifier
5>c:\fso\code\graphics\gropengldraw.cpp(2321): error C2146: syntax error : missing ')' before identifier 'GL_Functions'
5>c:\fso\code\graphics\gropengldraw.cpp(2321): error C2059: syntax error : ')'
5> gropenglbmpman.cpp
5>c:\fso\code\graphics\gropengl.h(278): error C2371: 'GLint' : redefinition; different basic types
5> c:\fso\code\graphics\gl-wes\wes_gl_defines.h(202) : see declaration of 'GLint'
5> gropengl.cpp
5>c:\fso\code\graphics\gropengl.h(278): error C2371: 'GLint' : redefinition; different basic types
5> c:\fso\code\graphics\gl-wes\wes_gl_defines.h(202) : see declaration of 'GLint'
5>c:\fso\code\graphics\gropengl.cpp(58): warning C4244: 'initializing' : conversion from 'double' to 'int', possible loss of data
5>c:\fso\code\graphics\gropengl.cpp(528): error C3861: 'glReadBuffer': identifier not found
5>c:\fso\code\graphics\gropengl.cpp(529): error C2065: 'GL_UNSIGNED_INT_8_8_8_8_REV' : undeclared identifier
5>c:\fso\code\graphics\gropengl.cpp(544): error C2065: 'GL_UNSIGNED_INT_8_8_8_8_REV' : undeclared identifier
5>c:\fso\code\graphics\gropengl.cpp(656): error C2065: 'GL_FOG_DISTANCE_MODE_NV' : undeclared identifier
5>c:\fso\code\graphics\gropengl.cpp(656): error C2065: 'GL_EYE_RADIAL_NV' : undeclared identifier
5>c:\fso\code\graphics\gropengl.cpp(657): error C2065: 'GL_FOG_COORDINATE_SOURCE' : undeclared identifier
5>c:\fso\code\graphics\gropengl.cpp(657): error C2065: 'GL_FRAGMENT_DEPTH' : undeclared identifier
5>c:\fso\code\graphics\gropengl.cpp(665): error C2065: 'GL_FOG_COORDINATE_SOURCE' : undeclared identifier
5>c:\fso\code\graphics\gropengl.cpp(665): error C2065: 'GL_FRAGMENT_DEPTH' : undeclared identifier
5>c:\fso\code\graphics\gropengl.cpp(857): error C3861: 'glReadBuffer': identifier not found
5>c:\fso\code\graphics\gropengl.cpp(865): error C2065: 'GL_UNSIGNED_SHORT_1_5_5_5_REV' : undeclared identifier
5>c:\fso\code\graphics\gropengl.cpp(867): error C2065: 'GL_UNSIGNED_INT_8_8_8_8_REV' : undeclared identifier
5>c:\fso\code\graphics\gropengl.cpp(911): error C3861: 'glReadBuffer': identifier not found
5>c:\fso\code\graphics\gropengl.cpp(912): error C2065: 'GL_UNSIGNED_INT_8_8_8_8_REV' : undeclared identifier
5>c:\fso\code\graphics\gropengl.cpp(922): error C3861: 'glReadBuffer': identifier not found
5>c:\fso\code\graphics\gropengl.cpp(923): error C2065: 'GL_UNSIGNED_INT_8_8_8_8_REV' : undeclared identifier
5>c:\fso\code\graphics\gropengl.cpp(953): error C2065: 'GL_FRONT_LEFT' : undeclared identifier
5>c:\fso\code\graphics\gropengl.cpp(953): error C3861: 'glReadBuffer': identifier not found
5>c:\fso\code\graphics\gropengl.cpp(972): error C2065: 'GL_UNSIGNED_INT_8_8_8_8_REV' : undeclared identifier
5>c:\fso\code\graphics\gropengl.cpp(1027): error C2065: 'GL_UNSIGNED_INT_8_8_8_8_REV' : undeclared identifier
5>c:\fso\code\graphics\gropengl.cpp(1123): error C3861: 'glReadBuffer': identifier not found
5>c:\fso\code\graphics\gropengl.cpp(1124): error C2065: 'GL_BGR_EXT' : undeclared identifier
5>c:\fso\code\graphics\gropengl.cpp(1191): error C2065: 'GL_FILL' : undeclared identifier
5>c:\fso\code\graphics\gropengl.cpp(1191): error C3861: 'glPolygonMode': identifier not found
5>c:\fso\code\graphics\gropengl.cpp(1196): error C2065: 'GL_LINE' : undeclared identifier
5>c:\fso\code\graphics\gropengl.cpp(1196): error C3861: 'glPolygonMode': identifier not found
5>c:\fso\code\graphics\gropengl.cpp(1201): error C2065: 'GL_FILL' : undeclared identifier
5>c:\fso\code\graphics\gropengl.cpp(1201): error C3861: 'glPolygonMode': identifier not found
5>c:\fso\code\graphics\gropengl.cpp(1221): error C2065: 'GL_MATRIX_MODE' : undeclared identifier
5>c:\fso\code\graphics\gropengl.cpp(1222): error C2065: 'PFNGLACTIVETEXTUREARBPROC' : undeclared identifier
5>c:\fso\code\graphics\gropengl.cpp(1222): error C2146: syntax error : missing ')' before identifier 'GL_Functions'
5>c:\fso\code\graphics\gropengl.cpp(1222): error C2059: syntax error : ')'
5>c:\fso\code\graphics\gropengl.cpp(1237): error C2065: 'GL_MATRIX_MODE' : undeclared identifier
5>c:\fso\code\graphics\gropengl.cpp(1238): error C2065: 'PFNGLACTIVETEXTUREARBPROC' : undeclared identifier
5>c:\fso\code\graphics\gropengl.cpp(1238): error C2146: syntax error : missing ')' before identifier 'GL_Functions'
5>c:\fso\code\graphics\gropengl.cpp(1238): error C2059: syntax error : ')'
5>c:\fso\code\graphics\gropengl.cpp(1255): error C2065: 'GL_MATRIX_MODE' : undeclared identifier
5>c:\fso\code\graphics\gropengl.cpp(1256): error C2065: 'PFNGLACTIVETEXTUREARBPROC' : undeclared identifier
5>c:\fso\code\graphics\gropengl.cpp(1256): error C2146: syntax error : missing ')' before identifier 'GL_Functions'
5>c:\fso\code\graphics\gropengl.cpp(1256): error C2059: syntax error : ')'
5>c:\fso\code\graphics\gropengl.cpp(1286): error C3861: 'gluErrorString': identifier not found
5>c:\fso\code\graphics\gropengl.cpp(1324): error C2065: 'PFNWGLSWAPINTERVALEXTPROC' : undeclared identifier
5>c:\fso\code\graphics\gropengl.cpp(1324): error C2146: syntax error : missing ')' before identifier 'GL_EXT_Special'
5>c:\fso\code\graphics\gropengl.cpp(1324): error C2059: syntax error : ')'
5>c:\fso\code\graphics\gropengl.cpp(1900): error C2065: 'GL_MAX_TEXTURE_IMAGE_UNITS_ARB' : undeclared identifier
5>c:\fso\code\graphics\gropengl.cpp(1959): error C2065: 'GL_MAX_ELEMENTS_VERTICES' : undeclared identifier
5>c:\fso\code\graphics\gropengl.cpp(1960): error C2065: 'GL_MAX_ELEMENTS_INDICES' : undeclared identifier
So at this point im investigating what is missing on gl_wes. But that is nothing compared to what happens if you put in the OGL ES 2 libs directly.
-
If it's a project that "will take years", one should probably point out that ES is bound to progress, and it would be stupid if it didn't developed towards OpenGL standards. 2.0 is already 4 years old and with the new tegra and arm chips to promise "PS3 levels", this progress may not be that far off.
We should also remember the promise in ARM on actual pcs and laptops for the future. So all these devices that are fragmented in a very steep way now, they won't be so much in the future (of course, the convergence may happen in a way that is completely inappropriate and unusable for FSO).
With the "controls" in mind, I visualize something like tilting the device for joystick, one button to fire primaries, another the secondaries, and 4 or 5 that have the most important controls in mind, while letting all the other ones unused. Shields could be managed by leveraging the bar graphs, likewise with velocity. For picking up targets upfront, you could simply touch them.
Don't take me seriously, I'm just daydreaming.
-
I don't think that ES is going to go much farther than version 2. To me, it's more of a transitory standard, because as embedded GPUs get more capable, they'll probably go and implement the full OpenGL standard. Also note that ES2 is based on OpenGL3, and as such already is as flexible as you would want it to be.
-
Yes that also makes sense. More so.
-
I don't think that ES is going to go much farther than version 2. To me, it's more of a transitory standard, because as embedded GPUs get more capable, they'll probably go and implement the full OpenGL standard. Also note that ES2 is based on OpenGL3, and as such already is as flexible as you would want it to be.
That will depend if they can give support to full OpenGL whiout removing OpenGL ES/OpenVG/EGL supports.
But i dont think they will, full OpenGL spec needs a good performance in float point operations, thats requieres extra hardware, and thats means extra power comsuption. Power comsuption is the main issue.
Tegra 3 is more than powerfull enoght, they could have done it there, but they did not.
But someone will have to something soner or later, since ES 2.0 is quite old, as it is based on OpenGL 2.0.
-
Well if you see what epic is doing in the iphone 4s, they apparently have little need of better standards...
-
That will depend if they can give support to full OpenGL whiout removing OpenGL ES/OpenVG/EGL supports.
But i dont think they will, full OpenGL spec needs a good performance in float point operations, thats requieres extra hardware, and thats means extra power comsuption. Power comsuption is the main issue.
Tegra 3 is more than powerfull enoght, they could have done it there, but they did not.
But someone will have to something soner or later, since ES 2.0 is quite old, as it is based on OpenGL 2.0.
Shows how much you know :P
OpenGL ES 2, in its basic concepts (no fixed function pipeline, for example), is very close to OpenGL 3 already. Oh, and part of OpenGL 4 is compatibility to ES 2 (as in, ES2 is a subset of OGL4).
Updating GLES to better reflect OGL3 requires a leap in hardware capabilities that we're probably going to see in two or three generations, when Intel and AMD try to get a piece of the Smartphone/Tablet market.
OpenVG is unrelated to OGL functionality (albeit closely related); while EGL is kept up to date regularly.
-
Again, Windows 8 will change that, face it, Linux cant change the world, Android is Linux, so the same applies.
Windows 8 ist even close to launch yet and Futuremark already announced a 3Dmark for ARM (and x86) and mobile platforms running Windows 8, that means it will be using OpenGL ES 2.0.
to E:
To what ive read ES 2 is based on OGL 2, i know nothing about OGL 3 or 4, so i give you that.
BTW, E you know lot more than me, you have any idea of what can expect from Windows 8 ARM? do you think they may implement Directx support using some kind of wrapper? and you know where i going with this, FSO can still use the old Directx api?
-
To what ive read ES 2 is based on OGL 2, i know nothing about OGL 3 or 4, so i give you that.
Yeah, the whole situation is a bit confusing. OpenGL ES2 is a hybrid of OpenGL 2 capabilities combined with OpenGL 3 API design. This means that you get the increased flexibility from GL3 and the way it is structured, while at the same time the hardware only has to support the limited feature set of OpenGL2; this was done in order to keep hardware requirements (especially power requirements) as low as possible while at the same time giving programmers the flexibility to get the most out of the hardware available.
BTW, E you know lot more than me, you have any idea of what can expect from Windows 8 ARM? do you think they may implement Directx support using some kind of wrapper? and you know where i going with this, FSO can still use the old Directx api?
It would surprise me if Microsoft didn't do some form of DirectX support in the ARM editions of Win8, given MS' desire to unify their operating system structures across all platforms (Windows Mobile, XBox, Windows Desktop). I suspect that we're going to get a special edition of DirectX 9 on ARM devices, or something similar to the XBox APIs.
As far as DirectX support in FSO goes, that's a bit tricky. After 3.6.9, the DirectX code was purged from the codebase, so there's no way at the moment to do DirectX builds. The basic infrastructure that allows API switching is still there though; it should be possible (if seriously work-intensive) to create a new DirectX interface. Whether that's actually a good idea is something I am unsure about though, given that the reasons for purging DX back then are still valid today (lack of people able to maintain the platform, mostly).
-
So, theoretically, once a test version of Win8 ARM comes out, and if it has DX8 support and there is a way to compile for WinARM(or whatever they call it), we can try to compile one of the older 3.6.9 sources to give it a try.
BTW, it seems that Visual Studio 11 dev preview can compile for ARM.
-
Well, yes, but being able to compile ARM binaries for an as-yet unreleased OS running on unreleased hardware is kind of a useless feature.
Also, I am pretty sure that when the SDKs and such come out, compiling our old DirectX code against it will be just as much trouble as trying to compile our current OpenGL code against OpenGL ES.
-
Err... there *is* a way to get ahold of
Windows 8 Developer Preview
If you know where to get it, that is the search term to use. :warp:
-
...
plz 2 read thread, kthxbai.
We were talking about the ARM version, you know, the one that isn't the Desktop version which you can download and test right now. You will excuse me if I do not take it for granted that any program written against the Windows 8 desktop specs will be able to run on all Windows 8 versions (especially those that do NOT use x86 hardware) without modifications.
-
I'd love to see a PSP version of FSO.
-
I'd love to see a PSP version of FSO.
Then get the homebrew SDKs (if there is such a thing), and get to coding.
-
...
plz 2 read thread, kthxbai.
We were talking about the ARM version, you know, the one that isn't the Desktop version which you can download and test right now. You will excuse me if I do not take it for granted that any program written against the Windows 8 desktop specs will be able to run on all Windows 8 versions (especially those that do NOT use x86 hardware) without modifications.
You mean Windows 8 still won't have universal binaries? :P
-
No, I mean we do not know how the APIs are going to look.
-
it was already stated that Windows 8 on ARM cant run x86 binaries. The apps needs to be recompiled for ARM, that's why VC2011 has capability to compile for ARM. Not sure how it works anyway.
What remains to be seem is if W8 has OpenGL ES and/or Directx 8/9 and/or Directx 10/11 support.
BTW, this is related, but i just noticed this today. http://adrenalin.gamestring.com/ sounds like a lot of input lag to me.
-
The apps needs to be recompiled for ARM, that's why VC2011 has capability to compile for ARM.
wasnt that capability around with the proper SDK's for the good old WinMo? i mean seriously, winmo devices almost universally run on ARM.
(from my limited research on the subject anyhow)
-
I only read the first few posts on this one and all I can say is who would want to play FS on a phone? I have a Samsung Epic, it will play anything I want it to but my old two button computer mouse is smarter than my smart phone.
-
Well you should have read the rest of the thread then.
The idea seems to be more to go for the android tablets than the phones, not that it helps with the control concerns that were brought up.
-
Well you should have read the rest of the thread then.
The idea seems to be more to go for the android tablets than the phones, not that it helps with the control concerns that were brought up.
Android phones and tablets are 100% capable of useing full qwerty keyboards, mice, and ps3 controlers over bluetooth, and for tablets, over usb. Just saying.
Pretty sure the main issue was opengl compatability.
-
Well you should have read the rest of the thread then.
The idea seems to be more to go for the android tablets than the phones, not that it helps with the control concerns that were brought up.
Android phones and tablets are 100% capable of useing full qwerty keyboards, mice, and ps3 controlers over bluetooth, and for tablets, over usb. Just saying.
Have you actually tried it? Because it sure does not look like they do it "properly"... "natively"... or "sensible"... or "usable" LOL.
Trying to use mouse buttons (i.e. more than 1 haha) and windows specific keys on your android tablet may be a revelation to you :p
You may (or may not - no clue) be able to get it all to work if you code yourself... but out of the box it's sure a mess.
Even just using a terminal app on android to try (remote) control your windows PC is a chore for this very reason. You always gotta work around the utterly deficient controls.
(I.e. you could even try to use something like Splashtop to "play" Freespace on your Android Tablet right now.... except you can't because the control issues would make you want to hang yourself. (... and input lag, but that is just an issue with Splashtop - not Android.) ...... You could possibly use Splashtop to make a silly "hey look Freespace is running on my Android Tablet Youtube video" tho that would make everyone hate you ;) ... mhhhhhhh..... lol)
-
Well you should have read the rest of the thread then.
The idea seems to be more to go for the android tablets than the phones, not that it helps with the control concerns that were brought up.
Didn't have time, was downloading a mod before I started splitting more wood for the heater and it finished to I made a quickie and shut down. But its nice to know you guys are thinking about Tablets, cause here soon those things are gonna be as big as laptops, and both FS1 and FS 2 run perfectly on my wifes Laptp
-
Well you should have read the rest of the thread then.
The idea seems to be more to go for the android tablets than the phones, not that it helps with the control concerns that were brought up.
Android phones and tablets are 100% capable of useing full qwerty keyboards, mice, and ps3 controlers over bluetooth, and for tablets, over usb. Just saying.
Have you actually tried it? Because it sure does not look like they do it "properly"... "natively"... or "sensible"... or "usable" LOL.
Trying to use mouse buttons (i.e. more than 1 haha) and windows specific keys on your android tablet may be a revelation to you :p
You may (or may not - no clue) be able to get it all to work if you code yourself... but out of the box it's sure a mess.
Even just using a terminal app on android to try (remote) control your windows PC is a chore for this very reason. You always gotta work around the utterly deficient controls.
(I.e. you could even try to use something like Splashtop to "play" Freespace on your Android Tablet right now.... except you can't because the control issues would make you want to hang yourself. (... and input lag, but that is just an issue with Splashtop - not Android.) ...... You could possibly use Splashtop to make a silly "hey look Freespace is running on my Android Tablet Youtube video" tho that would make everyone hate you ;) ... mhhhhhhh..... lol)
1: Freespace doesn't use Windows keys, so that doesn't matter very much.
2: If you need an app to use the keyboard/mouse, you're doing it wrong.
3: If there is any lag over a qwerty keyboard pluged in over USB (tablets), you're really doing it wrong.
4: No, a ps3 controler over bluetooth has zero lag. I use it for all emulators all the time.
Even Hacker's Keyboard offers full qwerty functionality, including ctrl and alt. Some devices may need to be rooted to support proper bluetooth devices, but thats not the concern of the app makers, considering a keyboard really is needed.
Well you should have read the rest of the thread then.
The idea seems to be more to go for the android tablets than the phones, not that it helps with the control concerns that were brought up.
Didn't have time, was downloading a mod before I started splitting more wood for the heater and it finished to I made a quickie and shut down. But its nice to know you guys are thinking about Tablets, cause here soon those things are gonna be as big as laptops, and both FS1 and FS 2 run perfectly on my wifes Laptp
Read the title [FS2 SCP and Android... (NOT GOING TO HAPPEN)]. Last i paid any attention it was due to some mobile version of opengl not supporting everything FSO uses, which is a pretty big issue.
-
KyadCK, you really do need to look up what Splashtop (or other "supposedly" gaming capable remote desktop programs) does to get a clue what I was actually referring to ;)
-
KyadCK, you really do need to look up what Splashtop (or other "supposedly" gaming capable remote desktop programs) does to get a clue what I was actually referring to ;)
The 'project' is literaly fso on android, not remote desktop to a pc playing it, so...
-
As far as the aspect of limited input ability goes, we've had someone turn FSO into an RTS. I'm sure with a little creative FREDing, scripting, and maybe a few code tweaks, that FSO could run something both playable and fun on a handheld device. Assuming you could get past all the other hurdles of that device, which is already covered in this thread so I'm not commenting on that.
-
OK, im a bit busy in the late days(new job) so i dindt much time to keep investigating this, but i may share my findings so far:
1) Ive abandoned the idea of making the game runs directly on OpenGL ES api, all existing wrappers are not up to the task, and rewriting the game to use OpenGL ES is not something i can do.
BUT, im searching other possibilities, and talking with the Chainfire3D dev, evaluating the odds of a OpenGL plugin for Chainfire3d, seems possible.
2) For the game itselft, it shouldt be much problem, as the Android NDK can compile native C/C++ code, and Android itselft can run compiled C/C++ apps from a terminal, ive already tested this with some of my own C apps.
The main problem should be doing the makefiles and ensure that everything compile fine, and that is not a quick task, but as the game compile already for Linux x86, i not expect any mayor source code change to be nesesary.
As for any other issue, the game needs to think that Android is just as any other Linux.
3) The launcher needs to be re-done, launcher has to be a full Android app. The Launcher should be the one capable of downloading all game data files to sdcard and to play the game, the launcher just needs to execute the game binary file.
-
Hi there,
as I would love to see Freespace2 running on Android (even with an acion-like dumbed-down version), I think I can contribute some pointers as I investigated some concepts without touching the code myself.
As the main problem here seems to be the OpenGL-compatibility issues, there seem to be several approaches to maybe reuse as much code as possible:
- OpenGL-issues: have a look at JumpCore: https://bitbucket.org/runhello/jumpcore/wiki/Home
It promises to abstract away the differences between OpenGL and OpenGL ES-versions
- libgdx: a cross-platform game-development framework targeting windows, linux and android http://libgdx.badlogicgames.com/
- as fs2_open for linux seems to be compiled against libsdl, pelya has ported libsdl to android: https://github.com/pelya/commandergenius and http://libsdl-android.sourceforge.net/
- there also exists an official android-port of libsdl: http://hg.libsdl.org/SDL/file/ (look for android-project as a template and readme.android for instructions)
As for the Launcher: I could help with that, even with trying to port the Qt-YAL to android.
So let me know if any of this helps and if you need help with anything... :-)
-
yeah sdl has been ported and used by several apps.
Also ill like to mention that Raspberry PI will be avalible soon, using the damn SLOW ARM11 and a good OpenGL ES card, so i think its not longer about Android, its about ARM/MIPS and OpenGL ES devices, from that, to Android its just a small port.
So bad for OpenGL as new mobile gpu are fully supporting OpenCL(parallel processing) and Directx11(Windows 8 likely)...
About mobile gpu performance, most of the devices are more powerfull than gpus from 1999 when the game was released, but shader performance will be crap, that for sure. Except from new Mali mobile gpus who are awesome.
BTW, Jumpcore seems good.
-
MMM im checking now and Windows 8 ARM seems to be causing havok in ARM gpus planning...
(http://www.nordichardware.com/images/labswedish/nyhetsartiklar/Grafik/ARM_Mali/fullimages/Mali_portfolio.jpg)
Those Malis are coming with full Directx support, and the new Tegra (Wayne), will be coming out with not only Directx, but OpenGL 4.0 support too... as well is PowerVR Series6.
So im optimistic about the future of FSO in mobile devices now, as well in Windows 8 ARM, as OpenGL ES support is not longer needed. I wonder if there is any chance of re-add Directx support for future Windows 8 ARM builds, as not all modern arm gpus will be supporting full OpenGL yet.
-
See this thread on making FSO OpenGL ES2 compatible (http://www.hard-light.net/forums/index.php?topic=80183).
-
The major problem for most mobile devices is still getting decent input devices attached to them. You can probably plug in a joystick and decent keyboard to a typical Android tablet, but you still need to find a way to prop it up and sit back. I have no idea how you would do that with an iOS device. When suggesting a new porting target for this game, that's the first question you have to answer.
However, it's entirely plausible that mobile-class hardware will get more exposure in laptop- and nettop-type devices. For example, the Asus Transformer Prime is essentially a laptop with an ARM CPU running Android, regardless of whether the "screen" detaches to become a tablet. Porting to that kind of device would make sense at least in theory.
The FitPC TrimSlice on my desk is also a viable target, running Linux but supporting OpenGL ES2 instead of full OpenGL. It compares directly with the Raspberry Pi that is my main target: significantly better CPU, several times more RAM, allegedly weaker GPU, ten times the price.
-
Personally i have two tablets, a a Novo 7 Basic (JZ4770 MIPS/GC860 GPU) and a Novo 7 Aurora (AllWinner A10 / Quad core Mali-400). And im using both of them with this:
(http://wholesale-district.com/avactis-images/u/keyboard-case-with-tablet.jpg)
so input is not a problem, in SEVERAL cases, also ive been playing FPS games on my Aurora, like Shadow Gun and Modern Combat 3, while its not that confortable to play, its still playable, so i think touch playing fs2 ITS posible, keep in mind that we can also try using the accelerometer/G-Sensor for ship movement.
-
Think I've got an answer here...
http://www.engadget.com/2012/03/16/kainy-remote-gaming-app/
Not truly standalone, it's remote, but it's do-able.
...and Shivan - nice... been looking to get me a Ainol unit for dev purposes and generally fiddling.
-
I wonder if there is any chance of re-add Directx support for future Windows 8 ARM builds, as not all modern arm gpus will be supporting full OpenGL yet.
:banghead:
Maintaining an OpenGL ES and OpenGL 3 code path at the same time: No big deal.
Maintaining a DirectX and OpenGL code path at the same time: Bloody stupid. There's a reason why we've dropped DirectX years ago. Maintaining feature parity for both renderers is too much work.
-
Think I've got an answer here...
http://www.engadget.com/2012/03/16/kainy-remote-gaming-app/
Not truly standalone, it's remote, but it's do-able.
...and Shivan - nice... been looking to get me a Ainol unit for dev purposes and generally fiddling.
Have you actually tried playing like that? Let's say that I was quite surprised as well as dismayed as my wishful thinking met reality while I was still on my "tablet craze".
It's bloody aggravating. The only benefit I can see is being able to sit on the couch... but you will still be yearning for proper controls every second you play. In addition to that you have to contend with input lag and video quality issues.
... and the moment you actually use a keyboard for your tablet it just becomes stupid as the whole Couch benefit goes away and its flat out inferior to the regular computer experience in every possible way.
These "streaming from PC" gaming solutions are a fancy way of producing results that are in every possible way worse than the original experience with little tangible benefit. You can't effectively use them outside of WLAN range, which means truly mobile gaming is still impossible, and they introduce a slew of new issues, most notably input lag and crappy controls (compared to the original input solutions). In general... once people got over the "Wow I can play this on my tablet COOOOLL!" effect... there is not a single actual reason left to actually play it on a tablet due to all the problems associated with the streaming solution and playing games on a tablet in general.
My advice: If you want Couch gaming... invest in a projector with low input lag and an USB extension cable for your Joystick/Keyboard or possibly a wireless Keyboard. Best of all worlds :)
-
... ... ...
If you don't like it don't use it.
Some people like to try new things even if they aren't the established or quote un quote "best" way.
...and no "I' don't plan to play like that, but I beleive it'd be entirely possible to make a somewhat fun space sim experience
on a android device. As such I posted that so the people here wanting to try it could take a shot at it...
-
... ... ...
If you don't like it don't use it.
Some people like to try new things even if they aren't the established or quote un quote "best" way.
...and no "I' don't plan to play like that, but I beleive it'd be entirely possible to make a somewhat fun space sim experience
on a android device. As such I posted that so the people here wanting to try it could take a shot at it...
Just sharing my experience with actually trying it. Sorry if it sounded too harsh. :)
In general there s a lot of hype about Android (and IOS)... but sadly, the solutions offered are quite often extremely lacking or even not practical at all.
Tablets are a great way for media consumption and especially for browsing the web... but... sadly...
... most of my other hands on Android experiences went like this: "Oh cool you can do *this* on Android too! Let's try it... yeah I guess it runs, sort of... gosh this sucks, why would anyone actually want to do *this* on a tablet like *that*?" lol.
-
Bluetooth roll-up keyboard + Bluetooth portable mouse = Profit?
-
Bluetooth roll-up keyboard + Bluetooth portable mouse = Profit?
Well, in my eyes the biggest benefit of a tablet is that you can use it on the couch. With a keyboard, BT mouse and its tiny screen that is not really conveniently possible however, so it would lose it's biggest benefit.
And were you talking about Kainy?
In that case, instead of sitting in front of your PC with its 22"-24" monitor, you would stream the game from your PC to your tablet over WLAN, so you could sit in front of a tiny 7"-10" tablet screen, while dealing with input lag and video streaming issues?
Yeah.... great idea. :p To each their own LOL.
And as said before, if it's about "quality" couch based entertainment... you can always take a step forward and buy a projector... instead of making ten leaps back by trying to awkwardly stream PC games to a tablet.
-
Well, streaming from PC to tablet does allow you to keep gaming while you're doing something like taking a dump, if that's what you desire. :p
-
would a simple model viewer be possible? I think that'd be awesome just to have the model + textures available on my Samsung.
-
You can already do that provided you export to OBJ.
https://play.google.com/store/apps/details?id=net.mcmiracom.modelviewer&feature=search_result
-
sweet!!!!!!!!!!!!!!!!! :eek2:
would you need to modify the texture files as well?
-
I don't know, there's a handful of model viewers on there. Just look around a bit.
-
Was changing the thread title really necessary?
-
It's HLP. C'mon, now.
-
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
-
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.
-
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.
-
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. ;)
-
Just don't try to run it on Windows RT.
-
I bet Windows RT support will be a lot easier than Android...
Im still unsure how WinRT works on graphic APIs
-
LOL, good luck with the ARM build.
-
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...
-
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.
(http://imageshack.us/a/img191/940/img20121009174554.jpg)
And so can my Nexus7.
(http://imageshack.us/a/img338/5449/img20121010015133.jpg)
And even older devices then that can too. The ability to run Linux on Android isn't a new one by any means.
-
Yeah this too.
(http://i.imgur.com/CYi18.jpg)
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 :P
-
uh, tell me again what's the major difference in the ES API versus their respective OpenGL APIs?
-
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).
-
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?
-
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).
-
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 :P, 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.
-
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.
-
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.
-
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.
-
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.
-
But can desktop OpenGL be used on Android? i cant get a answer anywhere.
This took me literally two seconds to find. (http://developer.android.com/guide/topics/graphics/opengl.html)
What part of "Android supports OpenGL ES 1.0 on Android <= 2.2 and OpenGL ES 2 on higher versions" is unclear?
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.
Good luck with that.
-
Actually the NDK is playing by the rules, you will never see OpenGL on there unless is supported by all SoC running a specific version of Android, something that may never happen. Unless adoption of OpenGL 4.3 with full compatbility with ES 3 is selected for support by mobile gpus, thats the only chance in the future.
But ive been asking to XBMC devs, and they say is possible to use desktop OpenGL on android as long the gpu and driver supports it, the NDK is missing the headers but thats all.
-
This is what i was talking about, http://www.ainol-novo.com/ainol-novo9-quad-core-9-7-inch-retina-screen-ram-2gb-android-tablet-pc-16gb.html
SGX544 supports OpenGL 2.1
-
So?
Have you actually given any thought at all to such issues as gameplay yet? Or how to get coders to work on this?
-
I imagine that those problems could be sorted out. We already had one coder working on this to some extent, going through the code and removing some of the more archaic OpenGL calls that just don't exist on the more trimmed down varieties of the library. As far as input goes, all it would take is an SDL touchscreen driver and a clever modder to make use of the engine on some of these platforms. Or, for the more desktop-like embedded platforms, that have input device support, I would think gameplay wouldn't have to be very different at all. All you need is to have it running Linux and hook up a USB hub and you have all your input device support you need. I assume that's the gameplay aspect you were referring to, the limited input support available on most embedded platforms.
-
This is likely to sort out the input on Windows based tablets
http://blog.overwolf.com/
Im thinking of Freespace 2 + Windows 8.1 based Bay Trail tablet.