Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 08 Mar 2009
Offline Last Active Aug 27 2014 08:01 PM

#5158294 Sampling Texture2D vs Texture1D?

Posted by IkarusDowned on 05 June 2014 - 12:37 AM

Once again, chatting with you all helped me solve the issue.

A couple things seemed to be needed for me to solve this:


1) I changed the Filter type to MIN_MAG_MIP_POINT. linear interpolated across the colors (which...is what it does...)

2) For my usage, I needed to switch the Addressing to CLAMP. 


I don't know if this mattered, but I also:

3) moved the three Texture1D declarations in the shader to an array, and did the DSSetShaderResource as an array...this probably didn't change much but I /think/ is a better approach


Also, I double-checked all the channel values and hand-calculated a bunch to make sure that what I was seeing in the SaveDDSToFile call was in fact what I was inputting -- as it turns out the DDS viewer I am using is a bit weird and unreliable...best to just do the math by hand.


Now, the calculations all seem correct and i'm getting some interesting stuff being done using the 1D textures.

Thanks again (and double thanks to MJP who helped me out twice in 2 weeks!)

#5158266 Stretched pixels in windowed mode

Posted by IkarusDowned on 04 June 2014 - 08:00 PM

You should also keep in mind that the ratio of buffer size to window size is important. If your backbuffer is set to say 640 x 480 but your window rectangle is 600 x 480, then the result will look "squashed" as you put it. If the window rectangle was, say, 700 x 480, then it would look "stretched."


As a rule I like to not optimize unless I must, and also try to keep things simple until it needs to be changed...thus I would suggest that your backbuffer and window rect keep the width and height in constant ratio of each other. I like to use multiples of the back buffer. Again, this isn't "optimal" as much as I just follow the rule: "get it to look right before getting to be fast."

#5156898 DX11: Pixel Shader not outputting to Render Target anything when domain shade...

Posted by IkarusDowned on 30 May 2014 - 12:08 AM

wow...finally solved the issue.

I'm such a fool....here's what went wrong, and its pretty freaking obvious...

When switching shaders from the deferred shader to the regular texture shader that outputs to the "screen," I call the PS and VS set shader functions...but i wasn't clearing out the HS and DS shaders...in essence they were still in place while only the PS and VS shaders had changed....wow....


Thanks as always guys for your help. just chalk it up as one of the many learning experiences out there....

#5037496 Want to learn programming...again

Posted by IkarusDowned on 28 February 2013 - 01:53 AM

As someone who is an avid C / C++ fan, but works a LOT in Python, Java and other languages, I would like to say that a solid understand of C (and the concept of constructors and destructors in C++) will take you a LONG way. Understanding how memory works, what pointers are (and what references AREN'T) can help you pick up other languages REALLY quickly. Having to train people in programming and software development, I find that the people who do well not matter WHAT gets thrown at them have the concepts of scope, memory management, construction / destruction firmly in their head get more work done faster and understand things better.


That being said, it takes both effort and time to get to a level comfortable with some of the craziness of pointers and all that. What is your main purpose to learn programming? The OP doesn't state "game programming" explicitly. If you are interested in just learning some basic programming, the vast majority of scripting languages are just fine -- Perl, Python, Ruby, any of those give you the ability to rapidly produce results with minimal fuss. the core concepts of "programming" are in all languages.


Too often, people get into the "Language Wars." Languages are like the paints and paintbrushes to an artist, or the tools in a toolbox to a craftsman. Each language has its strengths and weaknesses -- pick the right tool for the job, but most importantly is to know WHICH tool is right for which job. 

#5035213 Zelda style boomerang

Posted by IkarusDowned on 21 February 2013 - 07:02 PM

yeah, frob explains much better what I tried to say.


just outta curiosity frob, doesn't this also depend on the boomerang velocity and how much the player can move in a single update? It seems like if the motions were too rapid, you'd get a stutter with the motion. I guess attenuating the velocity would take care of that tho?

#5035198 Zelda style boomerang

Posted by IkarusDowned on 21 February 2013 - 06:36 PM

are you looking to just be able to have the boomerang come back to the player in a direct path? One "simple" way is that once you hit the maximum distance:


1) figure out the vector from the current boomerang position to the player

2) calculate the step towards them

3) move the boomerang that distance


this will make the boomerang seem kinda funky tho...it will look like its attached to a zip-line as opposed to a nice arching return...

just a thought

#5035191 Need some motivation

Posted by IkarusDowned on 21 February 2013 - 06:23 PM

"The candle that burns brightest, dies fastest."


Don't push yourself to constantly be motivated, because like any human being you need downtime. Ask any serious athlete -- even olympians take massive chunks of rest, not only to rest their body but to actually have some time to rest their mind and spirit.


As a fellow software developer, I can tell you that its the balance of both:

1) studying and programming and learning

2) keeping my body healthy as much as my mind

3) days of just doing nothing (except maybe sitting around and drinking beer :P)


What is more important than "constantly driving yourself," is to check yourself from time to time to see if you are heading int he direction you want to be. Remember that you are just starting your career -- getting a job isn't the end goal, its merely a step on the way. All you need to do is make sure feel like you are in an area you want to be in, and the rest will fall into place with enough long-term motivation :)

#5014591 Anyone know of a good "practice" resource in terms of C++?

Posted by IkarusDowned on 26 December 2012 - 08:57 PM

for general programming tricks and practice Alpha_ProgDes has provided an awesome list.


if you are looking for practice with things like polymorphism and such things, here's a suggestion:


if you haven't already, pick up a book on Design Patterns. Most of these books provide sample programs and examples for each of the major design patterns. In my opinion, if you are comfortable with C++ syntax and mostly want to challenge yourself with classes, polymorphism, etc., then it might be easier to pick a Java-based Design Pattern book and simply do the examples in C++. This is a matter of comfort, and remember that you won't get the more C++-only stuff out of such a case (such as static polymorphism)


go through the design patterns and you will generally understand how C++ deals with pointers, classes, polymorphism, etc. It will also build your confidence up.

#5014587 2D tile map collision detection

Posted by IkarusDowned on 26 December 2012 - 08:41 PM

Its a bit unclear how you are handling the generic collision testing. Could you elaborate a little bit more?

for example, since it is tile-based, can we assume you have a multi-tier grid to partition the space? 


the general algorithm I've seen over and over is something like this:


- each character has a bounding-box that is either calculated at run time or pre-calculated on a per-frame basis. In other words, you have the rectangular "space" your guy occupies

- each character also has its x,y coordinates stored somewhere


1) for each character, do a bounding-box vs space partition test. For example, if you are using multi-leveled grids then you would "query" the grid for the possible tiles that collide with the character's bounding box. If you get no results, then you know that there are no collisions


2) for each possible tile you collide with in (1), re-check the character's bounding box against the tile, removing all the tiles that you DON'T collide with


3) now for each remaining tile, you can offset the character's x and y location using a similar algorithm to what xinifinite33 mentioned to "stop" the character from going thru the tile. 


There are other algorithms i'm sure, and your information provided is a bit vague so I apologize if this is more info / different info than you wanted

#5014582 Still not confident in my game programming skills in C++ and SFML

Posted by IkarusDowned on 26 December 2012 - 08:21 PM

as ultramailman mentioned, try not to look at it as one big task. when you do that, you'll get the ol' "step 1: everything" problem.

My suggestion is the take your simplest AS3 game and try to recreate that.

start with the basics, as already mentioned:

1) create a window

2) draw still images to the window

3) draw animated images to the window

4) handle basic keyboard controls, like knowing when a button is pressed

5) handle basic mouse controls, such as button click and mouse movement


if you can get those 5, that's the core for most of your other apps i'd imagine. Then you build features from there.