Direct Pixel Access
I''m thinking about making a game very simmilar to the old qbasic gorilla game (two players, one on each side of the screen, with a hilly terrain underneath. in turns, one player picks a velocity and an angle and it fires a projectile toward the other player using the selected numbers), except I want to do mine in windows and add lots of fancy options (the game ''pocket tanks'' is more where I want mine to go).
The basic graphics operations I need are the ability to draw a bitmap rotated at any angle, alpha blended sprites, and direct pixel access to ''deform'' the terrain (projectiles explode and make holes in the terrain, and any unsupported dirt falls downward until it is supported).
I''m trying to figure out which API I should use and how to get the direct pixel acces easily. With direct draw, I wouldn''t have hardware acceleration for alpha sprites. With opengl, I can''t just make the terrain a texture because textures have to be a power of 2 and the target screen resolution(800x600) is not a power of 2 in either direction. With windows GDI, I don''t know how to rotate sprites (other than manually) and I don''t know how to do alpha blending.
Any suggestions on API and method to get a full-screen terrain to which I can have direct access {to run whatever algorithms I need on a per-pixel basis to drop down dirt, remove it from the game, etc}?
GDI+ is pretty simple and can be used with a lot of things. (Comes with the .NET framework).. I don''t know exactly which functions that are included though, but you can use transparent sprites if you like to.
Still, OpenGL (or D3D) is the fastest API, since you can use hardware functions. Also, spriteroation and true alpha blending is very easy and fast to do.
However, about direct pixelaccess, I don''t really know, but there has to be some way to access pixels directly even in OpenGL
Still, OpenGL (or D3D) is the fastest API, since you can use hardware functions. Also, spriteroation and true alpha blending is very easy and fast to do.
However, about direct pixelaccess, I don''t really know, but there has to be some way to access pixels directly even in OpenGL
Ok, well I''ve got the 2D terrain rendering up and running, but for some reason it is extremely slow. I''m testing it on a pentium 4 using the onboard i810 graphics card, which I know is not a great card but I know it can do this kind of thing because another game already does it and it runs fine on this machine. I store an array that is 800*600 to store state information about the terrain, and I convert it to RGBA information in 800*25 chunks. I tried converting the whole thing at once to an 800*600 but it didn''t increase speed at all. Right now, it takes approximately 750ms per frame using glDrawPixels.
Does anybody have any ideas on a way to speed it up? I need to have pixel access to the terrain and really I''ll need more info than just color (and I can easily convert from the byte array to color, so imo its better to store the bytes), plus its 800*600 and not a power of two, so I can''t just use an opengl texture. I''ll also need to redraw the terrain from the byte array every frame (or at least almost every frame - whenever I need to redraw it though it will need to be redrawn for several successive frames because it will constatly change for a short time{few seconds})
Does anybody have any ideas on a way to speed it up? I need to have pixel access to the terrain and really I''ll need more info than just color (and I can easily convert from the byte array to color, so imo its better to store the bytes), plus its 800*600 and not a power of two, so I can''t just use an opengl texture. I''ll also need to redraw the terrain from the byte array every frame (or at least almost every frame - whenever I need to redraw it though it will need to be redrawn for several successive frames because it will constatly change for a short time{few seconds})
I think this should be everybody''s first game! It can teach physics, trig, graphics, game engine design, particle sysem etc. etc. Then progress to 3D and you''ve done it all! (almost)
Anyway - if you are rendering a screen that is 800x600 pixel by pixel, yes it will be slow if you do not have direct access to the frame buffer.
If you are using Windows, you have a choice of using OpenGL, DirectX, GDI or GDI+. Using GDI is probably the easiest but DirectX will lead to a more natural progression of learning game based technologies.
When using DirectX - you can lock a screen surface and get direct access to the memory that contains the pixels for the screen.
Once you have this it will still be slower to render the screen pixel by pixel instead of using polygons or tiles or whatever - include a bit more information about how you want your terrain to look and peeps here can give you more help.
Anyway - if you are rendering a screen that is 800x600 pixel by pixel, yes it will be slow if you do not have direct access to the frame buffer.
If you are using Windows, you have a choice of using OpenGL, DirectX, GDI or GDI+. Using GDI is probably the easiest but DirectX will lead to a more natural progression of learning game based technologies.
When using DirectX - you can lock a screen surface and get direct access to the memory that contains the pixels for the screen.
Once you have this it will still be slower to render the screen pixel by pixel instead of using polygons or tiles or whatever - include a bit more information about how you want your terrain to look and peeps here can give you more help.
I know that in my NES emulator, I have to render the scene pixel by pixel. I use directdraw, render an offscreen surface, and when I''m finished with rendering, I just flip the surface. Its just a matter of writing each pixel separately to the offscreen surface, which is done by simply using a pointer to the surface. I don''t know if this is what you are looking for, but if you think it might be, ask for more information.
Regards,
Mike
Regards,
Mike
Well, rather than directly accessing the frame buffer (which I'm not sure is possible in OGL, maybe via an extension), I use glDrawPixels which copies from a buffer to the screen (though it may go through some translation since the screen can be using 32, 24, or 16 bit color and the buffer I write to will always be 32 bit color because it has to have an alpha). I'd really rather not use direct draw because (last I checked anyways) it doesn't support hardware accelerated alpha blending. Also, I don't think GDI supports drawing rotated bitmaps (or at least, I don't know of any function to do so) which is why I chose OpenGL. It doesn't need to be fast really, but it has to have at least ~20 FPS.
I'm not really doing this as a learning exorcise because I already know enough to make the game (in theory anyways, and I have made tons of little 'tech demos' and a few small games, though obviously I haven't done much with directly manipulating the pixels in windows), but more to improve upon a game I've been playing in my downtime(you know those 10-15 free minutes you get every once in a while?) recently. I really like the game, but its pretty boring to play agains the computer and multiplayer is on the same PC only. I want to recreate the game, add some features, and add net play so I can play with my friends. Maybe even sell it as shareware - if blitwise can why shouldn't I =-)
You can see 3 screenshots of how the terrrain needs to look on the page for Pocket Tank Homepage. If you ever played the QBasic game 'Gorillas', it is very simmilar except that dirt falls when it has room to do so (and mine will have different kinds of 'dirt' with different hardnesses if I can get enough speedup to get my current method working).
[edited by - Extrarius on July 10, 2003 2:21:42 PM]
I'm not really doing this as a learning exorcise because I already know enough to make the game (in theory anyways, and I have made tons of little 'tech demos' and a few small games, though obviously I haven't done much with directly manipulating the pixels in windows), but more to improve upon a game I've been playing in my downtime(you know those 10-15 free minutes you get every once in a while?) recently. I really like the game, but its pretty boring to play agains the computer and multiplayer is on the same PC only. I want to recreate the game, add some features, and add net play so I can play with my friends. Maybe even sell it as shareware - if blitwise can why shouldn't I =-)
You can see 3 screenshots of how the terrrain needs to look on the page for Pocket Tank Homepage. If you ever played the QBasic game 'Gorillas', it is very simmilar except that dirt falls when it has room to do so (and mine will have different kinds of 'dirt' with different hardnesses if I can get enough speedup to get my current method working).
[edited by - Extrarius on July 10, 2003 2:21:42 PM]
Programming for the Gameboy Advance is cool!
.lick
[edited by - Pipo DeClown on July 10, 2003 1:56:09 PM]
.lick
[edited by - Pipo DeClown on July 10, 2003 1:56:09 PM]
quote:Original post by Pipo DeClownPerhaps, but how is that in any way related to the contents of this thread?
Programming for the Gameboy Advance is cool![...]
I tried the program at home, and on my radeon 8500 it takes approximately 31ms per frame, which is a very long time for something so simple as just drawing an 800*600 screen. I guess I''ll go post in the OpenGL board since this is more openGL stuff I''m asking now
"You are my friends if you do what I command you."
[edited by - Big Brother on January 1, 1984 12:00:00 AM]
Have you actually profiled the code to see where the bottleneck is? I mean, without knowing how you are drawing whatever you are drawing, it''s pretty hard to say what could be improved.
I''m sure OpenGL''s blt isn''t that slow so there must be something in the way you are filling your buffer that is slowing things down.
Try profiling it or posting it to get some help in optimising it.
I''m sure OpenGL''s blt isn''t that slow so there must be something in the way you are filling your buffer that is slowing things down.
Try profiling it or posting it to get some help in optimising it.
Know of any ok free profilers that work with .Net? I''ve tried a few but it seems like they can''t read the debug info generated by VC.Net or something because they wouldn''t give any info about time spent in each function or anything like that (tho they did slow the execution speed down to slower than a crawl).
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement