Brent Taylor
-
Posts
215 -
Joined
-
Last visited
Content Type
Blogs
Forums
Store
Gallery
Videos
Posts posted by Brent Taylor
-
-
well what other component of DirectX could you possibly be referring to...
jeeez, what tangent are you heading off on now...
FINALLLLLLYYYYY!!!
now lets let the networking discussion continue without anymore of this foolishness...
PLEASE...
--Mike
...
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.
-
that's exactly what you said...
on page 3...
Dx7 era Windows might run on a system with a minimal card, using the GDI to draw the various windows elements... but It won't run a directx7 game on that same system... dx7 wouldn't automatically fall back to anything and run...
Reversii and the card game are dx7 games... no DX7 graphics are capable without a capable gpu... period..
it doesn't fall back... and DX7 is not a wrapper for the GDI...
--Mike
...
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.
-
1
-
-
there ya go... finallly...
now, how do you figure this translates to the the assumption that GDI is a fallback for DX...
--Mike
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.
-
LOL @ Loomuja...
@Brent
read the thing doggone it... for god sake, it's right in front of you...
--Mike
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.
-
show me anywhere in these docs where directx7 does this...
god... it's like pulling teeth...
--Mike
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:
Woohoo! Found the DX 7 documentation.
Anyone interested can find it here: http://dl.dropbox.co...ads/dx7docs.exeHere'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):
As with other DirectX components, DirectDraw uses the hardware to its greatest possible advantage, and provides software emulation for most features when hardware support is unavailable.
And for information on the HEL (Hardware Emulation Layer) (found on the Software Emulation page):
When the hardware does not support a feature through the hardware abstraction layer (HAL), DirectDraw attempts to emulate it. This emulated functionality is provided through the hardware emulation layer (HEL). The HEL presents its capabilities to DirectDraw just as the HAL would. And, as with the HAL, applications never work directly with the HEL. The result is transparent support for almost all major features, regardless of whether a given feature is supported by hardware or through the HEL.
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.
-
Well I suspect the article is referencing DirectX7 as the page is a reference page for the Windows 2000 display driver model and Windows 2000 shipped with DirectX7 not 9 which was much later. I just thought it was interesting that it appears that GDI could wrap around Direct Draw too and take advantage of the hardware acceleration. DirectX8 appeared late in 2000 so it's still possible this refers to that and the later rebuild as you point out.
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.
-
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.
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.
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 Win98.
-
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.
-
Woohoo! Found the DX 7 documentation.
Anyone interested can find it here: http://dl.dropbox.co...ads/dx7docs.exeHere'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):
As with other DirectX components, DirectDraw uses the hardware to its greatest possible advantage, and provides software emulation for most features when hardware support is unavailable.
And for information on the HEL (Hardware Emulation Layer) (found on the Software Emulation page):
When the hardware does not support a feature through the hardware abstraction layer (HAL), DirectDraw attempts to emulate it. This emulated functionality is provided through the hardware emulation layer (HEL). The HEL presents its capabilities to DirectDraw just as the HAL would. And, as with the HAL, applications never work directly with the HEL. The result is transparent support for almost all major features, regardless of whether a given feature is supported by hardware or through the HEL.
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.
-
For example god would kill a player who is jumping and running around for no apparent reason.
Those poor Quake players... =P
-
A one second interval should be just fine even for the fastest actions games, since the movements are done with MoveEntity/PointEntity commands anyway, which implements interpolation.
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.
-
That doens't explain why I can send 14 bytes or 114 bytes with send(), and get not a millisecond difference in transfer speed. It would mean, that I have to manage when I call the send() function, after I have a big enough string to send (or binary data).
Obviously, it's not very effective to send small packets, because each sending takes FPS, and it would be much more efficient to send larger packets, since the FPS drop is the same.
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.
-
there is no logic to anything you've said so far...
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.
Among the important properties that logical systems can have:
-
Consistency, which means that no theorem of the system contradicts another.[12]
-
Validity, which means that the system's rules of proof will never allow a false inference from true premises. A logical system has the property of soundness when the logical system has the property of validity and only uses premises that prove true (or, in the case of axioms, are true by definition).[12]
-
Completeness, of a logical system, which means that if a formula is true, it can be proven (if it is true, it is a theorem of the system).
-
Soundness, the term soundness has multiple separate meanings, which creates a bit of confusion throughout the literature. Most commonly, soundness refers to logical systems, which means that if some formula can be proven in a system, then it is true in the relevant model/structure (if A is a theorem, it is true). This is the converse of completeness. A distinct, peripheral use of soundness refers to arguments, which means that the premises of a valid argument are true in the actual world.
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.
yet you still continue to argue... most illogical...
Until proven that I'm wrong, I see no real reason to stop. Why would I? Peer pressure? That wouldn't be logical.
if you're really interested...
<link ommitted by BTaylor>
I'm sure that's great information on using DirectX 7. I'm interested in it's implementation. That is not the DirectX 7 documentation. (I'm also pretty against piracy in general.)
As a side note: Linking a piracy site on here is probably not a good idea.
EDIT: Honestly, I give up. This is a meaningless argument. I can't argue my point as I can't find the documentation. All that is being accomplished is allowing Red to attack my character despite not having any proof or documentation himself. In addition we've hijacked a thread on a completely different topic.
If I can find the DX7 documentation somewhere, I'll add one last post on the subject indicating whether I was right or wrong. Otherwise, I'll stay on topic.
-
Consistency, which means that no theorem of the system contradicts another.[12]
-
wrong again... MSDN has all the DX7 docs archived... and i have the DX7 SDK disk, with all the docs... as do many others i'm sure...
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.
It just seems as if you make statements that present an authoritative knowledge and experience on some matters, but in fact those statements are incorrect and based on misconceptions rather than fact... it's those statements that are wrong, and i would think that you might want to look further into what you are saying, to ascertain the actual facts behind it...
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.
if the conclusions of others aren't enough ...
And that "conclusion" would have much more validity as an authority on the subject if DirectX 9 was not already in common use at the point of his post. In regaurds to DirectX 8 and 9 he's absolutely correct.
why would directx(directdraw) wrap itself around an inherently slower api to do high speed rendering... which is the one main features of directx... high speed rendering...
This I would think would be fairly obvious. Remember, I said it defaults to GDI if a proper video card is not found. It's a fallback.
Hence why I said:
Also note me pointing out my mistake. Just for good measure.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.cmon man... think about it for a sec... take me out of the equation... take yourself out of the equation... and think about it... logically, objectively, and pragmatically...
I think I've presented a fairly logical argument here. As I said, this is unfortunately very difficult for me to argue seeing as I can't find the DirectX 7 documentation anywhere. If you happen to have a link handy, by all means send it my way (and to be clear, I'm not putting the search on you. I'm looking for it as well).
EDIT:
@Everyone else
My bad. It's pretty clear we're hijacking the thread here.
-
@Brent...
i am so impressed... not only at your ability to refuse to acknowledge a fact when you are confronted by one... but also at your deftness and skill in conjuring an argument in a futile attempt to validate your position...
i stand in awe...
i must ask two things though...
1 - do you actually believe any of what you're saying...
2 - and if you do, do you think that it will in any way change the plain and inarguable fact that DirectX is not a wrapper for the GDI...
--Mike
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 for it. However, you have not shown any proof of this occuring in this instance and you've moved on to belittling me instead. I won't suffer a tantrum, Red.
-
@Brent...
actually a lil too simple...
lemme refer you to a lil discussion i remember reading which is almost a word for word copy of the one we're having here... maybe the answer given by someone other than me might be more pallatable to you...
oh... here's the url, just in case you want to read it yourself...
http://www.gamedev.n...tdraw-together/
from a discussion on GameDev...
--Mike
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.
-
@Brent...
i was just gonna ask you what you meant by this... glad you sorta corrected yourself...
i've forgotten more than i can remember about coding the windows gdi subsystem (circa Chicago), but from what i do remember... the gdi subsystem was around way before directx ever made it appearance... and, the gdi does a lot more than just draw things on the screen...
it's an interface that provides device independence for outputting graphics...
--Mike
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.
-
Virtual IS needed. IMO, you should always make all your class functions and destructors virtual, all the time. Forgetting to do this when you need to will cause some problems that are very hard to track down.
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.
While we're talking about C++ rules, please ALWAYS initialize pointers to NULL, ALL THE TIME. I've wasted more time as a result of uninitialized pointers than anything else in C++.
Indeed. In addition, always use initialization lists.
-
I don't recall DD being a wrapper for GDI. This was a long time ago when I was looking into DD but from what I remember DD takes advantage of hardware acceleration if available (which I would assume it mostly is these days) and if not available it falls back to the software drivers which can be calling GDI for some cases but not all.
If DD was just a wrapper around GDI I'd rather use GDI because anything DirectX is a nightmare to work with. MS goes huge structures passing by pointer crazy with all things DirectX. But everyone was/is using DD to take advantage of hardware acceleration.
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 about).
I don't understand... you mean he's not accurate, uh I mean he's not informative or ah gee wiz I so dumb founded that I just can't formulate a coherrent thought to save my life. Is this how some people above came to this new level of consciousness!
I just wanted to make it clear that I didn't agree with him beyond the one statement. =P -
Really, I can't find any mention of Direct X in SDL, but there's plenty to do with Open GL...
I can't see SDL achieving its cross platform goals if it relies on Windows proprietary graphics APIs.
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.
-
The market is full of 2D **** games, that's why nobody buys them. There is no engine on the market yet which can do decent 3D graphics on mobile, and that brings a new market opportunity.
@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.
-
I think the more this looks and feels like Hammer the better off you are in pulling in that large group of modders looking to take the next step. Keyboard shortcuts are nice as long as they don't get in the way of what people would "expect" coming from similar tools like Hammer or 3DWS. From what I remember the first time I tried to fly around in 3D mode in Blender it wasn't like 3DWS or Hammer and I was shocked and frustrated. Did I read the manual before I started? Hell now. I figured at the very least I would be able to move around with WASD and mouse like like in I've done in 3DWS and Hammer. It seems like Blender just went crazy with keyboard shortcuts and almost makes them a requirement to use which is great once you remember them or take the time to learn them, but gives a horrible first impression.
That was my impression anyway coming from Hammer and 3DWS and not a modelling background.
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. -
The reason why Blender works so well with just one view port and other software usually by default use 4 is because of Blender's well mapped out hot keys for view-port navigation.
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 on "Auto Perspective". It isn't on by default. It'll automatically swap between orthographic and perspective views at the appropriate times.
I bring this up strictly so Josh knows of the problem. It's easily solved.
-
Not saying a laptop isn't capable and that people don't use them... Once again all I'm saying is I doubt desktops will ever die.
I don't think anyone claimed anything to the contrary. It just won't be the norm.
Anyone interested can find it here: 
Leadwerks3D networking? What there is currently? What's planned for the future?
in General Discussion
Posted
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 I supposed to just let it go? We have a lot of people on these forums who are just beginning in their programming career. Am i supposed to just let them stumble on information like this and let them think it's legit/correct? I argue because I care.
However, this is just ridiculous. He's now twisting my words and transplanting anything I say into a different context. I'm tired of being insulted. I'm tired of being mocked. I'm tired of being belittled and treated like an imbocile. I'm not trying to be dramatic, but why should I put up with this?