Jump to content
Search In
  • More options...
Find results that contain...
Find results in...

Brent Taylor

  • Content Count

  • Joined

  • Last visited

Everything posted by Brent Taylor

  1. Of course I'm not. Nor was I ever doing so to begin with. I was talking about DirectDraw which has been stated ENDLESSLY throughout this thread. Does anyone else see the problem here? He's arguing about a system in DirectX that is completely irrelevant to the conversation. He insults me, mocks me or otherwise baits me in every post he makes. I have documented proof FROM THE SDK, and I'm the fool. I'm the one he constantly insults. I've insulted him ONE time, after watching him start in on rick in another thread. I love coming here, but this is not worth the frustration. Am
  2. ... You are aware that DirectDraw and Direct3D are two completely different things, right? At least as far as DirectX 7 is concerned. He walks into a conversation about DirectDraw, starts arguing about Direct3D without letting anyone know, and I'm the one on a tangent. I'm the foolish one here. Keep throwing the insults.
  3. ... Wait wait wait. All this time you insult me, and you're taking a post that was in the context of a DirectDraw conversation and applying it to mean DirectX 7 as a whole? Are you serious? All those childish remarks from you. All the insults. And you take something from one context and supplant it into another? Are you kidding me? Of course Direct3D doesn't have a GDI fallback renderer! I have never said such and I never will. You took what I said COMPLETELY out of context.
  4. That isn't what I said. I said that GDI is a fallback for DirectDraw, not DirectX. In fact I've never indicated otherwise at any point. The HEL (Hardware Emulation Layer) emulates most if not all features of a video card in software (Windows' software drawing API is GDI). You've just admitted that DirectDraw drops the the HEL if a proper video card isn't found.
  5. I did. It's pretty clear. It drops to the HEL for any feature the HAL can't support. I'm not sure what else we're supposed to get out of that man.
  6. Considering the rapid posting in this thread, I think you probably just missed the post. You can find it: Here And I'll repost it here for convenience: And for information on the HEL (Hardware Emulation Layer) (found on the Software Emulation page): Still a little vague and doesn't mention GDI. This chart however is relatively clear (found on the System Integration page): So there you have it. If a proper video card is not found, it did in fact drop down to GDI for rendering.
  7. I stand corrected! This is the 2k XDDM driver. My mistake entirely. However the DirectX 7 documentation does pretty clearly indicate GDI as a backend. That said, I see no reason that GDI couldn't use DirectDraw as a backend if a proper video card is found. Though that much is just guesswork on my part. It wouldn't surprise me if there is a mention of this in Windows Internals somewhere. In addition, that's the 2k XDDM driver. DirectX 7 ran on Windows 95, 98 and 2k. It's very possible it's a 2k specific change.
  8. I would conclude that DirectDraw under DirectX 8 and higher do not have a GDI backend. Then again, you already know for a fact that I said this before this whole argument. Afterall, in the initial post that you replied to that started this whole argument I had already said this. However, as the DirectX 7 documentation has proven, it did in fact drop down to GDI if a suitable video card was not found. Must we go on? EDIT: As indicated a few posts down from here, that is documentation for Win2k's XDDM driver so Dx7 is potentially used. This however is not the case for Win95 and Wi
  9. The problem with a lot of info on DirectDraw is that most of it pertains to DirectDraw under DirectX 8 and higher. With the release of DirectX 8, DirectDraw was completely rewritten to run on top of Direct3D. In addition, a lot of other systems ended up being written to take advantage of DirectDraw under XP with the release of DirectX 9 (which is what your snippet is refering to I believe). The whole argument was about DirectDraw before the rewrite.
  10. Woohoo! Found the DX 7 documentation. Anyone interested can find it here: http://dl.dropbox.co...ads/dx7docs.exe Here's a few choice bits from the DirectX 7 documentation on the subject. It first hints at software emulation here (found on the Architectural Overview for DirectDraw): And for information on the HEL (Hardware Emulation Layer) (found on the Software Emulation page): Still a little vague and doesn't mention GDI. This chart however is relatively clear (found on the System Integration page): So there you have it. If a proper video card is not found, it did
  11. Keep in mind, this would make a lot of games fairly unplayable. In an FPS, one second is enough time to circle around a player and shoot him from behind. If all clients are potentially one second behind you're going to have very frustrated players.
  12. I haven't actually taken the time to actually time any of this so excuse what may be ignorance on my part. We send data pretty quick these days, especially when sending via localhost. Is it possible you're just sending too little information to actually measure a time difference? It's possible the queue is just empty before the next bit of data is loaded and sent along to the queue. In addition, how are you timing this exactly? Post code if you could.
  13. So there is no logic to GDI being used as a fallback renderer? Keeping in mind it's the only thing I've been arguing about. And you haven't shown any proof otherwise. Uh, great. With the exception of not being able to find the proof (seeing as the DX7 documentation is nowhere to be found), I'd say I fit that definition just fine. In either case, rather than explain why I'm being illogical you seem bound and determined to simply belittle me. Until proven that I'm wrong, I see no real reason to stop. Why would I? Peer pressure? That wouldn't be logical. I'm sure that'
  14. I'd be greatful for a link to the old DirectX 7 documentation. I've found several links to it on the MSDN, all of which are dead. And I have no issue with being proven wrong in those instances. However, I find it interesting that you portray this as a common event. This is why I think you're still upset about the events from our previous argument. I'm certainly wrong on ocassion (it's healthy), it's not often however. It's very rare that I'll argue a point without some sort of documentation to back me up. And that "conclusion" would have much more validity as an authority o
  15. On the off chance that I just wasn't clear, let me rewrite part of my last post. "Unfortunately this is a hard thing for me to argue as the documentation for DirectInput (DX7 and below) is pretty much non existant at this point." Red, I understand you're still clearly upset about our little argument from the other day. However, do not attempt to belittle me at every opportunity. That would simply be childish. I take no issue with being proven wrong, when it actually occurs. It's happened a number of times on these forums and I tend to be fairly graceful about it and I'm better f
  16. Unfortunately this is a hard thing to argue as the documentation for DirectInput (DX7 and below) is pretty much non existant at this point. With the release of DirectX 8 DirectDraw was rewritten to run on top of (or as part of, as the details are a bit sketchy) Direct3D. Keep in mind that the post you linked is back from 2003. DirectX 9 was released in 2002. The poster you quote is certainly correct, but we're talking about a feature that was depricated in years prior.
  17. Err, I don't see an error in what I've said. DirectDraw was a wrapper for GDI. If a proper video card wasn't found it'd default to GDI for rendering. Simple as that.
  18. Specifically in regaurds to making all your class functions virtual: This is a bad idea. Unless you're intending the highest derived implementation of a function to ALWAYS be executed, you don't need to mark it as virtual. Virtual destructors however are a damned good idea. Indeed. In addition, always use initialization lists.
  19. Ok, I'm partly mistaken here. DirectDraw (as in for DirectX 7, not higher) uses GDI by default unless a supported video card is found. At the time it was written as a completely seperate library (at a time where the 3DFX Voodoo cards were the most common around, most of which didn't support DirectX). Later versions of DirectX rewrote DirectDraw as a wrapper around Direct3D. The latest SDK doesn't include DirectDraw at all. Also, trust me, use DirectX over GDI. DirectX really isn't so bad. It's pretty normal as far as most API's go. (GDI is far worse in regaurds to what you complain
  20. SDL under windows uses DirectDraw for all of it's rendering by default. To give you an idea of how this works: SDL is a wraper for DirectDraw and DirectDraw is a wrapper for GDI. It's pretty horrible. Meta is unfortunately right in this case, SDL_net does rely on SDL. Under windows that does include a dependancy on DirectX being installed. *EDIT: Just to be clear, he's right strictly about the DirectX dependency. The rest of it is all standard Lumooja nonsense.
  21. @Josh I'm gonna stay out of this in terms of "what engine is better", etc. Until we see a final product, it's all guesswork at best from our end. As we've seen before, we disagree on a few things. Even so, I think we both agree that there is a lot of potential for Leadwerks in the future. I wish you the best of luck. @Metatron As mentioned, I'm not getting into the "which engine is better" debate. I will however point out that there are several engines that can do 3D on mobile quite well. Unity, UDK and Shiva.
  22. To be fair, Rick, Blender isn't a CSG map editor. It's a high end 3D modeling app. None of the 3D modelers out there work like Hammer. I get your point however.
  23. I agree this works well, with one caviate. Most Blender users do all of their modeling in an environment with zero perspective. This is a really bad idea. By default, all camera views are an orthegonal projection. This is fine for front, side, (and so on) views. However the moment you start orbiting around the object freely, you really need to be looking at a perspective view. Now in Blender you have two options for this. Once you start orbiting an object you can hit the 5 key on the keypad to switch between the two perspective types (on/off), or you can go into the preferences and turn
  24. I don't think anyone claimed anything to the contrary. It just won't be the norm.
  • Create New...