I'm currently taking a course on polygonal 3D rendering from scratch. We write our own line drawing and clipping algorithms that are eventually used to draw polygons in 3D space using code for perspective transformations that we write ourself. The assumption of the course is that we write to 2D arrays that represent the window, viewport, or display device. In the first week of the course we wrote code to write out these 2D arrays as bitmap files so we could view the output.
Now I want to see the output of my software renderer in real-time and interact with it. What is the fastest way to draw a 2D bitmap array to the screen, in Mac OSX 10.9 for example? Linux? Windows?
I'm specifically looking for speed here, as the only thing that I want the GPU to do is draw the 2D array that I just rendered in main memory at runtime.
Without the initialization step it should be OpenGL rendering of the bitmap on screen aligned quad(What's the best way to draw a fullscreen quad in OpenGL 3.2?) Only costly operation will be uploading the bitmap but it's unavoidable anyway.
Related
Plotting packages offer a variety of methods for displaying data. Write an interactive plotting application for two dimensionsional curves. Your application should be able to allow the user to choose the mode (line strip or polyline display of the data, bar chart or pie charts), colours, and line styles.
You should start with the GUI editation like this:
Does anyone know of a low level (no frameworks) example of a drag & drop, re-order-able list?
and change it to your primitives (more points per primitive instead of one ... handle each point as (sub)object so you can change its position later).
Then just add tools like add object,del object,... For hand drawing tool use piece wise interpolation cubics
The grid can be done like this:
How to draw dynamic 2D grid that adjusts according to camera zoom: OpenGL
Mouse zooming/panning is also important
Zooming graphics based on current mouse position
Putting all above together into simple editor looks like this:
Using GPU for curve rendering might give you some nice speed and functionality boost:
Is it possible to express "t" variable from Cubic Bezier Curve equation?
Mouse selection of objects might be a speed problem if your scene contains too many objects so in such case its best to use index buffers where you can mouse select with pixel perfect precision for almost free in O(1):
OpenGL 3D-raypicking with high poly meshes
The example is for 3D , in 2D is much simpler ...
Also do not forget to implement save/load functionality to some vector file format. I recommend using SVG it might be complicated to start with it but you can quickly check it contents in any SVG viewer or browser also in notepad as its just a text file. If you use just basic path elements and ignore the rest of SVG features you will see the parsing and creating SVG is not that hard for example See these:
Get Vertices/Edges From BMP or SVG (C#)
Discrete probability distribution plot with given values
For really big datasets you might want to use spatial subdivision techniques (Bounding (Volume)Area Hierarchy, or Quad tree) to ease up the operations...
More in depth implementation details about 2D vector gfx editors depends on language, OS, gfx api and GUI api you using and task you are aiming for ...
I'm trying to learn SDL2. The main difference (as I can see) between the old SDL and SDL2 is that old SDL had window represented by it's surface, all pictures were surfaces and all image operations and blits were surface to surface. In SDL2 we have surfaces and textures. If I got it right, surfaces are in RAM, and textures are in graphics memory. Is that right?
My goal is to make object-oriented wrapper for SDL2 because I had a similar thing for SDL. I want to have class window and class picture (has private texture and surface). Window will have it's contents represented by an instance of the picture class, and all blits will be picture to picture object blits. How to organize these picture operations:
Pixel manipulation should be on surface level?
If I want to copy part of one picture to another without rendering it, it should be on surface level?
Should I blit surface to texture only when I want to render it on the screen?
Is it better to render it all to one surface and then render it to the window texture or to render each picture to the window texture separately?
Generally, when should I use surface and when should I use texture?
Thank you for your time and all help and suggestions are welcome :)
First I need to clarify some misconceptions: The texture based rendering does not work as the old surface rendering did. While you can use SDL_Surfaces as source or destination, SDL_Textures are meant to be used as source for rendering and the complimentary SDL_Renderer is used as destination. Generally you will have to choose between the old rendering framework that is done entirely on CPU and the new one that goes for GPU, but mixing is possible.
So for you questions:
Textures do not provide direct access to pixels, so it is better to do on surfaces.
Depends. It does not hurt to copy on textures if it is not very often and you want to render it accelerated later.
When talking about textures you will always render to SDL_Renderer, and is always better to pre-load surfaces on textures.
As I explained in first paragraph, there is no window texture. You can either use entirely surface based rendering or entirely texture based rendering. If you really need both (if you want to have direct pixel access and accelerated rendering) is better do as you said: blit everything to one surface and then upload to a texture.
Lastly you should use textures whenever you can. The surface use is a exception, use it when you either have to use intensive pixel manipulation or have to deal with legacy code.
I'm total new in graphics and DX, encountered a problem and no one around me know graphics too. Sorry if the question seems too naive.
I use DirectX 11 to render a mesh, and I want to get a buffer for each pixel. This buffer should store a linked-list (or some other structure) of all triangles that contribute color to this pixel.
Should I operate on which shader or which part of DX? Or simply, where could I get the triangle information in pixel shader?
You can write the triangle ID in the pixel shader but using the hardware z-buffer you can only capture one triangle per pixel.
With multisampled textures you can capture more triangles. This should be enough in practical situations.
If your triangles are extremely small and many of them are visible within one pixel then you should consider the A-Buffer with your own hidden surface removal algorithm.
If you need it only for debug purposes you can use any of graphics debuggers:
Visual Studio Graphics Debugger (integrated since Visual Studio 2012)
For AMD GPUs: GPUPerfStudio
For NVidia GPUs: Nsight
Good old PIX from DX SDK.
If you need it at runtime (BTW, why? =) )
Use System-Generated Values: VertexID, PrimitiveID and SV_VertexID to calculate exact primitive or even vertex, that contributed in pixel color. It is tricky, but possible.
Another way is to use some kind of custom triangle ID in vertex declaration. But be aware of culling.
You can output final data from pixel shader into buffer, then read from it on CPU.
All of such problems are pretty advanced topics in DirectX. I'm not sure if "total new in graphics and DX" coder can solve it.
I am working on a simple 3d software renderer but one thing I'm no sure about is how to actually draw it all on the screen. What could I use to draw a wireframed cube ?
I am not asking HOW to write a complete 3D pipeline just the final step, the actual drawing on the screen.
Edit: I think I could do that with SDL.
You need to project the 3D object onto the 2D screen using a perspective transformation matrix.
This will generate a set of 2D lines etc. which get drawn in the same way as "normal" 2D lines get drawn.
However, without more information about the language and/or framework you are using, it's not easy to go into any more detail.
For the "actual drawing on screen" in Windows XP of your software-rendered wireframe 3D, call StretchDIBits with a pointer to the array of bytes that represents your pixels. This answer addresses maximum convenience; maximum efficiency is another matter.
I'm trying to set base to a 2D game with destructible terrain and/or particle effects, scroll, zoom, characters, etc... I'd like to know if there is a graphics library that would support those things in both software and hardware acceleration (need pixel access). I've tried SDL (even with DirectX back-end), but it seems hardware does its job only in full screen. I'd appreciate any suggestion.
Use OpenGL. Perhaps via another library e.g. SDL. I do not know why you can't get windowed HW acceleration working, it might be a platform thing (but it's certainly a different question).
Set the projection matrix to orthographic and use one of the axis (typically z) to organise 'stacking' elements. With an appropriate transformation in the display subroutine, you can align the x/y coordinates with "traditional" drawing (i.e., top-left down, rather than bottom-left up).
Build your graphical elements into bitmaps, convert them into textures and draw them on top of OpenGL Rects.