Jump to content
  • Advertisement


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


Yet Another PixelPlot Question

This topic is 5913 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

Pixelplotting = argh! I''m currently doing this with SDL but I think it counts for everything: In fullscreen you have to lock the surface before you can place individual pixels directly into video memoru, right? And then as long as the screen is locked, you see the result immediatly without having to do a special update command and such? And in a window, you DON''T have to lock it, isn''t it? But then you have to run a slow update command before you can finally see the pixels you placed. So in fact you would almost be able to think that... in fullscreen it''s possible to draw individual pixels and see the result immediatly, while in window you must update the surface all the time before you can see changes. And that is of course no problem for graphical intros that fill the whole window every frame, but on the other hand for a starfield demo it''s annoying! So how should I do a fast starfield demo in a window without updating the screen all the time?

Share this post

Link to post
Share on other sites
first off you must always lock and unlock. being that sdl uses directdraw on windows platform not locking/unlocking reults in bad code and problems.

technically you shouldnt access the primary buffer in window mode since your app does not have direct control over the screen. however you can access it if you wish just like in fullscreen mode. you just cant switch the mode and have to plot in the screen depth the desktop is set to. thus you have to at least handle 16bit and 32bit desktops. this is true even when you draw to the backbuffer.

you can do a fast starfield in a double buffered enviroment easily. just:
1. lock() back buffer
2. draw the entire starfield
3. unlock() back buffer
4. blit back to front

this is EXACTLY how things would be done in fullscreen mode excetp you would use flip instead of blit. also dont use windows that are larger then 640x480 otherwise you have fillrate problems. most common mistake of newbies is to think that direct pixel access somehow allows super fast updates f the screen as if you were using 3d hardware. its not the case.

if you truly want to write to the primary buffer, by all means go ahead. however you have to actually use directdraw instead of the sdl wrapper.

also NEVER read from vram. its quite slow.

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!