Jump to content

  • Log In with Google      Sign In   
  • Create Account

Squared'D

Member Since 08 Apr 2013
Offline Last Active Yesterday, 07:37 PM

#5143391 Why are my two classes sharing variables? C++

Posted by Squared'D on 31 March 2014 - 12:27 AM

I think i found out the bug today guys. Basically what happened was that i declared an array of octorocks:
OCTOROCK octorocks[4];
But what i did wrong was that initialized it like this
octorock[1].x =......
octorock[2].x =......
octorock[3].x =......
octorock[4].x =......
What i did wrong is that i didnt access octorock[0] and did a memory violation by going out of bounds in tbe array with octorock[4].


Don't worry. Mistakes like this are quite common. That's why I tend to look to see if I've made silly mistakes first when debugging. I hate it when I end up making major changes when the original bug just turns out to be a missing minus or something. Glad you found the answer.


#5141608 Why are my two classes sharing variables? C++

Posted by Squared'D on 23 March 2014 - 11:08 PM

If you still can't find the problem, put a break point in the code that fires the projectile and step through the code one line at a time keeping the variables in a watch window. I agree that it's either bad pointer management or you put an assignment somewhere and didn't notice.


#5141566 Why are my two classes sharing variables? C++

Posted by Squared'D on 23 March 2014 - 06:35 PM

I'm curious about whether or not you were able to solve the problem. Non-fully answered forum post can bring such misery.

 

 

wisdom_of_the_ancients.png




#5136469 Bonafide Newb in need of assistance

Posted by Squared'D on 05 March 2014 - 01:04 AM

The two post above have a lot of good starter terms. As mentioned by jbadams, terms without context won't help you much. The internet is good, but if you choose a language and get a good book on the subject, that will help you out a lot. Books will have a lot of sample code and exercises for you to try and should be layed out in a way that will teach you all the important jargon. If you hear "function" and then can imagine code for a function, I think that will help you more than a definition.

There are free compilers and interpreters on the internet, and your local library can be a good source for programming books.

As you're just starting in coding, I hope you stick with it. It can be challenging at first, but once you get the hang of it, you'll be able to do many good things and find that it's very rewarding.


#5127376 Is it practical to have two instance of a Game class object

Posted by Squared'D on 29 January 2014 - 10:50 PM

Yeah. Like Dave Hunt said, if you only need one, just make one. Sometimes is not good to over think things. Singletons add more unnessary complexity that goes beyond just saying there can only be one. You'll also be giving global access to the object which can cause problems down the line as ownership and the interactions won't be clear.

There may be a reason to run 2 instances at once if the app wants to run 2 simultaneous simulations, but it depends on the needs of the needs of the app.


#5113745 Does this approach to pass frequent method parameters implicitly seem evil?

Posted by Squared'D on 02 December 2013 - 07:55 AM


void Scene::update()
{
    runMachines(*this); //Lots of moving parts - may affect surroundings
    growGrass(*this); //Need to check other objects - grass may impale those who stand on it while its
growing
    glowLight(*this); //Heat the neighbors
    for each object do
    {
        for each otherobject do
        {
            checkCollisions(*this)
            doGravity(*this)
            sayHi(*this)
        }
    }
    etc.
}

 

I think you're asking the wrong question. Instead of how can I pass Scene to all of these things quickly without using globals, you should have asked yourself, why do all of these thing even need Scene in the first place? runMachines, growGrass, etc--do all of these things need Scene? At first glance, they look like methods to the Scene class anyway. If that's the case, you don't need to past them at all. If they are separate objects and this is just pseudo-code, does runMachines need everything that's within Scene? Does runMachines need to access the grass stuff?

 

If all those things are separate objects or methods in some other class, why not only pass exactly what it needs from Scene? Or just have the class store the information. Have a Machines object that has a list of all of the machines and updates them.

 

That's the problem. All those functions shouldn't even need to be passed Scene.

 

A side rant:

What's with all this things are evil post? I feel like L Spiro when some posts "Don't make engines, make games." Just saying globals are evil leads to worse practices because many not understanding the real problem just find ways to use "globals in disguise." Think of singletons. Since globals are bad, let's wrap it in a class so now it's good. Oh wait, singletons just made it worse. Globals are not evil, BUT they can show problems in the overall code design. Globals often mean class dependencies are too deep and globals are used as a hack to skip some of the layers. If you need globals or statics to pass data, reconsider that entire structure of your code.

 

How a component-based system could help

By the way, if you used a component based system, this would all be easy to handle. If all collidable objects have CanCollideComponent, the collision system would be able to check for collisions regardless of whether it's a machine or even a blade grass (if you really have a need to work at such a detail.)




#5113187 Is using static variables for input engine evil?

Posted by Squared'D on 29 November 2013 - 10:51 PM

Yes it is! You're Hitler to me now.


This is actually very useful. Don't worry about something being evil, worry about how it will affect your code down the line and see why it's not good. Statics aren't bad, but they can lead to habits that make the code hard to maintain.


#5112742 making a program, all code in one file

Posted by Squared'D on 28 November 2013 - 08:01 AM

what about only one file and no use of classes, that means lots of global variables and functions


This is an interesting question. I've never thought of it before. As was mentioned you may be able to speed up your compile time, but the code will be harder to maintain.

Also, keeping everything in one file, using classes, and using globals aren't related. You can put everything in one file, not use classes and still not use globals. When it comes to classes, you can right fast code that uses classes and slow code that uses classes. This is in the graphics forum so I'm assuming you want to speed up some graphics code. By the question you seem to just be starting out. If you're looking for ways to speed up your code, i'd look for better ways like analyzing code that gets called multiple times in a frame. Writing clean maintainable code will be more beneficial than trying to make the code faster by putting it in one file or using globals.

BTW, when I want to quickly prototype something I kind a put everything in one file, but even in these cases, I have a prototyping framework that I link with it that's not in the same file and linked in. I put things in one file in these situations because I just want to test out something quickly and one file makes sense. Other than in testing situations or when writing small console programs, the benefits of keeping it in one file don't out weigh the cost.


#5112390 Is squeezing performance out of a console the same as premature optimization?

Posted by Squared'D on 27 November 2013 - 03:12 AM

For me, a premature optimization is an optimization that adds complexity to the code and possibly makes it harder to read that's made before it has been determined that such an optimization is even needed. There's nothing wrong with writing fast code and optimizing early. I always try to do this, but after examining my projects needs, sometimes I choose the easier albeit slower implementation/algorithm over the faster and more complicated (and potentially buggier) one. If later I find that it's a bottleneck, I'll change it then.

 

When working on hobby projects as the lone coder, this is important. Take this example. A programmer is working on a simple 3D game and uses a 2D array to keep track of his objects locations in 3D space. Its simple and it works well, but he hears that 2D arrays are slow and quad-trees are faster so he changes his code. He's new to quad trees and adds a bunch of bugs. He's not sure if the bugs are from the quad tree or other parts of the code. On top of that, we didn't even have that many objects so using 2D arrays was actually more than fast enough for his project.




#5109613 Appropriate number of bugs

Posted by Squared'D on 15 November 2013 - 08:01 PM


- The game sometimes crashes hard.

 

This is a very worrisome bug. If the game suddenly crashes at unexpected times, it could mean deep problems that could be very hard to fix, and if you release/sell this game and it crashes on people, your reputation will take a dive. By not fixing it immediately, you may have built code that relies on code that needs to be removed or was poorly designed. I personally try to keep bugs to 0 and if a bug creeps up, I fix it before moving on to anything else. When building new features on buggy code bases, future bug fixes can break working code. I've been in that situation before and found it better to stop adding features and just fix everything first. In the long run, you'll save time.

 

Buggy code can kill motivation. If you remove all the bugs before adding more features, your nicely working program will provide more motivation to finish it. "Hacky" code and endless bug fixing can drive a person insane and kill an otherwise good project.

 

I hope you fix all of your bugs first. Then you'll see how much easier and enjoyable coding your project can be.




#5105593 Abstracting away DirectX, OpenGL, etc.

Posted by Squared'D on 30 October 2013 - 01:13 AM

I was very similar to you. When I first started using Direct X 7, I wanted to create an abstraction layer so I'd later be able to support other things, maybe even other OS. Well I still think this is a good idea, at the time I was new to graphics programing and just learning DX 7 was a huge task for me. I never ended up supporting any other API, and when I moved to DX8, I scrapped most of the code anyway. (FYI, first attempts usually suck.)

Now that I've written like 5 or 6 different 3D engines, I've finally think I have enough knowledge to do a multiplatform framework. It's working well, but after I finish this game, I'll probably redesign it yet again.


#5097605 Game programming help?

Posted by Squared'D on 29 September 2013 - 08:16 AM

It all depends on what you want to do. There aren't many short cuts when it comes to programming. You have to learn the basics and gradually build on what you learn. Internet tutorials are ok, but I feel that books are better. I learned a lot by getting books from the library. Remember you need to learn the basics of programming if you want to be a programmer.

I'm not sure what kind of a portfolio getting into that TAFE course would take. You can try searching for past participants to see what they submitted. Then you'll be able to get a better idea of what will be required.


#5097556 Game programming help?

Posted by Squared'D on 28 September 2013 - 11:39 PM

I currently have no skills or education in programming, I am messing around with GameMaker and Unity but with no luck


Remember, games are just specialized programs. If you want to become a game programmer, you'll need to become a programmer first. I started by picking a language and getting a book on that language, made some simple text based programs, and then later moved on to games. If you want to program games and don't have any knowledge or experience, looking at the source for other projects won't be too helpful.


#5095691 Game Logic: Creating a Scripting Language

Posted by Squared'D on 21 September 2013 - 02:09 AM

I can understand the desire to make a scripting language. I guess I can be a bit nerdy, but designing the language, building the compiler, and writing the byte code interpreter can be a lot of fun. I decided against it though because of my lack of time. Developing a good 3D game is hard enough and takes a great deal of time. I did make a simple AI script though. The language itself is simple enough to parse with a library string tokenizer. It just sends basic commands with some parameters to the AI.

It's your decision if you want to make a scripting language for your engine. My suggestion is, if you want to finish the engine/game in a reasonable amount of time, make something simple. Focus solely on your games needs and what you need to script. You can expand it later.


#5083148 Do you ever have to release or free a D3DXHANDLE

Posted by Squared'D on 05 August 2013 - 12:14 AM

 

From the function declararion, it looks like you are using DirectX 9. Am I correct? In Direct X 9, those handles are merely a way to identify the technique so you can set it. Setting the technique using a handle is faster than using it's name each time because string comparisons can be slow. The method GetTechniqueByName is used so you can get the handle once and just use it. It's only an identifier. As far as I know, you can't release or delete a technique without freeing the whole effect. Here's more info http://msdn.microsoft.com/en-us/library/windows/desktop/dd607390(v=vs.85).aspx

 

Actually, from d3dx9shader.h:

typedef LPCSTR D3DXHANDLE;

A D3DXHANDLE is just a string.

 

I believe that the MSDN page you've linked is slightly misleading; what should be the slower part is all of the Get* calls, as they would require parsing the effect and searching for the name.  Doing them upfront at creation time rather than at runtime should mean that once you have the handle - I'm assuming (i.e. I haven't seen the source code for D3D9 Effects so I don't actually know...) that Effects is using a hash table or similar container to map each handle to it's register slot - it's actual underlying register can be retrieved more quickly and without all of the parsing/searching.

 

 

Actually in DirectX 9, the handles can be strings or the values returned by the Get*ByName methods. You can use either when you call Set*. The Get*ByName functions return handles using string pointer types, but they are not real pointers. They are not real memory addresses. I don't remember exactly, but when looking at the value in a debugger a year or so ago, they set the high order bits to 0xff or some other special code so the functions know the handles coming in are not strings but these special handles that they use.

Basically, when you set techniques or textures or matrices, etc using the DX9 effects methods, the handle can be a real string, or the value returned by the Get*ByName funtions.

Edit: The Get*ByName functions should be called only once after the effect has been loaded. You should just save the handles somewhere and use them when you need them as using the handles returned from the Get*ByName functions will be faster than using the actual string name every time.






PARTNERS