Sounds like a good use for threads..
Cheers
Chris
safe to open a file everyframe?
if accessing using file methods seem easier. then create a simple wrapper that acts like a file. you should not store anything beyond log data in a text file or a saved state. if its data you will read back again every frame, its wasteful and slow.
for instance;
its not perfect and dont check all errors, heck it may not even work (did not test the code). using the vector class (isntead of use alloc/realloc) is probably a good idea (handles memory allocation automagically). also if its just the fprintf/fscanf function that you like. use sprintf and sscanf which can be used with memory buffers.
since text files are about 10KB, you can easily allocate that and keep it in memory writing to disk only if the data needs to be kept after the app is closed.
[edited by - a person on July 16, 2002 8:46:41 PM]
for instance;
CMemFile::Open(){ valid = 1; actual_size = START_SIZE; dataSize=0; pos=0; memBuffer = (char*)malloc(START_SIZE); return SUCCESS;}CMemFile::Read(destBuffer, readSize){ int i; for(i=0; i<readSize; i++, pos++) { if(pos<dataSize) destBuffer[i]=memBuffer[pos]; else break; } return i;}CMemFile::Write(sourceBuffer, writeSize){ int i; for(i=0; i<writeSize; i++, pos++) { if(pos>=actualSize) { memBuffer = (char*)realloc(memBuffer, actualSize+START_SIZE); actualSize+=START_SIZE; } destBuffer[i]=memBuffer[pos]; } if(pos>dataSize) dataSize=pos; return i;}CMemFile::Close(){ free(memBuffer);} its not perfect and dont check all errors, heck it may not even work (did not test the code). using the vector class (isntead of use alloc/realloc) is probably a good idea (handles memory allocation automagically). also if its just the fprintf/fscanf function that you like. use sprintf and sscanf which can be used with memory buffers.
since text files are about 10KB, you can easily allocate that and keep it in memory writing to disk only if the data needs to be kept after the app is closed.
[edited by - a person on July 16, 2002 8:46:41 PM]
If you''re accessing the file every frame keep and you decide to keep the file open throughout, keep in mind that if your program crashes your file will not be saved, i.e. if you don''t call fclose() on the file then you''re screwed. I''m pretty sure flushing the outstream won''t help you there. So, if you''re using the file to keep track of any debugging stuff or anything volatile or important that needs to be saved, regardless of a crash or not you''ve got to open and close whenever you update the file. I don''t think you have to fclose() if you opened the file for reading only.
Other than that you might want to give some more info on what it is you''re trying to do.
------------
- outRider -
Other than that you might want to give some more info on what it is you''re trying to do.
------------
- outRider -
fflush() sends data in the io buffer to the disk and thus if the app crashes, all data prior to the crash and before the last fflush() call will be on the disk. though calling fflush slows things down since it forces a physical write to the disk even if you only have a few bytes in the IO buffer.
input boxes dont need to be handled as you say, a string object (see STL), vector object (again STL) or just a straight up array with a limit is fine. NO chat app has no input limit. in fact you want to limit chat input since if someone decides to send their life story they could clog everyone else and flood things easily. most apps tend to put the limit at 1024 bytes since most messages and ideas somone types fits into that nicly. longer ideas can be split between messages (ie fill the buffer to 1024, send it, then repeat).
input boxes dont need to be handled as you say, a string object (see STL), vector object (again STL) or just a straight up array with a limit is fine. NO chat app has no input limit. in fact you want to limit chat input since if someone decides to send their life story they could clog everyone else and flood things easily. most apps tend to put the limit at 1024 bytes since most messages and ideas somone types fits into that nicly. longer ideas can be split between messages (ie fill the buffer to 1024, send it, then repeat).
Author
This was a hypothetical question originally, because I was really curious... And THANK YOU to everyone so far who has provided input.
outRider is correct, because this happens more than once. I have a log file that I access throughout major functions in the loading process of my game. The main function called is engine.Create(), which in turn calls world.create(), console.create(), player.create(), etc...
Basically, I wanted to start off my world.create() function like so:
Someone told me that that is bad coding... Now, there''s nothing wrong with the code... Even if I purposly return false in one of the called functions, it still runs fine...
lol and I realize that I should''ve posted some more information regarding my situation.. Sorry.
But originally my friend (who just converted from PHP... Which isn''t really relevant, so I''ll continue) thought of a chat system in which the game could give you messages based upon what you do (this could be from anything like walking into a new room to jumping up and down)... THe main loop would look something like this:
1. Game sends you a message by writing it to a file (optional)
2. Check the message file
3. Process the messages (put them on screen)
4. loop
But now that I think of it, I think I _should_ just tell him that he should just use virtual memory.
~Jesse
outRider is correct, because this happens more than once. I have a log file that I access throughout major functions in the loading process of my game. The main function called is engine.Create(), which in turn calls world.create(), console.create(), player.create(), etc...
Basically, I wanted to start off my world.create() function like so:
int CWorld::Create(){ Log_Open(); if(player.create() == false) { Log_Post("Creating player... [ FAILED ]"); Log_Close(); engine.suicide(EXIT_CODE_2); } else Log_Post("Creating player... [ OK ]"); if(console.create() == false) { Log_Post("Creating console... [ FAILED ]"); Log_Close(); engine.suicide(EXIT_CODE_3); } else Log_Post("Creating console... [ OK ]");... Log_Close();} Someone told me that that is bad coding... Now, there''s nothing wrong with the code... Even if I purposly return false in one of the called functions, it still runs fine...
lol and I realize that I should''ve posted some more information regarding my situation.. Sorry.
But originally my friend (who just converted from PHP... Which isn''t really relevant, so I''ll continue) thought of a chat system in which the game could give you messages based upon what you do (this could be from anything like walking into a new room to jumping up and down)... THe main loop would look something like this:
1. Game sends you a message by writing it to a file (optional)
2. Check the message file
3. Process the messages (put them on screen)
4. loop
But now that I think of it, I think I _should_ just tell him that he should just use virtual memory.
~Jesse
What you want is an event handling system, and doing that based on files is a very very bad idea. Even if the two functions communicating are in seperate EXEs, this is a very bad idea.
Create a common event manager (look at Java for a good example of how to design this). Any messages generated by a sub-system is added to the event manager (as a linked list, probably), and every frame the different sub-functions can call the event-manager to check what new events are available, and process them..
For things like logging debugging information, etc, fflush() should work fine.
Allan
Create a common event manager (look at Java for a good example of how to design this). Any messages generated by a sub-system is added to the event manager (as a linked list, probably), and every frame the different sub-functions can call the event-manager to check what new events are available, and process them..
For things like logging debugging information, etc, fflush() should work fine.
Allan
You could also create a callback function that is caled every time there is a message. This way you don''t have to do any polling.
---
Make it work.
Make it fast.
"I’m happy to share what I can, because I’m in it for the love of programming. The Ferraris are just gravy, honest!" --John Carmack: Forward to Graphics Programming Black Book
---
Make it work.
Make it fast.
"I’m happy to share what I can, because I’m in it for the love of programming. The Ferraris are just gravy, honest!" --John Carmack: Forward to Graphics Programming Black Book
*reads over responses*
*glances at code*
*watches files open/close several times a frame, 800 frames a second*
Errr, well... it''s an 80GB harddrive, it can take a beating. Love is supposed to be painful
------------
aud.vze.com - The Audacious Engine <-- It''s not much, yet. But it''s mine... my own... my preciousssss...
MSN: nmaster42@hotmail.com, AIM: LockePick42, ICQ: 74128155
*glances at code*
*watches files open/close several times a frame, 800 frames a second*
Errr, well... it''s an 80GB harddrive, it can take a beating. Love is supposed to be painful
------------
aud.vze.com - The Audacious Engine <-- It''s not much, yet. But it''s mine... my own... my preciousssss...
MSN: nmaster42@hotmail.com, AIM: LockePick42, ICQ: 74128155
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
