• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.
Sign in to follow this  
Followers 0
KingofNoobs

R-value and L-value confusion

6 posts in this topic

Hello all,

I do not understand why the following example 1) compiles while example 2) does not, with the noted compiler error (using VS2012).

1) ID3D11ShaderResourceView* temp = (ID3D11ShaderResourceView*) i->first->GetTexture();
mContext->PSSetShaderResources( 0, 1, (ID3D11ShaderResourceView*const*) &temp );

- OK. Compiles fine.

2) mContext->PSSetShaderResources( 0, 1, (ID3D11ShaderResourceView*const*) &(ID3D11ShaderResourceView*) (i->first->GetTexture()) );

- Not OK. The following error is generated: error C2102: '&' requires l-value

I tried researching l-values versus r-values, but it seems to me that the void* returned by GetTexture (which is actually an ID3D11ShaderResourceView) is a valid l-value. Can someone exaplain why this is not so? Originally the return value was const void * const, but I took away the const-ness in all possible combinations and this did not yield me an l-value. I know I can just use my temp hack here, but I want to know why this doesn't work to save myself coding time in the future.

Thanks in advance for all your help.

-Dave Ottley
0

Share this post


Link to post
Share on other sites
The return value of a function is an l-value if an only if it is a reference type. Your pointer return type is not a reference and thus is not an l-value.
1

Share this post


Link to post
Share on other sites
So, then what I really need to do is return a reference to a pointer with GetTexture()? If I use my temp hack, will I get unexpected results?
0

Share this post


Link to post
Share on other sites
If this is your own code, why isn't it designed such that you can pass the return value directly into the desired function without any casts or temporary variables in the first place? You called it a "hack" yourself, and you shouldn't be hacking your own code.
[code]
mContext->PSSetShaderResources( 0, 1, i->first->GetTexture());
[/code]
Whether your temporary variable is dangerous or not depends on what the receiving function assumes and expects from it. For example, if it is only assumed to live for the duration of the function call then you're fine, but if it stores the pointer locally then your temporary variable may be destroyed before your [i]mContext[/i] object is done with it.
0

Share this post


Link to post
Share on other sites
Brother Bob,

Thank you for your response. Yes, the function only assumes that the pointer is valid for the life of the function, so I should be ok there. The reason that I don't send the texture as the correct class is that I am attempting to make a multiplatform rendering engine (i.e. DX and GL) so having pointers to D3D types in my generic SpriteInstance class is a no-no. However, I assume that GL will also have the concept of textures and that pointers are (or can be) used to describe them, so using a void* seemed apt as it allows the client code (i.e. Graphics Subsystem) to handle the pointer as it sees fit. The pointer was originally created by the same Graphics Subsystem so there will never be a type mismatch. Does this make sense, and would you recommend coding in another way?
0

Share this post


Link to post
Share on other sites
Do you require runtime-dynamic renderer selection? If not, then you can solve this with a simple typedef instead.

But if you need runtime-dynamic renderers, then you can you can solve this by adding a function to your DX renderer that returns the proper concrete type and cast [i]i->first[/i] to the DX renderer instead of casting the return value from the basic renderer.
[code]
mContext->PSSetShaderResources( 0, 1, static_cast<DXRenderer *>(i->first)->GetTexture());
[/code]
I assume you have a [i]BasicRenderer[/i] class that has a [i]GetTexture[/i] function that returns a [i]BasicTexture[/i], and both of the [i]Basic[/i]-classes are derived with specific DX and GL variants. The above assumes that the renderer is a [i]DXRenderer[/i] where you have a [i]GetTexture[/i] that returns the proper type for [i]PSSetShaderResource[/i].
0

Share this post


Link to post
Share on other sites
About that generic renderer, you don't actually want to have direct3d resource laying around in plain sight, correct? It seems to me like your master list, wherever "i" is coming from, should be internal to your renderer, and it should just contain a list of poitners to direct3d resourcees, no casting necessary. Then if you do write an OpenGL renderer, it will have it's own list of OpenGL resources. If you want to use the same code for that list, use a template. The only place where a renderer needs to be generic, is in the interface, in which case you might just return a number that represents where the resource is in some master list, but only the renderer knows if the resource is D3D or OpenGL and what information it's going to send to the video card when you want to use it.
0

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0