Decorator (blitzsys.dll) crashed
Blitz3D Forums/Blitz3D Userlibs/Decorator (blitzsys.dll) crashed
| ||
| Hello I am a user of "decorator". I love this tool. Since i started using decorator on my new AMD Athlon (64 bit) it does not work anymore. For me, it looks like a problem with this blitzsys.dll. Any ideas ? PC Config: - nvidia 660GT latest drivers - AMD Athlon 64 bit - 1gig ram - Windows XP |
| ||
| Hi Chi3f Stadi, I am also a user of "Decorator". What versions of Windows XP are using (32-bit or 64-bit)? How about if you change the compatility mode to other windows versions in the shortcut of decorator's properties? Sammy :) |
| ||
| It is a 32Bit Windows XP edition. I tried several different modes. It always crashes with: "Memory Access Violation" Is there Sourcecode available to debug the problem ? Any other ideas ? Why is it only on this PC crashing ? |
| ||
| Hi, I don't know what the problem is, but I'd guess that it is the 64 Bit issue. Not sure what to do about it though. If this is going to be a problem for everyone, I'll have a look into replacing Blitzsys with something else. I was hoping to do a DecoratorMax at some point, but time has been hard to come by recently. As another point, could you test out Tattoo (in my sig.) as this also used blitzsys, so may be having the same issues :/ |
| ||
| Lee, while you're at it, I had some troubles with a non-square texture that was used as standard texture in Maplet. All textures in Decorator 1.8 scale nonsquare now, also the scaling functions work this way (both, mousewheel and fine scaling adjustment). It's pretty nifty to scale something in proper square proportions. May be a bug. Of course, now that I know it I won't use non-quare textures anymore in Maplet. But, as usual when you have finished half the map, there's no return. |
| ||
| @ TeraBit: Tattoo looks fine. It does not crash. I'm not sure if AMD 64Bit CPU is causing the crash. The CPU operates in "Legacy Mode" -> Protected Mode as far as i know. So this should not affect any applications. |
| ||
| @ TeraBit: Tattoo looks fine. It does not crash. Thanks for that. Not sure how to go about fixing it then :/ |
| ||
| So, the manufacturers (or nore often Microsoft) move the goal posts, and get it wrong. So then we, in this case Lee, have to consider rewriting our code (which usually means (surprise, surprise) buying a whole new development suite. I really hate this. Are we really all going to move to 64-bit because we're told to? I suspect that there will be many, many government departments for example who will say "Enough. We had an X million pound layout last time - we stick with what we've got." Let's face it, as car users we make our cars run for as long as possible - we don't let the maunfacturers tell us it time for change just coz they feel like it. |
| ||
| The problem is not with windows it with the blitzsys.dll. There is no need to use this now simply for file requesters as you can access the user32.dll directly. BlitzSys was created before Blitz had userlib capability. |
| ||
| BlitzSys was created before Blitz had userlib capability. True. But Blitzsys is just a wrapper for the same calls. Perhaps the same thing will happen if I call them directly. It depends on what is causing the issue. :/ |
| ||
| I've also updated the version of BlitzSys to the same one that Tattoo uses, so it may solve the 'BlitzSys crashing'. I've also tweaked a few other bits, so it's worth trying the new version. You can download 1.81 here |
| ||
| Great, it works again. :-) Thank you very much for your effort. rgds -Chi3f Stadi |
| ||
| Hi TeraBit, It works fine for desktop windows xp and win 98. However, whenever I run decorator 1.81 on my laptop, the whole computer freezes and is out of control after I move around for a while. Why? The laptop shares memory for video and system. Does this matter? Thanks in advance. Sammy :) |
| ||
| Not sure. It is very likely a driver thing. It uses the standard Blitz3D rending system, so nothing new there. Try running it in full screen mode (Take the W out of the first line of the prefs.txt file). |
| ||
| There is a problem with meshes containing more than about 10500 tris in one surface. Due to the fact that Decorator is unwelding the tris, this will result in 31500 Vertices. Although Meshes can be loaded in Decorator as long as there are less than 64k Vertices after unwelding (that's about 21k Tris), Decorator MAVes when I try to click a triangle. Loading Meshes with surfaces with more then 21k Tris MAVes during loading. When the max number of tris is below ~10500 then it works nicely, no MAV. So I guess the max number of Vertices is ~32000. I made a simple workaround that will recreate the mesh and split surfaces that have too many tris and add dummy surfaces. Some real textures must be created , and they need to be used by decorater, since blitz will collapse all surfaces that are using textures that were not found. Also, using brushes that are using the same texture won't work since Blitz will automaticly optimize (during LoadMesh) the surface count when there are identic brushes, resulting in too high tris count again. So for every new surface a dummy texture file is created, named by meshfilename+"_csptemp_"+index+".bmp". If they are once replaced in Decorator, the files can be deleted. It would be cool if this automatic splitting of oversized surfaces is implemented in Decorator one day. That said, with complex meshes (like the one I'm working on right now that has 90k Tris) the automatic plane painting tool is painful slow. If the plane scanning algorithm could be optimized, that would be great and I would even pay some money for it. AFAIK Decorator is the only tool that works this way. |
   |