When i run PIX it shows me in the viewport window where my pimitives are drawed on the "screen".
In a d3d9 proxy dll i call the DrawIndexPrimitive regular:
DrawIndexedPrimitive(PrimitiveType,BaseVertexIndex,MinVertexIndex,NumVertices,startIndex,primCount)
How can i access after this the "Viewport" points of my primitives?
The simple answer to your question is
It is not possible to recover vert information from a GPU once it has been sent to the GPU. The GPU loads the verts and buffers into it's super fast GDDR memory, which cannot be accessed by the CPU. There is one DX function to retrieve a render buffer back into normal memory (but that is slow), and really the GPU just wants to send a render target to the screen.
Looking at the starcraft blog...
http://graphics.stanford.edu/~mdfisher/GameAIs.html
That is why the blogger, created a mirror driver that would capture the DX calls as they went to the GPU, so he knew what was sent to the GPU, and could keep it in normal memory.
Then as he describes in the section titled 'Vertex Shader Simulation' he explains how gets duplicate CPU versions of the GPU shaders (noting they will run MUCH MUCH slower on the CPU). He then runs emulates the work already done by the GPU vert programs, on the CPU, so he can have the verts in viewport space is normal memory. I presume he only runs the vert shaders, and not the tessellation or pixel shaders, because in your question you were only asking for verts.
Maybe this website can help you a bit.
There he wrote a great DirectX Interception DLL.
Matt's Webcorner
Related
I'm making maps for my game. I designed forest for map by using many tree, stone.. Images (insert image into unity scene and arrange it). My game runs well on Android but can not run on iOS (ip4s). It met memory problem. I want to ask everyone:
If i design the forest in photoshop instead of unity, is that way better than my current way?
Thanks all
It depends on what you are trying to do.
But anyway, there is a common way to solve memory usage related problems. Fire up the Profiler!
http://docs.unity3d.com/Manual/Profiler.html
There you can see what is eating your precious memory. So you can try and decide if it's best to make them combined in one image or keep them as separate images. Maybe you would also see the memory problem could be related to other assets you use.
You need to look at Instruments in XCode. Also you can use the Profiler that comes with Unity. Another way you can save memory is by reducing the graphics strain on the screen. You need to see your draw calls and verts, and tris under stats. Keep draw calls under 50-60. And keep verts and tris down. Look at the graphics benchmarks for Graphics on OpenGL, iPhone 4S is an older device and depending on your android may be substantially slower. iPhone 4S has 512MB of RAM I think. This should be enough to handle a pretty big memory load. Check out your OnGUI() objects and calls. You want to mitigate those as much as possible. Also try and use culling to your advantage! Also if you are using Fog or camera filters they take a substantial load as well too. Stay away from Literal Types, too if you can.
Also use Vertex Lit for rendering path vs forward rendering path. Use auto best performance for resolution, too. This will make everything go at 0.75 resolution instead of full retina 960x640 or whatever it is for 4S. You can also in Xcode tweak the resolution, depending on the size of your controls you could make it 0.6
under DeviceSettings.mm in your XCode Project:
case deviceiPhone4S: resMult = 0.6f; break;
or in your MonoDevelop UnityScript (depending on orientation):
Screen.SetResolution (Screen.width * 0.6f, Screen.height * 0.6f, true);
I've made a small png (100x30) and added it as a texture in Unity. I've also added it to a script so I can poll it, but if I print out its width and height it now states its 128x32. What happened?
I've tried to adjust the camera, but it does not seems to have anything to do with it. Any clue?
Generally textures are scaled to a power of 2 on both sides for performance reasons.
For example multiplication and division are faster if the GPU can assume that you are working with POT textures. Even mipmaps generation process relies on that because division by 2 never produces a remainder.
Old GPU (I don't know exactly but probably even several mobile GPU these days) requires strictly POT textures.
Unity by default will try to scale the texture to a power of 2. You can disable or tweak that setting switching texture import settings to "Advanced".
For more details checkout the doc.
Note that generally you want NPOT textures only for GUI, where you need to control exactly the resolution on screen and mipmap aren't used. For everything in the 3D scene power of 2 performs better.
I want to to run several shaders one after the other (mostly image processing), the output of one being the input of the following. I wonder if there's a performance gain to use only one FBO bound to all the needed textures, or if it's the same to create one FBO for each texture?
In case it matters, the aimed platform is the iPhone, therefore with OpenGL ES 2.0.
Thanks
I am not familiar with OpenGL ES, but on PC platform it is normally better to use only one FBO, and i don't see why this should be different on ES (however, I might be wrong). It is important though that all textures bound have the same size (e.g. viewport size) for FBO completeness, otherwise it won't work.
Normally, you attach all textures to one FBO initially and then in each frame just change the rendertarget channel in each pass. This saves you a lot of state changes caused by fbo binding.
Note that the maximum number of textures that can be bound is limited by GL_MAX_COLOR_ATTACHMENTS_EXT.
You might also find this helpful: http://www.songho.ca/opengl/gl_fbo.html
Cheers,
Reinhold
I am writing a 2d game on the android and I am targeting phones with that have a minimum OpenGl ES 1.1 support.
I am currently looking at creating my animated sprite class which is basically a quad that has a changing texture on it to provide animation.
I wanted to stick to Opengl 1.1 so am avoiding shaders and was wondering how other people have approached the implementation of animated sprites.
My thoughts initially were to either:
Have a single vertex buffer object with one texture coordinate set, then use lots of pre loaded textures that would be swapped at runtime in the correct order.
Have just one texture sprite sheet and modify texture coordinates at runtime to display the coorect subsection of the sprite sheet.
Is there a more clever or more efficient way to do this without shaders?
Thanks
Choose #2 if you have only the two options.
However, I recommend making and caching all of quad vertex set for each sprite frames into vertex buffer on memory closest to GPU. Or just generate new sprite quad vertex and specify them for each drawing. This is trade off problem between performance vs memory by caching. Think about memory consumption vertices for single frame.
Changing GPU internal state is a lot expensive operation. Of course, including texture object swapping. Avoid this as much as possible.
This is the reason huge texture atlas are used on traditional game development.
Transferring resources (including vertices) to VRAM (closest memory to GPU) may be expensive because they need to be copied over slower bus. This is similar with server-client situation. GPU+VRAM is server, CPU+RAM is client connected through PCI-bus network. However this can be vary by system structure and memory/bus model.
I'm trying to determine if OpenGL ES 1.1 (Or 2.0, if there is a difference) will attempt to render anything that would fall outside of the viewable area.
Does it do a check to ensure that the actual rendering is needed before computing everything, or not? And if it does, where does this step occur? I haven't found much information on this subject at all.
Should I, while programming check to see whether an image should/will fall in (or very close to being in) the viewable area and only draw it if it is? Or will this be entirely redundant as OpenGL handles portions of this for me?
Or are there even OpenGL states that can be set to change the behavior here?
Thanks!
It can't render anything outside of the framebuffer (assuming you have set the viewable area to the same size) as there is nothing to draw into. That counts for both, OpenGL ES 1.1 and 2.0.
However, you still push your data to the GPU and the data will be clipped, so you still waste time by letting your CPU waiting for the bus and the ok from the GPU. Better clip your stuff before you push the data to the GPU via OpenGL ES