Fast Pixels

Blackstream · 2000-11-06T16:20:35

I feel like such a newbie for asking this (and that is probably because I am), but I am having problems drawing pixels fast. First off, I have a Pentium 166mhz with 32MB RAM and a video card that doesn''t want to accelerate anything, even though it is a Riva Viper v550 16MB. That may have something to do with it, but I think there is more to it than that. Right now, I have an inline pixel drawing function basically filling up the screen to an offscreen surface. The resolution of the surface is 800x600x8bpp, and I get about 18 frames/sec just filling up the surface. I heard something about register variables and using DDLOCK_WRITEONLY, and I''ll try out some more stuff while I wait for your guy''s answer. What''s that? I didn''t ask the question. Doh. My question is, can you store the pitch of a surface and count on it staying the same for that surface as long as the surface and the resolution don''t change? If I can, I could probably make a table of pitch*y values for that surface... Yes, I know a table of pitch*y values would be way taxing on memory if I had a lot of surfaces and a table for each one. Your guys thoughts would be nice. I have a sneaky feeling that my comp is a big cause of my pain, though. -Blackstream

Graphics and GPU Programming Programming

Started by Blackstream November 02, 2000 09:21 PM

13 comments, last by Blackstream 23 years, 5 months ago

neocron

122

November 03, 2000 02:26 PM

Here''s some code that may speed up your application (this assumes you have MMX on your CPU)

    void DrawMMX( DDSURFACEDESC *dest, BYTE *src, RECT &area, int bpp ){	int w=(area.right-area.left)*bpp/8;	int h=area.bottom-area.top;	char *sptr=(char*)src;	char *dptr=(char*)(unsigned char*)((unsigned char*)dest->lpSurface);	DWORD adddpos=dest->lPitch-w*8;	DWORD addspos=bpp*(area.right-area.left)-w*8;	__asm	{		mov edx,h		mov esi,sptr		mov edi,dptr		NextLine:		mov ecx,w		NextPixels:		movq mm0,[esi]		movq [edi],mm0		add esi,8		add edi,8		dec ecx		jnz NextPixels		add edi,adddpos		add esi,addspos		dec edx		jnz NextLine		emms	}}////// EXAMPLE of use:////		if ( g_bMMX_Enabled )		{			DDSURFACEDESC	ddsd;			ddsd.dwSize = sizeof(ddsd);			if ( DD_OK != g_pDDSPrimary->Lock(NULL, &ddsd, DDLOCK_WAIT, NULL))			{				return FALSE;			}			RECT rc={0,0,CSDScreen::GetWidth(), CSDScreen::GetHeight()};			DrawMMX( &ddsd, CSDScreen::GetDib()->GetBits(), rc, 3 );			g_pDDSPrimary->Unlock( NULL );		}

Graham Reeds

122

November 03, 2000 05:04 PM

For your information, Doom and Doom2 used ModeX.

Also the speed increase from 640x400x8 to 320x200x8 is due the fact you are filling 4 times less pixels (45x4 = 180fps - overhead for copying = 160fps).

Nice trick Neocron - got any more of that?

Stay Lucky, Graham "Mournblade" Reeds.
http://homepage.dtn.ntl.com/grahamr

Stay Lucky, Graham "Mournblade" Reeds.The Ivory Tower

BASSOFeeSH

122

November 03, 2000 05:20 PM

I thought that Doom and DoomII were not really true 3D. Didn''t it use a type of ray casting engine? Maybe I am just confusing myself!

"If at first you DO succeed...try not to look astonished!!"

BASSOFeeSH@aol.com
><>

-- What would Sweetness do?

laeuchli

338

November 04, 2000 08:37 AM

you are right, DOOM and DOOM2 are not real 3d games.....

furby100

102

November 06, 2000 04:20 PM

They were not true 3D as such, no, as in the walls were in fact lines. It used BSP based on lines, rather than based on planes like Quake, which is true 3D. However, the Display was 3D, even though the levels and monsters weren''t.

Please state the nature of the debugging emergency.

sharewaregames.20m.com

Fast Pixels

This topic is closed to new replies.

Popular Topics

Recommended Tutorials

Fast Pixels

This topic is closed to new replies.

Popular Topics

Recommended Tutorials

Reticulating splines