BlitzMax 137 now up!

BlitzMax Forums/BlitzMax Programming/BlitzMax 137 now up!

marksibly(Posted 2010) [#1]
Hi,

Blitzmax 137 is now available from the product updates page of the account section.

This is mainly a bugfix release, including:


* Fixed some bugs in bbStringFromUTF8()

* Fixed some leaks in pub.libjpeg module.

* Added .cc and .hh file extension support to bmk.

* Fixed image memory leak in d3d9max2d driver.

* Max2d SetViewport now works in virtual coordinates as set by SetVirtualResolution.

* Max2d virtual resolution now resets when graphics resized - really only relevant for canvases.




GfK(Posted 2010) [#2]
Good stuff. Nearly midnight here but I'll test tomorrow. :D

[edit] By the way - Otus has posted a brilliant appstub mod tweak that allows full debugging in threaded mode. Subject to a bit of testing, it definitely needs adding to an official release.


ziggy(Posted 2010) [#3]
I can confirm the canvas issue is fixed... :P


Brucey(Posted 2010) [#4]
Added .cc and .hh file extension support to bmk

Yay! :-p

I suppose the Max2D updates will break all my mods again? :-)


therevills(Posted 2010) [#5]
Thanks for the update Mark!


Arowx(Posted 2010) [#6]
Darn it now I've got nothing to complain about or procastinate over, Mark! ;o)


sebas76(Posted 2010) [#7]
I hope overloaded method is ready in this release.


Brucey(Posted 2010) [#8]
I hope overloaded method is ready in this release.

Ha... :-p


Jesse(Posted 2010) [#9]
Free Audio still does not work here. is it still being supported in BlitzMax? Anybody else have that problem? It just doesn't play any sound on my system.


John G(Posted 2010) [#10]
With each new version -- thanks Mark -- I Rebuild Documentation. Should we also Build Modules or Rebuild All Modules each time? Cheers.


xlsior(Posted 2010) [#11]
Should we also Build Modules or Rebuild All Modules each time?


You shouldn't have to for the standard modules - but if you are using any 3rd party modules, you may need to recompile those depending on the changes in the new version. (Changes to core components like the garbage collector may need a recompile)

It may not always be necessary to recompile the modules, but it won't hurt either.


degac(Posted 2010) [#12]
Ohh! Downloading now!
Thanks!


Docster(Posted 2010) [#13]

Free Audio still does not work here. is it still being supported in BlitzMax? Anybody else have that problem? It just doesn't play any sound on my system.



I have the same problem with BRL.FreeAudioAudio, so I use BRL.DirectSoundAudio instead. Works as a charm! :)

Nice update Mark!


Mr. Write Errors Man(Posted 2010) [#14]
Yeah, thanks for the update.


Chalky(Posted 2010) [#15]
Thanks for the update.

I have the same problem with BRL.FreeAudioAudio

Me too. Maybe FreeAudioAudio is no longer going to be supported due to lack of demand? I realise there are workarounds but it would be nice if each release of BMax was backwardly compatible with existing code.


GaryV(Posted 2010) [#16]
Does FreeAudio still work for Linux?


Jesse(Posted 2010) [#17]
well the module is included with the newest update. It just looks like something broke in the process of updating.

Has anyone experienced the lag that DirectSound has on windows Vista with Windows 7?


marksibly(Posted 2010) [#18]
Hi,

FreeAudio seems to be going OK here, and it hasn't been touched for a while now.

If I add 'Print SetAudioDriver( "FreeAudio" )' at the top of rockout, it prints 1 and audio is OK.

Note that FreeAudio is no longer the default sound driver under windows - the directsound driver is now.


Chalky(Posted 2010) [#19]
Doh! That would explain it then. It now works fine!


Jesse(Posted 2010) [#20]
Thanks Mark! I didn't know I had to set that flag on. It works fine here now thanks!


Armitage 1982(Posted 2010) [#21]
Thanks for this update Mark !
Everything still working fine here :)


Nate the Great(Posted 2010) [#22]
thanks for the update!


marksibly(Posted 2010) [#23]
Hi,

Hmmm...does this mean people are having trouble with the DirectSound (default) audio driver?!?


GfK(Posted 2010) [#24]
Wouldn't it be less of a headache to just use OpenAL as the default audio driver?


ziggy(Posted 2010) [#25]
Hmmm...does this mean people are having trouble with the DirectSound (default) audio driver?!?

Maybe the move to DirectSound is making some games with a Framework+imports based on FreeAudio stop playing sound? This scenario could cause this 'false' issues. Can anybody having this problems tell if importing DirectSound fixes anything? I know, this new 'default' behavior should be set at the directsound module but I've been looking to the source, and haven't found it (maybe it's me being blind).


marksibly(Posted 2010) [#26]
Hi,

> Wouldn't it be less of a headache to just use OpenAL as the default audio driver?

Well, I've got no idea what's even causing the heartache right now so I have no idea whether it's FreeAudio/DirectSound or even game framework issue.

But...wouldn't using OpenAL as default mean that apps would have to ship with OpenALL.dll? esp. in Windows 7 land where it may well not be installed? Isn't that a major PITA for the 'default' audio driver?

Also, to the best of my knowledge, DirectSound is still the most reliable way to do audio on Window in general - MS has broken multimedia device audio in Vista/Windows7 and while OpenAL works when it works, I doubt whether it has the breadth of support DirectSound has, which MS are more or less obliged to make work to support all those older XP etc games.


GfK(Posted 2010) [#27]
Well, I can only speak for meself. And since its no big deal to change the audio driver to whatever I want, it doesn't much matter to me what the default is. Fair point about the DLLs though (There's actually two for OpenAL) - the BlitzMax installer would need to include the OpenAL installer and run it in quiet mode at the end of the installation, which may or may not be a problem? Or maybe just more bother than its worth since anybody who wants OpenAL can just go get it anyway.

I had all the usual problems with FreeAudio/DirectSound when I was developing in Vista (1-second lag, and crackly sound) and I honestly haven't tried either recently, so I don't know how they fare. I use MaxMod for streaming audio, and I think its openAL-dependent, so I couldn't really use anything else even if I wanted to.

Anyway, that's my ill-placed $0.02 on audio drivers. :)


therevills(Posted 2010) [#28]
Are you sure that OpenAL has to be "installed"?

In the past I've just distributed the DLLs (OpenAL32.dll and wrap_oal.dll) with my exes and they have worked.


Chalky(Posted 2010) [#29]
Maybe the move to DirectSound is making some games with a Framework+imports based on FreeAudio stop playing sound?

That's certainly the issue with my code - although adding a SetAudioDriver "FreeAudio" does cure the problem.


Brucey(Posted 2010) [#30]
Are you sure that OpenAL has to be "installed"?

A dll is a dll, I thought, so simply dropping it in the app folder should work?


sebas76(Posted 2010) [#31]
And for overloaded method/functions ?
Will it be implemented one days in bmax ?


hub(Posted 2010) [#32]
Mark is it possible to add 'GetAudioDriver' to the next bmax release ? just to kwow what's the audio driver automatically used by bmax (usefull for debug purpose !)
Thanks !


plash(Posted 2010) [#33]
hub: I'm pretty certain the last imported audiodriver module would be automatically set as the current driver.
Obviously, though, if you're not using Framework it can be hard to tell which one is imported last..


GfK(Posted 2010) [#34]
No, OpenAL doesn't need to be installed, but the DLLs are best placed in either the Windows folder, or the folder in which the executable resides.

If the Blitz installer just plonked the DLLs in the installation folder, I'm not sure how that'd sit with using OpenAL as the default audio driver. It probably wouldn't work.


therevills(Posted 2010) [#35]
Ahhh I understand now.

If the Blitz Installer places (somehow) the DLLs into the Windows folder and OpenAL becomes the default driver, some people may not know that when they distribute their exe they must also distribute the DLLs...

One (dodgy) way we could get around this is when the Blitz compiler compiles it places a copy of the DLLs in the same folder as the compiled exe...


byo(Posted 2010) [#36]
Thanks a lot for this update. :)


Grey Alien(Posted 2010) [#37]
I still use FreeAudio for 98/Me/2000/XP, it's fine. Then OpenAL (via dlls plonked in the exe folder) for Vista/Win7. This combo works well, has been tested by QA and a huge amount of BFG customers.

I found OpenAL sounded nicer than DirectSound which was louder and sometimes a bit "noisy/clicky" plus I found a couple of other minor issues if I recall, but that was about 3 years ago, so it may be better now, dunno.


Dreamora(Posted 2010) [#38]
I still use FreeAudio for 98/Me/2000/XP, it's fine. Then OpenAL (via dlls plonked in the exe folder) for Vista/Win7


Just ensure to use the right one on OpenAL. otherwise x64 users especially i7 users will find a nonstarting app because the wrong dll is used.
Its normally the better idea to integrate the openal installer and run it, that way the right dll is on the system and in the right place


ziggy(Posted 2010) [#39]
@Dreamora: Are you sure it is a good idea to use a 64 bits dll from a 32 bit app? Windows will handle properly any 32 bits dll used from within a 32 bits application.


Dreamora(Posted 2010) [#40]
Just to explain that, he answered while I edited.
@ziggy: the problem is not what I'm using, the problem is that the devs mess it totally. they provide a dll with their app that overrides my system installed one, yet that provided dll can and will not and never work on win 7 / win vista 64 at least for sure not on core i7 systems (its the only 64bit I have at the time).

For that reason I am forced to manually delete the dll provided so the app uses the correct one actually, not the one the "dev believed to be the right one"

Just to get that straight: many engines have this problem. Even the just release Global Agenda thats using UE3 is having that problem, same for osmos and any other recently released title on steam that uses openal.

I would be more than happy to punch a few faces at the Steam QA team that let this stuff still pass although me and several dozen users post on the boards about it, drop forms etc.
OpenAL32.dll is a big no no in your project folder unless you are willing to handle the fair and appropriate anger over the ignorance.
You don't include DX9 dlls too in installers, you include the dx installer and run it silently and the very same holds for openal.


therevills(Posted 2010) [#41]
Dreamora, Im using a core i7 on Win 7 64bit and the "provided" dlls work fine...

OpenAL32.dll is a big no no in your project folder unless you are willing to handle the fair and appropriate anger over the ignorance.


See Grey Aliens reply...

tested by QA and a huge amount of BFG customers


Maybe your PC has got other problems...


Dreamora(Posted 2010) [#42]
or GA / BFG are the only ones using the right and up to date dll :)

and no its not my problem. See the Race Driver Grid boards. They were a great example of the issue with hundreds of users


sebas76(Posted 2010) [#43]
and for overloaded method ?


markcw(Posted 2010) [#44]
Wherefore art thou my beloved overloading?