Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[ZCM]

4Kb is the magic number on Windows for the smallest allocatable block, of which some bytes are reserved for OS data.  Then your language memory manager splits that up and reserves a few more bytes with each chunk for its data.

Correction: Windows doesn't reserve any memory in the allocated block. If it did, you'd be able to overwrite that memory and screw up Windows, and that would be Bad.

Whether the language memory manager reserves bytes in the block itself depends on the memory manager. That doesn't really matter, though, since there's no guarantee your memory manager will give you a page-aligned block in the first place. (It probably won't.)

[devek]

You are 100% correct that 36x36 would be better.

The only problem is that an embark region is 48x48... not sure how well it would work with map tiles crosses embark boundaries. It might work, idk. That is why I picked 48x48.

And what ZCM said, it is all on the heap anyway.

[Thief^]

And 16x16 is 256 tiles. This could be a magic number in the code elsewhere, as it means each tile inside a section could be addressed with a single byte...

[Veroule]

4Kb is the magic number on Windows for the smallest allocatable block, of which some bytes are reserved for OS data.  Then your language memory manager splits that up and reserves a few more bytes with each chunk for its data.

Correction: Windows doesn't reserve any memory in the allocated block. If it did, you'd be able to overwrite that memory and screw up Windows, and that would be Bad.

Read the Windows API entry for PROCESS_HEAP_ENTRY.  If it doesn't become apparent from that then do some testing with HeapWalk, LocalAlloc, and
GlobalAlloc.  You will find that for small blocks the PROCESS_HEAP_ENTRY structure is at the start of the allocated memory and the pointer for first useable address is right after that.

Whether the language memory manager reserves bytes in the block itself depends on the memory manager. That doesn't really matter, though, since there's no guarantee your memory manager will give you a page-aligned block in the first place. (It probably won't.)

There are no guarantees when you use someone elses memory manager, however the standard ones tend to use the same design.  Getting page alignment isn't so much the priority as making each portion a readily prefecthable group.  Keeping the memory overhead down is a bonus, but isn't totally achieved unless you do the entire allocation for all the map blocks as a single group.
Thief^, very true.  For the purposes of a 2 stage pathing method larger abstract blocks tend to be better.  The exact size that is best is something around the square root of the total area.