64x64 limit problem

Ok, I’ve uploaded the VBO (vertex buffer object) version of the demo. Run the tiledemo3.cmd to see it in action. I had to change the demo structure a little to overcome some odd timing problems…

Well, anyways the tiledemo3 shows an FPS counter in the caption of the window instead of a printout in the console.

This demo requires the GL_ARB_vertex_buffer_object extension to work.

I’m experiencing 800-900 FPS with grid size of 40x40 and 1 tile modification per frame. With 100x100 grid the FPS drops to around 500 or 600. Basically this method of drawing/modifying the grid should be the ultimate one, although the code is optimized for clarity :).

This has been a fun experiment, since I’m trying to learn some more advanced OpenGL too. Hope it works for you.

Cheers

[quote]Hmmm, it seems that the vertex arrays are really ineffective on your board. That’s no surprise really, because the arrays are transferred to the GPU from Java heap each time they are drawn. I’m actually working on a VBO version of the demo (this is the last one, I promise ), which should perform quite nicely on board with VBO capabilities. I’ll post it here later on today…
[/quote]
I would say the drivers are broken. If it can’t even do vertex arrays, then it won’t do VBOs either. Try changing the drivers, or better yet, buy another gfx card :wink:

There are still things you can do to improve performance using immediate mode.

  1. Do you need textures? If the rectangles are single colored, then you can use vertex colors instead. Or generate a texture that is uploaded once per frame and drawn with one quad that covers the screen.
  2. Use Triangle strips or quad strips.
  3. Generate one big texture that contains one of the sprites tiled across it. The texture is drawn first using one quad covering the screen. Then you draw sprite nr 2 where it is needed. Basicly swapping gl calls for overdraw.

Thanks for that info.

You were right … the VBO extension isin’t available.

I’m a bit confused … I am using Red Hat Linux 7.2 and a Matrox G450 which the documentation sais does have OpenGL support, however my installastion is about 3 years old. Do you think it would just be a question of downloading the latest Matrox G450 drivers for Linux or does it mean that my physical card would never support VBOs under Linux?

Thanks

Sally

Hi,
For sure your G450 will never support VBO’s and don’t even try to search new drivers, this card is really dead now! (In fact it was already 2 years ago, when we try to get support from Matrox…) :-/

Thanks for that info. It’s best to know these things in advance.

Just to compond my misery :frowning: I just tired to run the tiles demo on a friend’s machine (Red Hat Linux 8 os) which uses an Nvidia geforce 4 card. The frame came up but I received the following (none of it makes much sense to me). So presumably the Nvidia geforce 4 is not very compliant either ???

Any clues ???

Regards,

Sal

java.awt.AWTException: cannot open XIM
at sun.awt.motif.X11InputMethod.(X11InputMethod.java:147)
at sun.awt.motif.X11InputMethodDescriptor.createInputMethod(X11InputMethodDescriptor.java:76)
at sun.awt.im.InputContext.getInputMethodInstance(InputContext.java:734)
at sun.awt.im.InputContext.getInputMethod(InputContext.java:684)
at sun.awt.im.InputContext.dispatchEvent(InputContext.java:210)
at sun.awt.im.InputMethodContext.dispatchEvent(InputMethodContext.java:180)
at java.awt.Component.dispatchEventImpl(Component.java:3476)
at java.awt.Container.dispatchEventImpl(Container.java:1437)
at java.awt.Window.dispatchEventImpl(Window.java:1566)
at java.awt.Component.dispatchEvent(Component.java:3367)
at java.awt.EventQueue.dispatchEvent(EventQueue.java:445)
at java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.java:190)
at java.awt.EventDispatchThread.pumpEventsForHierarchy

"
XIM (= X Input Method) is a generic API to build applictions which have support for international input.

All applications which have support for the XIM-protocol build in, can be used to input Japanese, Chinese and Korean.

Many X11 applications already support XIM, for example:

most KDE 2 and most Gnome applications
Browsers like Mozilla, Netscape, Konqueror
Editors like Emacs, XEmacs, gvim
terminals like mlterm, kterm, and rxvt
Java applications
"

Interesting. :slight_smile: I wonder why the error did not comp up when I ran the JOGLBasics demo though (from the “Jumping into JOGL” page) on the Geforce 4 card. Why would it only be Vertex Arrays that cause the error and only on this machine? To say: “I’m confused” would be the biggest understatement of the decade ;D

Either way … it seems I cannot use either my Matrox G450 card or my friend’s Nvidia Geforce 4 card to have any success with my application.

I think I’ll try using Motif :stuck_out_tongue:

Thank you to everybody who has taken the trouble to reply though. :slight_smile:

Regards,

Sally

That’s a foolish thing to say - especially since there are drivers on the Matrox.com website dated 2004 (windows only) and 2003 (linux).

EDIT: (snipped some irrevelvant bits above) + here’s the URL for downloading matrox G450 drivers:

http://www.matrox.com/mga/support/drivers/latest/home.cfm

I’d rather use images or textures but hey … when you’re desperate I’ll make do with rectangular colors if I have to :smiley: I have actually tried solving the problem with vertex rectangles before and they gave about the same speed as gldrawpixels (too slow).

[quote]Or generate a texture that is uploaded once per frame and drawn with one quad that covers the screen.
[/quote]
If I understand you correctly - there would need to be several million combinations of screen texture depending on where the 2 tiles are within the grid so this couldn’t be an option.

[quote]2) Use Triangle strips or quad strips.
[/quote]
Don’t know much about these … do you think these would give me more speed than drawing vertex rectangles???

Not sure how I’d go about implementing it but I’d like to give it a try before I give up completely. Does anybody know where I could find an example of how to implement a system like this?

Many thanks for your reply,

Sally

Well, for spending hours with the matrox technical support and hearing them said that their new drivers(wich are generic ones) may improve something with G550 but decrease perfs with G450 ( 200 of which my compagny was about to buy…) I thought this wonderful card was dying.
But i there are new drivers that make it run like a rabbit it is certainly worth trying them!

[quote]'d rather use images or textures but hey … when you’re desperate I’ll make do with rectangular colors if I have to I have actually tried solving the problem with vertex rectangles before and they gave about the same speed as gldrawpixels (too slow).
[/quote]
Using vertex colors instead of textures will reduce the number of gl calls. Since you only need to transmit it once per quad, or less if it don’t change. Won’t give you a huge improvement.

[quote]Quote:
Or generate a texture that is uploaded once per frame and drawn with one quad that covers the screen.

If I understand you correctly - there would need to be several million combinations of screen texture depending on where the 2 tiles are within the grid so this couldn’t be an option.
[/quote]
Sorry, I wasn’t clear. I was thinking that the texture is an image of the grid, where one pixel represents one tile. It’s got the same limitation as using vertex colors, the tiles can only have a single color. You generate this texture in software and transmit a new one every frame. This will only be a 128x128 texture so it won’t be to slow. Then you scale it up to fit the screen using a textured quad. On a related note, how fast is it to draw a single image with the size of the screen using using glDrawPixels?

[quote]Quote:
2) Use Triangle strips or quad strips.

Don’t know much about these … do you think these would give me more speed than drawing vertex rectangles
[/quote]
It would be slightly faster because of less gl calls. See “OpenGL Geometric Drawing Primitives” in the Red Book.

In the end I think you’ll have to be creative to find a method that will be fast enough.