• Content count

  • Joined

  • Last visited

Community Reputation

122 Neutral

About JohnSKX

  • Rank
  1. Copyright and Chapter 11

    Thanks for the infos.
  2. Suppose that a ‘company’ published a game long ago and now exercise chapter 11, does it mean the copyright of the materials such as image and sound are not longer valid? That is, do I get into trouble if I use images or sounds from a game of that company? Thanks
  3. Complex Weapon Systems

    The way I see it, RPG will always be experience balanced rather than progressive because that’s what the player expect when they see RPG. They don’t expect the requirement of ‘god given talent’ to handle a sword well to play the game well. Also monitors can project a 3D but ‘non-depth’ images so close fighting is very hard to do in progressive way. Unless you start to implement with those 3D glasses to give image depth distance. This is why I think all those games which started as sword fighting ended up as a shooter when they decide to stay on a progressive balanced game (example, Savage.) Now it does not really matter how and where you place the stats numbers, all computations comes down to offensive and defensive scaling. So you might as well just simplify the location of the stats. I think if you want an RPG merging with progressive game play, you need to give a new genre and define a new expectation. Maybe an FPF( First person fighter).
  4. Alpha blending

    Quote:Original post by mrmrcoleman Hello. I have just had a thought, does it matter that I am not rendering to any particular surface? Is this required for blending? I was under the impression that I could just BeginScene(), draw all my primitives, end scene and then present. Does this mean the blending in the frame buffer? Do I need a specific render target surface? As long as you don't change the target surface, the target surface is the backbuffer( frame buffer ). Quote: Are the blend operations taken into account on the frame buffer? If you see what I mean, will textures that are drawn to the frame buffer be properly blended with the images in the frame or do I have to render to another surface to achieve the blending and then send the other surface to the frame buffer? Yes. You can think of 'alpha blending' as just 'blending' by using the formula below Frame Buffer <= SRCBLEND × X (OP) DESTBLEND × Y You can think of ... SRCBLEND as the color pixel of the texture. DESTBLEND as the color pixel of the Frame Buffer. X and Y can be set to any of the D3DBLEND_??? It just happens that by using ... SRCBLEND x _SRCALPHA (+) DESTBLEND x _INVSRCALPHA ... you can archive ‘transparency effect’. So, alpha blending naturally must take into the account of the frame buffer (DEST). Quote: As you may be able to tell I am ever so slightly confused.. Would it help if I posted all the relevant code with a bit of an explanation as to what is what? Namethatnobodyelsetook, I will check the surface desc and get back. Just a thought, thanks for all the help guys. Mark Coleman Also, to get transparency effect, you need SOURCE alpha (alpha from texture) and not the alpha from the frame buffer (destination). Trace the formula and you will see why. It is a mathematical illusion and not really 'transparency' as color keying. Btw, the frame buffer (the backbuffer) can not have alpha channel. Even if you create the backbuffer with A8R8G8B8, it reset to X8R8G8B8. The document indicates that you can have alpha if the SwapEffect is 'COPY' rather than FLIP/DISCARD. That is, Direct3D creates an 2nd frame buffer as A8R8G8B8 and after a Present, it copies into the real X8R8G8B8 frame buffer. (Although I never tried it.)
  5. Why Alpha Test is so slow?

    Wow, the pipeline reorganizes itself! OMG! No wonder I kept getting result on my test runs with combination of alpha and depth test and kept getting result that does not made any logic sense compare to the conceptual view of the pipeline. All your details information explained all my many sleepless night confusions. Thanks for the GOLD MINE information. I love you man!
  6. Why Alpha Test is so slow?

    Quote:Original post by CrazedGenius you will only get performance improvements when you make changes to the bottleneck. For instance, if your vertex processing is the bottleneck, changes to pixel processing won't buy you anything. The problem is that the rendering engine I'm working on is more overdrawn intensive than vertices count. It’s kind of those 2D rendering issues. What annoys me is that I keep reading about articles indicating that discarding pixels that doesn't make any different via alpha test will improve performance. The testing texture's alpha 0 to non-0 is a difference of 90%+ in pixel discarding yet not improvement was seen. As I don't have any other video card, I'm trying to find out if this is the expected result.
  7. Annoying rendering problem

    It might be nothing but your vertices is at z=10. Are you sure that it is within the view range ? check your Projection matrix. "up" is -ve in DirectX btw. Quote:Original post by nickwinters I feel really bad posting tons of code. The problem is I don't know where to start looking for it. It's going through all the code, without giving me an error. All values are hard coded. The only part I can think of is where I declare the Vertex Buffer and Index Buffer. That's all in Triangle.cpp. I've created them here: void Triangle::create(IDirect3DDevice9 *device) { device->CreateVertexBuffer( 3 * sizeof(NVertex), D3DUSAGE_WRITEONLY, NVertex::FVF, D3DPOOL_MANAGED, &VB, 0); device->CreateIndexBuffer( 3 * sizeof(WORD), D3DUSAGE_WRITEONLY, D3DFMT_INDEX16, D3DPOOL_MANAGED, &IB, 0); // define unique vertices: NVertex* vertices; VB->Lock(0, 0, (void**)&vertices, 0); vertices[0].x=1.0f; vertices[0].y=1.0f; vertices[0].z=10.0f; vertices[0].nx=0.0f; vertices[0].ny=0.0f; vertices[0].nz=-1.0f; vertices[0].dwColor=D3DCOLOR_XRGB(255, 255, 255); vertices[1].x=-1.0f; vertices[1].y=-1.0f; vertices[1].z=10.0f; vertices[1].nx=0.0f; vertices[1].ny=0.0f; vertices[1].nz=-1.0f; vertices[1].dwColor=D3DCOLOR_XRGB(255, 255, 255); vertices[2].x=-1.0f; vertices[2].y=1.0f; vertices[2].z=10.0f; vertices[2].nx=0.0f; vertices[2].ny=0.0f; vertices[2].nz=-1.0f; vertices[2].dwColor=D3DCOLOR_XRGB(255, 255, 255); VB->Unlock(); WORD* indices = 0; IB->Lock(0, 0, (void**)&indices, 0); indices[0] = 0; indices[1] = 1; indices[2] = 2; IB->Unlock(); } And rendered them here: void Triangle::render(IDirect3DDevice9 *device) { device->SetStreamSource(0, VB, 0, sizeof(NVertex)); device->SetIndices(IB); device->SetFVF(NVertex::FVF); device->DrawIndexedPrimitive(D3DPT_TRIANGLELIST, 0, 0, 8, 0, 12); } All it's supposed to do is draw one triangle.
  8. Have you guys encounter the problem with alpha test where turning it on and off actually make not difference? I tested on a 256x256 texture. All alpha 0 except one single horizontal line (1 pixel height) across the texture rendering it many times. When I turned it on, only one line was shown as expected but the performance was not improved in any way. It was the same as when it was turned off. Is this normal? Thanks