Author Topic: OpenGL ES2 and Linux and pi - now with patches!  (Read 35467 times)

0 Members and 1 Guest are viewing this topic.

Re: OpenGL ES2 and Linux and pi - now with patches!
Looks like -Wconversion should do the trick provided a new enough version of G++ is in use. I'll try that tonight.

Meanwhile I had a quick look at apitrace v3 which looks very promising. Progress towards less API calls per frame should be quite visible in that.

 

Offline Aardwolf

  • 211
  • Posts: 16,384
    • Minecraft
Re: OpenGL ES2 and Linux and pi - now with patches!
Was about to make an "are you insane? my old Intel POS only goes up to GL 1.4" post...

But now that I look at the reference pages I see that glVertexPointer, etc. are from GL 1.1, so you're good :P

 
Re: OpenGL ES2 and Linux and pi - now with patches!
Indeed, it is the vertex *attribute* pointers that only come in with shader support.

Those will come later, at which point it will be necessary to explicitly add compatibility code for GL 1.x.

I have a test machine or two that I can fit with an original Radeon (supporting GL 1.3) to make sure that sort of thing continues to work.

 
Re: OpenGL ES2 and Linux and pi - now with patches!
Real Life got in the way for a while, but I'm getting back into this again.

Eventually the text rendering code is going to need more cleanup, but for the moment I've just fixed the conversion warnings.  I'm going to try to convert a few extra functions to vertex arrays for the next patch too.

 

Offline ShivanSpS

  • 210
Re: OpenGL ES2 and Linux and pi - now with patches!
Any update on this?

There is now one more reason for it... http://apc.io/about/

 
Re: OpenGL ES2 and Linux and pi - now with patches!
Real Life got in the way again.  I've had to put most of my mental energy into a customer project, and the rest into resolving a couple of computer failures at home.

And I still haven't got my Raspberry Pi.  The distributor as deigned to take my card details for it though, so it shouldn't be *that* far off.

No doubt once I get time to look at this again, I'll have to merge some upstream code into it first.

 

Offline jg18

  • A very happy zod
  • 210
  • can do more than spellcheck
Re: OpenGL ES2 and Linux and pi - now with patches!
Good to hear from you, Kromaatikse. I was concerned that you'd lost interest.

 

Offline qazwsx

  • POST DRUNK GET TITLE
  • 29
    • Minecraft
Re: OpenGL ES2 and Linux and pi - now with patches!
I shall be getting my Raspberry Pi by the end of the month, if you require any testing, nightly builds or if there's anything I can help with, I would be glad to be of assistance :)
<Achillion> I mean, it's not like he's shoving the brain-goo in a usb slot and praying to kurzweil to bring the singularity

<dsockwell> idk about you guys but the reason i follow God's law is so I can get my rocks off in the afterlife

 

Offline Echelon9

  • 210
Re: OpenGL ES2 and Linux and pi - now with patches!
I shall be getting my Raspberry Pi by the end of the month, if you require any testing, nightly builds or if there's anything I can help with, I would be glad to be of assistance :)
I'm sure that would be much appreciated.

 
Re: OpenGL ES2 and Linux and pi - now with patches!
As it happens, I picked mine up from the post office today.

A second tester is a good thing though, especially if you use a different distro.

 

Offline Nuke

  • Ka-Boom!
  • 212
  • Mutants Worship Me
Re: OpenGL ES2 and Linux and pi - now with patches!
i intend to get one at some point, when im not using it for electronics projects i can always do testing. of course that could be months off from now.

that said how well will the game code run with a risc architecture? will a 700 mhz cpu and 256 mb of ram be enough? probibly will want an optimized set of media vps, with models and textures optimized for low end (but not antique) hardware such as this.
I can no longer sit back and allow communist infiltration, communist indoctrination, communist subversion, and the international communist conspiracy to sap and impurify all of our precious bodily fluids.

Nuke's Scripting SVN

 

Offline niffiwan

  • 211
  • Eluder Class
Re: OpenGL ES2 and Linux and pi - now with patches!
make that a 3rd tester when my Pi arrives - scheduled for the end of June :)
Creating a fs2_open.log | Red Alert Bug = Hex Edit | MediaVPs 2014: Bigger HUD gauges | 32bit libs for 64bit Ubuntu
----
Debian Packages (testing/unstable): Freespace2 | wxLauncher
----
m|m: I think I'm suffering from Stockholm syndrome. Bmpman is starting to make sense and it's actually written reasonably well...

 
Re: OpenGL ES2 and Linux and pi - now with patches!
Given that a 700MHz Pentium-3 and a Rage128 was a high-end laptop spec around the time of retail release, and a 500MHz PowerPC G3 (RISC) was still considered faster than that...  The ARM11 core in the Raspberry Pi is not as powerful as a G3, but it's not total crap either, and at least has a competent FPU.

We'll see.  There's still a lot of work to do, but it will definitely be sensible to start with retail level graphics and then work up, mostly because of the RAM limitation.

Incidentally, I managed to extract a decent Pentium-3 based laptop (a ThinkPad, no less) from the office scrap pile a while ago, so I should be able to verify running the real retail code on that using an appropriate version of Windoze.  Probably the limitation would be the Rage128, which is a lot slower than what the Raspberry Pi has.  As an idea of just how high-end this laptop was at the time, it even has a USB port, so I can plug in my joystick!

 

Offline Nuke

  • Ka-Boom!
  • 212
  • Mutants Worship Me
Re: OpenGL ES2 and Linux and pi - now with patches!
yea, i remember the first time i ran the freespace 2 demo, on my old 120 mhz pentium machine, with 12 mb ram and a voodoo banshee card. ultimately i believe i ran the full version of the game on a 500 mhz pentium 3 (i think), 128 mb ram, and a voodoo 3 3500. im pretty sure its enough to run vanilla data (which iirc was not opengl optimized, as glide and d3d were the prime targets at the time). and that was the retail pre-scp engine, not the current iteration of the source which has by far a larger amount of stuff in it. ive been reading the spec sheet for the arm11 processor, and it has some advantages, it gets over the ****ing von neuman bottleneck for example.
I can no longer sit back and allow communist infiltration, communist indoctrination, communist subversion, and the international communist conspiracy to sap and impurify all of our precious bodily fluids.

Nuke's Scripting SVN

 

Offline pecenipicek

  • Roast Chicken
  • 211
  • Powered by copious amounts of coffee and nicotine
    • Minecraft
    • Skype
    • Steam
    • Twitter
    • PeceniPicek's own deviantart page
Re: OpenGL ES2 and Linux and pi - now with patches!
i've ran FS2 on a pentium 166 mmx, 128MB RAM, Voodoo2 8MB on top of a S3 Virge DX/GX
it was the only pc i had back then, and yes, the game ran smoothly on that. in glide mode however, not DX. DX always had some awful visual artifacting on the V2.
Skype: vrganjko
Ho, ho, ho, to the bottle I go
to heal my heart and drown my woe!
Rain may fall and wind may blow,
and many miles be still to go,
but under a tall tree I will lie!

The Apocalypse Project needs YOU! - recruiting info thread.

 
Re: OpenGL ES2 and Linux and pi - now with patches!
Quote
...it gets over the ****ing von neuman bottleneck for example.
I don't see how, unless you mean the caches that every CPU since the 68030 has had to some extent.  The RAM is often very close to the CPU these days (and the R-Pi uses package-on-package to maximise that), but the bottleneck still exists.

The nearest thing to a solution I've yet seen is the layout of a modern high-end graphics card, which uses many narrow RAM channels in parallel, gives each of them a separate L2 cache, and pipelines the shader engines so insanely deeply that the latency can be completely hidden in many cases.  But it's still possible to run even one of those monsters in a RAM bandwidth starved mode.

 

Offline The E

  • He's Ebeneezer Goode
  • Moderator
  • 213
  • Nothing personal, just tech support.
    • Steam
    • Twitter
Re: OpenGL ES2 and Linux and pi - now with patches!
Before I forget, here's a combined patch of the stuff in this thread, based on current trunk and with the post processing code adapted to use it as well:

Code: [Select]
Index: cutscene/mveplayer.cpp
===================================================================
--- cutscene/mveplayer.cpp (revision 8833)
+++ cutscene/mveplayer.cpp (working copy)
@@ -66,12 +66,13 @@
 void *g_vBackBuf1, *g_vBackBuf2;
 ushort *pixelbuf = NULL;
 static GLuint GLtex = 0;
-static GLint gl_screenYH = 0;
-static GLint gl_screenXW = 0;
+static GLfloat gl_screenYH = 0;
+static GLfloat gl_screenXW = 0;
 static GLfloat gl_screenU = 0;
 static GLfloat gl_screenV = 0;
+static GLfloat glVertices[4][4] = {{0}};
 static int g_screenWidth, g_screenHeight;
-static int g_screenX, g_screenY;
+static float g_screenX, g_screenY;
 static int g_truecolor = 0;
 static ubyte g_palette[768];
 static ubyte *g_pCurMap = NULL;
@@ -478,12 +479,12 @@
  }
 
  if (mve_scale_video) {
- g_screenX = ((fl2i(gr_screen.max_w / scale_by + 0.5f) - g_width) / 2);
- g_screenY = ((fl2i(gr_screen.max_h / scale_by + 0.5f) - g_height) / 2);
+ g_screenX = ((ceil((gr_screen.max_w / scale_by) - 0.5f) - g_width) / 2);
+ g_screenY = ((ceil((gr_screen.max_h / scale_by) - 0.5f) - g_height) / 2);
  } else {
  // centers on 1024x768, fills on 640x480
- g_screenX = ((gr_screen.max_w - g_width) / 2);
- g_screenY = ((gr_screen.max_h - g_height) / 2);
+ g_screenX = ((float)(gr_screen.max_w - g_width) / 2.0f);
+ g_screenY = ((float)(gr_screen.max_h - g_height) / 2.0f);
  }
 
  // set additional values for screen width/height and UV coords
@@ -494,6 +495,32 @@
  gl_screenU = i2fl(g_width) / i2fl(wp2);
  gl_screenV = i2fl(g_height) / i2fl(hp2);
  }
+
+ glVertices[0][0] = g_screenX;
+ glVertices[0][1] = g_screenY;
+ glVertices[0][2] = 0;
+ glVertices[0][3] = 0;
+
+ glVertices[1][0] = g_screenX;
+ glVertices[1][1] = gl_screenYH;
+ glVertices[1][2] = 0;
+ glVertices[1][3] = gl_screenV;
+
+ glVertices[2][0] = gl_screenXW;
+ glVertices[2][1] = g_screenY;
+ glVertices[2][2] = gl_screenU;
+ glVertices[2][3] = 0;
+
+ glVertices[3][0] = gl_screenXW;
+ glVertices[3][1] = gl_screenYH;
+ glVertices[3][2] = gl_screenU;
+ glVertices[3][3] = gl_screenV;
+
+ 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);
  }
 
  return 1;
@@ -579,24 +606,12 @@
  if (gr_screen.mode == GR_OPENGL) {
  glTexSubImage2D(GL_state.Texture.GetTarget(), 0, 0, 0, g_width, g_height, GL_BGRA, GL_UNSIGNED_SHORT_1_5_5_5_REV, pixelbuf);
 
- glBegin(GL_QUADS);
- glTexCoord2f(0, 0);
- glVertex2i(g_screenX, g_screenY);
-
- glTexCoord2f(0, gl_screenV);
- glVertex2i(g_screenX, gl_screenYH);
-
- glTexCoord2f(gl_screenU, gl_screenV);
- glVertex2i(gl_screenXW, gl_screenYH);
-
- glTexCoord2f(gl_screenU, 0);
- glVertex2i(gl_screenXW, g_screenY);
- glEnd();
+ glDrawArrays(GL_TRIANGLE_STRIP, 0, 4);
  } else {
  // DDOI - This is probably really fricking slow
  int bitmap = bm_create (16, g_screenWidth, g_screenHeight, pixelbuf, 0);
  gr_set_bitmap (bitmap);
- gr_bitmap (g_screenX, g_screenY, true);
+ gr_bitmap ((int)g_screenX, (int)g_screenY, true);
  bm_release (bitmap);
  }
 
@@ -779,6 +794,9 @@
 void mve_shutdown()
 {
  if (gr_screen.mode == GR_OPENGL) {
+ glDisableClientState(GL_VERTEX_ARRAY);
+ glDisableClientState(GL_TEXTURE_COORD_ARRAY);
+
  if (mve_scale_video) {
  glMatrixMode(GL_MODELVIEW);
  glPopMatrix();
Index: cutscene/oggplayer.cpp
===================================================================
--- cutscene/oggplayer.cpp (revision 8833)
+++ cutscene/oggplayer.cpp (working copy)
@@ -50,6 +50,7 @@
 static GLint gl_screenXW = 0;
 static GLfloat gl_screenU = 0;
 static GLfloat gl_screenV = 0;
+static GLfloat glVertices[4][4] = {{0}};
 
 // video externs from API graphics functions
 extern void opengl_tcache_get_adjusted_texture_size(int w_in, int h_in, int *w_out, int *h_out);
@@ -535,6 +536,32 @@
  vglUniform1iARB( vglGetUniformLocationARB(shader_id, "utex"), 1 );
  vglUniform1iARB( vglGetUniformLocationARB(shader_id, "vtex"), 2 );
  }
+
+ glVertices[0][0] = (GLfloat)g_screenX;
+ glVertices[0][1] = (GLfloat)g_screenY;
+ glVertices[0][2] = 0.0f;
+ glVertices[0][3] = 0.0f;
+
+ glVertices[1][0] = (GLfloat)g_screenX;
+ glVertices[1][1] = (GLfloat)gl_screenYH;
+ glVertices[1][2] = 0.0f;
+ glVertices[1][3] = gl_screenV;
+
+ glVertices[2][0] = (GLfloat)gl_screenXW;
+ glVertices[2][1] = (GLfloat)g_screenY;
+ glVertices[2][2] = gl_screenU;
+ glVertices[2][3] = 0.0f;
+
+ glVertices[3][0] = (GLfloat)gl_screenXW;
+ glVertices[3][1] = (GLfloat)gl_screenYH;
+ glVertices[3][2] = gl_screenU;
+ glVertices[3][3] = gl_screenV;
+
+ 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);
  }
  if(!use_shaders && tinfo->frame_height > 450) {
  mprintf(("VIDEO: No shader support and hd video is beeing played this can get choppy."));
@@ -549,6 +576,9 @@
  }
 
  if (gr_screen.mode == GR_OPENGL) {
+ glDisableClientState(GL_VERTEX_ARRAY);
+ glDisableClientState(GL_TEXTURE_COORD_ARRAY);
+
  if (scale_video) {
  glMatrixMode(GL_MODELVIEW);
  glPopMatrix();
@@ -680,19 +710,8 @@
  } else {
  glTexSubImage2D(GL_state.Texture.GetTarget(), 0, 0, 0, g_screenWidth, g_screenHeight, GL_BGR, GL_UNSIGNED_BYTE, pixelbuf);
  }
- glBegin(GL_QUADS);
- glTexCoord2f(0, 0);
- glVertex2i(g_screenX, g_screenY);
 
- glTexCoord2f(0, gl_screenV);
- glVertex2i(g_screenX, gl_screenYH);
-
- glTexCoord2f(gl_screenU, gl_screenV);
- glVertex2i(gl_screenXW, gl_screenYH);
-
- glTexCoord2f(gl_screenU, 0);
- glVertex2i(gl_screenXW, g_screenY);
- glEnd();
+ glDrawArrays(GL_TRIANGLE_STRIP, 0, 4);
  }
  Mouse_hidden = 1;
  gr_flip();
Index: graphics/gropengldraw.cpp
===================================================================
--- graphics/gropengldraw.cpp (revision 8833)
+++ graphics/gropengldraw.cpp (working copy)
@@ -59,6 +59,29 @@
  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) ) {
@@ -120,20 +143,8 @@
 
  GLboolean cull_face = GL_state.CullFace(GL_FALSE);
 
- glBegin(GL_QUADS);
- glTexCoord2f(u0, v1);
- glVertex2f(x1, y2);
+ opengl_draw_textured_quad(x1,y1,u0,v0, x2,y2,u1,v1);
 
- glTexCoord2f(u1, v1);
- glVertex2f(x2, y2);
-
- glTexCoord2f(u1, v0);
- glVertex2f(x2, y1);
-
- glTexCoord2f(u0, v0);
- glVertex2f(x1, y1);
- glEnd();
-
  GL_state.CullFace(cull_face);
 
  GL_CHECK_FOR_ERRORS("end of aabitmap_ex_internal()");
@@ -318,6 +329,7 @@
  opengl_aabitmap_ex_internal(dx1, dy1, (dx2 - dx1 + 1), (dy2 - dy1 + 1), sx, sy, resize, mirror);
 }
 
+struct v4 { GLfloat x,y,u,v; };
 
 void gr_opengl_string(int sx, int sy, const char *s, bool resize)
 {
@@ -328,6 +340,10 @@
  int x1, x2, y1, y2;
  float u_scale, v_scale;
 
+ // conversion from quads to triangles requires six vertices per quad
+ struct v4 *glVert = (struct v4*) alloca(sizeof(struct v4) * strlen(s) * 6);
+ int curChar = 0;
+
  if ( !Current_font || (*s == 0) ) {
  return;
  }
@@ -350,7 +366,7 @@
 
  bw = i2fl(ibw);
  bh = i2fl(ibh);
-
+
  // set color!
  if (gr_screen.current_color.is_alphacolor) {
  glColor4ub(gr_screen.current_color.red, gr_screen.current_color.green, gr_screen.current_color.blue, gr_screen.current_color.alpha);
@@ -384,9 +400,6 @@
 
  GLboolean cull_face = GL_state.CullFace(GL_FALSE);
 
- // start rendering...
- glBegin(GL_QUADS);
-
  // pick out letter coords, draw it, goto next letter and do the same
  while (*s) {
  x += spacing;
@@ -482,22 +495,43 @@
  u1 = u_scale * (i2fl((u+xd)+wc) / bw);
  v1 = v_scale * (i2fl((v+yd)+hc) / bh);
 
- glTexCoord2f(u0, v1);
- glVertex2i(x1, y2);
+ glVert[curChar*6 + 0].x = (GLfloat)x1;
+ glVert[curChar*6 + 0].y = (GLfloat)y2;
+ glVert[curChar*6 + 0].u = u0;
+ glVert[curChar*6 + 0].v = v1;
 
- glTexCoord2f(u1, v1);
- glVertex2i(x2, y2);
+ glVert[curChar*6 + 1].x = (GLfloat)x2;
+ glVert[curChar*6 + 1].y = (GLfloat)y2;
+ glVert[curChar*6 + 1].u = u1;
+ glVert[curChar*6 + 1].v = v1;
 
- glTexCoord2f(u1, v0);
- glVertex2i(x2, y1);
+ glVert[curChar*6 + 2].x = (GLfloat)x1;
+ glVert[curChar*6 + 2].y = (GLfloat)y1;
+ glVert[curChar*6 + 2].u = u0;
+ glVert[curChar*6 + 2].v = v0;
 
- glTexCoord2f(u0, v0);
- glVertex2i(x1, y1);
+ glVert[curChar*6 + 3] = glVert[curChar*6 + 1];
+ glVert[curChar*6 + 4] = glVert[curChar*6 + 2];
+
+ glVert[curChar*6 + 5].x = (GLfloat)x2;
+ glVert[curChar*6 + 5].y = (GLfloat)y1;
+ glVert[curChar*6 + 5].u = u1;
+ glVert[curChar*6 + 5].v = v0;
+
+ curChar++;
  }
 
- // done!
- glEnd();
+ glVertexPointer(2, GL_FLOAT, sizeof(struct v4), &glVert[0].x);
+ glTexCoordPointer(2, GL_FLOAT, sizeof(struct v4), &glVert[0].u);
 
+ glEnableClientState(GL_VERTEX_ARRAY);
+ glEnableClientState(GL_TEXTURE_COORD_ARRAY);
+
+ glDrawArrays(GL_TRIANGLES, 0, curChar * 6);
+
+ glDisableClientState(GL_VERTEX_ARRAY);
+ glDisableClientState(GL_TEXTURE_COORD_ARRAY);
+
  GL_state.CullFace(cull_face);
 
  GL_CHECK_FOR_ERRORS("end of string()");
@@ -890,16 +924,21 @@
  }
 }
 
+struct v6 { GLfloat x,y,z,w,u,v; };
+struct c4 { GLubyte r,g,b,a; };
+
 void opengl_draw_primitive(int nv, vertex **verts, uint flags, float u_scale, float v_scale, int r, int g, int b, int a, int override_primary = 0)
 {
  GLenum gl_mode = GL_TRIANGLE_FAN;
- float sx, sy, sz, sw, tu, tv;
- int i;
+ float sx, sy, sz, sw;
+ int i,j;
  vertex *va;
  bool isNebula = false;
  bool isRamp = false;
  bool isRGB = false;
  ubyte alpha = (ubyte)a;
+ struct v6 *vertPos = (struct v6*) alloca(sizeof(struct v6) * nv);
+ struct c4 *vertCol = (struct c4*) alloca(sizeof(struct c4) * nv);
 
  GL_CHECK_FOR_ERRORS("start of draw_primitive()");
 
@@ -922,12 +961,11 @@
  } else if (flags & TMAP_FLAG_QUADLIST) {
  gl_mode = GL_QUADS;
  } else if (flags & TMAP_FLAG_QUADSTRIP) {
- gl_mode = GL_QUAD_STRIP;
+ gl_mode = GL_TRIANGLE_STRIP;
+ Assert((nv % 2) == 0);
  }
 
- glBegin(gl_mode);
-
- for (i = (nv - 1); i >= 0; i--) {
+ for (i = (nv - 1), j = 0; i >= 0; i--, j++) {
  va = verts[i];
 
  sw = 1.0f;
@@ -957,32 +995,67 @@
  }
 
  if (override_primary) {
- glColor3ub(va->spec_r, va->spec_g, va->spec_b);
+ vertCol[j].r = va->spec_r;
+ vertCol[j].g = va->spec_g;
+ vertCol[j].b = va->spec_b;
+ vertCol[j].a = 255;
  } else {
  if (isNebula) {
  int pal = (va->b * (NEBULA_COLORS-1)) / 255;
- glColor4ub( gr_palette[pal*3+0], gr_palette[pal*3+1], gr_palette[pal*3+2], alpha );
+ vertCol[j].r = gr_palette[pal*3+0];
+ vertCol[j].g = gr_palette[pal*3+1];
+ vertCol[j].b = gr_palette[pal*3+2];
+ vertCol[j].a = alpha;
  } else if (isRamp) {
- glColor4ub( va->b, va->b, va->b, alpha );
+ vertCol[j].r = va->b;
+ vertCol[j].g = va->b;
+ vertCol[j].b = va->b;
+ vertCol[j].a = alpha;
  } else if (isRGB) {
- glColor4ub( va->r, va->g, va->b, alpha );
+ vertCol[j].r = va->r;
+ vertCol[j].g = va->g;
+ vertCol[j].b = va->b;
+ vertCol[j].a = alpha;
  }
  }
 
  if (flags & TMAP_FLAG_TEXTURED) {
- tu = va->texture_position.u * u_scale;
- tv = va->texture_position.v * v_scale;
-
- // use opengl hardware multitexturing
- vglMultiTexCoord2fARB(GL_TEXTURE0_ARB, tu, tv);
- vglMultiTexCoord2fARB(GL_TEXTURE1_ARB, tu, tv);
+ vertPos[j].u = va->texture_position.u * u_scale;
+ vertPos[j].v = va->texture_position.v * v_scale;
  }
 
- glVertex4f(sx, sy, -sz, sw);
+ vertPos[j].x = sx;
+ vertPos[j].y = sy;
+ vertPos[j].z = -sz;
+ vertPos[j].w = sw;
  }
 
- glEnd();
+ glVertexPointer(4, GL_FLOAT, sizeof(struct v6), &vertPos[0].x);
+ glEnableClientState(GL_VERTEX_ARRAY);
 
+ if(flags & TMAP_FLAG_TEXTURED) {
+ vglClientActiveTextureARB(GL_TEXTURE0);
+ glTexCoordPointer(2, GL_FLOAT, sizeof(struct v6), &vertPos[0].u);
+ glEnableClientState(GL_TEXTURE_COORD_ARRAY);
+
+ vglClientActiveTextureARB(GL_TEXTURE1);
+ glTexCoordPointer(2, GL_FLOAT, sizeof(struct v6), &vertPos[0].u);
+ glEnableClientState(GL_TEXTURE_COORD_ARRAY);
+ }
+
+ if(flags & (TMAP_FLAG_NEBULA | TMAP_FLAG_GOURAUD)) {
+ glColorPointer(4, GL_UNSIGNED_BYTE, 0, &vertCol[0].r);
+ glEnableClientState(GL_COLOR_ARRAY);
+ }
+
+ glDrawArrays(gl_mode, 0, nv);
+
+ glDisableClientState(GL_COLOR_ARRAY);
+ glDisableClientState(GL_VERTEX_ARRAY);
+ glDisableClientState(GL_TEXTURE_COORD_ARRAY);
+ vglClientActiveTextureARB(GL_TEXTURE0);
+ glDisableClientState(GL_TEXTURE_COORD_ARRAY);
+
  GL_CHECK_FOR_ERRORS("start of draw_primitive()");
 }
 
@@ -1726,19 +1799,7 @@
 
  glColor4f(1.0f, 1.0f, 1.0f, gr_screen.current_alpha);
 
- glBegin(GL_QUADS);
- glTexCoord2f(u0, v1);
- glVertex2f(x1, y2);
-
- glTexCoord2f(u1, v1);
- glVertex2f(x2, y2);
-
- glTexCoord2f(u1, v0);
- glVertex2f(x2, y1);
-
- glTexCoord2f(u0, v0);
- glVertex2f(x1, y1);
- glEnd();
+ opengl_draw_textured_quad(x1, y1, u0, v0, x2, y2, u1, v1);
 }
 
 
Index: graphics/gropengldraw.h
===================================================================
--- graphics/gropengldraw.h (revision 8833)
+++ graphics/gropengldraw.h (working copy)
@@ -47,6 +47,10 @@
 void gr_opengl_scene_texture_begin();
 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 );
+
 extern int Scene_texture_initialized;
 
 extern GLuint Scene_color_texture;
Index: graphics/gropenglpostprocessing.cpp
===================================================================
--- graphics/gropenglpostprocessing.cpp (revision 8833)
+++ graphics/gropenglpostprocessing.cpp (working copy)
@@ -155,20 +155,8 @@
  GL_state.Texture.SetTarget(GL_TEXTURE_2D);
  GL_state.Texture.Enable(Scene_color_texture);
 
- glBegin(GL_QUADS);
- glTexCoord2f(0.0f, 0.0f);
- glVertex2f(-1.0f, -1.0f);
+ opengl_draw_textured_quad(-1.0f, -1.0f, 0.0f, 0.0f, 1.0f, 1.0f, 1.0f, 1.0f);
 
- glTexCoord2f(1.0f, 0.0f);
- glVertex2f(1.0f, -1.0f);
-
- glTexCoord2f(1.0f, 1.0f);
- glVertex2f(1.0f, 1.0f);
-
- glTexCoord2f(0.0f, 1.0f);
- glVertex2f(-1.0f, 1.0f);
- glEnd();
-
  GL_state.Texture.Disable();
 
  // ------ end bright pass ------
@@ -200,19 +188,7 @@
 
  GL_state.Texture.Enable(Post_bloom_texture_id[pass]);
 
- glBegin(GL_QUADS);
- glTexCoord2f(0.0f, 0.0f);
- glVertex2f(-1.0f, -1.0f);
-
- glTexCoord2f(1.0f, 0.0f);
- glVertex2f(1.0f, -1.0f);
-
- glTexCoord2f(1.0f, 1.0f);
- glVertex2f(1.0f, 1.0f);
-
- glTexCoord2f(0.0f, 1.0f);
- glVertex2f(-1.0f, 1.0f);
- glEnd();
+ opengl_draw_textured_quad(-1.0f, -1.0f, 0.0f, 0.0f, 1.0f, 1.0f, 1.0f, 1.0f);
  }
 
  GL_state.Texture.Disable();
@@ -323,20 +299,8 @@
  GL_state.Texture.SetTarget(GL_TEXTURE_2D);
  GL_state.Texture.Enable(Scene_color_texture);
 
- glBegin(GL_QUADS);
- glTexCoord2f(0.0f, 0.0f);
- glVertex2f(-1.0f, -1.0f);
+ opengl_draw_textured_quad(-1.0f, -1.0f, 0.0f, 0.0f, 1.0f, 1.0f, Scene_texture_u_scale, Scene_texture_u_scale);
 
- glTexCoord2f(Scene_texture_u_scale, 0.0f);
- glVertex2f(1.0f, -1.0f);
-
- glTexCoord2f(Scene_texture_u_scale, Scene_texture_v_scale);
- glVertex2f(1.0f, 1.0f);
-
- glTexCoord2f(0.0f, Scene_texture_v_scale);
- glVertex2f(-1.0f, 1.0f);
- glEnd();
-
  GL_state.Texture.Disable();
 
  // set and configure post shader ..
@@ -353,20 +317,8 @@
  GL_state.Texture.SetTarget(GL_TEXTURE_2D);
  GL_state.Texture.Enable(Scene_luminance_texture);
 
- glBegin(GL_QUADS);
- glTexCoord2f(0.0f, 0.0f);
- glVertex2f(-1.0f, -1.0f);
+ opengl_draw_textured_quad(-1.0f, -1.0f, 0.0f, 0.0f, 1.0f, 1.0f, Scene_texture_u_scale, Scene_texture_u_scale);
 
- glTexCoord2f(Scene_texture_u_scale, 0.0f);
- glVertex2f(1.0f, -1.0f);
-
- glTexCoord2f(Scene_texture_u_scale, Scene_texture_v_scale);
- glVertex2f(1.0f, 1.0f);
-
- glTexCoord2f(0.0f, Scene_texture_v_scale);
- glVertex2f(-1.0f, 1.0f);
- glEnd();
-
  GL_state.Texture.Disable();
 
  opengl_shader_set_current();
@@ -432,19 +384,9 @@
  glColor4f(1.0f, 1.0f, 1.0f, 1.0f);
  GL_state.Blend(GL_TRUE);
  GL_state.SetAlphaBlendMode(ALPHA_BLEND_ADDITIVE);
- glBegin(GL_QUADS);
- glTexCoord2f(0.0f, 0.0f);
- glVertex2f(-1.0f, -1.0f);
+
+ opengl_draw_textured_quad(-1.0f, -1.0f, 0.0f, 0.0f, 1.0f, 1.0f, Scene_texture_u_scale, Scene_texture_u_scale);
 
- glTexCoord2f(Scene_texture_u_scale, 0.0f);
- glVertex2f(1.0f, -1.0f);
-
- glTexCoord2f(Scene_texture_u_scale, Scene_texture_v_scale);
- glVertex2f(1.0f, 1.0f);
-
- glTexCoord2f(0.0f, Scene_texture_v_scale);
- glVertex2f(-1.0f, 1.0f);
- glEnd();
  GL_state.Blend(GL_FALSE);
  break;
  }
@@ -511,20 +453,7 @@
  GL_state.Texture.SetTarget(GL_TEXTURE_2D);
  GL_state.Texture.Enable(Scene_color_texture);
 
- glBegin(GL_QUADS);
- glTexCoord2f(0.0f, 0.0f);
- glVertex2f(-1.0f, -1.0f);
-
- glTexCoord2f(Scene_texture_u_scale, 0.0f);
- glVertex2f(1.0f, -1.0f);
-
- glTexCoord2f(Scene_texture_u_scale, Scene_texture_v_scale);
- glVertex2f(1.0f, 1.0f);
-
- glTexCoord2f(0.0f, Scene_texture_v_scale);
- glVertex2f(-1.0f, 1.0f);
- glEnd();
-
+ opengl_draw_textured_quad(-1.0f, -1.0f, 0.0f, 0.0f, 1.0f, 1.0f, Scene_texture_u_scale, Scene_texture_u_scale);
  // Done!
 
  GL_state.Texture.SetActiveUnit(1);
If I'm just aching this can't go on
I came from chasing dreams to feel alone
There must be changes, miss to feel strong
I really need lifе to touch me
--Evergrey, Where August Mourns

 

Offline Nuke

  • Ka-Boom!
  • 212
  • Mutants Worship Me
Re: OpenGL ES2 and Linux and pi - now with patches!
Quote
...it gets over the ****ing von neuman bottleneck for example.
I don't see how, unless you mean the caches that every CPU since the 68030 has had to some extent.  The RAM is often very close to the CPU these days (and the R-Pi uses package-on-package to maximise that), but the bottleneck still exists.

The nearest thing to a solution I've yet seen is the layout of a modern high-end graphics card, which uses many narrow RAM channels in parallel, gives each of them a separate L2 cache, and pipelines the shader engines so insanely deeply that the latency can be completely hidden in many cases.  But it's still possible to run even one of those monsters in a RAM bandwidth starved mode.

in that memory and instruction memories are kept separate, if im reading the arm1176JZF-S technical reference manual (from the raspberry pi wiki) correctly.  at least in the level one memory system (section 7 in the manual), though im not sure about the level 2 memory system. it states that "separate Instruction and Data Caches in a Harvard arrangement", referencing harvard architecture model, which was developed in response to the von neuman bottleneck. of course im making a lot of assumptions base on a 10 minute scan through of a manual which would probibly take a week or two to read and comprehend.
« Last Edit: June 08, 2012, 07:33:06 am by Nuke »
I can no longer sit back and allow communist infiltration, communist indoctrination, communist subversion, and the international communist conspiracy to sap and impurify all of our precious bodily fluids.

Nuke's Scripting SVN

 
Re: OpenGL ES2 and Linux and pi - now with patches!
Ah, I see.  ARM uses a unified memory space like most CPUs, and for quite a while also a Harvard-type L1 cache - also like most modern CPUs.  This is a standard feature these days (eg. Pentium and anything newer) because it allows instruction prefetch to proceed largely independent of data accesses, without needing to dual-port the cache memory cells.

Note that some older ARM CPUs, such as the ARM6 and ARM7 cores, used a small unified L1 cache.  This utterly failed to matter because the cache could refill the instruction prefetch buffer after servicing a data access.  Most likely the cache was also dual-ported so that concurrent hit accesses were also possible.

But the memory bottleneck still exists for datasets that exceed the cache size, so the von Neumann problem is still there.

However, the ratio between the R-Pi's CPU core and it's memory is unusually shallow - it is an old core (700MHz, single issue) coupled to a relatively fast memory (400MHz DDR2, forget whether it's 32 or 64 bits wide).  Yet the bottleneck can still be there even in this case, because the RAM bandwidth is shared with a rather powerful GPU, which is more latency tolerant but hungrier for bandwidth than the CPU (when it is in use).

 

Offline Nuke

  • Ka-Boom!
  • 212
  • Mutants Worship Me
Re: OpenGL ES2 and Linux and pi - now with patches!
i didnt know about that, i guess you learn something new every day. modern cpus have a lot of complex details about them, where as a cpu from the 80s (or one in a modern microcontroller such as avr) is an amazingly simple little device compared to behemoths like modern x86 and arm cpus.
I can no longer sit back and allow communist infiltration, communist indoctrination, communist subversion, and the international communist conspiracy to sap and impurify all of our precious bodily fluids.

Nuke's Scripting SVN