last_time = current_time; should be last_time += (1000.0f/60.0f);
edit: scratch that, i didn't realize you had that logic commented out. it's actually in your spawn timer:
m_spawn_timer = m_spawn_speed; should be m_spawn_timer+=m_spawn_speed;
Too explain, you are not carrying over whatever negative value the last spawn timer was at. let's say m_spawn_speed = 2; and m_delta_speed is 3. then in the next frame m_delta_speed is 1. in your current logic, m_spawn_timer would end up at 2, and by the second frame 1(which really should be 0) so now you've missed a spawning event. by incrementing by the frequency instead of resetting it, you don't lose any accumulation time.
What do you expect to happen with that shader? You have to actually write a pixel out, i.e:
Wrong. If you are rendering to a depth buffer with no render targets bound you still need the pixel shader for alpha testing, but there is no need for any return value.
Well then, how about you tell us the correct way to fix his issue?
I'm on mobile so I can't research his exact issue, but what I'm gathering from the error is that regardless that you have no color buffer bound, the api still expects him to output something, which is likely discarded when no colorbuffer is bound.
For the purpose of error-checking, a better alternative is, as you mention, initialize mem-pointers to nullptr in the constructor. Then implement another class function such as bool Init(). In that Init() call, you can perform required allocations and other initializations as desired. The benefit of a separate Init() call: you can return an error indication if any part of your initialization fails.
I'm pretty certain this goes against the RAII pattern. While i will say it can be better than a bad allocation in the constructor, i would say that this is an explicit case where exception handling is well suited.
Another option if exceptions are unwarranted is not to directly call your constructor, instead call an intermediary function which does the actual allocation/checks, and then passes that data to your actual object constructor, or reports an error if allocations failed.
you render the scene from your lights perspective, and save the depth buffer. you then take another render of your scene from your cameras perspective, but you also tell it the light's position as well, so when you translate your point by your camera matrix, you also translate it by your light's matrix as well. now you have 2 pixels, one for where it would be if seen by the light, and one for your camera. you then can compare if that pixel's light position depth is > then the pixel the light saw at that position. if it is, that means it's shadowed, if it isn't, that means it is visible to the light, and not shadowed.
As far as I know Apple haven't wanted to support flash for some time. So is there any point in making a flash game for iOS/Android? Also if you did use flash for say Android, how would you use C++ with it?
I do believe adobe air allows you to package flash games to be distributed for iOS/android(but don't take my word on that, it's just what i've gleamed over time). The workflow flash offers is pretty decent for 2D games, so I'd still recommend it even today, but for web based games, i'd recommend HTML5 over flash. As for integrating C++ with flash, I have no idea if this is even possible to be perfectly honest.
why can't you simply set draw mode to wireframe? (OpenGL: glPolygonMode, DX11: rastdescriptor.fillmode)
Create/model, not draw.
I assume his end goal is to draw those models like they were wireframed. instead of adding the overhead of generating a bunch of redundant vertices for his model in line mode, to instead just use built in api features for drawing models as wiremeshs. if this is not his end goal, then disregard my comment.
I'm trying to define a struct within my header file to use the new struct variable all over my code. I'm having some difficulties doing this. Any examples please? I looked around before coming here but nothing is working. A bare bone example would be appreciated.
I'm ganna go another route, and assume you mean to do the following:
The keyword your looking for is extern, it's basically like forward-declaring a function, but for a global variable. you define it in a single implementation file(in this case MyHeader.cpp), and when linking is done the linker will find it and use it for other implementation files.
With that said, I do not advocate the use of extern, and that using it generally means something bad is going on(this is really true if you are using any global variables). as such i don't advocate it's use at all.
there is a problem with this method: missing small objects. what happens if object B is small enough to fit between your raycasts? it's an idea i toyed with before, but imo it has potentials for missis.
So I could use an abstract class from which API specific code inherits: But using virtual functions in rendering code could bring performance issues to something very time-critical such as the rendering.
Honestly, i think your severely overestimating the performance impact a virtual call has. yes it's a bit of indirect with looking at vtables, but I'm extremely doubtful this is going to ever be your bottleneck. yet again it comes back to a case of pre-mature optimzations, demonstrate it is an actual issue before looking for complex patterns that results in overcomplicating your design because you think that it might be an issue.
I'm sorry i'm on mobile so i can't quote the relevant passage i want to respond to.
AlwayBiased i find the attiude of saying things like "you can't understand, you've never dealt with such a bug" a bit egotistical. Many of us here have been programmers for a long time, maybe we havent done your particular problem, but we've likely ran into similarly complex bugs. The thing is we also are trying to tell you there are alternatives to debugging then stepping over an entire loop to find your bug.
For example, you say you can visually see that their is an error in your output. This likely means for a given input you can produce said bug(making your bug reproducable is the start to solving it). Once you've isolated how to make your bug appear, you can begin narrowing down the code associated with that data and since this is a problem you can visually inspect, it's likely you could say "break on index x/y" after having inspected where in the image the bug first appears.
If this isn't a viable tatic, another tatic is to dump the output at each iteration, rather than walk through your code, dump lots of data about your code. Then you can go through this data and start to narrow down where things go wrong.
There are a multitude of ways to tackle solving complex bugs, but saying things like "you can't possible understand" is not helpful to yourself or those trying to help.
I want to help you, but their is just so much wrong here i don't know where to begin. I'd recommend going back and reading about how arrays, and pointers work(i'd even say their's abit of basic fundamental programming concepts you don't understand, considering the use of unnecessary copying, printing of individual characters, declaration of static strings, etc).
as well, this is a good opportunity to learn how to debug, you have alot of issues here that required you just typing out the code without actually testing what the results are(most noticeable how you calculate stringcount).