Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 30 Dec 2000
Offline Last Active Jul 28 2016 11:47 AM

#5221519 Looking for step my step guide for visual studio

Posted by nobodynews on 05 April 2015 - 03:56 PM

I'm curious: what features do you need that none of the engines you looked at provide? If you don't feel like getting into it that's fine, but it might help people give you some more specific suggestions or to explain why a particular engine does in fact do what you want.


If you must do it yourself using C# look into MonoGame. MonoGame is a pretty popular library based on a thing Microsoft made called XNA which, while still usable, hasn't been updated in forever. You can find tutorials on the MonoGame website and also from google (having a specific technology you want to learn is easier to search for on google).


As always, start slow. Make very simple games at first (I'm talking solitaire, hangman, pong simple) and gradually increase the complexity of your projects until you feel you can handle your ultimate goal.

#5221352 Anyone got any ideas where 4k a sec is coming from?

Posted by nobodynews on 04 April 2015 - 11:27 AM

Is there a question you have? You should be asking yourself "why aren't I using the standard library linked list which doesn't have any bugs in it?" If you really want to make your own linked list we can't stop you of course, but you seem to be making your life harder than it has to be.

#5221118 trouble parsing quake3 md3

Posted by nobodynews on 03 April 2015 - 09:23 AM

You're actually looking at it the wrong way. Both IDENT and VERSION are displaying wrong. This is an endian-ness issue. According to the md3 spec, IDENT is assigned the unsigned little-endian number 860898377 (0x33504449). If you were on a little-endian computer it would have displayed 3PDI when treated as a 32-bit number, because that's actually what the MD3 specifies it as on a little-endian machine. It would only display as IDP3 on a little endian machine if they read it one byte at a time and you converted it one byte at a time.


Since you're on a big-endian computer you need to convert all little-endian numbers to big-endian first. When you convert 0x49445033 to little-endian it will display (correctly) as 3PDI. Or you could treat the IDENT as 4 'octets' and read it 1 byte at a time.

#5219815 How do you motivate yourself for game design?

Posted by nobodynews on 28 March 2015 - 08:42 AM

“Don’t judge a book by its cover.” This is nice, but it conflicts with, “First impressions are the most important.”

The former is a good personal motto to use so you get to know the real person and give them some benefit of the doubt in case their having an off day. The latter is about recognizing that some people don't have the time or luxury to do that with everyone they meet so you have to game the system somewhat. And there's often value in telling people how they're coming across especially if that person is seeking advice.


That said, I mostly agree with your points, unless the OP thinks they have an underlying mental condition that is keeping them less motivated than they would be if they were otherwise healthy. If someone has depression there might not be anything motivating enough to get them to take action. And some people are in situations which are soul-sucking enough that it infects other parts of their lives.


OP, if you think you may be suffering from depression don't feel bad for looking into it and seeing if that's what's going on with you. However, if you're simply just not that into game design then there's no shame in recognizing that and changing direction to something that does motivate you. Good luck!

#5218817 c++ count lines in txt file and then read these lines without reopening a file

Posted by nobodynews on 24 March 2015 - 10:30 AM

i know i know but i wanted that everybody willl understand why i dont want to use it. i found it really slow loading 'big' model files.

You said you don't want to use vector because when loading big model files you found it slow. The implication given the topic being that your models were text files, because why else bring up an unrelated topic? Loading text and binary are different processes most of the time. It's like complaining about not liking the beach and we asked why and you said it was because one time someone threw dirt in your face and the beach has sand which is like dirt. Even if dirt and sand are similar the problem isn't the dirt/sand it's the person that threw the dirt in your face.


In this case, if you found std::vector slow when loading a big file then it was because of how you were using std::vector not because of std::vector being inherently slow. Learn how to use std::vector properly and your issue will go away.

#5213452 Real time multi-key input handling in console?

Posted by nobodynews on 27 February 2015 - 10:08 PM

(MS-DOS, right?)

Not really

#5209098 Does games that were writen in "c" will be processed faster then...

Posted by nobodynews on 06 February 2015 - 11:50 AM

Here's some harsh info: if you haven't released a game you don't have end users. Basically, the best languages are the ones you know because knowing the language helps you finish games and finishing games gives you end users.


Given it's possible to write slow code in C and it's possible to write fast code in C++ (and vice versa) I say you're better off not worrying about small speed differences (which mostly come down to programmer skill) and instead pick the more productive language. If you don't actually know either language then between the two I'd pick C++ because I think most people will be more productive in C++ because of its standard library. If you include other languages then I'd suggest C# or Python to start with.

#5208902 3D video game in C++ with OpenGL and DirectX 10

Posted by nobodynews on 05 February 2015 - 10:45 AM

Uh, I'd suggest Community Edition over the Express editions.

#5207213 Encapsulation through anonymous namespaces

Posted by nobodynews on 28 January 2015 - 11:57 AM

Weird. I think this stackoverflow question discusses this. The response says that when ~Instance() is defined inline it 'might cause problems'. Try moving the destructor definition outside of class Instance.

#5203337 About computer instruction in relation to RAM consumption

Posted by nobodynews on 10 January 2015 - 03:19 PM

As Alvaro said you should read up on how computers work. But here goes.


1. Theoretically I'm sure someone could make a CPU that gets instructions from a HDD instead of RAM, but in that case the CPU would just be treating the HDD as very slow RAM. You may be thinking that the program should be separate from the data instead of treated as data. This is actually done in some architectures, mostly for microcontrollers where there will only ever be one program and no OS. In this case the entire program would be stored in Flash (often set to read-only after the program is loaded) and the CPU would treat Flash as being from memory address 0xEFFF to 0xFFFF. and RAM from 0x0000 to 0x1000, and IO and configuration registers from 0x1000 to 0x1100 (all values made up and not based on any particular architecture).


2. There really isn't a relationship between size of an instruction and time to execute it, especially with modern processors which do very complicated things with reordering instructions anyway. There might be benefit to smaller instructions so there are fewer cache misses if the code itself takes up less RAM.


3. Adding something to the stack takes up stack RAM, but the RAM used by the stack is dedicated to the stack, usually at a preallocated size. Your program isn't supposed to ever use the RAM allocated to the stack except when used as the stack. So even if your program pops the data from the stack your program still won't use it as generic RAM. There are likely ways to change your program's stack size at the linkage stage. For example, read this MSDN article for the MSVC++ way to do this.


4. RAM is always a potential issue. RAM is probably not the first place most people will look when worrying about speed, but it is potentially something that could help. Sometimes using more RAM will make things faster (by using an algorithm which needs more RAM) sometimes using less will help (perhaps if you get more cache misses because of too much RAM being used).


5. Bottlenecks can be processor related or GPU related or bandwidth related or RAM related. They all play their parts depending on what you're doing and the system the code is running on.


6. I think you're blatantly misunderstanding this. A millisecond is more than a nanosecond. You're confusing speed (a rate) with time to accomplish something. If I can run a mile in 4 minutes that's the same as saying I can run a mile at 15MPH which is faster than someone who can run a mile in 6 minutes or 10 MPH. Lower time, faster rate.


7. It could be that your program is very efficient or very inefficient. Since we don't know what it's doing or even what kind of processor it is we can't possibly guess. If you made a basic clone of Super Mario Bros from the NES with the same resolution and type of pixel art and it was taking up 100MB and used 14% of a modern CPU that might be a sign your code isn't very efficient. If your 'clone' used much higher resolution sprites with 3d effects, more enemies, larger maps, and more eye candy then 100MB and 14% CPU might be decent. We can't know given the information you gave.

#5202914 Next Logical Step...

Posted by nobodynews on 08 January 2015 - 02:33 PM

Even more important, how do you know that trick will actually be faster than using an intermediate variable? It's bad to assume you actually know what's better than the compiler because in a lot of cases you don't, in fact, know better.

#5200827 Pressure equation (gravity force at lattitude 45*degs) <- what does that...

Posted by nobodynews on 30 December 2014 - 10:36 AM

The equation to determine gravity at a given latitude is supposedly:



However, i also checked the actual US Standard Atmosphere 1976 document (available here) and on the pdf page 19 they describe the value of g0 chosen for use in that equation.


Of course these are all estimates anyway, so unless you care about < 1% error it probably doesn't matter much.

#5198357 C++ Number guessing

Posted by nobodynews on 15 December 2014 - 11:27 AM

Other suggestions going forward:


1. put system("cls") in its own function named something like clearScreen. That way it's not only self-documenting, but it allows you to change how you clear the screen in the future.


2. You mean "lose" not "loose". And "your" not "tour" Minor gripes, but it's always good to strive for polished language.


3. Speaking of self-documenting, some of your comments are too obvious. If you have a function named displayMenu then having a comment saying to display the menu to the user isn't too helpful. Since displayMenu only does one thing the function name provides enough information that having a comment is unnecessary.


4. Like you did with getting the menu selection, why not do the same with getting a guess?


5. This isn't very important right now either, but there's an issue with the distribution of your random number. Let's say for the sake of argument that rand gives you a number between 0 and 149. If that happens then your rand()%100 will mean numbers between 0 and 49 will occur twice as often as numbers between 50 and 99. In reality the probability of each number occurring for you will be more even than that, but it won't be as even as it could be. The generic code using rand() to generate an integer range between min and max is:


int(((double) rand() / (RAND_MAX+1)) * (max-min+1) + min)


What this does is convert the original rand() integer to a double, then scales the range from 0 to RAND_MAX to 0 and 1. RAND_MAX is a constant supplied by the compiler containing the largest random number it will give you. Next, this floating point range is scaled back up to an integer range with a spread between min and max, in your case you'll get numbers 0 thru 99, inclusive (inclusive meaning both 0 and 99 are included). Then the spread is offset by the minimum range you want, in this case 1, to get the range 1 to 100, inclusive.


So in your case it would be:

int randomNumber = int(((double) rand() / (RAND_MAX+1)) * (100) + 1);


Although you might want to make the generic version into a function for the sake of re-usability. Then you could call, for example, randomRange(1, 100) or randomRange(-10, 10). If you changed the variable types of min and max to be doubles instead of integers you could even do randomRange(0.1, 0.5).

#5198250 VERY weird error. Structs in std::vector being updated more than once

Posted by nobodynews on 15 December 2014 - 12:28 AM

        for(unsigned int iterator = 0;
            iterator < currentSize;
            particleList[iterator].lifeTime -= 1.0f;
            if(particleList[iterator].lifeTime <= 0.0f)
                std::swap(particleList[iterator], particleList[particleList.size() - 1]);

            particleList[iterator].y += 0.01f;

            currentSize = particleList.size();

You should consider using your debugger and stepping through the code. I think I have a handle on what might be going on though. First, let's say you have particleList[0].lifeTime == 1.0f and then you enter this loop. iterator is 0 so particleList[0].lifeTime will decrement to lifeTime 0.0f so you swap and pop the element then decrement interator to -1. Then you access particleList[-1].y which doesn't exist so who knows what your program will do if it tries to access that memory.


Now, I also think this bug is causing your issues with the weird multiple increases. If particleList[0].lifeTime == 2.0f and particleList[1].lifeTime == 1.0f then at the start of the loop when iterator == 0, particleList[0] will remain in the list and particleList[0].y will increment by 0.01f. iterator will increment to 1. So next particleList[1] will be swapped and deleted because its lifetime reaches 0. When this happens, iterator is set to 0 and particleList[0].y will increment by 0.01f again for 0.02f total.


So, exercise for the reader: solve this bug!

#5198149 Order of winapi functions at compile time and runtime, and message loop

Posted by nobodynews on 14 December 2014 - 11:53 AM

Basically everything you described is run-time behavior, either initialization or normal program execution. If you want to know more about the difference between 'compile time' and 'run time' this stack overflow discussion might be informative.


(In fact there is no way for me to intact with it except a close, minimise, or resize)

You can also move your mouse around the window as well as in-and-out of the window. You can gain or lose focus of the window. And more that I'm not even thinking of. Of course what is really happening is Windows is interacting with your application, not you the user. The user interacts with Windows and Windows decides what to send to the program to handle and most of the time the program just says "ok Windows, I heard you. Now you take care of this message for me." That's what DefWindowProc is for. Of course, being the OS, Windows cares about more than the user so there were more messages than you thought. particularly during initialization. This link purports to list Windows messages and what the messages map to; it seems pretty accurate. So, based on your list of message numbers I found the corresponding message name and linked to MSDN so you can quickly reference the documentation on what the message is for:


uMsg = 36 -> WM_GETMINMAXINFO (addendum)

uMsg = 129 -> WM_NCCREATE

uMsg = 131 -> WM_NCCALCSIZE

uMsg = 1 -> WM_CREATE

uMsg = 24 -> WM_SHOWWINDOW




uMsg = 134 -> WM_NCACTIVATE

uMsg = 127 -> WM_GETICON

uMsg = 127 -> WM_GETICON

uMsg = 127 -> WM_GETICON

uMsg = 6 -> WM_ACTIVATE


uMsg = 642 -> WM_IME_NOTIFY

uMsg = 7 -> WM_SETFOCUS

uMsg = 133 -> WM_NCPAINT

uMsg = 20 -> WM_ERASEBKGND


uMsg = 5 -> WM_SIZE

uMsg = 3 -> WM_MOVE


As I said, most of the time you just want Windows to handle these for you.