MaxGUI Bug with 1.36
Archives Forums/BlitzMax Bug Reports/MaxGUI Bug with 1.36
| ||
| For the last 2 years my map editor has worked perfectly. During this time I have made no changes at all to the way my map editor draws to the GUI canvases, and it has worked perfectly through the last 6-7 versions of BliztMax and MaxGUI. Now, with the latest BlitzMax (1.36) and MaxGUI (1.34) I have a horribly crippling bug, though I have made no changes to the code that would account for it. The bug popped up when I tried to compile the Map Editor with the latest BliztMax and MaxGUI, just to update some GUI text. Examine the screenshot of the map editor below. I have downsized it for easy viewing, but the bug should be clear. The largest canvas in the majority of the upper-left of the window is my Map_Canvas object. It draws the current map. The canvas that I have highlighted with the red square is my Tile_Canvas object, and it displays a "palette" of tiles that I can draw with. The problem is that the Tile_Canvas should be just the tiles in the gray area on the left half. That gray tile palette should be expanded the full width of the red box. What we see is that the Tile_Canvas is now some horrible abomination of a mixture of the right-side of the Map_Canvas, compressed into the Tile_Canvas. As I have said, I've made no changes to the drawing code for nearly 2 years, and it has worked fine through multiple updates of BliztMax. Now I get this anomaly, and the code is very straight-forward. There is no reason that I can find for this problem!  |
| ||
| See here: http://www.blitzbasic.com/Community/posts.php?topic=88104 |
| ||
| Thank you for pointing me to that jsp!! I was about to break something! Adding SetGraphicsDriver D3D7Max2DDriver() fixes it for me, which is completely fine for now. I don't need DX9 for my editor. |
| ||
It appears as though the DX9 TGraphics instance doesn't update the width and height fields of the context after it is initially created. DX7 has a ValidateSize() method in d3d7graphics.bmx for handling this, but a corresponding set-up appears to be missing for the DX9 Graphics context:Method ValidateSize() If _depth Return Local rect[4] GetClientRect _hwnd,rect Local width=rect[2],height=rect[3] If width<=0 Or height<=0 Return If width=_width And height=_height Return dlog "Size invalidated" DestroyRenderSurface _width=width _height=height End Method |
| ||
| Hi, Can you please try this: http://www.blitzbasic.com/tmp/dxgraphics.mod.zip unzip into your mod\brl.mod dir. Let me know if it works! |
| ||
| Okay Mark... This new update still works fine with DX7. It works nearly 100% with DX9. The strange problem above with the Tile_Canvas is gone - that canvas works fine. However, do you see that small black window below the map? That is actually a 3rd canvas, and I was just using that to display a bitmap "cheat sheet" for keyboard shortcuts. It is drawn black black under DX9, but is drawn fine under DX7 and OpenGL. This update did not fix that canvas- it is still black under DX9. Now, hang on because there is something REALY WEIRD that just showed up under OpenGL. All the zeros that are drawn via DrawText onto the canvas are actually a mini tile from my game! The very first tile (Tile 1) is a isometric grass tile, and every zero drawn to the screen is actually a tiny little compressed tile of grass!! It is the strangest lookng thing. I can send a screenshot of you need it, but clearly something is crossing over into the DrawText command now. |
| ||
| Hi, Can you post some runnable code? Screenshots or dodgy graphics are unlikely to be useful. |
| ||
Ok, let's tackle the black canvas first. Here is some sample code. I am very sorry if my programming style is clunky -- I often still have to work at enforcing proper OOP manners.
SuperStrict
Import maxgui.drivers
SetGraphicsDriver D3D7Max2DDriver()
'SetGraphicsDriver D3D9Max2DDriver()
'SetGraphicsDriver GLMax2DDriver()
'// Create our GUI elements
Global Editor:TGadget = CreateWindow("GUI Test", 10, 10, 640, 480)
Global Canvas1:TGadget = CreateCanvas(10, 10, 160, 120, Editor, Null)
Global Canvas2:TGadget = CreateCanvas(180, 10, 160, 120, Editor, Null)
Global Canvas3:TGadget = CreateCanvas(350, 10, 160, 120, Editor, Null)
'// Load in some Graphics. You just need some generic 160 x 120 .png files.
Global img1:TImage = LoadImage("img1.png")
Global img2:TImage = LoadImage("img2.png")
Global img3:TImage = LoadImage("img3.png")
'// Fill in our canvases
SetGraphics CanvasGraphics(Canvas1)
DrawImage img1,0,0
Flip
SetGraphics CanvasGraphics(Canvas2)
DrawImage img2,0,0
Flip
SetGraphics CanvasGraphics(Canvas3)
DrawImage img3,0,0
Flip
Repeat
WaitEvent()
Select EventID()
Case EVENT_WINDOWCLOSE
If EventSource() = Editor Then End
End Select
Forever
The graphics I used are just .png files with a hand-drawn number on them (1,2,3) placed in the working directory. Switching graphics drivers and re-compliling, the DX9 driver draws all 3 canvases black. DX7 and OpenGL draws them normally. Again, maybe I am just not doing it properly? Done on Windows 7 with ATI Radeon 5850 video card, all drivers up-to-date. |
| ||
| What if you enable shared contexts? (or is that a Mac-only thing? - to whom ever knows the answer) |
| ||
| I thought that was a GL-only thing? |
| ||
| Hi, Can you please try this: http://www.blitzbasic.com/tmp/dxgraphics.mod.zip unzip into your mod\brl.mod dir. Let me know if it works! That seems to fix it! :-) Quite a few peeps are coming across this problem and posting bug reports against MaxGUI. Would it be possible to get a patched Windows build of BlitzMax 1.36 uploaded? |
| ||
| Hi, > Ok, let's tackle the black canvas first. Here is some sample code. Try replacing 'Flip' with 'Flip False' - bigger fix coming soon. The problem here is that the only way you can modify the swap interval in D3D9 is by resetting the entire device which interferes with the actual Flip. It may be that a command like SetSwapInterval will be needed to deal with this - dunno yet. |
   |