Cardwar - Issue under Win7
BlitzPlus Forums/BlitzPlus Programming/Cardwar - Issue under Win7
| ||
| Hey guys! I have noticed a glitch in my card game Cardwar. For reasons unknown, I see black rectangles when the cards are turned or modified/destroyed. There seem to be an issue with the imagebuffers. When I call a function for the first time everything works as expected. But the second and third time, transparency is broken. I "clear" the imagebuffer via: SetBuffer drawresizedimage_tempimage_ib Color 255,0,255 Rect 0,0,64,91,1 <- 255,0,255 is the transparency color! Screenshot:  Example Code: CW 1.3.3 Download: http://www.updates.de/software/download/Download_11941.html http://www.freeware.de/download/cardwar_11941.html It's been quite a while since I have last touched BP: So any help regarding this issue is welcome. Thanks Grisu |
| ||
| My only guess is that drawresizeimage_tempimage_ib's image is being freed somewhere else in your code. How come you don't just initialize it as a local within the function? |
| ||
| Unless you are using a bootleg version of win7 full, dont take the rc glitches personally. Windows coughcough'sucks'coughcough. Just, dont take microsofts holes hostage. Use Unix my friend, use unix. |
| ||
| Luke111, take your anti-microsoft BS elsewhere. Does BlitzPlus run on Unix? No, so how is that going to help here? |
| ||
| Lol. It runs under WINE Windows Emulator. I happen to be using micorosft right now as I dont like the other option - MAC. Now MAC just sucks worse. |
| ||
| You know that's hilarious :) You hate Windows, so you use Unix, then use WINE to use Windows on Unix. What's the frickin' point? ;) Ok, enough derailing, let's get the thread back on topic. Grisu, some things to check... BlitzPlus changed the default way images were managed some time ago (can't remember when exactly). It was something to do with the managed/dynamic/scratch modes IIRC, so you may need to add or change the flag parameters. Also, the image masking broke with Vista on some video cards, which might be related. |
| ||
| Id also look at the fact that win7 was completely engineered from scratch. A new type of nt since there were so many holes in nt before. :) LUKE |
| ||
| Id also look at the fact that win7 was completely engineered from scratch. Um... Excuse me? It's 98% identical to Vista. They've overhauled some components, but it's hardly a re-write. It's internal version number is 6.1 for crying out loud. (Vista is 6.0) |
| ||
| xlsior is right. In the industry the product known as "Windows 7" is often humorously called "Vista SP 3" among sys-admins. What they did for Win7 was pretty much what they should have done in the beta phase of the Vista release in the first place: Listen to usability and performance feedback from the testers and fix, fix, fix until it was really "lean". |
| ||
| xlsior is right. In the industry the product known as "Windows 7" is often humorously called "Vista SP 3" among sys-admins. Likewise, the initial Vista release has been called Windows ME 2.0 What they did for Win7 was pretty much what they should have done in the beta phase of the Vista release in the first place: Listen to usability and performance feedback from the testers and fix, fix, fix until it was really "lean". Microsoft tried to put the bar too high with Vista, and failed to deliver in a timely fashion... It was a rush delivery, and they simply ran out of time. Several of the initial major announcements (like WinFS, where the filesystem essentially behaves as a database) were scrapped altogether, and haven't even made it in Windows 7 either so far. One not insignificant problem was that they'd been promising the Vista launch for a long time in advance -- which isn't that bad, if it weren't for the fact that they'd also been selling corporate enterprise agreements that would entitle large corporations that signed on to updates to the new windows versions within the duration of the contract on that premise... the date of which was rapidly approaching without microsoft delivering anything. They had to ship something or a lot of companies would think twice about signing those kind of $$$ enterprise contracts. The result is what we're all familiar with: Vista got downgraded from it's initial pie-in-the-sky promises to shiney-but-kinda-broken-now-with-extra-driver-and-software-incompatibilities. Most of the problems got fixed with SP1, which kind of goes to show that they could have gotten it right if they hadn't tried to rush it out the door. One of microsoft's major problems are their odometer releases - they release a new version of a product because it's about that time on the calendar again, not because there is a need or because something is 'finished'. |
| ||
| Idd. And given Microsofts market share and the fact that their "current" operating system (at any time) is distributed on a very huge % of sold end-user machines, I'd like to think they'd benefit from an approach like this: 1.) Set the scope of the new OS. What should it include? What perceived problems do "our" customers have with existing products and how can "we" in the new version mitigate these problems. 2.) Optimize for speed and usability over "effects". One very big problem with recent Windows OS'es is that they are not GUI-wize optimized for "Realtime smoothness" or what we in the Blitz*-world call "tweening" if you catch my drift :-) Imo the OS GUI should run just as fast on a 5-year-old machine as a brand new one, except that animations/renderings/alpha-effects are "dieted" on the old one. Example: When the user clicks the minimize button on a window, it's far more important that the window becomes minimized within 300-500 millisecs, than to play the same "minimizing animation" that happens to take 300ms on a new machine while it takes 2 secs for an old machine to complete. I'm not saying that the old machine should not have the animation, but I'm saying that it should be written so that it takes 300ms no matter what on both machines, even if the older one shows it a bit "less smooth" than on the brand new one. 3.) Implement a "It's finished when it's finished" mentality regarding new OS releases. This is not to say that there will never be an release because the scope is changing all the time. That point goes back to #1 planning, and furthermore adding features to the upcoming release should require serious review and bureaucracy to determine if it's really necessary in the current release, where new "cool and nifty" features (like WinFS for instance) are weeded out and placed on the wish-list for the release AFTER the upcoming release. I'm think that after the fiasco that was Vista, some people at Microsoft did a list similar to mine above. Personally I think the marketing/bean-counter people at MS are to blame, but I look at it that way because I'm a dev ofc. :-) Now I just realized how I helped derail this thread a bit so I'll just finish with getting it a bit back on track: Grisu: If you could write a write a standalone, very short, but complete program that you post source for here, that pinpoints the problem on your Win7 setup I think that would help you much in getting fairly quick replies. That would for instance make it easier to determine if this is a driver issue or if it's in Win7 somewhere, if several people can test it on their machines. (and make small modification to it to see if they can fix the problems) |
   |