[The E]

Again, please provide proof that that hardware was available for the price necessary at the time the R-Pi project got started. I have no doubt that the next version of the Pi will be an upgrade, but please bear in mind the constraints the original hardware was released under; the price point was one of the hard constraints that the makers didn't want to violate, as far as I know. *****ing about how it could be better if it were more expensive is missing the point by quite a margin.

But i trought it where GPU limited because of using old OpenGL code. Fixing GPU programing will likely cause CPU usage to increase,

The exact opposite is true. FSO is CPU-limited because the graphics code does far too many things on the CPU side of things; Fixing our OpenGL pipeline is largely about using fewer OpenGL commands and state switches to achieve the same goal.

[Nuke]

the pi is about $20 cheaper than my first arduino and about 35x faster (forgetting the fact that its 8-bit vs 32-bit), not to mention it has an fpu and gpu while an arduino does not. even if it doesnt pan out in the running freespace department im sure i can use it for my other freespace related ideas. not to mention many a hardware project thanks to its gpio capabilities.

[Kromaatikse]

The retail code I ran on the old laptop doesn't use OpenGL at all - it is Direct3D.  I have no idea whether that implementation is efficient or not, but it runs well on old hardware so it can't be too awful.

The R-Pi's GPU *does* support programmable shaders, via OpenGL ES 2.  But to use that, we have to thoroughly overhaul the rendering engine as described at length previously.  Hopefully this overhaul will allow using the GPU more thoroughly and involving the CPU less.  An intermediate goal will be to use OpenGL ES 1, which requires vertex arrays but doesn't support shaders - this is more similar to the way the bulk of the current code works.

The relatively small amount of VRAM (128MB at maximum, if half the RAM is dedicated to it) is likely to limit the number of advanced features we can turn on.  But my experience with a 16MB Rage128 Mobility suggests that retail data plus glow/shine maps plus hi-poly models shouldn't be a problem.  Beyond that we'll just have to see.  The Foundation has stated clearly that increasing total RAM to 512MB would have been considerably more expensive, out of proportion to the increase in capacity - but they did manage to find 256MB chips cheap enough to fit to the Model A as well as the Model B.  Originally they had planned to fit only 128MB total to the Model A.

And, as I just mentioned, the ARM11 isn't as weak as you might assume if you are used to this year's desktop PCs.  It is much less capable than Sandy Bridge or even Tegra 3, but it is significantly more powerful than the minimum requirements for retail FS2, especially in the FPU and memory access departments which matter most.  It will be worth coding efficiently, that is all.

[The E]

Well, we are trying. Next thing on my list of things to do would be to update the patch I posted previously in this thread (and which was largely ignored ) to work well with the changes introduced recently (we moved glowpoint rendering to use the batch renderer instead of rendering them during model rendering).

Oh, and there are a few things Valathil is working on which may also offer benefits in the future. See: http://www.youtube.com/watch?v=LXDXQMSmXe4&feature=g-all-u and http://www.youtube.com/watch?v=q4Z2s3Q8t5E&feature=g-all-u

[Kromaatikse]

Yes, that sort of patch looks to be very helpful when I finally get around to restarting work on this.  I didn't ignore it, but I wasn't quite ready to make use of it since I was in the final stages of an important project at work.

How much work would the update to the latest trunk require?

[The E]

Not much, I believe. Should be doable in a couple minutes, tops (I just couldn't do it while away from my home comp)

EDIT: Aaaand committed in revision 8973

[Kromaatikse]

Good - I'll look forward to it then.   

[Kromaatikse]

My R-Pi is currently a bit overloaded with compiling Firefox (one of the link stages is using 900MB, so is mostly in swap), but I was able to checkout that revision (after first compiling subversion) and have a look.

There are still 15 calls to glBegin in gropengldraw.cpp, but this seems to be a much smaller overall number than I remember.  Good work.  We need to remove *all* such calls no matter how little they are used, and probably take care of a few other compatibility quirks, before OpenGL ES 1 will work.  That's in addition to modifying the context creation logic (which will have to be hidden behind a configure flag).

First however, I'm going to build it for straight OpenGL/GLX and try to run it with the display on one of my Linux desktops.  X11 is helpful that way, even if it's nasty in a lot of other ways.  The 100Mbps network link will probably be the bottleneck, but this should at least tell us something concrete about the CPU usage, since people seem to be worried about that.

[ShivanSpS]

oh i was to post this earlier and i forget, this is the list of dependencys to build fso and wxlauncher, i did not find the list of dependencys anywhere, i know configure tell you what ones are missing, but its kind of a waste of time.

Code: [Select]

autoconf subversion build-essential libsdl1.2-dev liblua5.1-dev libtheora-dev libvorbis-dev libogg-dev libjpeg-dev libopenal-dev cmake mercurial libwxgtk2.8-dev python-markdownThe last 4 are for wxlauncher only.
When i compiled fso on my A10 it took about 45mins, i wonder if CC is possible.
I was missing fred2, i think there is a argument for that.

What i was trying to compile out of curiosity is "glesport", is some kind of a modified old mesa gl lib that act as a wrapper that intercept gl calls and convert them to gles, i can imagine the process to be very slow, but still better than using the software renderer, i heard of some people that managed to run Quake 2 with that...

[Kromaatikse]

AFAIK you won't get FRED on Linux, it has too many Windows specific things.

I think I have most of the dependencies already, but I'l just build the ones I don't have yet.  I'm using Gentoo...

[ShivanSpS]

the pi is about $20 cheaper than my first arduino and about 35x faster (forgetting the fact that its 8-bit vs 32-bit), not to mention it has an fpu and gpu while an arduino does not. even if it doesnt pan out in the running freespace department im sure i can use it for my other freespace related ideas. not to mention many a hardware project thanks to its gpio capabilities.

I just checked the prices, the R-PI B is about 50-55 usd with shipping with unknow avalibility.

I quick search on ebay i get (im not going to post links): With the AllWinner A10 processor
-100usd for Mele A1000 TVBox (512MB ram, with all video outputs, ethernet and a real SATA port)
-90usd for Mini X (1gb ram, remote control)
-75usd for MK802 (1gb ram)

All free shipping, every one of them comes with a case, DC adapter, some even HDMI cable, Wifi N, 4GB internal flash, dual boot Android 4.0.3 and Linux(and soon XBMC), very high bitrate multi-format 2160P VPU(with 3D support somehow), and a 1 to 1.5ghz ARMv7 cpu, so yeah, R-PI is cheaper and have a better gpu (Mali-400 on A10), but if i going to have something to use as a HTPC with capability to play FSO its not going to be the R-PI, also there is a lot of cheap A10 tablets out there.
It depends on what use every one of us want to give them.

[niffiwan]

oh i was to post this earlier and i forget, this is the list of dependencys to build fso and wxlauncher, i did not find the list of dependencys anywhere, i know configure tell you what ones are missing, but its kind of a waste of time.

The wiki has a dependencies list for different distros: http://www.hard-light.net/wiki/index.php/Fs2_open_on_Linux/Installing_the_Development_Libraries

And here's the start of the "Linux guide": http://www.hard-light.net/wiki/index.php/Guide_to_FS_Open_on_Linux

[ShivanSpS]

oh i was to post this earlier and i forget, this is the list of dependencys to build fso and wxlauncher, i did not find the list of dependencys anywhere, i know configure tell you what ones are missing, but its kind of a waste of time.

The wiki has a dependencies list for different distros: http://www.hard-light.net/wiki/index.php/Fs2_open_on_Linux/Installing_the_Development_Libraries

And here's the start of the "Linux guide": http://www.hard-light.net/wiki/index.php/Guide_to_FS_Open_on_Linux

oh i did not look in the wiki, sorry.

Anyway, with config is not hard to figure it out either, but it seem odd there where no a "how to build" file on the svn, or maybe its there and dindt see it... i think there should be a link to that wiki page in the readme/install files in the svn.

[niffiwan]

good point - I'll have to have a look at that, I know many of the README/CHANGE/INSTALL (& similar) files in the project are out of date...

[Nuke]

the pi is about $20 cheaper than my first arduino and about 35x faster (forgetting the fact that its 8-bit vs 32-bit), not to mention it has an fpu and gpu while an arduino does not. even if it doesnt pan out in the running freespace department im sure i can use it for my other freespace related ideas. not to mention many a hardware project thanks to its gpio capabilities.

I just checked the prices, the R-PI B is about 50-55 usd with shipping with unknow avalibility.

if its more than $50 il just have to wait another month or two. there are other arm platforms i guess but the thing is i want the pi because it is better suited for the uses i have in mind. also i plan to get me a 3d printer or laser cutter in a few months with which an appropriate enclosure could be fabricated.

[niffiwan]

EDIT: Aaaand committed in revision 8973

The E - I think you need to declare inline functions in the header, not the .cpp?  Otherwise you get this when compiling with gcc:

Code: [Select]

libcode.a(gropenglpostprocessing.o): In function `opengl_post_pass_fxaa()':
gropenglpostprocessing.cpp:(.text+0x216f): undefined reference to `opengl_draw_textured_quad(float, float, float, float, float, float, float, float)'
gropenglpostprocessing.cpp:(.text+0x2219): undefined reference to `opengl_draw_textured_quad(float, float, float, float, float, float, float, float)'
libcode.a(gropenglpostprocessing.o): In function `gr_opengl_post_process_end()':
gropenglpostprocessing.cpp:(.text+0x24b4): undefined reference to `opengl_draw_textured_quad(float, float, float, float, float, float, float, float)'
gropenglpostprocessing.cpp:(.text+0x25a7): undefined reference to `opengl_draw_textured_quad(float, float, float, float, float, float, float, float)'
gropenglpostprocessing.cpp:(.text+0x2651): undefined reference to `opengl_draw_textured_quad(float, float, float, float, float, float, float, float)'
libcode.a(gropenglpostprocessing.o):gropenglpostprocessing.cpp:(.text+0x28ae): more undefined references to `opengl_draw_textured_quad(float, float, float, float, float, float, float, float)' follow
collect2: ld returned 1 exit status
make[1]: *** [fs2_open_INF_r] Error 1
make: *** [all-recursive] Error 1


Here's a potential patch:

Code: [Select]

Index: fs2_open/code/graphics/gropengldraw.cpp
===================================================================
--- fs2_open/code/graphics/gropengldraw.cpp    (revision 8978)
+++ fs2_open/code/graphics/gropengldraw.cpp    (working copy)
@@ -59,29 +59,6 @@ void gr_opengl_pixel(int x, int y, bool resize)
  gr_line(x, y, x, y, resize);
 }
 
-inline void opengl_draw_textured_quad(
- GLfloat x1, GLfloat y1, GLfloat u1, GLfloat v1,
- GLfloat x2, GLfloat y2, GLfloat u2, GLfloat v2 )
-{
- GLfloat glVertices[4][4] = {
- { x1, y1, u1, v1 },
- { x1, y2, u1, v2 },
- { x2, y1, u2, v1 },
- { x2, y2, u2, v2 }
- };
-
- glVertexPointer(2, GL_FLOAT, sizeof(glVertices[0]), glVertices);
- glTexCoordPointer(2, GL_FLOAT, sizeof(glVertices[0]), &(glVertices[0][2]));
-
- glEnableClientState(GL_VERTEX_ARRAY);
- glEnableClientState(GL_TEXTURE_COORD_ARRAY);
-
- glDrawArrays(GL_TRIANGLE_STRIP, 0, 4);
-
- glDisableClientState(GL_VERTEX_ARRAY);
- glDisableClientState(GL_TEXTURE_COORD_ARRAY);
-}
-
 void opengl_aabitmap_ex_internal(int x, int y, int w, int h, int sx, int sy, bool resize, bool mirror)
 {
  if ( (w < 1) || (h < 1) ) {
Index: fs2_open/code/graphics/gropengldraw.h
===================================================================
--- fs2_open/code/graphics/gropengldraw.h    (revision 8978)
+++ fs2_open/code/graphics/gropengldraw.h    (working copy)
@@ -49,7 +49,26 @@ void gr_opengl_scene_texture_end();
 
 inline void opengl_draw_textured_quad(
  GLfloat x1, GLfloat y1, GLfloat u1, GLfloat v1,
- GLfloat x2, GLfloat y2, GLfloat u2, GLfloat v2 );
+ GLfloat x2, GLfloat y2, GLfloat u2, GLfloat v2 )
+{
+ GLfloat glVertices[4][4] = {
+ { x1, y1, u1, v1 },
+ { x1, y2, u1, v2 },
+ { x2, y1, u2, v1 },
+ { x2, y2, u2, v2 }
+ };
+
+ glVertexPointer(2, GL_FLOAT, sizeof(glVertices[0]), glVertices);
+ glTexCoordPointer(2, GL_FLOAT, sizeof(glVertices[0]), &(glVertices[0][2]));
+
+ glEnableClientState(GL_VERTEX_ARRAY);
+ glEnableClientState(GL_TEXTURE_COORD_ARRAY);
+
+ glDrawArrays(GL_TRIANGLE_STRIP, 0, 4);
+
+ glDisableClientState(GL_VERTEX_ARRAY);
+ glDisableClientState(GL_TEXTURE_COORD_ARRAY);
+}
 
 extern int Scene_texture_initialized;
 


also i plan to get me a 3d printer or laser cutter in a few months with which an appropriate enclosure could be fabricated.

You could try a lego case?

[Nuke]

also i plan to get me a 3d printer or laser cutter in a few months with which an appropriate enclosure could be fabricated.

You could try a lego case?

actually that was my interim plan, i got more legos than i know what to do with. one of the things i intend to use my future 3d printer for is custom bricks, and do away with destructive brick modding techniques.

[The E]

The E - I think you need to declare inline functions in the header, not the .cpp?  Otherwise you get this when compiling with gcc:

I think gcc needs to be less stupid, but what do I know?

[Echelon9]

The E - I think you need to declare inline functions in the header, not the .cpp?  Otherwise you get this when compiling with gcc:

I think gcc needs to be less stupid, but what do I know?

Clang/LLVM also agrees with GCC on this one. Committing fix to trunk.

[Kromaatikse]

On general principle, inline functions need to have their implementation visible at point of calling.  I'm glad people found a use for that one in more than one file.