I tried Enemy Territory and it works fine. So it got to be a problem with my game. I tend to think it has something to do with the opengl libraries.

If I'm not wrong, on Linux the Nvidia drivers install shared and static libraries for opengl. The ones that come with MinGW seems to be at least 1 year old. Would they have something to do with OpenGL performance?

I also noticed that the drivers I'm using on linux (43.63?) are a higher version that the ones I have on Windows (43.53...), I'll try downloading new ones and see what happens.

I've been touching my code here and there and I noticed the framerate drops down when I render 308 vertex arrays in a loop (5 quads each array, this seems odd, but it works on linux).

If I remove that part, the framerate gets increased almost at the same level I get on Linux...

Quote:Original post by _the_phantom_
the libraries are a non-issue, anything hardware accelerated goes via your gfx card drivers, the dlls/libs for windows havent been updated since 1.1.

Whats more likely is that for some reason those small batches are killing the performance. While I cant say why it doesnt effect you on linux the general rule is to try and make batches as large as you can, with 5 quads per array you are probably shoving far to much strain on the CPU thus causing the stall.

imo, you'll be better off reworking your code so that it shoves as much geometry as possible down the pipeline in one go, that should also improve things on the linux side.

Yes you are right, I was planning on doing this sometime in the future. Anyway, I think this shouldn't be happening, and I would like to know what's the reason. Am I just lucky? Or are still there other methods that will work fine on linux and at 40% on Ms. Windows? I would like to avoid them directly instead of coding everything and then testing if that works fine on both systems.

Thanks.

Could it be because I'm using quads?...

Quote:
While there is no theoretical reason why quads should be slower for the same area, in practice they are less useful than triangles, and there is no advantage to using them so hardware manufacturers focus on rendering triangles quickly at the expense of quads. Some OpenGL drivers may not even implement quads in hardware.

Quote:
Could it be because I'm using quads?...

Highly doubt that, since most recent drivers split quads into triangles anyway. Try increasing the amount of quads per batch, maybe that'll help.

And please, stop refering to Windows as Windoze, it has it's good points, just as Unix/Linux.

And note, I sugest you to try it on a decent Windows, try 98 or XP, as Millenium should be called Windows with Prettier GFX and crappier Overall.

Quote:Original post by owl

Quote:Original post by zedzeek
eg platformA might give you RGB555 textures when u ask for RGB8 and plaformB might give u RGB8 when u ask for RGB8
etc

I'm creating my textures with RGBA values. I run both the linux and Ms.Windows versions in 1024x768 32bits.

not precise ebuf, eg if ask for RGBA textures on windows u might be getting RGBA8 texture and on linux u might be getting RGBA4 textures, same thing with the windows etc.
always query after youve created them (windows textures etc) to see what u get given.
cause often what u ask for is not what u get given

Quote:Original post by zedzeek
cause often what u ask for is not what u get given

It's not a texture issue, I removed all the code related to textures and it still runs slow.

I've yet to test the very-lastest nv drivers..

want to host a zip of the exe (or source, I'm using Dev-C++ with the mingw port of GCC 3.3.1)? I'll try it out, and I'm sure others won't mind either.

I'm not connecting from home, so I can't upload it right now.
Anyway, the render method is quite simple, it's something like pseudo-this:

  Check_SDL_Window_Messages();  resetviewport();  erase_viewport();  check_SDL_keyboard_array_state();  update_camera_position();  update_light_position();  push();  Transform_Render_500_quads_mesh_vertex_array();  pop();  push();  TransformRender_50_quads_mesh_vertex_array();  pop();  Iterate_308_times:  {     Mesh_five_quads->enable_vertex_normal_texture_arrays();     push();     Mesh_five_quads->transform_and_draw_Vertex_Array();     pop();     Mesh_five_quads->Disable_every_array();  }  FlipBuffers();  

The opengl calls to draw the vertex arrays are the ones used in almost every tutorial out there. I'm not doing anything strange, nor using extensions of any kind. Not using sound neither.

EDIT: I tried enabling the arrays outside the loop but it still runs slow.

Okay. I've been working out this a little.

I downloaded the very lastest nvidia drivers yesterday and installed them. The first thing I noticed with this brand-new drivers for Ms. Windows is that they don't come anymore with an OpenGL option tab for turning vsinc on/off etc, but still comes with the Direct3D one. Ok, no problem.

As soon as I ran the game: blue screen of death, and after reseting the machine Ms. Windows decided not to load anymore because of an Access Violation blue screen at startup.

So, I reinstalled Ms. Windows again, installed the newest drivers again (61.xx?) and got the same result: a crash and access violation at startup.

At this point I didn't want to install Ms. Windows again so I restored the system and happily it got restored ok.

I installed the driver's version I was using when first I had the FPS slowdown problem, and automagically the game begun to run with acceptable FPS. Still slower than linux (even being a new fresh with nothing installed OS).

I wonder why my game won't run with the new Nvidia drivers for Ms. Windows. Maybe the SDL.dll I have is old? I'll try that later.

Resume: This first experience showed me that the worst part of porting your game from linux to windows is not to compile it, but to make your game run. And if you achieve to make it run, to make it run well.