Windows7/Vista again
Blitz3D Forums/Blitz3D Programming/Windows7/Vista again
| ||
| Since the last thread soon degenerated into an argument over who likes which programming language...... I tried my Blitz3D program (XP-developed) on 2 machines today, Windows7 and Vista. Both gave an immediate Windows MAV message, and Windows refused to run the prog without any further explantion. Now these are two patient friends, but they are not going to want to hear that they need to download new DX drivers or somesuch in order to run my software. Nor is my potential user-base. Vista and 7 reacted so immediately that I'm surprised that people on here say they are running their progs in either (at all, never mind speed!). Is there something obvious I need to do? (-Other than watch for the potential sprite problem) So far, this feels like 6 months work down the drain. |
| ||
| Realistically I think the best thing you can do is get a Windows 7 development environment, because there's really only so much you can ever hope to do without replicating behaviour first-hand. Second thing is to try running the programs in XP mode. If that works (and it should, if it's a later-Windows specific problem), put that as a required setup step in your installation guide until such time as you can get a Windows 7 environment for yourself. Thirdly... if the error happens immediately, that means it's something in your program initialization. Are you doing anything that would offend the stricter security policies of the later systems, such as trying to write to protected files or accessing something you shouldn't? (I can't imagine initializing DirectX 7 should actually crash the program, even with suboptimal drivers...) |
| ||
| Thanks Yasha. Tried XP-mode. No difference. Tried supervisor. No difference. Not aware I'm writing to anything during bootup. I _am_ linking to dlls: Bass, FastExt, FastImage, BitzSys. These never gave trouble in XP. Am I the only person who thinks that this is beyond tedious, that MS can't support previously sound working software. After all, Bill Gates' original pitch to IBM was that his OS versions would always be backwards compatible. (... and there goes that flying pig again.) Remember, I'm trying to cater to a user-base who don't even know what a driver is, let-alone how to download one. All comments and experiences welcomed. |
| ||
| Perhaps you are falling victim to virtual paths. Try installing your software to C:\yourfolder instead of C:\program files\yourfolder on the vista\7 machines and see if it helps. If it does , then something is being saved to the virtual folder and your program is trying to find it in the actual folder. |
| ||
| Thanks RifRaf. Having trawled the web for a few hours, that seems the most likely reason. I simply copied a folder of files from a cd to their hard drives, then tried to run the program. I had already come to that conclusion, so thanks for also clarifying that. So I guess a) I've got to finally buy a Windows 7 machine b) then confirm that a proper installation program needs to be used to conform with the new securities. (-notwithstanding already known issues of sprites, etc.) |
| ||
| I'm suprised at your problems, tho I have always tested my latest project on Windows 7 after major changes (developing still on an XP machine) but I have been using proper user paths from the start. As I mentioned previously aside from having to avoid sprites and some other minor things I've had no major performance issues except with certain uses of read/write pixel fast and no crashes. Another thing that can be very slow is direct back/front buffer access if your using anything that directly read/writes its better to use copyrect to dump the current content before reading and if writing again dump it to an image with copyrect and then copy the image back to the screen buffer after editing. |
| ||
| Thanks for those hints Rroff. Ok, for now I will disable my lensflare until I can rewrite it to use quads. Whoops I just found the sun image, water ripples, and fire halos - all done as sprites. Ok - recoding for quads then, but not very major. "performance issues except with certain uses of read/write pixel fast" I'm using readpixelfast to examine my terrain (layers) to decide where to place trees. Are the normal read/write pixel calls ok? Just the fast ones faulty? Thanks to you guys I feel that when I go out to buy a new machine tomorrow it won't be wasted money, and the problems are cureable. But still keep coming back to me with your comments and solutions. |
| ||
| I was seeing 40x the amount of time spent in readpixelfast loops (over XP) when reading from some texture buffers, I've never tried with the normal readpixel commands as they are too slow for my uses in the first place. I'll try and post an instance of the code where its reproduceable tomorrow don't have time tonight. |
| ||
| Rroff, don't worry. I've already converted my readpixelfast code to readpixel. There's no problem - it's not realtime, just working out (once only) positions for trees from dots on an image, and quite fast enough. |
| ||
| Also, I would normally assume this was done, but there's no mention of it, so: if you're getting a MAV, the first thing to do is run your program with Debug Mode enabled. That at the very least should give you details on what's causing the MAV. |
| ||
| If your only using readpixelfast at load time then it shouldn't be a problem - worst case its twice as slow as regular readpixel. The problem there was realtime usage on some Windows 7 setups would result in 100s of ms spent in read/write pixel fast loops which would kill performance. |
| ||
| Thanks guys. I'm including below day 1 of being a new Windows 7 owner - - a reply I sent to 2 friends who have been testing:- -------------------- I went out today and bought a new Windows 7 machine. The assistant had the gall to tell me it was 'just like XP'. It took an hour to work out where it would even _allow_ me to copy my files, so I could begin to look at the problems. 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. ----------------- Yours, knackered and with a blinding headache, John |
| ||
| It took an hour to work out where it would even _allow_ me to copy my files, so I could begin to look at the problems. This hasn't changed in a long, long time. The only difference is on Vista and above it is enforced because some developers do not like playing by the rules. 1st crash: due to 'parented-sprites'.... code that's been in use successfully for 10 years on XP. DirectX 10 and above are not backwards compatible. This means that default installations of Vista and 7 will not properly support legacy products that are using dead and deprecated APIs like DirectX 7. Legacy products will try and run under emulation. DirectDraw 7 gets emulated pretty good, but Direct3D 7 can be very problematic.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.) The best hope for supporting these legacy products on Vista and 7 is downloading DirectX 9 (which is backwards compatible) and installing it side-by-side with the modern versions of DirectX. This is not guaranteed to work 100% perfectly since DirectX 9 has not seen an update in a year and new graphics drivers sometimes do not properly support deprecated versions of DirectX. But, in most cases this will allow all of your old stuff to still run fairly decently. 2nd crash: due to trying to play a sound without the speakers plugged in. Yes, W7 detected that, blamed the program and crashed it. This really hasn't changed since the DOS days. As a programmer, you need to make sure a hardware device is actually available before trying to access it. It sounds like you are not properly checking or properly handling the message that Windows gives back to you. I am not sure how Microsoft is responsible for your shoddy coding?It is also worth noting that B3D besides using a deprecated rendering API is also using a deprecated sound API. DirectSound is deprecated and runs under emulation on Vista and 7. This emulation does not have hardware abstraction, so there could be issues to worry about. Because it uses FMOD it seems to do a bit better as FMOD (IIRC) provides its own software fallback instead of relying on the OS to provide the emulation. 4th problem: programs cannot be installed in 'Program Files' as before, but must be in 'Program Files (X86)\<username>' [who would know that?], All developers would know this as it is nothing new and it has been this way since XP first hit.You are trying to run a 32-bit program on a 64-bit OS. 32-bit programs are not directly supported on 64-bit versions of Windows and they must run under emulation using WoW64 (Windows on Windows 64-bit). When installing a 32-bit program on a 64-bit OS, the 32-bit programs (and any dependencies) must be placed in the 32-bit directory equivalents so the emulator can access them. This has not changed since XP 64-bit was released. The only difference is now, other than a few models of netbooks, there are not any 32-bit processors in use and the majority of new systems sold ship with a 64-bit version of 7. otherwise programs are not allowed access to their own files, which was the problem I had on both your machines yesterday. As long as you store your data where it should have been placed for many, many years, you will have no problems. The proper storage location for these files has not changed since the active desktop update was released for Windows 95 (September 1997). The only difference is now it is enforced to protect users against developers who do not like playing by the rules. Windows will try putting things in your virtual store when writing/saving data/files, but it will not by default load them from there. It will only virtualize those files/data to keep you from losing anything. 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. I am not sure what MS have fouled up? So far, every complaint has been your own fault for not doing things correctly. The proper locations for files have existed for 14 years. The proper file locations for 32-bit programs under a 64-bit OS has existed for 10 years. The DirectX 7 deprecation issues have existed for almost 5 years.Microsoft made many changes and improvements to Windows 7, but you are not complaining about any of them. You are complaining about things which predate Windows 7, and most of them predate it by a decade or more. Microsoft goes out of their way to make sure developers know about any changes and MSDN is a wealth of information as is the Windows SDK. |
| ||
| GaryV, wake up in a bad mood ? Helpful information I'm sure is welcome but I don't think all that "should have known", "all developers know this" and such is helpful at all. i didn't know much of this until it effected my game as well, so it's not shocking to me that other Blitz Coders wouldn't know until the same happens. Anyhow, John don't let the hand smacking get you down, we're not all working for Nintendo or anything. It's alright to learn new things, even if its old information. |
| ||
| GaryV, wake up in a bad mood ? I merely pointed out, with a much politer tone than he used in his rant, that his problems are really ones that he is needlessly creating for himself and I explained why he is running into some of the problems he is. However, in reading back, I was a little FlameDucky and for that I apologize. That was not my intent. :) |
| ||
| 1st crash: due to 'parented-sprites'... I remember seeing some code that treated this with the following:
Local newSprite = LoadSprite("spark.jpg")
EntityParent newSprite, e\emitter ;Avoid sprite-parenting bug.
See how the code doesn't place the parent directly with LoadSprite(), although it has a parameter for this.I can't judge on this since I still run under XP, but the coder had a tone of reason worth testing. |
| ||
| Kryzon, no sprites are now parented, and they're running fine. Rif, thanks for the defense, and the positive comments. Gary, thanks for the apology, but I laughed all the way through. "The proper locations for files have existed for 14 years." Yes, whereever I, or the user, wanted to install them. But let's not play table-tennis over this. I've been developing professionally in MS products for 20 years. I know from long experience that 'depracated' and 'legacy' means 'can't be arsed'. It's a while ago now, but I remember when we found that in moving from 16 to 32 bit my company had to re-buy all new development software suites and compilers. The problem, as I remember it was that MS has changed TextOut() - among many others - to have a new extra parameter. They could have left the old call, and added a new one, but now the compilers couldn't compile the old function. You want to try explaining that to an M.D. who has to spend £5000 just to make existing software run on the next verion of Windows, even though it looks exactly the same? I know we're not going to agree on this, but don't let's fall out - I had no intention of starting a flame-war. I just feel that MS should support their old APIs - by all means add new functionality - but support the old calls. |
| ||
| Well, honestly it seems like there's a side of truth to both your cases. Yeah, cutting off backwards compatibility can be an issue, and generally I don't think much of it; however, every time the system changes and the modus operandi evolves, you have to leave a bit more code for that support, and a bit more, and a bit more... The entropy there could potentially get a bit clunky. With regards to the sprite issue, I know it's been said many times already, but I really have to pop it out again due to my own experience from dealing with it: ditch sprites entirely. Use program-created quads, just a quick two-triangle square. Not too long ago I swapped out every sprite in my program for quads, and immediately saw total stability, far greater flexibility with texturing, and best of all, a performance increase of roughly 2.5x. |
| ||
| I just feel that MS should support their old APIs - by all means add new functionality - but support the old calls. MS is in a no-win situation with this. They get slammed for bloated products and APIs, but much of the bloat has always been backwards compatibility. Their olive branch now is Windows 7 Professional, Ultimate, and Enterprise are all capable of using XP Mode which is an excellent solution for software that fails under compatibility mode. That said, it is not a solution for DX based games and is mainly targeted towards the professional sector (not home users).For the most part, backwards compatibility for XP and older is increasingly difficult as Windows is no longer designed to work the way it did back then and there are not always exact "equivalents" now to be translated to at runtime. Of course, whether MS or Windows is the proper solution for anything is an entirely different conversation. ;) Still, most of your issues with B3D can be solved or worked around. There are many others still happily pushing along with it. |
| ||
| When a program won't run or 'we find ourself incapable of constructing it correctly', the first step is to always blame the OS. John Blackledge stated that he laughed all the way through while reading 'GaryV''s reply when in fact he should had been taking notes and listening to the reply. I assume you expect every version of an OS to act identical to its predecessor? If so then why on earth would we ever need an update. People have been complaining about Blitz3d and win7/vista for many years now, if your just getting around to reading/hearing about those then it's your fault, the information has been here.. It is a shame that Microsoft didn't build Win7 soley with Blitz3d in mind, but since this didn't happen then its time to move on to something more 'updated' that win7 doesn't have a problem with. Bmax+xors for example.. anyways - not hard to figure out.. |
| ||
| Sabata, you're the one missing the point (and the fact that I said 'I've been developing professionally in MS products for 20 years'; not young, not moaning about new OS's). 'we find ourself incapable of constructing it correctly' Do we? It already runs fine on XP. Just two effects as examples:- Third layer multitexturing is now disabled; but 4th and 5th (lightmapping etc) work fine. CameraFog effects are 'deprecated' (lovely word, that) e.g. trees don't blend into the mist, they punch through. And they're just grey. I could mention about W7's inability to read my memory stick (not every time, but every _other_ time. Lock up and crash, the first day), and how it trashed my router's settings so I had to reinstall. From XP. If this were the old development team I bossed, then I'd be stopping their bonuses. We can only hope that a future 'service pack' will help. But wait. You have the answer. "Bmax+xors" Oh goody. Now I have to spend more money, and take another 6 months to learn new software, instead of someone saying to the MS developers, "C'mon guys. Just copy over that last 5% of the code that you forgot." Sorry if I sound sarcastic - just been in the game too long. Heard all the excuses? - Hey, I invented some of them. Seriously, my best wishes to you all, those who agree, and those who don't. I seriously know you're all trying to help, and this is still a great community. |
| ||
| 'I've been developing professionally in MS products for 20 years' If this were actually true, you wouldn't be having any of the problems you are having as you would have been doing things properly and in compliance with the developer guidelines all along as that is what a professional does. |
| ||
| Alright look. This is getting out of hand, but there are a few bits I'd like to add. John, with the utmost respect to you, you say you've been professionally developing MS-wise for 20 years... Do those 20 include the last four or five? Because honestly, Windows 7 ( and indeed Vista, but we don't talk about Vista ;P ) really wrenched things around - for the better, imho - and gave some low-level architectural changes. Hell, like the fact that documents and so forth are now stored in library archives, the actual nature of which remains unknown to me. With XP and under, one could simply boot the machine into a different OS like Ubuntu, and the entire Windows file list was laid bare, all documents readily available with no security needs. Try that on a Vista/Seven machine and you just get four (or more) .LIBRARY files. I guess what I'm ultimately saying is, stuff changes, sometimes for the better, sometimes for the worse, but always outside of our capacity to control. Just roll with the punches and move on, working around what you need to as you go! |
| ||
| Adam, I'm not criticising MS for what they've put in, but for what they've left out. GaryV, and does "compliance with the developer guidelines" include writing fixes and workarounds for now mysteriously disabled features such as "Third layer multitexturing is now disabled; but 4th and 5th (lightmapping etc) work fine." Well, I guess it does. "Just roll with the punches" There's no choice is there. Let's end it here. |
| ||
| GaryV, and does "compliance with the developer guidelines" include writing fixes and workarounds for now mysteriously disabled features such as "Third layer multitexturing is now disabled; but 4th and 5th (lightmapping etc) work fine." A professional developer with 20 years of experience wouldn't still be trying to use a rendering API that was deprecated and became unsupported five years ago. The API was deprecated for a reason and you can't say that Microsoft didn't warn you.Last edited 2011 |
| ||
| Yea its all Our fault that windows 7 completely changed everything and most software that wasn't written specifically for 7 bombs out or refuses to run. And that XP emulation on Win 7 is a complete joke. Or that most of the users I know bitch and complain about their software collections basically gathering dust because they sold or gave away their old computers because Microsoft promised them 7 was the answer to all their prayers. I remember the same argument, on this very site about Vista, People putting down anyone that dared challenge the mighty Microsoft for creating such a bad OS. " Vista is great, you just dont know how to spend days tweaking it!". But thats Our faults too , for expecting Apple like quality outta Microsoft and for all the lemmings that ran to both Vista and Windows 7 (which has vista as its core). and not demanding that Microsoft put in some backwards compatibility in its new OS's. Look I know XP has problems, It has memory limits, which could have been addressed, (pun intended). it looks old, (unless you use Themes to make it look more Windows 7 like). But the fact remains Microsoft Messed up, twice. In the name of driving new OS's down people throats. Oh and by the way, Steve Jobs stole his OS from Xerox Parc while invited there one day, Bill Gates stole his from Steve Jobs while creating Word Perfect for the Mac or working on Lisa software, not sure which ( I don't google when I type comments). But at least when Jobs stole it, he improved apon the Idea. Bill gates just threw together some code to head off Apple taking over the market. So again, dont blame the users for the Software companies that create OS's acting like fools and thinking were all Car buyers and we need a new upgrade every 4 years so they can drive their stocks higher. Windows 7 was created because Vista was such a bomb. And though Win 7 is an improvement over Vista. it was rushed and could have been way more compatibility with old software than it is. And as for bloatware, DX 7 is not that big. and would have made a world of difference in running old software if they had just worked it in. And next we have Windows 8 coming down the line, lets hope they do better than just take a screen shot of Leopard or Lion for the Macs and writing some code to make their OS look good. I myself like running old software, some good games were written in the XP era. Thank you for your time, now go program and stop reading forums, jk Last edited 2011 |
| ||
| This discussion has been going nowhere for a while. DROP IT. |
| ||
| WOW ADAM!!!!, since when did you become the moderator of this site?. Damn I hope Mark is payin you well. Sorry if some of us disagree with you and have our own opinions. But you are right. Most things posted on these forums about anything not working goes nowhere. So see, I finally agree with you. peace out my brothers , hang it low,.. hang it high, just make sure it never gets in your eye. happy progamming to all, and to all a good night! Last edited 2011 |
| ||
| Yea its all Our fault that windows 7 completely changed everything and most software that wasn't written specifically for 7 bombs out or refuses to run. Unfortunately, he wasn't complaining about anything Windows 7 related. He was complaining about things that not only predate Windows 7, but are things that have been in effect for 5-14 years. And as for bloatware, DX 7 is not that big. and would have made a world of difference in running old software if they had just worked it in. DX7 stuff will work if you download DirectX 9 and install it. DirectX 9 is fully backwards compatible, no emulation used. Unfortunately, some people refuse to download and install the proper version of DirectX because it is easier to complain that something doesn't work. Using the logic that you and John use, there is no reason to even use B3D. You should be using DOS based programming languages and game creation programs and still be turning out DOS products and expecting them to run on modern hardware and operating systems. |
| ||
| Gary: "he wasn't complaining about anything Windows 7 related" Yes, I was. - Specifically removed functionality. Please actually read my posts. "DX7 stuff will work if you download DirectX 9" No it won't. Been there, done that. Tried it. No difference. "You should be using DOS based programming languages" There's no need to be insulting. We're still talking about what has either been removed, or deliberately not included, in Windows 7. Don't take it so personally. |
| ||
| Yes, I was. - Specifically removed functionality. Please actually read my posts. What forum did you post that on? Here, every single complaint has nothing to do with Windows 7 and has to do with you not following the "rules" that have been in effect long before Windows 7 was released. These are issues that you are intentionally creating for yourself. Microsoft provides these guidelines so that your software will not encounter problems with Windows. No it won't. Been there, done that. Tried it. No difference. You need to make sure you have a DX7 compliant graphics card and drivers. As I said before, new graphics drivers sometimes do not properly support deprecated versions of DirectX. DX7 compliant graphics cards are very hard to find. You might want to check some second hand shops and look for some first-gen DirectX 9 cards, these should be DirectX 7 compliant. There's no need to be insulting. I'm not. The simple fact is since you refuse to use anything newer than 10 year old, deprecated rendering APIs, you might be better off going back further another 10 years. Thanks to DOSBox, most DOS software runs better now than it has in many years. |
| ||
| Dang, First Adam is the new moderator of Blitz's forums and Now Gary is head of Microsoft developments. Didnt know you two were so well connected. And GARY (Head of Microsoft) The point I was making and also the complaints I get most from Windows 7 users is most of their old software will not work on WINDOWS 7. Some even went back to XP because they didnt need the features 7 has and they love some of their own software. Are they too suppose to become programmers and rewrite their favorite games they used to play that worked fine with DX7 and still works fine on a computer with XP and DX9????????????????????????????? So stop beating the Bill Gates drum and come down from your high horse. They could have built in compatibility in Windows 7 had they not rushed it out the door because Vista was such a dog. They could have made some pointers to redirect old routines to the new ones and made their own 2d sprite emulation within the new DX, they didnt want to. Shadowed some locations in other words. I'll have to search the forums to see if you are one of those who defended Vista too when it first came out. Oh and I can make programs that run on Windows 7 using some of my other languages. But Windows 8 will probably break those too, then we'll all be buying new games and software. And maybe thats what Bill Gates had planned all along ;) ...j/k SO DOS this Gary.........................DEL C:Garyv.duh Last edited 2011 Last edited 2011 |
| ||
| If you're going to insult people via DOS code, at least use correct syntax and remember where the backslashes go. |
| ||
| They could have built in compatibility in Windows 7 had they not rushed it out the door because Vista was such a dog. In spite of all of these compatibility issues you speak of, I have some DOS software than still runs fine under Windows 7, I have some 16-bit Win 3.1 software that still runs fine and the majority of my Win 32 software (including DX7 based games) still run fine under Windows 7.The key to having your software work properly under future versions of Windows is to always follow the developer guidelines that Microsoft lays out. This will always be your best chance to future-proof your development. It is also wise to stay away from hobbyist development tools which do not adhere to the standards. Hobbyist development tools are usually designed for short term solutions, not long term solutions. I'll have to search the forums to see if you are one of those who defended Vista too when it first came out. I am anti MS and anti Windows in general. As much as I do not like Microsoft, I am not going to blame them for mistakes that I make in programming, unfortunately some people will blame MS because they cannot accept personal responsibility for their mistakes. Continuing to use a rendering API that was deprecated years ago and whining because it no longer works properly on modern hardware and operating systems is nothing short of asinine. Microsoft said not to use it anymore for a reason. ;) Skidracer said it best: Blitz3D has never IMHO been a fully compliant DirectX7 design. That said the majority of B3D users are not having issues and can work around the few issues that pop up. I have many B3D made games I have bought happily running on my Windows 7 system and I have bought many for grandkids who are happily using them on Windows 7 systems. For those with issues, it is very easy to port your B3D games to newer APIs. There are two 3D engines (Xors3d and SoftPixel) with a B3D-like syntax that are based on newer APIs that have B3D wrappers. If you move to BlitzMax, there are even more 3D engines (MiniB3D, N3xtD, plus Xors3d and SoftPixel) with a B3D-like syntax to choose from. Engine developers have gone out of their way to help B3D users remain competitive and compatible with their games. Don't be lazy, take advantage of the help these folks are offering. Keeping your B3D games compatible with modern technology is not as hard as some people are making it out to be. |
| ||
| Or put a link to Direct X 9.0c on your webpage with instructions on how to install it :D |
| ||
| Ok Adam, Good comeback, " I forgot the slashes", you should do stand up, no really, I bet people would laugh at you, just standing there, you wouldnt even have to say a word. Big money in comedy these days, People love to laugh when outta work, jk to those who lost your jobs. But ok, kidding aside, I hear what you're saying about following guidelines, and I also know of OLD software that runs, very few, but some still do run on Win7. Less than made it from Win 3.1 to 95, less that runs from 95 to 98, less that runs on 98 to 2000, less than runs on 2000 to..(note:see below) , a lot that made it from 2000 to XP,much less that runs from XP to Win 7. (skip over ME and Vista, go get the ball dog, dog runs into kitchen table leg, dogs not too smart is he?) . And again I was trying to make the point that languages break, sometimes its the programmers of the game and or softwares fault, sometimes its the Software developer of the OS's fault, this time I point the finger at Microsoft. And yes I know there are other languages that do Win 7 fine, I'm using Purebasic right now for that very reason, seems to run just fine on 98, 2000, XP,and Win 7. But took a lot of work to get it there. Also probably in 2030 when the worlds coming to an end because of over population and because Mickey Mouse found a way to become a Real Boy and took over South America, Microsoft, in 2030 (Renamed Big Brother Bill in honor of Gates death, thats BBB for short), ( and people worried about 666). will Hire Nintendo to make a good XP emulator( Nintendo's DS 3D was such a big flop and they needed cash flow). Then old games that will already have been replaced by versions 500.1 will run. on Windows 90. And no one will blame anyone for anything, they'll have all stopped thinkin for themselves. Facebook will have replaced our brains with Java code, or HTML5 or 6, or 500.1. Flash will be used for japanese billboard animations. So lets all agree that I'm write( pun really intended) and stop arguing with me. I have programming to do as I'm sure the rest of you do also. And as for BlitzBasic being broke, Who knows, when Marks done "Monkey"ing around. he may or may not fix it, its all up to him. After all it is his baby. So I bid you ado, I wave goodbye to you and yours, I'd kiss you all but I'm a guy and not french. SO later gators. I am outta here! Last edited 2011 Last edited 2011 |
| ||
| I feel that Dark Soul said it all, especially in the head of his second-to-last post. It feels utterly silly to be trying to have a conversation with someone who quotes me back to myself without actually reading my original particular points about specific areas of (MS, not Blitz) code that now malfunction. Used to be I could come here to ask for practical advice and fixes, not be told that it's my fault and I shouldn't be using "hobbyist development tools" (-like Blitz3D?). Sad. I've been on these forums nearly 10 years, but now like Dark Soul I feel that I am 'outta here'. Anyone who still needs advice about making Blitz run on W7 can get me through my email address. |
| ||
| This thread is in no way enjoyable to read thanks to all the bitterness, so I may have skipped a few bits, but I have suggestions for the four problems mentioned in post #12: 1) There have been a few reported problems with sprites under both Windows 7 and Vista if I recall correctly. I don't remember what they are, but I do remember that it was difficult for other users to track down the problem, and replacing sprites with quads is the safest solution (quads are also faster and more versatile). This is a Blitz3D bug, but there is that known workaround. 2) That's ridiculous behaviour and your reaction is about the same as mine would be. I would have thought disconnecting speakers is a legitimate way for users to mute the sound? However, since Windows can apparently detect the presence of speakers (or it wouldn't affect the program), there must be a kernel command for this. If you use CallDLL, you don't need to link statically against specific functions and can thus test the Windows version first, see if it supports testing for the presence of speakers, and then call the function if it exists (wow - a possible use for CallDLL!). 3) Is that a terrain problem, or a general texture problem that affects your terrains? If it's just terrains that don't multitexture, as with sprites - you can replace them with meshes easily in most cases (if I recall correctly Krischan made a drop-in replacement mesh terrain engine, and there may be others floating around). Personally I thought terrains were a bit rubbish anyway as the dynamic LOD is very visible even at high quality settings, and they can't be used like proper meshes. 4) I hate to say it, but yes that is the sort of thing you ought to find out before deploying to a new OS. That's a pretty well-known requirement actually, and I'm surprised you hadn't heard about it through general idea-osmosis the way I did (I don't even use Windows 7!). ...am I two weeks late to the party? Oh well. Sorry I couldn't be of more help. Also, Adam's comeback was actually pretty funny. I laughed. |
| ||
| 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 Thanks for hi-lighting this one, it was new to me! |
| ||
| 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. I would like to add a codicil here, that being that on my machine - Windows 7 - the path is, in fact, just C:\Program Files\. The installation type is admittedly an "upgrade," thus the drive was originally XP and then written over without reformatting, but still, there is at least one Win7 machine that doesn't conform to that. That said, my Grandmother's new OEM laptop is Windows 7 and uses the formerly mentioned (x86) extension... HOWEVER, it's 64-bit Win7, and there is a separate folder for Program Files (x64). My machine is 32-bit Win7 (laugh all you want, but I've no need for more than the 3.12GB of RAM that it gives me... Yet). I'm wondering if perhaps that's the key, that 32-bit installations use the "oldskool" path, while 64-bit systems have to separate the 32-bit and 64-bit programs that are installed. That said... Dude. Run this program: Print GetEnv("ProgramFiles") : WaitKeyProblem solved, kthxbai. This one simple line woulda solved your whole issue. Paths are frequently changed in Windows updates, so the GetEnv() command should absolutely be your best friend in all cases wherein you wish to write file data to any folder outside of the directory your program itself is contained in. To find the variable that you want, be it ProgramFiles or HOMEDRIVE or even APPDATA versus LOCALAPPDATA, just run the command prompt, type set and press enter. It'll give you all the properties that GetEnv() can access for your machine, but more importantly it tells you what value to use to find specific properties on other users' machines. EDIT: Wouldn't normally think to post this, but... yeah... Anyway, remember that not all properties returned by set on a Windows 7 machine will be present on a Windows XP or older rig. Things like ProgramFiles should be there, but I don't think XP has a LOCALAPPDATA property, for one. SECOND EDIT: I hate to tell you this, but: I unplugged my headphones (which go in my rear speakers slot via an extension, don't ask), so that there were absolutely no audio devices connected to my Win7 computer, ran my game with sounds on, and... Absolutely nothing happened. It ran 100% normally, at least through the main menu which plays BGM and a few sound effects. I have no idea why Windows is crashing your game because the speakers were unplugged. :/ Last edited 2011 Last edited 2011 Last edited 2011 |
| ||
| Here is a new "strange" behavior of BB under Win-7. A user in the german forum wrote about long loading times, when he tried to load and play a midi-file. Try this test-code with any *.MID file. On a XP it will start within 100msec, on a WIN-7 it will need over 8000msec to continue to the next code line: Time=MilliSecs() PlayMusic "polonaise.mid" DebugLog MilliSecs()-Time WaitKey() End If you have no midi-file, use this: http://www.blitzforum.de/upload/file.php?id=10947 |
| ||
| 740ms 725ms 695ms 720ms 670ms Windows 7 64-bit. 4GB RAM. Not exactly "over 8000msec". |
| ||
| @Midimaster: There are a host of possible reasons for this. First and foremost, PlayMusic() loads the actual audio from the hard drive either every time it plays, or the first time, I can't remember which; it's the equivalent of combining LoadSound() and PlaySound() in a single command. This means that it's only as fast as the hard drive it's being loaded from, and ALSO only as fast as the .MID file is small, since a larger file will take longer to load and process. So, it could be that it's a large, complex MIDI, it could be that his testing hard drive is extremely slow, it could be that his Win7 is very poorly optimized, causing hard drive bottlenecks, it could even be that his audio drivers are wonky. No telling why. One thing I can say for sure, though, is that for any MIDI to take 8sec to load is just bollocks, and something, somewhere, has gone quite wrong. |
| ||
| @adam novagen loading the file with ReadFile() needs only 48msec. The files are to small to need time because of the harddisk (4k-80k) @LineOf7s this is interesting... it is not really quick, but better than the systems we tested. We tested on a german Win-7 64bit Home Premium. Both computers need over 800msec |
| ||
| Both computers need over 800msec Wait, hold it... You said 8,000ms (8 seconds) previously. Was that a typo, and it's actually 800ms (0.8 seconds)? Or is it actually eight seconds? |
| ||
| 8.000 msec =8 sec to jump to the next code line! Please test the short sample code (on post #41) on your machine and tell me what's happen... I a genuine Win-7 it seems to be no support for MIDI any longer. Do you remember, there was a possibility to change MIDI-Driver in system properties on old Win XP ("Midi Mapper" or "Microsoft GS Wavetable"). It's gone in Win-7. And I fear, that they replaced the converter MIDI->Wavetable with a very poor one... Don't know why! But perhaps it is a problem of rights of BB's PlayMusic()? A lot of thing on WIN-7 you can do are followed by a long "thinking" (or should I say "meditation"?) of the system... Perhaps somebody has deeper informations about MIDI-Drivers on Win-7 or BB's PlayMusic()? |
| ||
| If your testing that code in #41 you probably want to put a delay 2000 or something before the time = millisecs() as on some machines regardless of OS Blitz can take a second or so to get going when first launched. Testing on my XP and Win 7 boxes, XP randomly took 140-600ms and Win 7 took between 1200 and 1600ms each time. Last edited 2011 |
   |