Jump to content
  • Advertisement

Archived

This topic is now archived and is closed to further replies.

Xeno

Pixel ploting with Lock() is slow for me :(

This topic is 6387 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

hi , first im using DX7 im trying to fill my screen with some color , and im trying to do it with pixel ploting with the DX7 Lock() and UnLock() , but for some reason its sooooooo slow and it wont even finish to fill the screen , any ideas what could make it to be very slow? coz by what i have heared , pixel ploting with Lock() should work very fast . thanks a lot

- Goblineye Entertainment

Share this post


Link to post
Share on other sites
Advertisement
Heya Xeno,

Locking and unlocking the surfaces is SsssLLLlllOOOoooWWwww. Avoid it whenever you can. As well as locking and ulocking being slow, it''s also crawling to copy from video memory to system memory (and the other way around.

If you''re going to plot a bunch of pixels, do one lock, plot all of your pixels, and then unlock. If you''re writing an interface to doing all of this, then include a Lock and Unlock call so the user/programmer can do this whenever they need to.

Hope that helps

---
Wait, you mean I have to actually... THINK?!

Share this post


Link to post
Share on other sites
hi random
well , its exactly what im doing , every frame im just calling one time to lock , ploting all the pixels i need , and then unlock , and its still slllllllllllllloooooooooooowwwwwwwwwwwwwww hehe , i dont understnad why


- Goblineye Entertainment

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
The pixel plotting functions are slow. You''ll need to find an alternative, or, if you NEED pixel plotting, use ASM to do it. Scaling down the resolution will also speed things up. If you''re running over 640x480, you''re running too high-res for this sort of thing, even if you do write it in ASM.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
I just reread your post. If you only want to fill it with a single color then just use BltColorFill. It''s fast.

Share this post


Link to post
Share on other sites
quote:
Original post by Anonymous Poster

The pixel plotting functions are slow. You''ll need to find an alternative, or, if you NEED pixel plotting, use ASM to do it. Scaling down the resolution will also speed things up. If you''re running over 640x480, you''re running too high-res for this sort of thing, even if you do write it in ASM.


HUH?!?!?!?
by what i know , what u are saying is just cant be , coz , so how the hell windows doing the pixel ploting so fast? and how DDraw doing it so fast?! , by what i know DDraw written in ASM.




- Goblineye Entertainment

Share this post


Link to post
Share on other sites
I did this recently...

Tips:

1. Do your run time RGB conversation at load (i.e. don''t do a RGB conversion for every pixel for every frame...)

2. Use ASM optimised routines... namely memcpy, memset, etc.

3. Don''t do it... using DDraw surfaces and Blt''ing allows for the use of HARDWARE! Thus reducing the load on the cpu




Regards,
Nekosion

Share this post


Link to post
Share on other sites
Nekosion:
first tnx

1. i have a question , did u got it to run fast? , i mean , did u get it to run smoothly every frame? without flicker or something....

2. i didnt understand what u meant in the #3 sentence....


- Goblineye Entertainment

Share this post


Link to post
Share on other sites
I managed to get it to run at about 75 fps (my monitor refresh rate). With the the DDFLIP_NOVSYNC, it got upto 125fps.

It can run quite fast, but generally it''s not fast enough. It all depends on what you want to do. That was basically writing every pixel once on a 800x600 screen, and then 8 more images that were about 200x150 in size on top (using a slower method).

2. If you use DDRAW surfaces, DDRAW automatically utilises the capabilities of the graphics card, taking the burden off of the CPU.



Regards,
Nekosion

Share this post


Link to post
Share on other sites

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!