Jump to content

  • Log In with Google      Sign In   
  • Create Account

Khatharr

Member Since 24 Apr 2010
Offline Last Active Yesterday, 02:28 AM

#5107074 I'm stuck, haven't gotten any better at programming in months

Posted by Khatharr on 04 November 2013 - 10:17 PM

From what you said about your history, it sounds like you're accustomed to navigating according to your feelings, which will usually end up leading you to a place where you don't feel too great. The time you spent on your addiction was not simply away time in your development. It was actively reinforcing destructive behavior patterns, and the core of that is taking the 'quick fix'. I'm sure you've realized by now that's a way of cheating yourself out of a more fulfilling life, but you need to decide whether or not you're going to overthrow that underlying pattern and start moving forward from where you were when you started with the heroin. It's not a nice thought, but again I'm sure you've figured it out: the drugs are used to cover over other problems. This is the next problem you face. The solution is self-discipline, which isn't something that can be taught. You just have to roll up your sleeves and conquer both yourself and your environment in order to start building successes.

 

That doesn't mean just clenching your butthole and charging in head-first, either. That means using your head and managing your life responsibly. If you're not hooked up with a support network, get hooked up. If you don't have a medical professional helping with your recovery, get one. Make good decisions and you'll be much more likely to get good results. There's no quick cash-out for being responsible. There's the long term investment of living well, which pays in dividends.

 

Suggested reading: The Road Less Travelled




#5106309 Dividing by zero, on purpose

Posted by Khatharr on 01 November 2013 - 01:36 PM

assert is likely to only work in debug builds though.

 

I don't think division by zero is a release-minded feature. YMMV biggrin.png

 

If you're one of them as sets your debug builds to be super-similar to your release builds, then you're already digging in the options, so you can just leave asserts enabled. honestly, though, a breakpoint is the better option.




#5106053 Looking for a good engine.

Posted by Khatharr on 31 October 2013 - 02:44 PM

An explanation of why you've received downvotes:

 

Your topic title makes a demand rather than describing your question, and the content of your post comes off as being abrasive. If you want people to help you, you'll have better luck just asking your question and thanking people for their time.

 

Specifically, saying things like this does not add to the value of your post, but has a good chance of turning away people who would otherwise gladly give you helpful information:

 


So please read my question carefully and then please answer me if you are an experienced user.

 

A good title for this question would be something like, "Looking for a good engine". Then in the post body you can describe your problem. Telling people to 'read carefully' or to only answer if they are an 'experienced user' is not going to help you a lot.




#5105812 32bit/64bit Woes?

Posted by Khatharr on 30 October 2013 - 05:10 PM

 

 

though, for many developers, there is a mindset that RAM is a nearly boundless free resource.

 
That's why we should have a government run program that abducts budding programmers and forces them to spend a year developing for old console systems.

 

Then they'll start using old console tricks to save memory at the cost of code readability.

Hardware has changed, and with it acceptable use of memory. Budding programmers should learn on today's hardware, with modern and relevant resource considerations.

But it's true enough that no resource is limitless.

 

 

Or possibly they'll start using discretion, planning, and responsibility (and maybe learn about portability) instead of using 800MB of memory to run a calculator. My point is not just that resources are limited. My point is that consuming resources simply because they're available is disrespectful to the end user who had to pay money to buy those resources so that they would have more available. There's no reason (apart from laziness) for a program to consume more than it's using, and it tends to lead to bad design habits, such as the ubiquitous 'load everything now' screen.




#5105570 32bit/64bit Woes?

Posted by Khatharr on 29 October 2013 - 08:50 PM

though, for many developers, there is a mindset that RAM is a nearly boundless free resource.
 

 

That's why we should have a government run program that abducts budding programmers and forces them to spend a year developing for old console systems.




#5105425 32bit/64bit Woes?

Posted by Khatharr on 29 October 2013 - 12:14 PM


basically, in my engine, voxel terrain and audio data were eating lots of RAM (previously, the thing kept running out of address space and crashing, but since has been reduced to a more stable 500-700MB, most of the time).

 

decided to leave out a longer description, but:

voxel terrain can eat lots of RAM (lots of largish 3D arrays of voxels);

to a lesser extent, so can things like PCM audio (at 44.1kHz 16 bit) and compressed video / textures / ...

 

so, while 2-3GB seems like it should be enough for almost anything "reasonable", it isn't too hard to run into the limit and then sit around trying to shave off memory use to keep everything fitting (or within a more reasonable limit).

 

basically, keeping voxel chunks, audio, ... compressed until needed, etc.

 

likewise, a person might need to do things like leave larger video files on disk, and read-in frames individually, rather than just reading the whole video into a memory buffer or put it in an asset pack and bulk-loading it (like one might do for most other asset loading).

 

for example, while a person might bulk-load their textures and animated textures and sound-effects and similar, they would probably not  do so with their cutscenes (which would be left on disk until needed).

 

also, there may be issues with trying to load or work with very-high-res images (ex: 8192 x 8192 or 16384 x 16384), which may have a hard time fitting in RAM (8192 x 8192 is hit or miss, 16384 x 16384 = no).

 

 

That's like venting the oceans into space and then saying, "We ran out of water because 1,400,000,000,000,000,000,000kg isn't as much as you may think."




#5104655 Visual studio 2013 hangs on opening certain projects?!

Posted by Khatharr on 26 October 2013 - 04:36 PM

Well, given that it's an RC you should probably be making noise at Microsoft about it, because you've found a nasty bug. Since you clearly have the power to reproduce the problem at will, you may be able to help them figure out what's actually going wrong, especially if you can use an external debugger to help figure out where it's hanging at.




#5104508 Need Code Translation From Pascal/Delph to C++

Posted by Khatharr on 25 October 2013 - 07:49 PM

Is There any shorter Coding Than  strcpy(customer.name,"Jeremy Smith");

                                                        strcpy(customer.cell,"123456789");

 

-.-

If you want it simpler than that then use a std::string.

Also, when dealing with C-style strings, at least use a safe strcpy function so you don't overflow.

 

I can intialize everything at time of instance, For the short Program than I am writing ( Testing some theories in a short test program )  in which depending upon user input, I would change these entries from 1 set of data to another then maybe back to the first.  All may not change, maybe just customer.cell ?

 

Has anyone really been far even as decided to use even go want to do look more like?




#5104116 How can I gain a deeper understanding of C/C++?

Posted by Khatharr on 24 October 2013 - 09:16 AM

Some of the advices might be true here. But if you really want to understand how programming and computers really work together, you should learn Assembly language, at first you might be scared of it, because a lot people think it's the holy grail of programming languages, and they think that only best of the best can learn it.

 

Ah, yep. Saw the title, read the post, scrolled down and someone beat me to it.

 

If you want a deep understanding of what's going on under the hood, then take the hood off. Learn assembly and start using the disassembly view in your debugger to see what your compiler does in order to implement things. It's fun, it's hands-on, and it will change the way you look at the code you write.




#5103373 Will it be C++ the preferred game dev language in 3 years from now?

Posted by Khatharr on 22 October 2013 - 07:23 AM

I'd like to see a complete rehash of C++ into a new language, honestly. I appreciate the work that's being done by the committee, but making a clean break and starting over would give us an opportunity to ditch a lot of the old baggage and get some much nicer means without sacrificing the ends.




#5102971 Practical help on making a simple bullet hell

Posted by Khatharr on 20 October 2013 - 05:35 PM

You'll probably want to make a 'schedule' file for each stage, which the program will load and then proceed through in order to play the stage events at their correct times. For instance, a stage file can start with information about what music to play, what the background is, what enemies are present (so you can start caching resources), etc. You load that information from the file, then start a timer. The rest of the file will have simple commands (at the 30 second mark, spawn enemy type E at position X,Y - or things like that). Make sure those are all in chronological order, then as the stage plays it can just check to see if it's reached the time of the next command, and if so it executes it and moves to the next one.

 

As for 'controlling' bullets and such, that's usually simple deterministic AI. Just make an abstract Bullet class and then derive each bullet type from that. give each bullet type its own logic, and update each of them every frame.




#5102311 The Copy&Swap Idiom

Posted by Khatharr on 17 October 2013 - 11:03 PM

Is this not how it's done traditionally? Or am I missing something?


'traditional' isn't a technical term, but in this context it would mean 'plainly wrong and rather straw-mannish'. Of course you can get leakage if you do it that way. You're using raw pointers for resource control. That doesn't mean that C&S is the only alternative. Doing it right is another alternative, as I showed in the block after that.

C&S collects the copying behavior and then adopts it in a single transaction. That's the correct pattern, but C&S is not the only way to implement that pattern, and it can be unclear, make the machine do more work than it needs to, and/or trigger side-effects.

Using smart pointers or other RAII implementors allows you to prepare the new state, and then once everything is created successfully you adopt it. That's the 'normal' way of writing exception safe code. C&S is just a trick for doing that by invoking the copy ctor and then adopting it only if construction succeeds.

 

It does not magically guarantee exception safety.
 

Your code here is NOT exception safe!

    // copy constructor
    Player( const Player& that ) : m_Texture( new Texture(*that.m_Texture) ),
                                                  m_Sprite( new Sprite(*that.m_Texture) ),
                                                  m_Health( new m_HealthController(*that.m_Health) )

    {
    }

What if the allocation for m_Health fails? m_Texture and m_Sprite have already been allocated! How will you reach them in order to release them, since the object failed construction?




#5102087 The Copy&Swap Idiom

Posted by Khatharr on 17 October 2013 - 03:54 AM

 


I get the idea of copy and swap, but you're really just offloading the work to the copy ctor, aren't you? You could just as easily write the code into the assignment operator and then write the copy ctor to just call the assignment operator. If you're copying resources then you have to write the explicit copy behaviors somewhere.
  • The Big Rule Of 3 states: If you need either a copy-constructor, destructor, or overload the assignment operator, you will need all 3. http://en.wikipedia.org/wiki/Rule_of_three_%28C++_programming%29 This is always the case if your class manually manages resources (e.g. uses 'new' for its member variables).
    It is good practice to have a swap method for such classes in addition to all of that (the "3 and a half rule", some people call it). So with all of this in place, it is usually easier to write a copy&swap implementation and offloading the workload to the copy constructor rather than duplicating your copying code.
  • A copy-constructor's initialisation list will execute noticably faster than manually assigning values. http://stackoverflow.com/questions/13894415/c-creating-objects-initialization-lists-vs-assignment
  • When using copy & swap, no needless self-assignment checks have to be performed ( if( &cp == this ) return *this; )
  • copy & swap is guaranteed to be exception safe.

The bottom line is: There are more pro's than con's for a copy&swap over the traditional method.

 

-.-

 

Look, if you're talking Ro3 then you have at least one member that won't copy correctly on its own. That means that you're going to be specifying explicit behavior somewhere in there, otherwise there's no reason to write the functions. If that behavior is not exception safe, regardless of which method you put it in, then you don't have exception safe code. If it is exception safe then you do have exception safe code. C&S will not change this. When you accept by value in operator=(), you are triggering the copy ctor. If the copy ctor is not safe then you can have leaks.

 

Initializers can be faster than manual assignment, but you need to bench this before asserting that you're saving the universe through premature optimization here. believe it or not, a comparison for equality is likely to be a little more lightweight than constructing a whole new object in a significant number of scenarios. Additionally, the reason initializers are faster than manual assignments is that manual assignments in a ctor are touching members that have already been instantiated. You're not instantiating new members in operator=(), since they already exist, so manual assignment is not slower.




#5100721 Coud any one explain me the following code "self"

Posted by Khatharr on 11 October 2013 - 11:54 PM

A singleton named manager...

 

Sounds like it should be renamed 'Monotheos'.




#5100386 Unit Testing ftw?

Posted by Khatharr on 10 October 2013 - 07:26 PM

This video killed all of my interest in automated unit testing.






PARTNERS