Listing incompatible code/features for Vista/Win7
Blitz3D Forums/Blitz3D Beginners Area/Listing incompatible code/features for Vista/Win7
| ||
| I know to stay away from using sprites and the draw text commands for blitz3d. While they work fine on XP the use of such code will make Blitz not play nice on newer operating systems/hardware. What else should a Blitz programmer be aware of in respect to compatibility of their applications? What would be a practical replacement for sprites? I could use a flat plane and map the texture on it but I have no idea how I could implement rotational sprites using such a method. Concerning text.... Is the Ultra fast library for text and fonts still the best solution at the moment? I really would prefer not to cutup my fonts into tiny bitmaps. Any information on this would be welcome. |
| ||
| Might just be better to go with Blitzmax at this point. Anyone care to give an opinion on the Pro's and Con's? |
| ||
| the draw text commands for blitz3d. While they work fine on XP the use of such code will make Blitz not play nice on newer operating systems/hardware. What ? I have tested the 2d commands Text, Rect, Line, on 4 computers with windows7 and they work correctly ? I can't say for sprite because i use quad meshes instead. I have no idea how I could implement rotational sprites using such a method. Easy i can give you an example if you want. |
| ||
| Here my try at it : |
| ||
| The biggest cause for incompatibility is programs trying to write in locations that they are not allowed to, e.g: if your program is installed in c:\program files\myprogram you can't simply create a config file, save game, etc. in that same folder after installation time: Windows UAC will prevent it. Instead, that kind of info needs to go in c:\users\<username>Appdata\local\myprogram You HAVE to use the microsoft recommended file locations to store your data. You ignore the MS guidelines, unlik with XP and older. Now, be smart about it of course -- use the MS API's to obtain the file locations, if you hardcode the directory location you can run into more issues with e.g. non-english versions of windows where the folder may be named differently, or custom/non-standard installs where the OS may not reside on the C:\ drive, etc. |
| ||
| xlsior>>What if i distribute the program in a .zip ? Can i write in the same directory the user extracts it in, or do i have to follow the rules you have mentionned ? Is it possible to write in a directory if i install a program in another directory than C:\Program Files (x86), for example C:\Progs ? Thanks, |
| ||
| Certain folders have UAC rules enforced, others do not... Before you can run the program you'll have to move it from the zip to a folder anyway, and whether or not the program is able to store files in the defstional location upon running it greatly depend on -where- the user extracted it to. Today, it'll work just fine if it got extracted to a folder on the desktop, or to your own folder under C:\. It will NOT work if the user tried to tidy things up and put it under c:\program files or c:\program files (x86), or anywhere else where UAC enforces the limitations. It may or may not work in other locations -- the biggest problem is that it is unpredictable, and even more so the next time a windows update comes out. you never know what additional limitations MS will enforce in the name of security. If you follow the MS guidelines and they redesign/redo things, at least the OS will catch it and redirect you (e.g. under windows XP, the user folders were under 'c:\documents and settings'. Under later windows versions, it's c:\users -- but the documents and settings folder will automatically redirect to users, so any app still trying to read/write to documents and settings should continue to work even though in reality the data ends up in c:\users.) Ignore the guidelines, and next time something changes your program may come to a screeching halt because maybe you can't make your own folders off the root directory at all anymore or something -- who knows. Bottom line: annoying as those guidelines may be, and annoying/unintuitive/ugly the recommended locations may be, using them greatly increases the odds that your programs won't bomb out on random computers, and are at least somewhat future-proofed. |
| ||
| Ok i understand. Can you please suggest a tutorial or an article to learn how to do this. For example how to identify the windows version (XP or Vista or 7 or 8) and the langage in order to know where to write/read the config/save files ? Thanks, |
| ||
| Wow thanks RemiD! That is EXACTLY what I was looking for. This will definitely help me out in the future. http://www.nadergator.com/games.html I should have mentioned I was looking at some dated Blitz basic code from around the 2000 era. The sprite explosions in Naders tank game cause it to lockup the moment the sprite is displayed on Windows 7. During the Helicopter example it locks up the moment text is displayed. Both games play fine on XP. I cannot locate the thread but it was on this forum I came across a lengthy post about staying around from using 2d text/sprite commands in Blitz3d. I believe this does not affect Blitzbasic/Plus. @xlsior - this was exactly what I was worried about. Thanks for clearing that up. But couldn't this easily be avoided if you distribute your program with an installer? |
| ||
| I cannot locate the thread but it was on this forum I came across a lengthy post about staying around from using 2d text/sprite commands in Blitz3d. If you find the thread, i am interested to read it. As mentionned previously i have tested the 2d commands rect + line + text on 4 different pcs with Windows 7 and 1 pc with Windows Vista and 2 different pcs with Windows XP and it works properly on all configs. |
| ||
| Thread1: http://www.blitzmax.com/Community/posts.php?topic=97366 Thread2: http://www.blitzbasic.co.nz/Community/posts.php?topic=95677#1106541 I was mistaken it was related to the use of Print() command when drawing 2d graphics on the green in 3d mode. Sorry for the confusion! Pulled the text below from thread 2. By John Blackledge: Windows 7 Issues. 1st crash: due to 'parented-sprites'.... code that's been in use successfully for 10 years on XP. 2nd crash: due to trying to play a sound without the speakers plugged in. Yes, W7 detected that, blamed the program and crashed it. 3rd problem: terrains can only have 2 layers, so I can't have grass and stones and sand. (My software is going to look substandard on W7.) 4th problem: programs cannot be installed in 'Program Files' as before, but must be in 'Program Files (X86)\<username>' [who would know that?], otherwise programs are not allowed access to their own files, which was the problem I had on both your machines yesterday. And on it goes. I'm working my way through each of the problems, trying to find a programming workaround for each problem as I hit it, but I'm beginning to think that when I set up a web page I'll be brutally honest and tell it like it is; that Microsoft have fouled up again, and it may take a couple of years (as it did with XP) before they sort out the problems that they blame on everyone else. ---------------------------------------------------------------------------- end After combing over this post I think it's safe to assume this was a user related error and not anything caused by Blitz? Has anyone else had similar problems? |
| ||
| 1st : no problem with a sprite mesh (a quad) (see example above) 2nd : yes i have seen it too. I don't know if there is a way to prevent that, maybe add a note at the end of the installation of the software, or in the readme.txt, or on a configuration screen. 3rd : i don't know i have not used terrains with 2 layers (i guess it is for terrain splating ?) 4th : See the explanations by xlsior or tell the user to unzip the program in a custom directory (example : C:\Progs or C:\Games) |
| ||
| If you're going to quote me then you should also quote my embarrasing second installment: http://www.blitzbasic.co.nz/Community/posts.php?topic=99361#1166876 By the way, I'm still using sprites, just not parented in the creation call. Parented using EntityParent(). That seems to be the only real Blitz problem, and I don't think it's theirs. I think microsoft have changed the internal function. |
| ||
| Good to hear you addressed the sprite issue. It's frustrating when stuff goes wrong but don't ever be afraid to ask a question. I'm still learning Blitz so I'd rather not repeat other people's mistakes so I can save myself some time. Sometimes different opinions can stir up emotions and people disagree. It will always happen. Either way I learned a lot from those threads. :D |
| ||
| Some great tips about overcoming installation path woes, thanks for the info |
| ||
| Also on the subject, the whole Program Files (x86) is not a Windows 7/Vista specific issue, but rather, a 64-bit Windows issue. The Program Files (x86) is included in 64-bit versions to allow for backward compatibility for 32-bit programs. The UAC 'issues' with paths are only a problem if one is going to use absolute paths in trying to write to locations - this is BAD PRACTICE anyway! Overall, in cases such as the above, ALWAYS use the registry or where applicable, ENV VARS to locate special folder locations. |
   |