I''ve been playing around with graphics on the framebuffer. Currently im simply mmap()''ing the framebuffer device and implementing my own double buffering using a malloc''d back buffer in system memory the same size as the used video memory. Problem is, framebuffer seems terribly slow. On my p3 950 w/ a GF2 Ultra running 1600x1200x16 with rivafb im getting about 10 fps with a test program I wrote, which simply fills the screen with a different color on each frame. I spent a day optimizing the hell out of it and this 10fps is the most im going to get out of this set up. I''ve also tried using the hardware panning ioctl and setting up the framebuffer to have a virtual y resolution twice that of the real y resolution - two give me two screens I can swap between using panning. Panning ended up being a bit slower than simply using a system memory back buffer and memcpy()''ing to the frambuffer, though it did look better when drawing the new frames (the memcpy() can be seen working its way down the screen). Anyone have any tricks or ideas that might help improve performance? I am not interested in 3rd party libraries. saai

Your wasting your time, use a third party library. DirectDraw does exactly what you are trying to do and is as optimized as it gets.

First off directdraw isn''t available on linux. You obviously havent noticed the fact that i posted in the unix forum.

Second, im asking for ideas and suggestions, not anonymous people telling me im wasting my time.

saai

Then get Windows and drop that unix crap ya kook.

That''s like saying "Go buy a used car for $50,000 and get rid of your free 2002 Porsche".

SHilbert, that is a very stupid statement. he is not using a new 2002 porchese which was gotten for free. its used as well and not any better then windows for gaming. linux is still not ready to be a desktop OS, artly because of ignorent morons like you that bash anything ms, and consider linux the best OS for everything.
AP, your being pretty ignorent as well.

Saai, technically it is via wine. but if emulation aint your thing, try sdl. its basically directdraw for linux. though copying data from sysmem to vram at that resolution NOTHING will speed it up except a faster bus. so you ARE wasting your time. instead lower the resolution. just becuase you have a geforce2 does not mean its fast at doing 2d pixel stuff. in fact its at the same level as nearly any agp card including the very old ati rage pro.

you will NOT get any decent framerate at 1600x1200 with your backbuffer copying the entire screen each frame. also reading from the framebuffer is exccedingly slow. dont do it, instead have the hardware to the work, use an api like sdl which will allow you to use hardware accelerated blits when dealing with vram to vram, at least making your double buffer work better.

look into dirty rects, this will help reduce the amount you need to draw to the screen each frame helping increase the framerate. again 1600x1200 is ridicously high to the point of absurdy for doing what yoru trying to do. reduce the resolution to 640x480 at the max (assuming you will continue to send all the data over the bus). 512x384 is even better if your drivers (since i am pretty sure it is hardware supported) supports it.

you could also consider opengl, but only if you understand that per pixel access will be slow, and you must do things in a tile based manner. view some of the tutorials on the net, many are written for windows, but you should EASILY be able to grasp the concepts since the opengl code is almost exactly the same on both OSes.

though since you are not interested in 3rd party libraries, you can ignore the sdl, and opengl suggestions. instead just lowere the resolution and try to reduce the amount of data you send across the bus NEVER reading from vram. if you wish to be foolish, that is your choice to make.

This is a hobby. I''m doing this because i want to see how the framebuffer does with graphics. I have no game or other project planned based on this work.

Hardware panning is similar to vram-vram blitting in the fact that I do have memory allocated for two ''screens'' in video memory, but rather than copying between them I am changing the range of memory the graphics card is using to make up the display. Which, supposedly, when done in hardware, is nothing more than changing some registers in the GPU. Yet from what I''ve seen its slower than using a system memory backbuffer.

I know about dirty rectangles and plan to take advantage of it, but for the moment I am drawing an entire screen. Drawing the entire screen is why things are as slow as they are, but the display refreshing is a major part of it, more of it than i think it should be. The buffering setup and such is what im interested in improving right now.

Yes, 1600x1200 is high, it is what I have set up and use on a daily basis and decided to do my testing with. I''ve tried lower resolutions and performance scales predictably.

saai

AP, this forum is not supposed to be for Windows, as it is clearly titled "Everything Unix." If you''d read the forum FAQ, you''d also see that OS bashing is strictly prohibited, and Oluseyi does not look very kindly on it.

rm -rf /bin/laden

just use Allegro, it works on many platforms!
check out http://www.allegro.cc i write my games with it, you can get way above 60 fps with it!

[edited by - yves032784 on May 20, 2002 9:22:59 PM]

I slip out of town for one weekend - to pick up my mother, no less - and all hell breaks loose. AP, watch it. a person, thanks, but I''ll do the moderation on this forum (tempers run high where UNIX and Windows meet).

Now, framebuffers. To actually achieve significant fb performance, you''ll want to patch your kernel with fb support. Anything else is really a waste of time. I remember playing some game using an fb-patched kernel about a year ago, and it had pretty decent support. Search the web, check out KernelTraffic.org, Freshmeat.net and LinuxGames.com (archives, if any are available). Also poke around at SourceForge.net and HappyPenguin.org. I might add, however, that if you''re merely interested in high performance graphics under Linux, OpenGL with DRI support is (currently) the way to go.