fmatak

Members
  • Content count

    8
  • Joined

  • Last visited

Community Reputation

536 Good

2 Followers

About fmatak

  • Rank
    Newbie

Personal Information

  • Interests
    Design
    DevOps
    Production
    Programming

Recent Profile Visitors

1984 profile views
  1. Not motivated at all

    biggest motivation kill for me is not knowing what to do next. so i do the same thing: compile same code 100th time, check same results again, see it is still not quite right, browse internet..  and my solution is to make a to do list. which itself is a task that takes a lot of time. if i have a to do list with concrete items in it, which could be completed in preferably 1 coding session, then I feel great and I do great... Otherwise, it is just more internet browsing, checking other peoples games' screen shots and pity myself :)
  2. I should show my progress

    just tried and loved it. very nice.
  3. It is good to see I am not the only one who follows that path. I could not finish mine, yet, but I hope you can finish your project.
  4. Slow down...

    I did it and it seems to be working great. Thanks for your help.
  5. Slow down...

    @ Drigovas Actually I thought the double queue thing before, but then I thought it would be slow to copy everything each time. But what you say makes sense. It could actually be waiting until the text is rendered. I will try this and see what happens. Thanks for the clue.
  6. Slow down...

    Let me explain a bit more details.. There is a text render queue. Script system appends text info to the render queue. Each item in queue has a life time, screen coordinate etc. When it times out, it is removed from the queue. Each frame, the rendering thread, goes over the queue and renders the texts. And if the text's life time is over, it removes it from the queue. So, render thread actually accesses and locks the mutex once per frame. But the scripting thread possibly accesses it multiple times. For testing, I added some Sleep calls to the scripting thread (which was smt like 100 ms execute 100 ms sleep), which eventually caused frame rate to increase. (This is also one of the reasons why I am suspecting the mutex thing) I think, the mutex thing takes some longer time than the actual operation inside it, so it causes both threads loose time waiting the other thread release the mutex. (Unfortunately I did not made a string timing for that yet) To sum up... I think you are right about my design. It seems to be problematic, but I could not come up with something better. Whatever I do, I will need to lock the queue. (apparently, the locked things will eventually increase when I add new things..) Maybe I should change the rendering thread to a read only one, and update it only from a single thread. I do not know. If you have any idea please share with me. Thank you.
  7. Hi All, I am trying to code an engine (as everybody else here) and I have a problem. My engine is supposed to be threaded. One thread is for display & graphics etc. usual tasks and the other thread is (there are exactly 2 threads) for the scripting VM. I have a dual core processor, so supposedly, both threads should be running on their own processor. That is why I am expecting the scripting thread should not drop FPS. When I disable scripting and just go with single thread, I got FPS about 40. When I enable scripting, and go with 2 threads, I get 15 to 20. There are 2 places which might be responsible from this, I think. One is the thread affinity setting used in QueryPerformanceCounter function, (to prevent bugs in dual core systems.. mentioned in some other thread in gamedev) And the other one is the WinAPI mutex thing I am using. (Scripting system can send data to display on screen, so there is some amount of shared data. And I am using it to prevent concurrent access to the data.) So, I commented out the timer call from the scripting thread, so it will not change the thread affinity. But this did not seemed to help. So, I assume the problem is with mutex.. (other ideas are also welcome) So, I decided to write my own mutex. Since I am only trying to sync 2 threads, no interprocess things etc, a very lightweight thing would be enough.. But before beginning on that, I wanted to ask you, which libraries do you use for that and is there any lightweight libraries you can recommend? (I do not use boost, and I am not planning to use it for this project only for mutex) (I also do not use/do not plan to use pthreads or any other threading libraries.) By the way, I am coding in C++. (using OpenGL) Any help/idea/references appreciated..
  8. Maybe you can try shifting the bullet hole towards the middle of the polygon a bit, if it is not completely lying on the surface..
  9. (C++ VC6) File I/O aHEEHEEE

    Here is my 2 cents.. 1. he is trying to do basic FILE I/O, and his code is essentially C code, with cpp extension. So, it should even work on VC 4-5. 2. instead of using open/close, i would prefer fopen/fclose/fwrite. 3. It seems there is a misassumption in the code, which causes the problem. file.Char = new int[32]; file.CharLen = sizeof(file.Char) / sizeof(int); ----- in the above line, sizeof(file.Char) will return 4, which is equal to sizeof( int ), which in turn makes file.CharLen = 1. You should just put 32 there. for(int i=0;i<file.CharLen;++i) file.Char[i] = i; Since charlen is 1, it will only set first element. write(fd,&file.CharLen,sizeof(unsigned short)); this will write 1 to the file. write(fd,file.Char,file.CharLen * sizeof(int)); This will write the first integer to the file. changing the above mentioned part to 32 should fix your problems. (NOTE: I did not test the code, so I may be wrong... )
  10. IMHO, in real life, we do not put infinite negative value on death, since, we come accross suicides or self sacrifice things (maybe a mother for her children etc.) but, the chances we keep taking despite death possibility may not be as high as we think. you are taking a risk of death while crossing a street or driving a car. but what is the % of death? imho quite low. (some things it is higher on plane and do not get on planes) maybe less that 1th in 10 million or less. would you do something which has a higher death possibility? lets say 10%? would you involve a group of 10 people, which one of them be chosen and killed and remaining ones will get lets say 1000$? would you accept this for 1,000,000$ ? some people tends to accept second one. (which i also would give a serious thought) or would you accept if it was not 10 (10%) people but 1000 (0.1%) people or 10,000 (0.001%) people? so, what i am trying to say? 1. death is not infinite. 2. if you mimick real life, your agents will try to make groups to decrease the ratio to an acceptable level. (very low) how to solve it? (maybe use a logarithmic/quadratic ratio calculation so possibility will decrease with less number of agents)
  11. VBO problem

    could it be because you are setting mNOArrayE to 0 when deleting, and using it in glDrawElements call?