A) You shouldn''t EVER try to write pixels directly to rendered scenes (say by locking the front buffer) if you want anything like decent performance. Doing so stalls and serialises the whole pipeline so you essentially throw away all hardware acceleration - not good!

B) For cursors check out IDirect3DDevice8::SetCursorProperties and similar!

C) Try to do as much as you can using textures mapped onto polygons. You should be able to do an awful lot that way. In fact I can''t think of many reasons to need to plot pixels directly these days. Definately not for HUD/interface graphics or cursors/target dots!

D) If you really must, then make a dynamic texture, lock that, plot what you need to that and apply it to polygons in the scene. Even better is to make say 3 dynamic textures and triple buffer them so that the one you have locked isn''t the one the graphics hardware is trying to render from.





--
Simon O''Connor
Creative Asylum Ltd
www.creative-asylum.com

quote:Original post by Anonymous Poster
tru, tru agreed but it seems that texture sizes are VERY limited in hardware acceleration (don''t cards these days support 256x256 pixel textures normally ? )

Caps for GeForce2:

MaxTextureWidth = 2048
MaxTextureHeight = 2048

(GF256 had the same IIRC, TNT1 had half, most do 1024x1024)

From 1x1 to 2048x2048 doesn''t seem too limited to me

IIRC the last commonly available card which had a 256x256 restriction was the Voodoo2!!

quote:while a larger thing i think im gonna retrieve a pointer to the backbuffer surface and CopyRect straight from a picture surface to the backbuffer surface. i''m not really going to be displaying giant pictures much, im just tryin to make a background picture covering the screen for my main menu, nothing like it will be displayed in-game. all primitives in-game

That shouldn''t be too bad for the menus, however IMO it is still better to use textures for that:

- If the chip only supports 256x256 textures, then CopyRects to multiple 256x256 textures. i.e. split the large image up at load time and apply those maps to polygons. That''s essentially what I did in the Pac-Man:Adventures In Time engine for backdrop screens.

- Having polygons for your backgrounds makes doing fades, cross fades, wipes, rotations etc *very* easy - e.g. change vertex colour and/or alpha values to fade!

- If the chip supports larger textures and non-square textures, your load time image splitter can make even better use of textures. A 640x480 screen for example can be done with one 512x512 texture and one 256x256 texture or two 128x256 textures.

- If the player changes the resolution of the game, then your method of copying the pixels manually will also need to scale. With textures the scaling is automatic and you get filtering if they go to a resolution higher than your artwork is authored at.

I''ve used both methods in commercially games - the manual pixel plot method in a DirectDraw based game and image split into textures for a Direct3D based game (which also had to run on very low spec hardware). I''d *ALWAYS* go for textures applied to polygons for backdrops unless there was a very good reason not to!.



--
Simon O''Connor
Creative Asylum Ltd
www.creative-asylum.com

quote:Original post by wannabe H4x0r
btw, is the directX->showcursor different from the windows showcursor() ? im thinkin im supposed to turn off the windows showcursor and turn on the directx showcursor to get a smooth lookin mouse (im also using directinput btw).

Nope, different thing (sort of - see below).

Because MS removed the ability to lock the front buffer (because that screws up all sorts of stuff from antialiasing to parallelism), they expected to have people moaning "but I want lock access to the front buffer so I can render my cursor" - so they introduced hardware accelerated cursors (or more correctly access to the hardware accelerated cursors already available).

The only reason people started locking the front buffer to render cursors in the first place is because some older graphics chips (*cough* Voodoo *cough*) couldn''t reliably cope with rendering GDI features on top of 3d output.

There are limitations on what you can do with the cursors. In that case, once again, two textured polygons in screen space with alpha test and no Z test rendered just before you do your EndScene() or with Z test and Z write rendered just after BeginScene() saves the day - and lets you do funky things with the cursor too.

3x500

--
Simon O''Connor
Creative Asylum Ltd
www.creative-asylum.com