Reply to Re: Say Goodbye Seq/Frame
If you don't have an account, just leave the password field blank.
Let's piece this bit by bit...
Well, there is the obvious question of what happend when there are too many images in one pak file, but then again, if you have 65535 frames in a single sequence, well, there either is a problem, or there will be a problem. Now, since there is a limit to how many images can go into a pak file, why not limit the slot variable to a xxxx variable instead of a xxxxxxxx variable?
Where did I say there was a limit? There is no limit (aside from the theoretical limit of 2^32 on 32-bit machines).
Would that make much difference in the performance anyway?
Yes. Definitely. See, if I limited it to xxxx (maximum 9999) I would have to create 9999 * who-knows-how many bytes (let's say 50) because I would have to use a C Array. So, there's 500 KB allocated on the stack. With my current method using a C++ Vector you only allocate what you need. So, say you only need 7 of those 9999 slots. That's only 300 bytes, ~499.5 KB of wasted space. Not to mention that the entire 9999 slots would need to be iterated through each time instead of just the seven.
So, not having a limit is much more beneficial.
Also, I think you mean that the slot variable can't exceed 4294967295, cause, er, you didn't count zero.
Yes.
Also, a pressing question, how do hardboxes fall in line with all this? Is there gonna be a certian couple bytes at the start of the wpak file letting the engine know that the file contains hardbox-images, background-images, music-files, etc?
No. That would be wasting 4 bytes of memory. All you would need to do is use the appropriate DinkC++ command in the appropriate library and you essentially tell the engine what is in the file.
...Or am I completely off tangent, and dink either already does this, or there are not even gonna be hardboxs in Windemere?
There will not be hardboxes in Windemere. There will be hard maps, though. They will be integrated into the map file. Or are you referring to the same thing?
Well, there is the obvious question of what happend when there are too many images in one pak file, but then again, if you have 65535 frames in a single sequence, well, there either is a problem, or there will be a problem. Now, since there is a limit to how many images can go into a pak file, why not limit the slot variable to a xxxx variable instead of a xxxxxxxx variable?
Where did I say there was a limit? There is no limit (aside from the theoretical limit of 2^32 on 32-bit machines).
Would that make much difference in the performance anyway?
Yes. Definitely. See, if I limited it to xxxx (maximum 9999) I would have to create 9999 * who-knows-how many bytes (let's say 50) because I would have to use a C Array. So, there's 500 KB allocated on the stack. With my current method using a C++ Vector you only allocate what you need. So, say you only need 7 of those 9999 slots. That's only 300 bytes, ~499.5 KB of wasted space. Not to mention that the entire 9999 slots would need to be iterated through each time instead of just the seven.
So, not having a limit is much more beneficial.
Also, I think you mean that the slot variable can't exceed 4294967295, cause, er, you didn't count zero.
Yes.
Also, a pressing question, how do hardboxes fall in line with all this? Is there gonna be a certian couple bytes at the start of the wpak file letting the engine know that the file contains hardbox-images, background-images, music-files, etc?
No. That would be wasting 4 bytes of memory. All you would need to do is use the appropriate DinkC++ command in the appropriate library and you essentially tell the engine what is in the file.
...Or am I completely off tangent, and dink either already does this, or there are not even gonna be hardboxs in Windemere?
There will not be hardboxes in Windemere. There will be hard maps, though. They will be integrated into the map file. Or are you referring to the same thing?
