Jump to content
  • Advertisement

ProgramMax

Member
  • Content Count

    295
  • Joined

  • Last visited

Community Reputation

162 Neutral

About ProgramMax

  • Rank
    Member

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. ProgramMax

    Discrepancies in Maximum Texture Size

    Yeah, it has everything to do with the feature level you chose. Look at the comments under Width / Height http://msdn.microsoft.com/en-us/library/windows/desktop/ff476253(v=vs.85).aspx Here is a list comparing the feature levels (including max texture sizes) http://msdn.microsoft.com/en-us/library/windows/desktop/ff476876(v=vs.85).aspx#Overview So yeah, you probably chose a feature level other than DX11 and so the max texture size is being artificially limited. Now, why is it limited like that? I'm not 100% sure.
  2. ProgramMax

    Discrepancies in Maximum Texture Size

    Just interesting food for thought: I have an ATI HD 5570, which also supports DX11. And when I open up the DirectX Caps Viewer, DXGI 1.1 Devices -> ATI Radeon HD 5570 -> Direct3D 11 -> D3D_FEATURE_LEVEL_11_0 "Max Texture Dimension - D3D11_REQ_TEXTURE2D_U_OR_V_DIMENSION ( 16384 )" But if I instead navigate to: DXGI 1.1 Devices -> ATI Radeon HD 5570 -> Direct3D 11 -> Additional Feature Levels -> D3D_FEATURE_LEVEL_10_1 "Max Texture Dimension - D3D10_REQ_TEXTURE2D_U_OR_V_DIMENSION ( 8192 )" And if I go down to D3D_FEATURE_LEVEL_9_3 then "Max Texture Dimension - 4096" And 9.2 is 2048 But then there is Direct3D9 Devices -> ATI Radeon HD 5570 -> D3D Device Types -> HAL -> Caps has MaxTextureWidth / Height of 16,384. Is it possible that using the old D3D9 allows you the 16,384 size, but going through DXGI with 9.x feature level restricts it down?
  3. ProgramMax

    C++ for loop performance

    ++i is called pre-increment. i++ is called post-increment. Since i is an int here (or really, if it were any POD) there is no real difference. The difference comes in if that is a heavy class. The reason is because ++i just increments the value and returns the new value. So int i = 5; std::cout << ++i; would output 6. The other option, i++, must return a copy of i's original value and then increment i. Meaning now there are two ints here instead of just one. So int i = 5; std::cout << i++; would output 5. However after that line i's value is 6. That's because it isn't actually outputting i, it is outputting that copy of i's original value. Like I said before, for ints it won't matter. But if i was some huge, heavy class and creating a new copy is expensive then you'll notice a difference.
  4. ProgramMax

    Particle Batch calls with degenerate verts

    A degenerate triangle is one with no area. So two of the points must be idential. For example: (0,0,0) (0,0,0) (1,0,0) If you tried to draw it out you would notice the triangle has no area. Video cards can quickly throw these triangles to the side. Which means to connect two seperate things in a tristrip you can use two degenerate triangles to setup the last two points fo that the next triangle has something to work with. Does that make sense?
  5. Instead of writing your own error number to string code you could just use the tool that comes with the DirectX SDK for error lookup. Also, recently I got a chance to talk to someone at Microsoft about an undocumented error I had previously found. He told me that: 1.) Development for DirectX 9 has stopped so they won't be updating the docs with the new find, (If it was an error in DirectX 10 that would be different.) and 2.) Undocumented error are common place for DirectX. Especially when multithreading things. He suggested that my switch statement also have default cases to catch any undocumented errors. So my suggestion is to stick with what you currently have but use the DirectX Error Lookup tool and get what you need. I hope this helps.
  6. ProgramMax

    DInput and mouse button issues

    Hey. Sorry. Was a bit busy. The code I posted toggled with mouse state change. Not per click. Oops. Here is correct code. bool gWasButtonPressed = false; bool gIsButtonPressed = false; gIsButtonPressed = directInput.mouseButtonDown( 1 ); if( gIsButtonPressed != gWasButtonPressed && gIsButtonPressed = false ) { gRotate = ! gRotate; } gWasButtonPressed = gIsButtonPressed; This should now only toggle if the mouse state changes in the depressed direction. You could change the end of the if to true if you wanted it to occur in the pressed direction.
  7. ProgramMax

    DInput and mouse button issues

    NM ignore my last post. I keep thinking about the hold-to-rotate thing. gRotate = ! gRotate is correct for the click-to-toggle thing.
  8. ProgramMax

    DInput and mouse button issues

    Or better yet, don't have gRotate = !gRotate;. Instead have gRotate = IsButtonDown;. It might be a little more clear and self-documenting.
  9. ProgramMax

    DInput and mouse button issues

    Oh I am missunderstanding the problem. I reread your post and saw that you want a click to toggle wether or not you are rotating. So you can do this: bool WasButtonDown( false ); bool IsButtonDown( false ); do // your loop { IsButtonDown = directInput.mouseButtonDown( 1 ); if( IsButtonDown != WasButtonDown ) { // mouse button state has changed since we last polled gRotate = !gRotate; } WasButtonDown = IsButtonDown; }
  10. ProgramMax

    DInput and mouse button issues

    Are you saying that every time you call the function it returns true if the mouse button is down? And hence it is flipping the variable every time you poll? If that's the case why not just: g_IsRotating = blah.mouseButtonDown( 1 ); I must be missunderstanding the problem.
  11. Quote:Original post by Polymorphic OOP No, you don't gain any exception safety since implementing + via += is already just as exception safe. That's not what I was saying. operator + will be exception safe no matter what. It is operator += that won't be exception safe. If you don't implemented += in terms of + then you have this: Matrix & Matrix::operator +=( const Matrix & rhs ) { // copy matrix over // this is not atomic and could throw half way through // but since you didn't use a temporary, this matrix // is now incorrect, holding half of the new values // and half of the old, wrong values } I use a matrix instead of MyInt because MyInt is small enough that it is atomic already, and this isn't a problem. Nevertheless it is a good habbit to get into. In the examples you gave me you allowed the temporaries to be in invalid states, which is fine. The temporary gets cleaned up in the case of an exception and we don't care about it. But in your examples, without using a temporary, you wouldn't be able to safely call: Matrix foo; Matrix foo2; // fill with values foo += foo2; You NEED a temporary inside operator += if you want exception safety. It is as simple as that. And since you have a temporary in operator +, you might as well implement += in terms of +. You do lose the optimizations, that's true. But the slow down in programs is normally a bad algorithm or poor choice of container. If your operator +/+= needs optimization then it must be terribly slow. And the tiny difference in speed that a temporary costs is nothing compared to what you gain for being exception safe.
  12. I don't think it will be just as usable. First off a half-filled container when you expected a full container is already wrong. Second the copy will likely look like this: m_Count = rhs.m_Count; for( unsigned int i( 0 ); i < m_Count; ++i ) { // copy item i } If this fails half way through, your count still shows an incorrect number. This is why NONE of the standard containers do this. It isn't exception safe. It doesn't "still work."
  13. Also it is perfectly common for non-exception safe operators to leave an object in an invalid state. Something so simple as MyInt won't have a problem since its only operations are atomic. But take a class that is more complex: Matrix & Matrix::operator *=( const Matrix & rhs ) { // This is not atomic. // If an error occurs half way through, our object is out of a valid state. } Same with vectors. Same with all of the std container library. Suppose you are calling operator = on a container, which is templated over type T. You have no garuntee that T's operator = won't throw an exception. And this is good because maybe T is something like database connections, where you may want only 4 max. Copying and trying to create 8 would be bad. T's operator = should throw in this case. But that means your container's operator = can throw an exception half way through. If your origional had 3 connections, the first connection will copy without throwing. But then the second connection will throw. And now your container is in an invalid state.
  14. Exception Safe Case: MyInt operator +( const MyInt lhs, const MyInt rhs ) { MyInt temp( lhs ); temp.m_Value += rhs.m_Value; return temp; } MyInt & operator +=( const MyInt rhs ) { MyInt temp( m_Value + rhs.m_Value ); Swap( temp ); return * this; } void MyInt::Swap( MyInt & rhs ) { std::swap( m_Value, rhs.m_Value ); } In this situation you will only run out of memory in the allocation of the temps. And if you ever run out of memory, your origional object is still in a valid state. So contrary to what you said, there isn't a problem. The problem is fixed. That's the whole point of exception safety. Also you could use Swap( temp ); in many other places, like operator =. This helps you work on a seperate, temporary copy, preserving your origional state. You can read more about it in Exceptional C++.
  15. I would suggest making MyInt( int ); different. Right now it can be implicitly casted from any int to MyInt, which can lead to confusion and troubles. Instead write it: explicit MyInt( int ); Also I agree that += should be implemented in terms of +. You lose the benefit of no temporary, that is true. But you gain exception safety. Case 1: If += begins modifying itself and an exception occurs half way through, the object is no longer correct and you are not exception safe. Case 2: If += calls + and the exception occurs in +, the object's state hasn't been altered and you can propogate the exception.
  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!