DRM wrappers and BlitzMax crashing.
BlitzMax Forums/BlitzMax Programming/DRM wrappers and BlitzMax crashing.
| ||
| I'm trying to get my game to a survey group through a publisher. When the publisher wraps it, it crashes. They have tried both ActiveMARK and Yummy. I also use MoleBox to pack the data files. Does anyone have any idea how to do this? Is it problems with MoleBox or the way I'm using it (default pack for the exe and a 'resources.dat' pack for the data files). Is it something with BlitzMax? I have seen forum chats about this problem, but nowhere is there posted any sort of solution or a proper procedure (settings, how to best pack, best tools, etc.). |
| ||
| You probably won't be able to use Molebox. It self-references and that's the number one thing DRM wrappers don't like you to do. |
| ||
| Thanks, Gabriel, but this leaves me in the same spot. I need to know what exactly to do to fix the problem. Is there a wrapper that works, and are there any special settings/procedures and such? Thanks again Gabriel! |
| ||
| In particular, I'd like to find a solution that works with Trymedia's ActiveMARK. |
| ||
| Can't you just not use Molebox to see if the problem goes away? |
| ||
| ...but I need to pack the data files somehow ;) |
| ||
| Do you really need to pack them, or can't you just put them in a data directory? |
| ||
| ...and, hopefully, the way (proven) other games have made it to market already. |
| ||
| I wish that was possible, but the data files need to be packed. |
| ||
| Why? |
| ||
| For securing the data. |
| ||
| What data, exactly? Sounds and images? |
| ||
| Yes, sir, sounds, images, and some text files. |
| ||
| Can't you just incbin them instead? I'm also surprised the DRM software doesn't pack everything up neatly anyway... |
| ||
| Yes, sir, sounds, images, and some text files. Why do you need to secure them? Are expecting your work is really that important that someone is going to target your game and steal its content? Nevermind that the content is most likely very specific to your game and would require significant modification to be otherwise.I think you're wasting your time, you really don't need to secure these files. |
| ||
| Brucey: Evidently the DRM does not do this. I would have thought so also. This is my first launch, as a one-man studio. I've done many other AAA titles, but this is the casual audience. Doesn't IncBin create a huge exe and memory footprint? I mean, all the data is loaded into memory when the game loads, rather than read files as they are needed. Nilium: The portals want this, as well, so there isn't huge directories and such for casual gamers. |
| ||
| Also, I have nearly 2000 PNG files that have their names stored in text files. So doing the initial IncBin referencing will be a nightmare. It's a hidden objects game, btw. I have a guy at Teggo looking into this, but I'd rather find a BlitzMax solution, I guess, so it's all self-contained. |
| ||
| Put your data in an archive and read it out of the archive? The whole security bit is a waste of time, so think less about that and more about how you can easily read your data without any other problems. Doesn't IncBin create a huge exe and memory footprint? I mean, all the data is loaded into memory when the game loads, rather than read files as they are needed. It's not going to be any bigger a binary than your game would be if it were packaged differently. As for memory footprint, that's almost entirely irrelevant unless you're packing more than, say, 64mb of content into the executable. Also, I have nearly 2000 PNG files that have their names stored in text files. So doing the initial IncBin referencing will be a nightmare. Really can't possibly be that hard. Find/replace (")([^"]+?\.(?i:png|jpg|tga|etc)") with $1incbin::$2 would probably catch most cases. Getting all the Incbin declarations in place is also a piece of cake. |
| ||
| It's over 100mb of data ;( |
| ||
| See the first suggestion. If you can't think of any other alternatives, I'd say you're hosed unless the folks who work on the DRM software know how to fix the issue. |
| ||
| Well, you can always create yourself a little file format of your own - and encrypt it, if need be. The file might have a header, and a body. The header stores : 1) number of files 2) for each file, offset and size the body stores: 1) each file, one after the other. The write yourself a custom TStream. Have one method to retrieve the header, and another to retrieve a specific file from the body. Of course, if you can get it to read multiple files from the body in sequence, it'll read them more efficiently... If you decide to encrypt the file, you can have your custom TStream handle the decryption for you as it goes... Just an idea. Never done any packing before, but it seems like it's something extremely easy to implement. |
| ||
| You can put the data in password-protected zipfiles and incbin them -- with Koriolis' zipstream module your program can still read the data without problems. |
| ||
| There are other packers out there.. I personally use a type structure that allows me to easily serialize and deserialize the data for the given types (and I RC4 upon writing). |
   |