Relationship of Handle to Memory
Blitz3D Forums/Blitz3D Programming/Relationship of Handle to Memory
| ||
| Do entity Handles correspond to memory addresses? If so, then it should be possible to modify entities in some way by 'Poke'-ing at a certain offset from the Handle address (?) , the precise details of what to Poke and the effect it has would no doubt vary due to the entity type, but I'm curious as to the possiblity at least. Might this be faster than, say, Read/WritePixel fast for images? |
| ||
| Yes, I believe that it does. In these threads, there might me more info on it: http://www.blitzmax.com/Community/posts.php?topic=66397 http://www.blitzmax.com/Community/posts.php?topic=57663 A search on RTLMoveMemory on the site should also help: http://www.google.com/search?hl=en&q=rtlmovememory+site%3Ablitzbasic.com&aq=f&oq=&aqi= |
| ||
| i saw people doing this kind of thing's. with the api functions RtlMoveMemory(), using the blitz entity as address and knowing the Structure of the Data, with the coorect offset you point to any variable on it. as an example the Blits3D+ uses that to get the attributes returned by its's functions and the XUserLib (XWorld) has an extension that does the same with the kernel32 lib. in the case of an image i think is the same but i don't know how blitz stores them. by the way, once i saw that mikayl (fast extensions) has in his page tables with the structs of blitz (he give the link in one post almost) edit: warner: you were answer at the time i was doing the same so we talk about rtlmemory twice! Juan |
| ||
| Seems a bit more techy than I first thought, but thanks for the replies. I've been working with the MP3 tag reader thingy in the codearchives which appears to use the RtlMoveMemory after copying the mop3 file info into a bank, so that helps me see how it's used. ne thing I do know, is that Blitz must store certain media, (Images, sound to name two) according to their Load**** in a 'standard' way, because you can effectively change the file extension from, say, a WAV to an MP3 and blitz will still play it fine, or a JPG to PNG and it will operate the same as a texture/image/sprite. Fonts (well, they're weird anyway) and Meshes, however don't follow this method. Changing a .x to a .b3d extension (I'm talking about just changing the file extension name, not actually converting), for example, will cause the mesh load to fail. So, I guess, internally, for meshes, Blitz does some checking on the extension to decide HOW it should process the file, but with sound or images, it locates the actual header details once the file is in memory, regardless of what exctension it had/has. You can even change .bmp to .mp3 if you wish to experiment, and it will still load in fine as an image/sprite/texture etc. but of course, will not be valid if ttried with LoadSound. |
| ||
| I suppose that could have something to do with that Blitz3D uses other libraries inside. For images, I believe it was FreeImage. For sound, I don't know. |
| ||
| for sound, its freesound. |
| ||
| Ah, FreeImage .. FreeSound .. that figures :) |
| ||
| indeed ^^ |
| ||
| FMOD. |
| ||
| imphenzia :P |
   |