Is there a way to use OpenGL to draw offscreen? What I want to do is this: I want to be able to use functions like glVertex, and get the result in a 2D pixel array.
I am using Python. I tried using PyGame, but it's not working very well. The problem with PyGame is that uses a window event though i don't need it. In addition, I had to draw to scene + flip the screen twice in order to access screen pixels using glReadPixels.
An other problem is that I can't have more that one window at once.
Is there any proper way to accomplish what I am trying to do?
What you are asking for seems to be two things in one... you want an off-screen buffer (FBO) and you want to get the contents of the framebuffer in client memory.
Can you indicate which version of GL you are targeting?
If you are targeting OpenGL 3.0+, then you can use FBOs (Framebuffer Objects) and PBOs (Pixel Buffer Objects) to do this efficiently. However, since you are using glVertex, I do not think you need to bother with efficiency. I would focus on learning to use Framebuffer Objects for the time being.
If you are not using GL3 you might have access to the old EXT FBO extension, but if you do not have that even you might need a PBuffer.
Note that PBuffers and Pixel Buffer Objects are two different things even though they sound the same. Before GL3/FBOs, WGL, GLX, etc. had special platform-specific functionality called Pixel Buffers for drawing off-screen.
Related
I have written some code in Python which allows 3D objects to be defined in 3D object space and mapped onto a 2D screen. Currently the finished 2D polygons are drawn on the screen using the PyGame library, which works effectively, but I would like to go the full way and write code myself to complete the drawing operations PyGame does for me. This means I would like to manually control the drawing of each pixel on the screen, with the use of GPU support to accelerate the entire rendering process. From some reading it seems OpenGL is suitable for this sort of thing, but I'm not sure what the complete purpose of OpenGL is and whether I could achieve what I am trying to do in a better way. Do I really need to use OpenGL? Or is there another way for me to directly access my GPU to draw at the pixel by pixel level?
It sounds like OpenGL's programmable shaders are what you're looking for (in particular fragment shaders). They run massively parallel on a pixel-by-pixel basis, in the sense that basically you write a function that takes a single pixel location and computes its color. Note that this means that the individual pixels can't exchange information, though there are certain ways around that.
(Technically when I said "pixel" I meant "fragment", which is sort of a generalized version of a pixel.)
I'm making a lo-fi, low-resolution (1024x576) game and I was hoping I could get away with just doing supersampling (render the game at 2048x1152 then scale down) instead of proper anti-aliasing.
Trouble is, I don't see any way to render the OpenGL commands to a memory surface instead of the display surface. Is there a way?
Using https://www.pygame.org/docs/ref/surface.html#pygame.Surface.blit you can do image.blit(image2) and use any special flags you want with that
Do not forget: Display objects inherit from Surfaces. So you can blit the screen to another Surface and scale it down! Create a subprocess using the corresponding module, initialize Display with the dummy video driver (as seen in the headless_no_windows_needed.py Pygame example), send the Surface converted to a simple list using PixelArray, through IPC, recieve it in the main process, and blit it to a Display without OPENGL flag. You can also use FBOs.
So I've been making a game using Python, specifically the PyGame module. Everything has been going fairly well (except Python's speed, am I right :P), and I've got a nice list of accomplishments from this, but I just ran into a... speedbump. Maybe a mountain. I'm not to sure yet. The problem is:
How do I go about implementing a Camera with my current engine?
That probably means nothing to you, though, so let me explain what my current engine is doing: I have a spritesheet that I use for all images. The map is made up of a double array of Tile objects, which fills up the display (800 x 640). The map also contains references to all Entity's and Particles. So now I want to create a a camera, so that the map object can be Larger than the display. To do this I've devised that I'll need some kind of camera that follows the player (with the player at the center of the screen). I've seen this implemented before in games, and even read a few other similar posts, but I need to also know Will I have to restructure all game code to work this in? My first attempt was to make all object move on the screen when the player moves, but I feel that there is a better way to do this, as this screws up collision detection and such.
So, if anyone knows any good references to problems like this, or a way to fix it, I'm all ears... er.. eyes.
Thanks
You may find this link to be of interest.
In essence, what you need to do is to distinguish between the "actual" coordinates, and the "display" coordinates of each object.
What you would do is do the bulk of the work using the actual coordinates of each entity in your game. If it helps, imagine that you have a gigantic screen that can show everything at once, and calculate everything as normal. It might help if you also designed the camera to be an entity, so that you can update the position of your camera just like any other object.
Once everything is updated, you go to the camera object, and determine what tiles, objects, particles, etc. are visible within the window, and convert their actual, world coordinates to the pixel coordinates you need to display them correctly.
If this is done correctly, you can also do things like scale and otherwise modify the image your camera is displaying without affecting gameplay.
In essence, you want to have a very clear distinction between gameplay and physics logic/code, and your rendering/display code, so your game can do whatever it wants, and you can render it however you want, with minimal crossover between the two.
So the good news is, you probably don't need to change anything about how your game itself works. The bad news is, you'll probably have to go in and rewrite your rendering/drawing code so that everything is drawn relative to the camera, not to the world.
Since I can't have a look into your code, I can't assess how useful this answer will be for you.
My approach for side scroller, moveable maps, etc. is to blit all tiles onto a pygame.Surface spanning the dimensions of the whole level/map/ etc. or at least a big chunk of it. This way I have to blit only one surface per frame which is already prepared.
For collision detection I keep the x/y values (not the entire rect) of the tiles involved in a separate list. Updating is then mainly shifting numbers around and not surfaces anymore.
Feel free to ask for more details, if you deem it useful :)
I want to do convert array of integers into some sort of 'picture' using PyQt (I've decided to do my app in Qt). I have array like this:
Array = [
[0,0,1,0,0],
[0,1,0,1,0],
[1,0,0,0,1],
[0,1,0,1,0],
[0,0,1,0,0]]
Now I want to rewrite it into picture, by replacing each integer by for example square 10x10 pixels. I have definition for each value in array in RGB. What's more This is some kind of game of life, so it must refresh on each step and shouldn't be slow. Maybe somethinf similar to OpenCV?
Thanks in advance!
Cheers,
Mateusz
You could easily do the above with QGraphicsScene and QGraphicsView. In order to get good performance, you'll want to call setViewport(QGLWidget()) on your QGraphicsView instance. Create a subclass of QGraphicsItem to represent an element in your array. You'll then even be able to animate the changes if you want.
If you do want animations or are demonstrating some progression such as in Conway's Game of Life you might also want to take a look at QTimeLine.
You can look up the equivalent python-based documentation on either the PyQt* or PySide websites. Both PyQt and PySide use a nearly identical API so for most everything you can use them interchangeably.
*Note: The PyQt website is inaccessible at the time of this writing
You should probably use QT’s graphics libraries for performance. Another, maybe simpler way could be to use PIL (Python Imaging Library) or some Python bindings to the ImageMagick or MagickWand library (I haven't found a good and current one) and use NumPy’s arrays for calculations and manipulation, and draw on a surface or canvas using PyGame, QT or some other GUI toolkit.
In PIL there is PIL.Image.fromarray(np_array, 'RGBA'), that reads suitable NumPy arrays – the datatype must usually be dtype=int8 and the shape is (height, width, n_channels).
For a very simple graphics format that uses ascii byte values, see NetPBM.
So I'm going through the beginning stages of producing a game in Python, and I'm looking for a library that is able to manipulate pixels and blit them relatively fast.
My first thought was pygame, as it deals in pure 2D surfaces, but it only allows pixel access through pygame.get_at(), pygame.set_at() and pygame.get_buffer(), all of which lock the surface each time they're called, making them slow to use. I can also use the PixelArray and surfarray classes, but they are locked for the duration of their lifetimes, and the only way to blit them to a surface is to either copy the pixels to a new surface, or use surfarray.blit_array, which requires creating a subsurface of the screen and blitting it to that, if the array is smaller than the screen (if it's bigger I can just use a slice of the array, which is no problem).
I don't have much experience with PyOpenGL or Pyglet, but I'm wondering if there is a faster library for doing pixel manipulation in, or if there is a faster method, in Pygame, for doing pixel manupilation. I did some work with SDL and OpenGL in C, and I do like the idea of adding vertex/fragment shaders to my program.
My program will chiefly be dealing in loading images and writing/reading to/from surfaces.
Have you tried the Python Imaging Library? You'd still have to communicate the data back to pygame via frombuffer or somesuch to do the blitting, but the PIL can handle the pixel access.
I checked out pyglet, and saw that it works well for static per pixel collision, when the image is not manipulated too much; however, I'm not sure how well it works with a dynamic image.
In short, I'm looking for a library that's able to quickly display a buffer of pixels. This buffer will be constantly changing, so fast access and blitting is essential. This could be done in C with relative ease using SDL; however, I'm looking for a similar method in Python. I'm not even too worried about hardware acceleration at this point, although it would certainly be nice.
Check Python bindings of Simple and Fast Multimedia Library. From it's documentation:
It implements the same 2D drawing and OpenGL-related functions (see their base class sf::RenderTarget for more details), the difference is that the result is stored in an off-screen texture rather than being show in a window.
Rendering to a texture can be useful in a variety of situations:
precomputing a complex static texture (like a level's background from multiple tiles)
applying post-effects to the whole scene with shaders
creating a sprite from a 3D object rendered with OpenGL
etc.
Check also methods contains and intersects of sf::Rect< T > Class Template.