Jump to content

  • Log In with Google      Sign In   
  • Create Account

Josh Petrie

Member Since 11 Jun 2003
Offline Last Active Private

#4699324 [June 2010 SDK] DirectX Viewer Missing! (solved)

Posted by Josh Petrie on 31 August 2010 - 04:02 AM

Should be there. My copy is in Program Files (x86)\Microsoft DirectX SDK (version)\Utilities\bin\x86 (or x64).

#4684203 Using goto efficiently

Posted by Josh Petrie on 29 July 2010 - 04:08 AM

goto is not inefficient -- it is, as far as these things go, almost certainly going to be the most efficient means of jumping to another location in the code (ignoring contextual issues). The if's are likely to be less efficient since they may not be as predictable.

That's not why people are "warned against" using goto, though: the warnings against it have to do with how easy it is to create ugly, unreadable code like you've posted.

I would rewrite the code to be more readable, break things into functions, et cetera. Use a profiler to determine bottlenecks. All you're doing now is wasting time.

#4597235 What are the commercial level engines out there?

Posted by Josh Petrie on 01 February 2010 - 01:48 PM


I did not want to invest a lot of time learning something that I shouldn't have been wasting my time on.

Then you learn to program and develop software, rather than trying to learn "engines." Engines just present a series of tools and APIs, and adapting to new tools and APIs is the hallmark of a skilled programmer.

The metrics you appear to be using for engine quality are sketchy, at best (for example the quality of the visuals has a lot to do with the art, regardless of the engine: good art on good tech looks good, so does good art on bad tech -- just not as good. But bad art on any tech looks horrid). Furthermore just because something was used in a shipped product does not mean it's any "good," and similarly, just because something hasn't been used in a commercial shipped product doesn't mean it isn't worthwhile or worth adding to your toolset.

#4597226 Banned in #gamedev

Posted by Josh Petrie on 01 February 2010 - 01:39 PM

If it was only a regular ban, it will expire in 24 hours. The issue is really if we want to upgrade it to a permanent ban or just let it expire. I'll review the logs.

#4597215 C# Game Programming by Ron Penton and SlimDX - questions...

Posted by Josh Petrie on 01 February 2010 - 01:13 PM

The author is active on these forums, although I'm pretty sure he will be completely uninterested in porting that code to SlimDX for you. This is something you will need to do for yourself. Have you even looked at the samples in the SDK yet? They illustrate quite clearly how to set up a device, etc (MiniTri, SimpleTriangle). That should provide a starting point.

#4597213 Converting from C++ to C# and Direct3D/MDX to SlimDX?

Posted by Josh Petrie on 01 February 2010 - 01:09 PM

To clarify a point you seem to be missing, but has been made multiple times across the various threads you've been participating in recently: you have to ask specific questions to get specific answers. Your other thread, for example, started out with a broad question, which I guessed at. You provided error messages that confirmed my guess. Then you asked for help about converting the code - showing no indication that you actually tried to do so, to consult the SlimDX documentation, the equivalent Direct3D documentation, or even (the best option, which another poster provided) to look at the SlimDX samples.

We aren't going to convert code for you, provide you a resource for copy-paste coding, or generally hold your hand and baby you through the educational process. What we will do is help you learn by directing your efforts and answering specific questions. But you need to give us something to work with.

#4597188 Best free IDE for coding c#?

Posted by Josh Petrie on 01 February 2010 - 12:24 PM

VS Express 2008. Until 2010 ships in April, most likely.

#4597181 What are the commercial level engines out there?

Posted by Josh Petrie on 01 February 2010 - 12:08 PM

What is a "commercial level" engine, to you? And why does it matter? What are your needs?

#4597153 Which Shader Designer do you use?

Posted by Josh Petrie on 01 February 2010 - 11:29 AM

I use a custom tool I wrote myself.

#4597148 Can't delete SlimDX install folder after uninstall!

Posted by Josh Petrie on 01 February 2010 - 11:17 AM

VS still could have set a persistent permission thing on the file, I dunno. I'm pretty sure SlimDX does not even bother to ship those artifacts, so the file had to have been created locally.

#4597145 Converting from C++ to C# and Direct3D/MDX to SlimDX?

Posted by Josh Petrie on 01 February 2010 - 11:15 AM


Well here's the problem...

I have a TON of C++ coding books, and basically I'm being told that I can't use them. I can't accept that. I can't afford current C# books either.

You certainly cannot use them to learn C# well. If you care at all about learning C# well, you should not be trying to learn C# from C++ books. This is equivalent to learning a natural language in the same fashion: learning French by learning Japanese. While you can find a dictionary or a phrasebook, that will only help you superficially. You will never become a fluent, because the grammar and thought processes involved differ. Greatly.

You don't need to buy books, there's reference material online. Look at the C# Workshop forum that's on this site; one of the introductory threads contains links to material that will be useful.


I accept that there are all kinds of differences between them, but there has to be a way to chart how something was done in C++, and how to do it now in C#, if its something that needs to be done in the first place (such as C++ used destructors but these are not really needed in C#). Also anything which was done in C++, or which is no longer the right way to do things, could easily be mentioned and the alternative C# method provided.

It's just not really possible to do this in a way that is remotely correct in general. Yeah, you can say that you use "new" in C# much like you use "new" in C++. And that you don't use delete at all. But that's not going to tell you anything about the higher-level concepts that are going on, about how the CLR is managing your memory, about how you need to work within the CLR's contexts to handle resources efficiently in a much different fashion that you would in C++. It's just not viable; you don't see that because you lack the requisite depth of experience with both languages.


I'm also stuck with source code that uses Direct3D and MDX that I now need to change to SlimDX and I have absolutely no idea how to proceed. I have no internet access at home, so an online search box does not help.

The general names and conventions of both APIs will be similar. You're likely to hit snags on very specific issues, such as device creation and management. If you ask the specific questions you can get specific answers. What you're asking now is just too broad for anybody to be able to reasonably type out a response with a hope of being remotely helpful to you.

#4597127 Can't delete SlimDX install folder after uninstall!

Posted by Josh Petrie on 01 February 2010 - 10:19 AM

TempPE is indeed part of the build artifacts generated by MSBuild and the IDE.

Rebooting the machine should also clear up a closed file handle.

#4597126 Converting from C++ to C# and Direct3D/MDX to SlimDX?

Posted by Josh Petrie on 01 February 2010 - 10:17 AM


Are there conversion charts floating around somewhere, that show you how to convert a program coded in C++ to C#?

Not that I am aware of, and such a chart would perforce describe a very simple, mechanical translation that would likely be extremely inefficient in many cases (for example, anything dealing with memory or resource access and management).


Are there conversion charts floating around somewhere that show you how to convert Direct3D/MDX instructions to SlimDX?

SlimDX maps more closely to D3D than MDX. Most SlimDX interfaces are just .NET-ified versions of the native interface (in terms of name), they're often easy to look up. It's also pretty easy to use the search box here to look up a native interface and find it's SlimDX counterpart.

Mapping between MDX is slightly more difficult, because the API differs more. It's not a need we've bothered to give much priority. It's not neccessarily possible to mechanically or simply translate from MDX to SlimDX because SlimDX exposes only what DX provides, whereas MDX added a few layers of abstraction on that in some cases (the Direct3D object, events).

#4597051 best approach design-wise for a game engine

Posted by Josh Petrie on 01 February 2010 - 08:31 AM


But i thought it would be better to devide everything in separate dll files, like this:

etc etc..



Or maybe it's better to have one DLL file, that can communicate to the other dll's for you. So that would be like this:

CoreEngine.dll (this communicates with:)
etc etc..

Even worse.


One of those two method i mentioned would seem to be a neat way of creating an engine. But i don't understand why engines like TrueVision3D and IrrLicht didn't do it like that? Is it because my method isn't the best way at all to do it?? Because i kinda want to build it with the idea that it is module based.

Yes, because there is very little reason to build a system this way, and by choosing to implement the "glut of DLLs" approach you increase your workload quite a lot for very little benefit -- in many cases, no benefit at all. Most engines of sufficient complexity and utility are integrated enough that you're referencing all modules anyhow, for any nontrivial project, so you've bought yourself nothing.

Also, see this for my thoughts on a more useful approach to learn about building engines (and perforce, the DirectX API as you want) by building games that actually use and have requirements for the functionality you want to build instead of dreaming it up in a vacuum like you appear to have done here.

#4596978 Simple MDX9 experiment not working?

Posted by Josh Petrie on 01 February 2010 - 05:34 AM

k, it must have been something else we had to set that state for then.