BlitzMax 135 Up!
BlitzMax Forums/BlitzMax Programming/BlitzMax 135 Up!
| ||
Hi, Please visit product updates page of the account section for the latest BlitzMax update! Major news is the addition of an official d3d9 max2d driver. There are also some new max2d commands for setting 'virtual' resolutions. * Added VirtualMouseXSpeed/VirtualMouseYSpeed (test me!) * Default behaviour of Flip (ie: "Flip -1") has changed: 1) If graphics hertz was 0, no vsync. 2) If graphics hertz was not 0, uses soft vsync in windowed mode (ie: possible tearing), hard vsync in fullscreen. Note: Using "Flip False" or "Flip True" still works as before, forcing vsync off/on. * New BRL.Graphics command: GetGraphicsDriver:TGraphicsDriver() * New BRL.Max2D virtual resolution commands: SetVirtualResolution width#,height# VirtualResolutionWidth#() VirtualResolutionHeight#() VirtualMouseX#() VirtualMouseY#() MoveVirtualMouse( x#,y# ) * Added new official D3D9Max2DDriver. This is the new default for Windows. * D3D7Max2DDriver will no longer be supported on Vista/Windows 7 etc. |
| ||
Yay! |
| ||
It's great to see this officially out! The Dx9 driver works wonders even on my crap intel integrated card!! :D |
| ||
Wow! Thanks for your hard work! |
| ||
Awesome!, Thank you! |
| ||
Excellent :) Thanks... With * D3D7Max2DDriver will no longer be supported on Vista/Windows 7 etc. I take that it will still work as normal, but you are no longer supporting it? Whens the official D3D11Max2DDriver coming out? ;-) |
| ||
"D3D7Max2DDriver will no longer be supported on Vista/Windows 7" What about on Windows XP? |
| ||
Woohoo! Awesome update. Downloading now! EDIT: This is so awesome. My editor used to run at 790-820 FPS on my system. Now it's 1180-1190. That's a huge "free" performance gain. Thank you Mark! |
| ||
Perfect! Thanks a lot for your work! |
| ||
Great update, I know I`ve already said it before but thanks Mark. The Virtual commands are a godsend. Cheers for your hard work on this. Jason. |
| ||
Major news is the addition of an official d3d9 max2d driver. HAVE MY BABIES!There are also some new max2d commands for setting 'virtual' resolutions. [edit]Actually, no don't. But this is an awesome update and a huge digitus erectus to all those who keep harping on about "Blitzmax is never updated/sunk/dead/old". |
| ||
Thanks, Mark! |
| ||
I just posted a few times in the bug reports forum as there seems to be one or two teething troubles... |
| ||
What about on Windows XP? Can't you read? Mark already answered that ;) |
| ||
ahhh.. built-in projection matrix AND dx9 driver? awesome :) Thanks Mark!! |
| ||
Its both good and bad, unlike code that was posted by users this does not account for borders to prevent screen stretching. |
| ||
Excuse my stupidity, but what are virtual resolutions and what are they used for? |
| ||
Basically its a projection matrix. You write your game in 800x600 so everything's where it should be. After that you can change to any physical resolution, set the virtual res to 800x600, and everything is scaled to fit the bigger/smaller resolution. Witchcraft is involved. |
| ||
Witchcraft is involved. O.O |
| ||
Nice Update :) The new DX9 Driver is sweet maybe this means we can finally get some type of shaders working :) I agree with Snixx, the new Virtual Resolutions simplifies supporting multiple screen sizes somewhat, but it does not letterbox the screen as it should, ie you will get distorted images if you try to display an image made for 1280x800 on a screen of 800,600. |
| ||
Does this mean that a games window could be resized by the player? |
| ||
From another thread: ... for a quick test of the virtual graphics commands, run RockOut and play with the resolution in the Graphics call, eg. set it to your desktop size. RockOut is hard-coded with a 'game area' of 640 x 480, but using the virtual commands allows it to scale easily to any resolution. Don't forget to use the virtual mouse calls alongside the virtual graphics calls or you'll get wonky results. (I'm hoping we'll see aspect ratio correction added too!) |
| ||
cool , thx Mr.Sibly |
| ||
Thank you Mark. Probably the most important update in a long time, along with the previous multi-thread support. Now if we can convince you to add in a *x64 compile flag, BlitzMax will be good to go on most future OSs. *Everyone, please don't comment on how pointless 64-bit software is. It is the future. Just accept it. |
| ||
Nice update. It's definitely a speed improvement here over DX7 but the OpenGL driver is still the quickest for me. For anyone that's interested I updated TimelineFX for this version. Thanks to Doug Stastny for the excellent DX9 mod for use in the meantime! |
| ||
who keep harping on about "Blitzmax is never updated/sunk/dead/old". Whomever was saying that doesn't know Mark very well. Generally, in my experience, long update blackouts are times when Mark has a big project on the go that is just not ready... I'm hoping for a native Max3D for Christmas ;) Pete Rigz, Thats my experience as well, but I think it depends on what you are doing. Almost every test I did OpenGL came up faster by 3-4ms minimum (not that it means anything without the test code lol) |
| ||
Oh Oh ! Does virtual resolution easy to use ? Currently I have a 2D platform game that can have multiple screen resolutions but each one reveal more or less tiles and game field. Would be nice to lock it to 1024x768 and then only change that virtual value to display it at any size. But what about all my SetViewport() function ? I need to test that thing right now. |
| ||
errr... I was almost ready to ***** my ***** until I realized this: "(I'm hoping we'll see aspect ratio correction added too!)" Seriously, add aspect support, black bars if needed on the top/sides,etc, and the update is easily worth another $50.00!! |
| ||
Currently its pretty much useless without the aspect ratio correction so i have no idea why it was even added in this patch. Not a proper job as of yet. |
| ||
Yeah that true. I hope to see the aspect ratio support too. |
| ||
Don't most video drivers have aspect ratio correction built in? I'll grant you that most people do not turn it on. (same thing with widescreen TV, people watching old shows in widescreen without the borders drive me nuts) |
| ||
Seriously, add aspect support, black bars if needed on the top/sides,etc, and the update is easily worth another $50.00!! I wouldn't go that far.. but I think Mark was a bit fast on the release trigger. |
| ||
Is that worse than watching new shows on old TVs with half the faces chopped off? :( |
| ||
By the way. I just try the new projection matrix stuff. It's impressive but I have a few function to rewrite particular low level OpenGl function for DrawTexturedPoly and the like. Logically the CeGui module of brucey still display itself at normal resolution which is a good thing except if you plan to use your game on tiny device with 640x480 or less resolution (GUI is then too large for that resolution obviously). Mark, this virtual feature come at an excellent timing really ! Since I simply write my tile engine to use as much as viewport available, I just needed to choose the desired resolution and keep everything else intact as well as any viewport code :D AWESOME ! One thing I don't need to worry about, and today it was very welcome. Thank you |
| ||
Oh and I just try a virtual resolution of 1024x768 at real resolution of 1280x800 and it render at correct ratio ! Even if the rendering isn't centred and lead to black rectangle on the right and on the bottom of the screen. Now like Dynaman is saying I don't know if it's hardware or BlitzMax feature. EDIT The low level OpenGl is not responsible for the few glitch I encountered but GrabImage() is probably more responsible. Maybe the virtual code support isn't present inside that function ? Can someone confirm that ? |
| ||
With regards to cards with aspect ratio correction inbuilt, yes most if not all modern cards do this, but as far as im aware it only helps when you want to display a 4:3 ratio game on a 16:9 or 16:10 display. So it will add black borders to the left and right of the screen so the image is square not rectangular. What we want ideally is for max to do the opposite, so you make your game at a 16:9 ratio and if someone with a 4:3 monitor wants to play your game, they still can but with borders on the top and bottom. |
| ||
And I don't know why but now my game has a lot more tearing than before but I never use flip -1. Now I need to activate VSYNC most of the time and it's not as smooth for unknown reason... Nobody experienced problem with GrabImage() while using the virtual resolution ? I don't know well what to do about this, maybe a virtualGrabImage() would help. I wish you could draw upon texture and don't need to use crappy GrabImage... |
| ||
Well I made this temporary VirtualGrabImage() until the official one :Rem bbdoc: Grab an image from the back buffer with Virtual support about: Copies pixels from the back buffer to an image frame. Only images created with the DYNAMICIMAGE flag can be grabbed. End Rem Function VirtualGrabImage(image:TImage, X:Int, Y:Int, Frame:Int = 0) Local gcr:Int, gcg:Int, gcb:Int GetMaskColor(gcr, gcg, gcb) Local gcw:Float = VirtualResolutionWidth() / GraphicsWidth() Local gch:Float = VirtualResolutionHeight() / GraphicsHeight() Local pixmap:TPixmap = _max2dDriver.GrabPixmap(X / gcw, Y / gch, image.width / gcw, image.Height / gch) If image.flags&MASKEDIMAGE pixmap = MaskPixmap(pixmap, gcr, gcg, gcb) EndIf image.SetPixmap(Frame, pixmap) End Function Work correctly now :) |
| ||
It's worth 50.00 to me because if Mark cleans up the bugs, adds proper aspect support, etc, this easily adds a HUGE life span to the product. wow...very pumped up about bmax again. :) |
| ||
Effectively the aspect support is welcome because I try some others resolution in full screen mode and not exactly the same portion of screen was rendered. Work fine when the resolution is reduced but not when increased (and squished on some weird resolutions obviously). And the black area to the right and bottom part of the screen is rather annoying. I really hope to see the final version of this feature in a near future ! |
| ||
Does anyone have problems using loadsound in a seperate thread with this new build? My code is now crashing when I call loadsound more than once. |
| ||
I feel like I'm missing out on something, because I don't see what's so useful it would be worth 50.00 somethings? Virtual resolutions seem nice and handy but I don't get it? :S |
| ||
GarageGames' Torque 2D costs $250 and does not run on Linux (bummer D: ). BlitzMax costs $80 and runs on all 3 platforms. This is an incredible value in my eyes, and I hope BRL charges something for every 0.10 they accomplish but it's really up to them and their business model. Even GLBasic ($80) has just a Windows-only development environment (it compiles code for many platforms), but it's Windows-only development environment, and what I believe to be an overreaching philosophy (the number of platforms (6+) they develop for), were the reasons I chose BlitzMax. |
| ||
I feel like I'm missing out on something, because I don't see what's so useful it would be worth 50.00 somethings? Virtual resolutions seem nice and handy but I don't get it? :S Don't forget the addition of DirectX 9 -- that by itself is a biggie, too. |
| ||
And what about GetViewport() and SetViewport() ? I suppose you also need to tweak those 2 functions in order to support Virtual resolutions. I wonder how many function I need to change... Plus the function names doesn't feel like the rest of Max2d (virtualResolutionWidth() while graphicsWidth() or MoveVirtualMouse() and VirtualMouseX() while moveMouse() and MouseX()). A temporary version of SetVirtualViewport() and GetVirtualViewport() until the official one :) Rem bbdoc: Set Virtual drawing viewport about: The current ViewPort defines an area within the back buffer that all drawing is clipped to. Any regions of a DrawCommand that fall outside the current Virtual ViewPort are not drawn. End Rem Function SetVirtualViewport(X:Int, Y:Int, Width:Int, Height:Int) Local gcw:Float = VirtualResolutionWidth() / GraphicsWidth() Local gch:Float = VirtualResolutionHeight() / GraphicsHeight() X:/gcw Y:/gch Width:/gcw Height:/gch SetViewport(X, Y, Width, Height) End Function Rem bbdoc: Get Virtual dimensions of current Viewport. returns: The horizontal, vertical, width and height values of the current Virtual Viewport in the variables supplied. End Rem Function GetVirtualViewport(X:Int Var, Y:Int Var, Width:Int Var, Height:Int Var) Local gcw:Float = VirtualResolutionWidth() / GraphicsWidth() Local gch:Float = VirtualResolutionHeight() / GraphicsHeight() GetViewport(X, Y, Width, Height) X:*gcw Y:*gch Width:*gcw Height:*gch End Function Also, I choose to draw border to every viewport camera. I now need to tweak them now because 1 pixel shift incorrectly here and there :s |
| ||
Also Grabimage create some kind of dithering when used in different virtual resolution... That mean even if you are using full alpha pixel in you texture with a maskbit background you see ugly anarchic border around your grabed image : Except with a RTT I don't know how I could resolve this problem :s I also open a new topic for that specific problem but with positioning/sizing : http://blitzmax.com/Community/posts.php?topic=87849 |
| ||
Well for that problem I simply 1) Backup and set the virtual Resolution equal to the current real resolution 2) draw my image and grabimage it 3) restore the previous virtual resolution It's a bit ugly but working correctly now :) HTH But still remain my problem with positioning/sizing : http://blitzmax.com/Community/posts.php?topic=87849 if anyone can help : it's welcome :D |
| ||
Thanks Mark. Sounds like a cool update. For those who are interested: The reason DX7 was slow was there was a fix in there (added about 3 years ago) to stop render lagging which reduced the framerate a lot (but made it stable). I presume that DX9 doesn't need the fix, which would mean a faster frame rate, but has anyone tested if the lag exists in DX9 (hopefully not)? I'm still using the DX7 driver, and it seems fine in Vista and Windows 7. I'm presume that it's no longer being supported because it's old, but at least it seems to work OK. I guess I can make my game test the OS and switch to DX9 for Vista and Win7 and keep DX7 for older OSes. I'll do that when everyone is 100% happy with DX9. Regarding the virtual resolution, has anyone tried it with tiles yet to see if there are edge artefacts between the tiles. Unless some magic has happened, I imagine this is still the case. The thing with virtual res is that for some types of games it can really reduce the quality, whereas it works very well for other sorts. |
| ||
I'm still using the DX7 driver, and it seems fine in Vista and Windows 7 Its not that fine Jake, Gfk found a nasty bug in it awhile ago [Edit: Ah youve already seen it ;-)] Regarding the virtual resolution, has anyone tried it with tiles Isnt that what Armitage is doing? http://blitzmax.com/Community/posts.php?topic=87849 |
| ||
As Therevills said my game is made of tiles and while I don't have any artefacts between them I do have problems with SetViewPort positioning with floating values. My tiles are 32x32 (I see no artefacts either with 24x24) and appear to be ok even while zooming (because I respect the tile format) anywhere I place the viewport 'camera'. But objects positioned with floating values as well as the viewport itself shift about 1 pixel because of the reduction factor. It's like the problem of drawing a 1 pixel line right in the middle of a pixel coordinate which is impossible. I thought that the accelerated smoothing reduction would take care of this for me but it does not work this way I presume (like scaling down images with different reduction mode in graphic tools). I think that's really the last problem that I have with virtual resolution. I do not know if the aspect ratio would help in this case... Maybe I need to place my camera viewport to precise integer pixel coordinates. |
| ||
Does using the DX9 driver mean that the viewport commands now use scissor tests rather than clip panes? This would be good for avoiding that irritating issue with some cards not supporting the required 4 clip panes, leaving viewports not functioning correctly. |
| ||
Would always overlapping images by 1 or 2 pixels be a suitable workaround, Armitage? Not sure if that is what you are talking about, but? |
| ||
Unfortunatly no. It's simply a rounding errors with the viewport positioning and size. I need to find the nearest round coordinances for the desired resolution in order to disable that bug. |
| ||
Yah changing the projection matrix isn't going to fix the tile issues. |
| ||
Nobody else is trying to use the Virtual Resolution ? I can't position and render any viewport correctly with this feature : http://blitzmax.com/Community/posts.php?topic=87849 I wrote a small program to demonstrate the problem: SetGraphicsDriver GLMax2DDriver() Graphics(640, 480) SetVirtualResolution(1024.0, 768.0) Local CW:Float = 250.0 Local CH:Float = 141.0 SetBlend(LIGHTBLEND) SetAlpha(0.75) While Not KeyHit(KEY_ESCAPE) ' Press SPACE to cycle various virtual resolution If KeyHit(KEY_SPACE) Select VirtualResolutionWidth() Case 1280.0 SetVirtualResolution(640.0, 480.0) Case 1024.0 SetVirtualResolution(1280.0, 1024.0) Case 640.0 SetVirtualResolution(800.0, 600.0) Case 800.0 SetVirtualResolution(1024.0, 768.0) End Select End If If KeyHit(KEY_ENTER) If CW = 250.0 CW = 320.0 CH = 240.0 Else CW = 250.0 CH = 141.0 End If EndIf Cls() SetColor(128, 128, 255) drawCamera(VirtualMouseX(), VirtualMouseY(), CW, CH) 'Draw the viewport in the middle of the screen SetColor(128, 255, 128) drawCamera((VirtualResolutionWidth() - CW) / 2.0, (VirtualResolutionHeight() - CH) / 2.0, CW, CH) 'Draw the viewport at 0,0 SetColor(255, 128, 128) drawCamera(0.0, 0.0, CW, CH) SetColor(255, 255, 255) drawCamera(0.0, 0.0, VirtualResolutionWidth(), VirtualResolutionHeight()) SetScale(VirtualResolutionWidth() / GraphicsWidth(), VirtualResolutionHeight() / GraphicsHeight ()) DrawText("Press SPACE to cycle virtual resolution and ENTER to change camera size", 10.0, 10.0) DrawText("Virtual Resolution:" + Int(VirtualResolutionWidth()) + "x" + Int(VirtualResolutionHeight()), 10.0, 32.0) SetScale(1.0, 1.0) Flip() Wend Rem bbdoc: Simply draw a viewport Camera with border line End Rem Function drawCamera(camX:Float, camY:Float, camWidth:Float, camHeight:Float) SetVirtualViewport(camX, camY, camWidth, camHeight) ' Reset View Port Origin for Layer Rendering SetOrigin (camX, camY) DrawLine(0.0, 0.0, camWidth - 1.0, 0.0) DrawLine(0.0, 0.0, 0.0, camHeight - 1.0) DrawLine(0.0, camHeight - 1.0, camWidth - 1.0, camHeight - 1.0) DrawLine(camWidth - 1.0, 0.0, camWidth - 1.0, camHeight - 1.0) End Function Rem bbdoc: Set Virtual drawing viewport about: The current ViewPort defines an area within the back buffer that all drawing is clipped to. Any regions of a DrawCommand that fall outside the current Virtual ViewPort are not drawn. End Rem Function SetVirtualViewport(X:Int, Y:Int, Width:Int, Height:Int) Local gcw:Float = VirtualResolutionWidth() / GraphicsWidth() Local gch:Float = VirtualResolutionHeight() / GraphicsHeight() X:/gcw Y:/gch Width:/gcw Height:/gch SetViewport(X, Y, Width, Height) End Function On some resolution the last vertical and horizontal lines are unavailable (move Mouse Camera on screen borders to see that). Is this is related to the problem of ratio? I also discover that virtualMouseX() and virtualMouseY() aren't precise enough in that case. |
| ||
The projection matrix is scaling your rendered image down, you _will_ lose some information, especially with thin 1-pixel lines. |
| ||
So there is nothing we can do about that ?? I will have to determine every position and every size where things actually correctly rendering for every resolution ? There must be a way to position each viewport and still get maximum visual informations. That would be useless for pixel perfect game then :( |
| ||
With hardware accelerated subpixel accuracy your pixels will never be perfect again so yes you don't need the smiley, floating point coordinates or these new commands if you want to code in a pixel perfect manner. You could fix some of your code replacing 1.0 with virtual version but there is still rounding on all your viewports as they are still integer in nature and don't fit the magnification model. Current BlitzMax viewport implementation is restrained by behavior of old geforce cards as a floating point viewport based on clipping plane hardware would solve the other issue your code has due to rounding at integer viewport boundaries. |
| ||
Well I try some of your ideas Skidracer but none of them work (or I probably don't correctly use them). I shift size and position of viewport for common resolution and this seems to work except with resolution higher to the virtual one (eg. gap between objects are visible at 1280x1024 even while setting the same virtual resolution of 1280x1024 which is bad). I'm loosing too much time on this and really don't know if I will use virtual resolution up to 1024x768 OR a unique screen resolution to skip all those problems. After all many great 2D games don't allow to change resolution and it's rare for common user to do so. |
| ||
The reality is LCD monitor has a native resolution, analog CRT does not. This means best practise for LCD is always use desktop resolution or even division of it. Here is your code with extra rounding for the viewports, it may well be usable, not sure. note the use of onex and oney to denote size of pixel and extra pixel in viewports to accommodate integer rounding of parameters the tweak to setorigin is I think needed due to aspect ratio difference and will break when aspect is dominant in x axis, it may be due to rounding on first arguments of setviewport... |
| ||
Thanks This is roughly what I try except the huge tweak around the SetVirtualViewport(). The code above seems to work but not with all resolutions for me. As I am not very comfortable with this exercise I will stick to a unique resolution until further update. |
| ||
I think this code rounds correctly, the setorigin now uses the rounded value to position top left of viewport which will keep you near pixel perfect. It would possibly be tidier if not better to do everything in centered coordinates meaning viewports would end up with even width and height physical pixels no matter what.Function SetVirtualViewport(X:Int, Y:Int, W:Int, H:Int) Local xx:Float = GraphicsWidth()/VirtualResolutionWidth() Local yy:Float = GraphicsHeight()/VirtualResolutionHeight() x=Floor(xx*x) y=Floor(yy*y) w=Floor(xx*w) h=Floor(yy*h) SetOrigin x/xx,y/yy SetViewport x,y,w+2,h+2 End Function |
| ||
Great stuff :) I'm doing some testing with virtual screenresolution and it also, not surprisingly, resizes DrawText. I find text downscaling much more noticeable than sprites. I was hoping to use 1600x1200 as a virtual screen resolution to make it look nice in higher resolutions. Any thoughts on this? Update: Ignore this post, I am a bit of an idiot =) You can set virtual resolution at any time of course, prior to drawing text for example then switch back. |