• Advertisement

Racky1275

Member
  • Content count

    81
  • Joined

  • Last visited

Community Reputation

122 Neutral

About Racky1275

  • Rank
    Member
  1. UpdateSurface or another method

    Have you tried rendering the on-screen letters as individual sprites? It worked on those crazy old 8 bit machines... 7.14MHz FTW!
  2. [XNA] Mipmap generation oversampling

    Hi MJP. No worries, as a world class pedant myself I simply feel a warm glow when I see such things pointed out. [oh] In the spirit of not pre-optimising this project into obsolenence, I'm going to make a note of it and move swiftly on. Box filtering will be fine. [smile]
  3. [XNA] Mipmap generation oversampling

    Thanks sirob, unfortunately the app will never know which assets it'll need before it runs... Its got to cope with any image you care to throw at it at runtime. I'm in two minds as to whether this should be reported as an XNA bug... On the one hand I understand what the issue is. So can work round it. On the other... when you render with texture clamping on you don't expect to see this top/bottom left/right texture contamination.
  4. Having trouble with XNA 3.0's automatic generation of mipmaps... It appears that you can't control the texture addressing mode whilst the mipmap chain is created. During rendering I set the texture addressing mode to Clamp, otherwise my non-wrapping textures produce oversampling artifacts on their edges. Unfortuately these texture artifacts are still showing up at certain scalings, as they exist in the mipmap chain. My current workaround is to simply use Box filter during texture creation, as its sampling algorithm by default doesn't seen to oversample. Rendering can then use better filtering. I'd like to use something 'better' than the Box filter though, as for me quality is more important than speed. Any ideas?
  5. If waiting for a fix is an issue (and it usually is) then I'd suggest you look at Gefen's DVI Detective. It's basically a dongle connected to a DVI port which make it seem as if a monitor is attached. You capture display EDID information by briefly attaching the monitor to be emulated, after that no power is require. I use them to prevent projector disconnections from making XP disable the screen.
  6. It's beginning to look like these OOP techniques aren't quite as useful as I had imagined... which is a pity really. An awful lot of my code depends on strict heirarchical structures, making inheritance seem like it truely is a panacea! Using DI to short-cut pathways from the top to the bottom of my code tree seems messy, but I'll bow to your collective experience and follow the pattern... Thanks for the help guys. [smile]
  7. Ah yes, you see how new to this I am! I read it as a cWheel is-part-of a cCar. In my world: I never want to create a wheel in isolation. A wheel is holding more specialised information about the car. A wheel intrinsically knows which car it is connected to, by inheritance. There are multiple wheels! A collection of wheels would still need to know which car they are individually connected to. Now I just sound like a raving lunatic... Great.
  8. Thanks again Zdlr, but as you say, that's basically DI. If I had a cCar class, and a cWheel class based on cCar, then cWheel could inherit the properties of cCar automatically. I could create as many cWheels as I like, but if I want to store them in a collection my inheritance is broken. I then have to start using DI to explicitly allow access to properties. DI definately short circuits the problem, and like you say it's definately a valid technique, but there must be another way... Sorry to be such a pain!
  9. Thanks Zdlr, I'm definately not questioning the wisdom of using DI, but this is more of a conceptual issue now... [headshake] If your code describes a heirachical structure, then surely C# will allow you to use inheritance from top to bottom. It might not be particulary sensible in this case, but unless I can figure out how it's done then the whole concept of objects inheriting properties from parents is fairly broken. Are we saying it is not possible with C#???
  10. Thanks for the help guys. You're right, passing a structure would be a great practical solution, but isn't there a more OOPy way of solving this problem. Maybe deriving a new type of Dictionary? The 'reasoning' behind my obsession is that my actual engine uses a lot more layers, and you end up passing the structure quite a few times. This seemed inefficient when the code itself neatly defines a heirarchical structure, with things like dxDevice always at the top. My graphics engine currently works, so this is more a theoretical exercise to help improve my OOP theory really. Solving the scope issue is part 1, finding a more generic way of adding cBox, cCircle, etc. was part 2. (thinking .Add(type, params...) (I went overboard with my public's in the sample, but in practice would probably convert most of them to Protected's.)
  11. Ok, I'm new to oop in general (still regard 68K Asm as my favorite language) and have got myself a little stuck... [rolleyes] I'm trying to implement a dictionary collection of graphic objects. Only cBox is implemented in this sample, the use of an abstract class makes it very easy to add cCircle, cSprite, etc. The Draw() method makes a call to the parent GraphicsDevice, but of course, it is out of scope. I realise it's the Dictionary limiting the scope of inheritance, but I don't know how to fix it. I've previously tried passing dxDevice as a parameter to the methods, but the code soon got messy. Unfortuneatly there's a few other things that are used globally, they're just not implemented in my sample. Any OOP gurus out there? [cool] class cSceneManager { private Dictionary<string, cSceneObject> dictObjects = new Dictionary<string, cSceneObject>(); public GraphicsDevice dxDevice; public cSceneManager(GraphicsDevice device) { dxDevice = device; } public void Draw(string strSceneName) { foreach (cSceneObject SceneObject in dictObjects.Values) { SceneObject.Draw(); } } public void AddBox(string name, int width, int height) { dictObjects.Add(new cBox(name, width, height); } } abstract class cSceneObject { public string strName; public abstract void Draw(); } class cBox : cSceneObject { public int intWidth; public int intHeight; public cBox(string name, int width, int height) { strName = name; intWidth = width; intHeight = height; } public override void Draw() { dXdevice.DrawBox(intWidth, intHeight); // Out of scope! } } [Edited by - Racky1275 on November 10, 2008 3:57:33 AM]
  12. Looks like profiling the application is your next step... I think you'll find some tutorials on this site that should help.
  13. Hope you don't mind if I clarify this thread slightly... Actually you don't need to use the CPU to copy texture data to the graphics card. As already suggested, the UpdateSurface command lets you copy data from system memory to texture memory. If your driver supports it (and most will) the hardware will use DMA to transfer the memory across the bus for you. The main memory will take a hit, but the processor isn't involved in the process. If driver support isn't available the system will preform a lock/copy/unlock instead, without the benefit of DMA. Hope that helps!
  14. Major performance problem on Vista

    Thought I'd run some numbers through my test rigs, including my personal VT5 system! XP sp3 + Intel D945GCZ + Pentium D 830 @ 3.0 + Nvidia 7800GTX = ~900Mb/s XP sp3 + P5B Deluxe + 6600 @ 2.4 + ATI 1950XTX = ~800Mb/s Vista + P5B Deluxe + Q6600 @ 3.2 + Nvidia 8800GTX = ~800Mb/s The Vista performance wasn't particularly affected by turning DWM's desktop composition on or off. CPU load during the tests was in the region of 60% on all machines... which seemed high to me. Maybe the memory transfer is not being conducted via DMA?
  15. Have you looked at this: Nvidia Stereo API [smile]
  • Advertisement