Program MAVing on other computers
Blitz3D Forums/Blitz3D Beginners Area/Program MAVing on other computers
| ||
| My game seems to be inconsistent in running across computers; on my computer and some other computers, it works perfectly fine, but on some other people's computers, it comes with an MAV error when trying to enter a level. I know it has nothing to do with external resources, because even with a demo where all the resources are unpacked and in the same directory as the .exe file, some people still get an MAV error. I also know I've packed all the resources in with the .zip file on the site, because when I download the zip from the site, it still works perfectly. Here's a link to the game. It's a Mario fangame, but let's keep the copyright discussion out of here =P Basic bug reports are in the comments; the people who played it and got the error couldn't go into much detail, because debug mode was off. I can't post the source code (it's too large anyway, and with very few comments), but just in case it matters, I'm using Blitz World Assembler as my level editor. Is there any problem with its loading routines that I have to fix so it's compatible with all computers? What can I do to make my game not MAV on all (or at least most) computers? |
| ||
| Can you perhaps show a chunk of code where you are loading images/meshes? 99.9% of the time it's because blitz can't find the media. Are you using absolute paths? If so, then that is most likely the problem, and would explain why it works for some and not others. How about screen resolution? Are you trying to force a resolution that might not be supported? |
| ||
| It won't run if they don't extract it from the ZIP file first. |
| ||
| The program is all contained in 1 exe (which is an auto self-extracting zip file itself). It runs even if it isn't extracted from the zip file. Every user who's had a crash has been able to actually open up the .exe, but crashes when they enter a level (the level loading routine is the one that comes with BWA). I'm only using relative paths, and the screen resolution used is 640x480 windowed. EDIT: For levels, BWA's routines are being used to load meshes. Here's a chunk of code where I'm loading an object's textures in the object's initialization routine (nothing is loaded outside of this routine for each object, and each object has its own initialization routine):
ClearTextureFilters
texFlags = 1+2+8+16+32
MapObj\texArray[0] = LoadTexture("Sprites/Boo/default1.png",texFlags)
MapObj\texArray[1] = LoadTexture("Sprites/Boo/default2.png",texFlags)
MapObj\texArray[2] = LoadTexture("Sprites/Boo/default3.png",texFlags)
MapObj\texArray[3] = LoadTexture("Sprites/Boo/default4.png",texFlags)
MapObj\texArray[4] = LoadTexture("Sprites/Boo/lookaway.png",texFlags)
TextureFilter "",1+4+8
Is there a list of things that can possibly cause an MAV somewhere, so I can check my program against it? |
| ||
| As long as the paths shown above are correct paths to files, then it should work. Gfk is correct though,... it won't find the files if the person opens the zip and clicks on the .exe without extracting. If they are extracting the .zip, then the next thing would be to check if the paths are all correct after unzipping. |
| ||
| Again, the .exe is a self-extracting zip; everything is inside the one .exe file. I provided the link to the game, download and see for yourself =P (unless they already updated it with the one I just submitted that uses external files). And yes, I'm sure those are the correct paths. That's why I'm so confused. |
| ||
| Make sure you're not using floats for any of your entity handles. This is something which has been known to MAV on some computers while running happily on others. |
| ||
| Ok, I went ahead and downloaded it and it works fine here. (WinXP) My latest guess is that it has to do with Vista and the compression of the files. What are you using to compress the assets into a single .exe? What I think is happening is that Vista is probably not letting it decompress where you think it is, so the files are not working on those systems. Can you make a version that doesn't require the decompress? |
| ||
| I was using a program called "ZIP 2 Secure EXE" to convert the zip into a self-extracting .exe. However, even with a version where all the external files are unpacked and in the .zip with the .exe, some people still get MAVs. Gabriel: That just might be it; wait, let me check... EDIT: No, I don't think I used floats for any objects handles, only integers. EDIT 2: Also, I forgot to mention; in both cases (w/ external and in one file), the main file was compressed with UPX. Is there a compatibility issue between UPX and Vista? |
| ||
| Yep - MAV in Vista. Works as far as the control select screen, but that's it. |
| ||
| GfK, download this fixed version and see if it helps: Link I just turned the debugger on (I had it off! >_<) and found that on the map's startup, two Blitz array indexes were being used out of bounds, and fixed that. This version also isn't UPX compressed; that might help too. |
| ||
| I still get a MAV with that version. Just checked ProcessMon and I'm not seeing any failure to locate files so I guess that narrows it to a code problem somewhere. |
| ||
| I forgot to reset something (I was testing to see if a certain block of code would crash on the map, and it did, but I forgot to reset it to its non-crashy state); can you replace the SML.exe in that version with this one? Also, in that last version you should have gotten the MAV after the map screen faded in. If you still got it before that, then something's wrong... |
| ||
| In the last version i get a MAV as soon as the control scheme page has faded out. I get the same error in the new version, too, in the same place. |
| ||
| The debugger was enabled in the last two versions, so it should have given something more useful than just an MAV error... I can't think of anything that could cause an MAV that wouldn't be consistent for all computers (except for the floating point mesh handles that Gabriel just mentioned, but I'm not using those). EDIT: When it MAVs, has the map music already started up, or is it before that? EDIT 2: Can you replace the SML.exe file with this new one and tell me what the debuglog.txt it generates contains? |
| ||
| Tried this on Vista, and it MAVS on me there. It works right up until the control screen select. After that the screen fades to black and when the fade ends the program MAVS. The new file MAVS immediately and the debuglog is empty. |
| ||
| So debuglog.txt has been created, but it's empty? That narrows it down significantly. I'll run some more tests and try to get a specific piece of code. EDIT: Can people who were getting the MAV download this new version and tell me what the debuglog.txt file contains now? I was assuming the error would be in initializeWorld(), but if Pongo's right, it's before that; the new file contains more thorough tracking. |
| ||
| That version MAVS right away also, but it did write to the debuglog this time. debuglog |
| ||
| Thanks, Pongo! The other people I asked got the same thing too. That narrows it down to these specific lines of code: However, I'm still not seeing the problem here. Could someone help me out? BTW, shadowTex.PNG was included in the zip, so it can't be related to not being able to find a file. EDIT: Whoops, I had it write "Shadow Texture Loaded" to the debug file instead of the correct "Non-Blitz Arrays Initialized". The error is still in this section, however; I just wrote the wrong thing to the debug file. =P |
| ||
| Ok, some quick tests. I made a new .bb file with just the above code and ran it. (Without the if statement.) I also had to add a graphics3d command. Guess what? MAV! When I removed the flag at the end of the loadtexture command, it worked ok. It looks like the texture has alpha, so I'm not sure what the problem is. Hope that helps. |
| ||
| If alpha is the problem, then I'll have to change every one of my sprites' textures; almost every one of my sprite textures uses alpha, in an attempt to smooth out jagged edges. Can you try changing the flags to 1+2+8+16+32 and see if that changes anything? Those are the texture flags I'm using for my sprite textures. I used Leadwerks Texture Tool to make the PNGs alpha'd; does that program have a problem? |
| ||
| You're trying to load a texture with the texture flag 2, which is alpha only. It should be 3, color plus alpha. |
| ||
| So not loading a texture in color causes an MAV in Vista? Do I have to load masked textures as 1+4 too? EDIT: Sorry I'm making you guys download all these files, but hopefully this will be the last one. I changed the textures flags like Gabriel said; here's a link to the new .exe file. Can you guys check if it MAVs on Vista? I really wish I had a Vista computer to test this on; my mom's computer used to have Vista, but it crashed so I had to install XP on it. |
| ||
| That did it! Works here on Vista now. |
| ||
| Awesome! Thanks for all the help. :D You can enter levels and all too, right? EDIT: Question; UPX works on Vista, right? Because my .exe is 2 MB and it would help the file size a little if I UPX'd it. |
| ||
| 2MB is nothing. Many casual games these days are pushing 80-100MB. |
| ||
| I know, but this is a fangame, so most people aren't going to want to download over 10MB. 2MB is the MAIN exe file; with all the resources, it's about 5MB. Keep in mind this is only 1 world; I plan to have 7 or 8. |
| ||
| Well, you'd be better off building an installer with InnoSetup, and leave the compression to that. It'll likely do a lot better than UPX anyway. |
| ||
| Heh, most people who play fangames hate installers, but I guess I could do that for the final version. BTW, does the game work for you too now? You said you were running Vista. |
| ||
| Seems like a cool game. Some problems were )If you flip the camera around, you can't see the fireballs anymore. )Hard to see some areas because the camera only turns 180 degrees. )Takes 5 seconds to remember which key is which. |
| ||
| )If you flip the camera around, you can't see the fireballs anymore. )Hard to see some areas because the camera only turns 180 degrees. )Takes 5 seconds to remember which key is which. Yeah, that first one is because I forgot to set the fireball's SpriteViewMode to 2. I've gotten complaints about the camera turning from other people; I'll make it only turn 90 degrees in the next release I thought the default control schemes were pretty easy to remember, but I'll probably add an option to make your own control scheme in the next demo. |
| ||
| I'll try it if you upload a 'working' version all in one file to save me messing about downloading all the media then finding the right EXE to go with it. |
| ||
| Here. |
| ||
| Works fine now. The rotate camera thing, though - should it rotate 90 degrees instead of 180? |
| ||
| Right now it's supposed to rotate 180 degrees, but I'm going to change that to 90 in the next demo because people are asking me to (both here and on other places where I've posted this). |
| ||
| Yeah, I got to the place where you have to use up/down to progress through the level and I couldn't see what I was doing. |
| ||
| Yes, UPX works on Vista, and it is worth doing because it can compress an EXE in ways which DEFLATE and other generic compression algorithms can't. |
   |