Sorry your browser is not supported!

Ok, this is becoming a serious issue for me.
Over the past few days in my new application things have been going a little weird.
It started when the variable i used to create a selection box started to grow, randomly just after it had previously worked with no changes. I didnt look at the code much i just disabled it cos it wasnt needed.

Then whenever i assigned a variable for AI[0].Run = true; it would randomly assign Units[0].Type = Block, and if it was false it would assign it to Line. After spending a few hours ensuring that these variables were never compared or even next to eachother i gave up and made it so you currently cant make your guy run.

A few more odd little ones happened but today it started with the camera, it would randomly increase the struct variable Cam.AZ (angle Z) by 1 constantly whenever this command was run: dbRotateCamera(Cam.AX,Cam.AY,Cam.AZ);
But because you shouldnt be able to rotate the camera on the Z axis i disabled it, so itll always be 0.

But now it is effecting the variable for the X angle which has been unchanged since i made the app but it again only has problems with dbrotatecamera is run, and that aswell increase itself by 1 completely randomly and in the code there is absolutely nothing telling it to do so.

(i even tried renaming the structs and variables but the problems would persist).

Does anyone know why or how this is happening because it is frustrating because it makes no sense how these variables are reassigning themselves.

So i know it isnt corrupted ram or something i will include the exe for the game if anyone minds running it to see if theres errors on their side.

Why didn't you include any source code? The issue is likely to either be that you're not initializing all your variables and/or that you're erroneously using pointer types to access memory that you shouldn't.

One other possibility is that you're doing something wrong with GDK and it's throwing an error, this causes GDK to write the error code to the first 4bytes of the stack which can be highly annoying to debug.

Well, I took some time last night looking over your code and it happened that I was on the phone With David W and we goto-meeting'd it for a bit.

We both were impressed with how you've made great efforts and attained progress with LOD, Alpha fading grass etc.

We also liked how the clicking does make the "Teams" of soldger's move to their destination.

What we believe at first glance was that your arrays of structures are likely getting mishandled, not cleared or maintained properly etc based on the fact that things work at the program's start up and then the functionality degrades.

Another observation about your code that is not related to your problem necessarily is your layout. Generally speaking, Header files are used to include function, variable and structure definitions but do not contain actual running code. Many folks then use these include files to "share" information from one source file to the next for example to "Pull in" the ability to call code in another source code file.

We thought about this and discussed this and we talked about how what you're doing is syntactically correct but deviates a bit from how include files are generally used. This made you code somewhat harder for us to follow but only because it was different; not necessarily wrong or anything. I personally think it possible you've taken the approach folks use when coding DarkBAsic and brought it over to C++ concerning include files.

I think this kind of thing will sort itself out as you keep hammering on code and find what works and what doesn't work and what's easier to maintain versus what might be more difficult. In short - I think you're doing great but I mention this stuff not to fetter or discourage but instead to encourage you; specifically to keep an open mind about code layout. My experience has been that for smaller projects, these things might be deemed less important but as the project grows in size and complexity; lack of a good code architecture that specifically a combines what works and what is readable by a human who must maintain the code of paramount importance.

In other words - this thing could become unmanagable as it grows if you're not careful. In the same breath I'll acknowledge that it has to be readable and maintainable by you because its your project so I'm not saying if you don't change your code you can't succeed... I'm not saying that at all. I'm saying keep an open mind to the importance of organizing your code and leveraging how C/C++ is rather strong concerning header files if they are used how I suggest most folks use them.

I'm not done looking through your project... I'd like to nail down where the structures are getting messed up.. but I have a lot going on and I will make an effort to squeeze this in.

--Jason

@Dark Coder - If Fatal Beserker permits - would you have time to take this project and see where the structures are getting hammered?

I know you can get around very well in code and I'm pretty strapped for time. Is this possible? Fatal Beserker? Dark Coder?

Perhaps a community effort can help sort things out?



Good Tip Dark Coder - Thank You!

Not if it's some massive project, I was hoping to see a main.cpp with some not so obvious bug and point it out. Debugging my own code takes enough time!

@DarkCoder - Totally Understandable.

I've dug in as a warm up to project work I have on my plate. I'm going through and breaking up the code architecture a bit to demonstrate a recommended use of header files.

I don't know for certain, but I suspect that in some situations - the compiler might compile certain code without a problem that doesn't execute as one might expect because for example a given function might appear twice in the compiled version of the code that compiled ok because the namespace was different or something. Likewise a variable or array could likewise be declared twice (one per namespace maybe and depending on which function accesses it - could result in strange results. I'm not trying to state a specific example here, but I feel that organizing the code to at least separate definitions from code could eliminate that potential and at a minimum give an example of the widely used techniques for organizing c/c++ source files. e.g.: Make it so header files contain declarations and not actual code; and to have *.cpp files contain the actual code. Hopefully, I can eliminate the potential for such anomalies. I haven't proved such anomalies exist admittedly; likewise... I've been coding long enough that I want to eliminate the possibility before getting into the meat of the problem. e.g. I don't want to chase my own tail.

Stay Tuned..

Ive just got in so ill edit this with a longer response later but.
I didnt know what use because i like to keep the code in seperate files to keep it organised, i hate having everything in 1 file because i hate massive amounts of scrolling, i know header files usually have things like functions inside which i used to do, but correct me if im wrong but isnt calling a function slower than what i just want to do, which is simply inserting that certain file.
I like to keep the main.cpp very clean and just linking the rest of the code together.


its something i cobbled together in the few days my internet was down, its probably around 1000 lines or something, but u can clearly see the problem in 2 files which is probably around 400.
Providing u can agree to not start sharing these files around the net and keep it to yourself, i dont mind sharing it with experienced programmers. If you are still interested ill send u an email with a link to download it.

Thanks for the response so far.