Yet Another PixelPlot Question
Author
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?
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.
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.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
