custom graphics functions too slow

Started by
17 comments, last by keethrus 20 years, 11 months ago
hello, im looking to speed up my custom graphic functions. i know you can use hardware to speed up some generic graphic things like polygon drawing, but im just creating a 2D game and i still want to know how to speed up my gfx functions regardless. right now im using simple "for" loops to draw something to the screen, like so:
      
Sint32 *imgdata; // assume this already has image pixel data


Sint32 *screenptr // assume this already points to the screen


for ( Sint32 y = starty; y < imgheight; y++ )
{
	for ( Sint32 x = startx; x < imgwidth; x++ )
	{
		screenptr[ y * screenwidth + x ] = imgdata++;
	}
}
      
i know one optimization could be to take the "y * screenwidth + x" outside of the inner for loop, but even optimizations like that leave the program too slow. should i drop down to assembly language, use a memcpy? any suggestions? also, my functions to draw images alpha-blended to the background are even more slow. how can i make my custom graphics functions faster? - jeremiah inlovewithGod.com [edited by - keethrus on May 6, 2003 10:26:33 AM] [edited by - keethrus on May 6, 2003 10:28:17 AM]
Advertisement
Here's a suggestion:


    Sint32* imgptr;Sint32* screenptrfor (Sint32 y = 0; y < imgheight; y++ ){  memcpy(screenptr, imgptr, imgwidth);  screenptr += screenwidth;  imgdata += imgwidth;}  


This will copy the whole image, without clipping. You might want to add some clipping code to adjust the starting pointers and the width/height of the image, because blitting functions are liable to mess up memory when you give them nonsense-parameters, or even blit half-outside of the screen.

[edited by - marijnh on May 6, 2003 11:54:35 AM]
Or use hardware acceleration

--------------------------------

"I''m a half time coder, full time Britney Spears addict"
Targhan
--------------------------------"I'm a half time coder, full time Britney Spears addict" Targhan
Yah, i forgot that, using openGL or directX will beat your own routines for speed most of the time, and these days you can do all kinds of fancy things with them so you do not really need your own blitting routine.
Of course, i think it is a good thing to do something all by yourself once before switching to a library, so you know what is going on behind the scenes.

Marijn
quote:Original post by marijnh
Of course, i think it is a good thing to do something all by yourself once before switching to a library, so you know what is going on behind the scenes.


Well, I certainly wouldn''t want discourage you from playing with software blitting etc., but behind the scenes of mainstream modern graphics (as in D3D/OpenGL polygon rendering) there isn''t much that resembles moving pixels in neat little rectangles. And the market for GBA developers is, ahem, overcrowded, to put it mildly.

Life''s too short to live yourself through the entire 20-30 years of computer graphics development (the ontogenesis/philogenesis thing). For a behind the scenes point of view, I''d suggest AT LEAST something like the Quake1 sources.

thanx for the replies. i understand that nowadays games are hardly 2D anymore. however, the game im developing is a top-down 2D game, where the focus isnt 3D graphics. i know i could still use hardware to make my graphics faster, 2D or not, but im still curious as to how to speed up my own custom graphics functions, even if its soley for learning purposes.

memcpy can help, but not if you want to do anything with an alpha channel. the only way i can think of speeding up my graphics routines is to drop down to assembly level. handling an alpha channel on a per-pixel basis in higher-level C/C++ just isnt going to cut it. i may indeed end up using opengl for graphics routines and directx to handle hardware acceleration, but for now im simply curious as to ways to speed my custom graphics functions up.

any more suggestions?

- jeremiah

inlovewithGod.com
Well, you can download the trial version of Intel's C++ compiler and play with its vectorization capabilities - it should be able to generate reasonable SIMD (MMX/SSE/SSE2) alpha blending code if you write the C loops just right.

And, by the way, when you start implementing the alphablending stuff, don't listen to the "code optimization" tutorials from the 386 days - e.g. avoid table lookups like hell. Nowadays you can do many multiplies for the price of one (out-of-cache) memory access.

Basically, look for "x86 code optimization" on Google. There is a good site by somebody called Paul Hsieh, I think it was something like azillionmonkeys.com

[edited by - assen on May 6, 2003 1:49:00 PM]
A few suggestions:

As already mentioned by marijnh: Instead of ( y * width), keep a y pointer, and just +=width to it after each scan line.

If you want to clip your copies:
figure out how long each horizontal ''span'' is, and using the above y+=width method, do one memcpy per horizontal span.

ie: memcpy (img.dst+dst, img.src+yOff+startX, endX-startX * bytesPerPixel);

This should be a bit faster.

Define your main image buffer as a global variable. Copy it to the screen/BM when you are ready.

If you are using the Windows GDI you''ll have to remember that it is quite slow to draw to the screen. Even if your code is lightning fast, you''re screen updates wont be.

I''m not sure why you need a speed boost though. Is your app sluggish, or are you just curious? I''ve done tons of graphics using windows (BitBlt with my own bitmap classes) and I''ve never had a speed issue that wasn''t easily accounted for.

As far as learning 2D (and 3D) from scratch: GO FOR IT. It''s worth the effort.

Good luck,
Will
------------------http://www.nentari.com
quote:quote from RPGeezus
I''m not sure why you need a speed boost though. Is your app sluggish, or are you just curious? I''ve done tons of graphics using windows (BitBlt with my own bitmap classes) and I''ve never had a speed issue that wasn''t easily accounted for.


well, in my current implementation (im programming with SDL in fullscreen) my fps is lower than i expect: 50 fps with a fullscreen single-color rectangle and a couple other images on the screen.

quote:quote from RPGeezus
As far as learning 2D (and 3D) from scratch: GO FOR IT. It''s worth the effort.


thanx for the encouragement!

- jeremiah

inlovewithGod.com
For the fastest software rendering you will need assembly. MMX can speed up most color operations by a factor of four or more. I can also advice to use DirectDraw or another library that gives you direct access to the frame buffer.

And it''s definitely true that learning things from scratch is worth it. My last project is a real-time Pixel Shader 2.0 emulator using soft-wiring technology: swShader.

This topic is closed to new replies.

Advertisement