ET3D

Members
  • Content count

    1572
  • Joined

  • Last visited

Community Reputation

810 Good

About ET3D

  • Rank
    Contributor
  1. Thanks for posting this. I needed to get an application with FTGL running in release, and removing global optimisation was the simplest way to do it. Not a long term solution, but if not for you saying this works I would still be trying freetype recompilations and other stuff, instead of moving on.
  2. [quote name='thePyro_13' timestamp='1301661116' post='4793012'] Scratch is a pretty interesting tool. It looks like it could make a very wide range of game types. [/quote] Thanks. This looks promising. I sent her the link. And thanks for the other suggestions, guys.
  3. My sister would like a tool to help her create games for her daughter, for example a memory game with her own images. I know there are some simple tools like Kodu, but they seem to be aimed at action games. Does anyone know of a tool which might fit her needs? Thanks.
  4. This error means you've specified more vertices in the draw call than are available in the buffer. I didn't find the draw call in your code, so couldn't check it (doesn't mean the call isn't there, it's just that there are too many snippets of abstracted code to comfortably go over).
  5. One off-the-cuff guess is that your layout and the vertex structure don't match, and you end up using the normal (all 0) as texture coords.
  6. The X format was never very good for advanced stuff. It did support animations, but the docs for that weren't very good, and the sample didn't help make it any clearer. Plus it was buggy. Couple that with limited support for exporters, and it wasn't that much fun to use. Some people did get it to work, but I don't think it was ever a great way to go.
  7. Use 'lerp' in the pixel shader to interpolate between the texture and the background colour of your choice. You can do this in the fixed function pipeline too, using D3DTOP_LERP.
  8. I don't see anything wrong offhand, but you might want to capture a frame using PIX and take a look at what happens with that call.
  9. Renderframe, order?

    It would be faster to go through the materials. But if your initial goal is to reduce memory waste, try to get that working as simply as you can first. I don't think you'll need to change anything in your rendering code to do that.
  10. You say that your code doesn't render anything, which suggests that neither of the draw calls draws. So reduce the code to just one draw call, which will be easier to debug. Does the code with two vertex buffers render something? If so, reduce it also to that same call, and compare the differences in the code.
  11. Your mistake is probably when you're using it, not when you're clearing it. To check if it has the right values you can use GetRenderTargetData and lock and check the memory copy (or save it to disk as a TGA using D3DXSaveTextureToFile and check it in GIMP or whatever).
  12. Transparency is controlled by the alpha channel, which is independent of the colour. When creating the texture it's possible to have the function change the alpha of a specific colour to zero (transparent), but you can do it yourself either by adding an alpha channel in an image editor or locking the texture and changing the alpha yourself.
  13. 1500 fps to 200 fps is a small change. It's less than 5ms overhead per frame. Considering that VirtualBox implements D3D on top of OpenGL using WineD3D you should expect some overhead, in addition to running in a VM which has an overhead by itself. In your code, if secsPerCnt is some value based on QueryPerformanceFrequency then I think it should work. You can check if the frame rate affects your code on the native PC by forcibly reducing frame rate (using Sleep for example).
  14. There's no direct way to do that. You can do it using rendering, with some restrictions and shader programming. Perhpas if you tell us what you're using it for we could come up with a good way to do that.
  15. I suspect that Havok will be faster, simply based on where it's coming from. PhysX is from NVIDIA, a GPU vendor. Havok is from Intel, a CPU vendor. Problem is you have to pay for Havok if you want to use it commercially. Don't know if that's a problem for you. You might also want to try Bullet. Don't know how it performs currently against the rest, but it has OpenCL support under development, which will work on GPU's from NVIDIA and AMD, as well as on CPU's (taking advantage of multi-core).