BlitzMax 135 Up!

BlitzMax Forums/BlitzMax Programming/BlitzMax 135 Up!

marksibly(Posted 2009) [#1]
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.




GW(Posted 2009) [#2]
Yay!


ziggy(Posted 2009) [#3]
It's great to see this officially out! The Dx9 driver works wonders even on my crap intel integrated card!! :D


rs22(Posted 2009) [#4]
Wow! Thanks for your hard work!


Jesse(Posted 2009) [#5]
Awesome!, Thank you!


therevills(Posted 2009) [#6]
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? ;-)


MGE(Posted 2009) [#7]
"D3D7Max2DDriver will no longer be supported on Vista/Windows 7"

What about on Windows XP?


_JIM(Posted 2009) [#8]
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!


degac(Posted 2009) [#9]
Perfect! Thanks a lot for your work!


QuickSilva(Posted 2009) [#10]
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.


GfK(Posted 2009) [#11]
Major news is the addition of an official d3d9 max2d driver.

There are also some new max2d commands for setting 'virtual' resolutions.
HAVE MY BABIES!

[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".


Amon(Posted 2009) [#12]
Thanks, Mark!


GfK(Posted 2009) [#13]
I just posted a few times in the bug reports forum as there seems to be one or two teething troubles...


GaryV(Posted 2009) [#14]
What about on Windows XP?
Can't you read? Mark already answered that ;)


Wiebo(Posted 2009) [#15]
ahhh.. built-in projection matrix AND dx9 driver? awesome :) Thanks Mark!!


Snixx(Posted 2009) [#16]
Its both good and bad, unlike code that was posted by users this does not account for borders to prevent screen stretching.


Czar Flavius(Posted 2009) [#17]
Excuse my stupidity, but what are virtual resolutions and what are they used for?


GfK(Posted 2009) [#18]
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.


Amon(Posted 2009) [#19]
Witchcraft is involved.



O.O


CyBeRGoth(Posted 2009) [#20]
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.


Arowx(Posted 2009) [#21]
Does this mean that a games window could be resized by the player?


BlitzSupport(Posted 2009) [#22]
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!)


Panno(Posted 2009) [#23]
cool , thx Mr.Sibly


Tachyon(Posted 2009) [#24]
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.


Pete Rigz(Posted 2009) [#25]
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!


_Skully(Posted 2009) [#26]
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)


Armitage 1982(Posted 2009) [#27]
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.


MGE(Posted 2009) [#28]
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!!


Snixx(Posted 2009) [#29]
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.


Armitage 1982(Posted 2009) [#30]
Yeah that true.
I hope to see the aspect ratio support too.


dynaman(Posted 2009) [#31]
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)


plash(Posted 2009) [#32]
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.


Czar Flavius(Posted 2009) [#33]
Is that worse than watching new shows on old TVs with half the faces chopped off? :(


Armitage 1982(Posted 2009) [#34]
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


Armitage 1982(Posted 2009) [#35]
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 ?


CyBeRGoth(Posted 2009) [#36]
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.


Armitage 1982(Posted 2009) [#37]
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...


Armitage 1982(Posted 2009) [#38]
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 :)


MGE(Posted 2009) [#39]
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. :)


Armitage 1982(Posted 2009) [#40]
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 !


zambani(Posted 2009) [#41]
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.


Czar Flavius(Posted 2009) [#42]
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


theHand(Posted 2009) [#43]
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.


xlsior(Posted 2009) [#44]
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.


Armitage 1982(Posted 2009) [#45]
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


Armitage 1982(Posted 2009) [#46]
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


Armitage 1982(Posted 2009) [#47]
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


Grey Alien(Posted 2009) [#48]
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.


therevills(Posted 2009) [#49]
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


Armitage 1982(Posted 2009) [#50]
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.


Fry Crayola(Posted 2009) [#51]
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.


theHand(Posted 2009) [#52]
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?


Armitage 1982(Posted 2009) [#53]
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.


ImaginaryHuman(Posted 2009) [#54]
Yah changing the projection matrix isn't going to fix the tile issues.


Armitage 1982(Posted 2009) [#55]
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.


Muttley(Posted 2009) [#56]
The projection matrix is scaling your rendered image down, you _will_ lose some information, especially with thin 1-pixel lines.


Armitage 1982(Posted 2009) [#57]
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 :(


skidracer(Posted 2009) [#58]
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.


Armitage 1982(Posted 2009) [#59]
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.


skidracer(Posted 2009) [#60]
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...




Armitage 1982(Posted 2009) [#61]
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.


skidracer(Posted 2009) [#62]
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



Imphenzia(Posted 2009) [#63]
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.