Jump to content
  • Advertisement


  • Content Count

  • Joined

  • Last visited

Community Reputation

176 Neutral

About schue

  • Rank
  1. The code does not work because you call CreateWindow without initialising the parentwindow there (you set it to NULL). From the docu of createwindow: ---------------------------------------- hWndParent [in] Handle to the parent or owner window of the window being created. To create a child window or an owned window, supply a valid window handle. This parameter is optional for pop-up windows. ----------------------------------------- As you do not supply a valid parent handle, your new window is not a child window. Than look into the documentation of SetParent: ----------------------------------------- An application can use the SetParent function to set the parent window of a pop-up, overlapped, or child window. The new parent window and the child window must belong to the same application. ----------------------------------------- I am not sure what exactly happens, but I guess that without the parentwindow and without the hinstance as well (you set both to NULL) that created window becomes a desktop window and maybe no longer counts as beeing "owned" by your application, thus cannot become one later on. How to resolve the problem? Well, you could i.e. use your applications framewindow as default-parent window and change to the desired parentwindow later on (tested this, works for me).
  2. schue

    odd thing

    Why it compiles? Have a look into the project-properties under c/c++, precompiled headers. If the setting is something like "use precompiled headers" and not "auto generate precompiled headers" than thats why it compiles. If the headers are not auto-generated, than adding/removing include-files will not affekt the precompiled headers, so, as in this case, the removed include-files are still in the precomiled header and are still beeing used. Try to clean-compile or set the header option to auto-generate. Oh, and rtfm...
  3. schue

    Frames per second

    Oh, this is even worse: for (int b = 0; b < texheight/tileheight; b++) { for (int a = 0; a < texwidth/tileheight; a++) { } } What happens here is, that for every single step of the for-loops one division will be calcutated. For the outer loop this is 96 / 16 = 6. The inner are 2144 / 16 = 134. So we come to a total of 804 divisions for every tile you calculate. Yes, you know that these are constants, but the compiler does not know because he can not know. So he das to calculate the value every time again.
  4. schue

    Frames per second

    You use 16 divisions per tile. Try to get rid of these as much as possible, cause divisions still need alot of performance. For example this: x / n; y / n; z / n; is significantly slower than m = 1 / n; x * m; y * m; z * m; because multiplications are in general way faster than divisions. So, especially in the inner loop, avoid divisions at all costs. try to precalculate them out sidethe loop or transfer them into multiplications. ( x / 2 is the same like x * 0.5)
  5. schue

    deleting a pointer

    deleted, the others were faster than me ;)
  6. Original post by beefsteak Quote:Original post by markr - My server does not block. It is single-theaded and non-blocking. I think you are missing the point. Just because your server is single-threaded does not mean that he will execute 100% of the time. At any time the OS could context-switch to another thread and put your server on hold. So measuring the time between two calls of your timer to profile the executing time actually is worthless, because you do not know if the server was running 100% of this time, or maybe only 10% and beeing put to hold for the other 90%. What you really would want to measure is the actual execution-time of the thread.
  7. schue

    Memory fill-up

    Just as a hint, your mainloop should be something like this: while ( SDL_PollEvent(&event) ) { if ( event.type == SDL_QUIT ) { done2 = 1; } if ( event.type == SDL_KEYDOWN ) { if ( event.key.keysym.sym == SDLK_ESCAPE ) { done2 = 1; } } } new_evo_array = evolve_species(evo_array, friends, color_map); DrawScene(screen,new_evo_array); if (stability_control(new_evo_array, evo_array)) break; array_delete( evo_array ); evo_array = new_evo_array; } And the array_delete-function should just do the deletes. btw, your delete-code is wrong. it should be like this: for (int i=0; i<640; i++) delete[] array; delete[] array;
  8. schue

    disabling the send delay on TCP

    Quote:Original post by hplus0603 The delay usually used per socket is on the order of at least 200 milliseconds -- the whole idea behind the option is to send one packet instead of two when the user is typing fast in telnet clients. (Yes, that's why it was invented!) I think this is a (common) misunderstanding of Nagle. It does not delay packets for a fixed amount of time. It works different, though it might look the same on first sight. What Nagle does is not sending small segments (where small means smaller than the MSS) as long as there is an unacknowledged packet outstanding. Lets say you write 10 small packets to your socket. The first will be send right away because there is no outstanding ACK. The second packet however will not be sent until the ACK from the first packet arrives. So the delay is fully dependant on the latency. Basicly Nagle avoids that you send more packets over the network than the other side can process to avoid congestion. The 200ms delay comes from another TCP-feature, the delayed ACK. TCP delays the ACK for up to 200ms, waiting for a data-packet, so it can piggy-pack it on a data-packet. If there is no data-packet within this delay, the ack will be sent without data. This reduces the number of packets on the network. But because Nagle waits for the ACk before sending the next packet, this can be bad at times. Well, at least this is how I understood it ;)
  9. schue

    My code in bugs

    Well... In your ToInt-funktion you allocate memory for your result and return the pointer to it: char* ToInt(char* buf) { char *result; [...] result = (char*)malloc(sizeof(char) * 1024 ); [...] return result; } than in your main-loop you use this function: [...] while(fcounter < 17043983) { ibuffer = ToInt(buffer); [...] } But you do not free this memory. Guess what? you have a really big memory leak here. Actually you try to allocate 17043983 * 1024 bytes, thats a total of about 16GB of memory. No wonder your computer pukes...
  10. maybe this: http://www.tantalon.com/pete/cppopt/appendix.htm#AppendixB_RelativeCosts
  11. char* data = new char[bytesToRead]; char* buffer = 0; buffer = strtok(data,"%"); delete[] data;
  12. Are you using this glCallList() for drawing bitmap fonts? From my experience this will eat up alot performance.
  13. I got a huge performance improvement in my engine when I eliminated all divisions in my time-critical code (well as much as possible) and replaced them by multiplications. Things like normalizing i.e: float len = sqrt(a*a+b*b+c*c); a /= len; b /= len; c /= len; are significantly faster if done that way: float len = 1 / sqrt(...) a *= len; b *= len; c *= len; so search fpr divisions, especially in time-critical code.
  14. schue

    strcpy + opengl combo question..

    hehe, got me. I am getting old :)
  15. schue

    strcpy + opengl combo question..

    Agree to Enigma. I kept the answer to plain C cause the original question was a plain c-function. For educational purpose, here the explanation why it still crashes: >> void zone::printScreen(char bmpFILE[1000], int count); Now how do you call this function? As it still crashes, I assume you call it like so: printScreen("", 0); or printScreen("constant", 0); well whatever. Now, this string is a constant and has an adress of its own. Your declaration of bmpFILE is nothing else but a pointer to an adress-space with 1000 Elements allocated. But when you call the funktion with a constant string, you overwrite the pointer. bmpFILE no longer points to the 1000 allocated bytes but to the "constant"-String adress. Or in other words, the constant string is not copied into your allocated buffer, it replaces it. If you strcat to bmpFILE now, you write into unallocated memory, NOT into your 1000 bytes buffer.
  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!