Home
Products
Community
Manuals
Contact
Login or Signup

BlitzMax V132 for Windows and MacIntel now up!

BlitzMax Forums/BlitzMax Programming/BlitzMax V132 for Windows and MacIntel now up!

marksibly(Posted 1+ years ago) #1
Hi,

Please visit the product updates section to download BlitzMax/MaxGUI V132 for Windows and MacIntel machines.

PowerPC Mac and Linux versions coming soon...

Note: The Windows version doesn't currently work on Win95/98/ME - fix coming soon.

This version contains many bugfixes etc and thread support!

Fixes/changes:

***** Threads *****


A new 'Threaded build' option in MaxIDE's 'Program/build options' menu allows you to enable threaded builds.

BMK also has a new threaded option (-h).



Thread support is currently limited to commands for creating/using threads, mutexes, semaphores and condvars.

See the BRL.Threads modules for more information.



Threaded builds are 'static' in the same way debug/release builds are. You can use the ?Threaded conditional variable to

determine if your program is being built in threaded mode.



Threaded mode uses a different garbage collector (the Boehm-Demers-Weiser conservative garbage collector). This is

a little slower than the standard BlitzMax garbage collector, but is thread safe (fairly vital!). It can also handle object cycles...


***** Lua scripting *****


Added Mark's/Brucey's lua modules to Pub.Lua and BRL.MaxLua.


***** Unicode *****

Many major improvements to unicode support. Win95/98/ME users will now need unicows installed - see:

http://www.microsoft.com/downloads/details.aspx?FamilyId=73BA7BD7-ED06-4F0D-80A4-2A7EEAEE17E2&displaylang=en

***** Graphics *****


Dodgy support for GL contexts sharing removed/cleaned up. Multiple GL contexts will no longer be able to share textures/displaylists etc. To the best of my knowledge, no one has ever even used multiple GL contexts, but if there is a demand for this it can be re-enabled (code is lurking...). Will probably never work on Vista + IntelGMA9XX chipsets though due to really, really bad drivers.



Changed GrabPixmap to just grab RGB, no alpha, ala D3D7.


Fixed GrabImage sample and added (empty!) TImage type doc.


***** Lists and Maps *****

Much faster mergesort now used for linked list sorting.



Null objects no longer allowed in TLists. Asserts have been added to guard against this.



TList.First, TList.Last, TList.RemoveFirst and TList.RemoveLast used to throw exceptions if the list was empty - now, they just return Null.



Null keys no longer allowed in TMaps. Asserts have been added to guard against this.

***** Audio *****

Fixed DirectSound panning so it's (more) linear.

OpenAL sources in INITIAL state are now considered to be paused/active, preventing premature recycling of cued channels.


Various other fixes to OpenAL driver.

***** Misc *****

The mysterious, undocumented BRL.Data module has been removed.

Fixed Mac OpenURL not working with freaky filenames.


Added 'TEvent.RegisterId' for adding external event descriptions - currently private.


Also added a public, optional 'description$' param to AllocUserEventId() - this one public.

Linux FreeProcess fixes.

Fixed String.Join() crashing with empty array.




JoshK(Posted 1+ years ago) #2
Wow, thanks for adding threads.

I use multiple GL contexts all the time. For example, in my scene editor, there is the main 3D viewport, and then another window is used to display and draw on the heightmap texture, which is shared across both contexts. Pretty much anyone doing a 3D editor will use shared textures across multiple contexts. I don't care about Intel graphics chipsets since I don't support them.


Zeke(Posted 1+ years ago) #3
THANK YOU! threads and LUA was just what i wanted..


N(Posted 1+ years ago) #4
Much faster mergesort now used for linked list sorting.
Hell yes. Can finally stop using my hack.


marksibly(Posted 1+ years ago) #5
> Hell yes. Can finally stop using my hack.

Thanks for the inspiration!

Didn't realize how cool mergesort is for linked lists.


GfK(Posted 1+ years ago) #6
Threads at last!

I haven't downloaded the update yet and may not get around to it today - does the garbage collector still dump a massive logfile full of warnings during runtime, or was that fixed?

I don't care about Intel graphics chipsets since I don't support them.
ATI Catalyst 7.2 used to have the same problem. Apparently a driver update fixed it but I'd gone to Nvidia by then.

New drivers for my Intel GMA965 laptop fixed the problem, too.


QuickSilva(Posted 1+ years ago) #7
Thanks Mark, this looks like a great update. I always look forward to you releasing them :)

Jason.


Warpy(Posted 1+ years ago) #8
Fab! The TList changes are very satisfying.


Panno(Posted 1+ years ago) #9
thanks


Armitage 1982(Posted 1+ years ago) #10
Up to date and my main project is still working correctly :)

Unfortunately using the Threaded version in my game result in periodic (each sec) freezing probably due to the new GC (even if I'm not freeing object...). This is well visible with Big Box2d project.

Also the thread version of the Box2d pyramid.bmx give "Unhandled Exception:Unhandled Memory Exception Error"

Is using the Threaded version only for the new GC features is a good idea ? Mainly if I have few circular references ?

Shall unicow be installed by default for 95/Me/98 or only if you use a special module ?

Thanks a lot !


Nigel Brown(Posted 1+ years ago) #11
Threaded samples all say the same thing in the source " MAKE SURE "Threaded Build" IS CHECKED IN THE Program -> Build Options menu!" I have no such menu option as Program -> Build Options -> Threaded ?


Tommo(Posted 1+ years ago) #12
Finally, I can replace my damaged svn-version with something new.
Cheers.


GaryV(Posted 1+ years ago) #13
Thank you, Mark.


degac(Posted 1+ years ago) #14
Thank you!


GaryV(Posted 1+ years ago) #15
I have no such menu option as Program -> Build Options -> Threaded ?
It is between "debug" and "gui" on build selections.

You have given no info of how you installed the new version, what directories, did you remove the old version and manually remove the files, what OS, etc.

If you are using Vista, I am guessing you are not running the new version you just installed due to Vista's virtualization code. Have you checked your virtual store to see if Vista recognized the new installation as changes being made to the existing files without elevated permissions and wrote the new exes to the virtual store, which could cause you to actually be running the old IDE?

With no info to really go on, you could try reinstalling it in an entirely new directory.


Nigel Brown(Posted 1+ years ago) #16
@ GaryV, I just downloaded the new version 1.32 and installed it over 1.30, Windows XP. Guess that will be the same that most people will do?


GaryV(Posted 1+ years ago) #17
AFAIK, the only public releases so far are full installs, not updates. With XP, you wouldn't have the potential Vista issues I mentioned.

It might help to remove the old one before installing the new full version. For the full version downloads it clearly says:

You should fully uninstall any previous version of BlitzMax before installing these versions:



danvari(Posted 1+ years ago) #18
thanks but when is linux 64bit avaiable? i do not know why bmax is selled for linux when there is at least no 64bit version for it (and in case of linux, there are many many people out there using it with no multilib distro).


Floyd(Posted 1+ years ago) #19

For the full version downloads it clearly says:

You should fully uninstall any previous version of BlitzMax before installing these versions:

It says that, but it shouldn't.

The trouble arises when different versions get mixed together. So don't install the new one over the old. But the "right" way is to install the new version to a new folder and keep the old version as well. The old version can be uninstalled when you have confidence in the new one.

Of course you can immediately replace the old version but I don't recommend it. There's no real harm in this. You can always reinstall an older version if necessary.


Nigel Brown(Posted 1+ years ago) #20
@GaryV, there you go, I should be less excited about new release and read the instructions :-)


Nigel Brown(Posted 1+ years ago) #21
Ctrl+D to re-build modules, re-builds BRL and PUB modules every time as if you have done a re-build all modules?


Pharmhaus(Posted 1+ years ago) #22
found a bug....
rebuild modules rebuild all modules every time you click it.
(try it!)

bmk bug?

EDIT: copied the old bmk from 1.30, its definitely the bmk.


Zeke(Posted 1+ years ago) #23
found a bug....
rebuild modules rebuild all modules every time you click it.
(try it!)

bmk bug?


confirmed.. all modules are rebuilded.

os:
vista 32bit home premium


Uncle(Posted 1+ years ago) #24
Hello,

I've just installed 1.32 and now Im having problems now loading some (but not all) meshes in minib3d. It nows throws an exception in the ReadBytes Method in the TStream class. Does anyone else get this? Im not sure that this class was changed in the update?

Cheers,


Unc


VicViper(Posted 1+ years ago) #25
Thank you!

Windows version run ok here in Windows xp but don`t show nothing on home/code/debug area in windows 2000. Bliztmax 130 run ok in win2k. :)

screenshot here :


MacIntel run ok, too.


Robert Cummings(Posted 1+ years ago) #26
Thanks for the update its all good, specially threads and stuff.

Now get on with your game dude! last one you made was 3D guardian back when flares were in fashion..!


lukehedman(Posted 1+ years ago) #27
Threading support is awesome! BlitzMax is now officially my personal favorite programming language.

Thank you!


AdrianT(Posted 1+ years ago) #28
Is the demo version going to be updated too? The main website link is to BlitzMaxDemo130.exe


QuickSilva(Posted 1+ years ago) #29
Every time I restart version 1.32 I am asked to rebuild the docs which fails at the end. Here is what I am getting,

Rebuilding documentation...
Building: BlitzMax Help
Building: Modules
Building: Audio
Building: BRL.Audio
Building: TSound
Building: TChannel
Building: BRL.AudioSample
Building: TAudioSample
Building: TAudioSampleLoader
Building: BRL.DirectSoundAudio
Building: BRL.FreeAudioAudio
Building: BRL.OGGLoader
Building: BRL.OpenALAudio
Building: BRL.WAVLoader
Building: Pub.OpenAL
Building: Miscellaneous
Building: BRL.Bank
Building: TBank
Building: Pub.ZLib
Building: Streams
Building: BRL.BankStream
Building: TBankStream
Building: BRL.EndianStream
Building: BRL.RamStream
Building: BRL.SocketStream
Building: BRL.Stream
Building: TStreamException
Building: TStreamReadException
Building: TStreamWriteException
Building: TIO
Building: TStream
Building: TStreamWrapper
Building: TCStream
Building: TStreamFactory
Building: BRL.TextStream
Building: BASIC
Building: BRL.Blitz
Building: BRL.Reflection
Building: TMember
Building: TField
Building: TMethod
Building: TTypeId
Building: BRL.Retro
Building: Graphics
Building: BRL.BMPLoader
Building: BRL.D3D7Max2D
Building: BRL.GLGraphics
Building: BRL.GLMax2D
Building: BRL.Graphics
Building: BRL.JPGLoader
Building: BRL.Max2D
Building: TImage
Building: BRL.Pixmap
Building: TPixmap
Building: TPixmapLoader
Building: BRL.PNGLoader
Building: BRL.TGALoader
Building: Pub.OpenGL
Building: Events
Building: BRL.Event
Building: TEvent
Building: BRL.EventQueue
Building: BRL.Hook
Building: BRL.Timer
Building: System
Building: BRL.FileSystem
Building: BRL.MaxLua
Building: TLuaObject
Building: TLuaClass
Building: BRL.StandardIO
Building: BRL.System
Building: BRL.Threads
Error reading from stream
Process complete



Any ideas as to what is wrong? I have done a complete reinstall and am running Vista.

Thanks for any help,

Jason.


Htbaa(Posted 1+ years ago) #30
What's the biggest difference between the latest axe.lua (the one I posted, updated to Lua 5.1.4) and the Lua 5.1.4 module in pub.lua ?

BRL.MaxLua seems like an easy way to bind BlitzMax objects to Lua.

One thing I did notice is that one global Lua state is being used. Why is it limited to one? You can run as *many* Lua states as you want...


QuickSilva(Posted 1+ years ago) #31
OK, it appears that the above problem is caused if you have UAC switched on.

Strange though, I do not remember having to turn it off to rebuild the docs before? Maybe I`m wrong?

Anyway, all is working now.

BMax files now have a proper file association, windows are correctly centered, everything is looking and working very nicely indeed.

Thanks Mark for a really great update! You`ve addressed a lot of issues and I for one am very grateful :)

Oh, before I go. What version of MinGW should we be using now? I`m still using version 5.1.3 Should we be upgrading to a later version?

Thanks again.

Jason.


Htbaa(Posted 1+ years ago) #32
Instead of disabled UAC (which exists to make Vista more secure) just change the directory permissions of C:\Program Files\BlitzMax (add write permissions to yourself).

Edit: Wonderful... axe.lua conflicts with pub.lua.


ImaginaryHuman(Posted 1+ years ago) #33
Cool stuff. Noticed a tiny link broken:

In the blitz runtime module, you have a line which says: "See the BlitzMax Language Reference for more information on Strict mode programming. " where `blitzmax language reference` is a hyperlink - but it is broken.


Grey Alien(Posted 1+ years ago) #34
Excellent thanks Mark.

Q. Were those OpenAL fixes in response to the memory leak issue I posted and do you believe that they may resolve it? Just wandered before I download + install. Thanks!

I'll post back if I get the UAC problem that QuickSilva had.


slenkar(Posted 1+ years ago) #35
is there a way to open individual libraries in the LUA module?

I dont want to open the OS library because it allows people to make malicious scripts.


N(Posted 1+ years ago) #36
is there a way to open individual libraries in the LUA module?
Please read the Lua manual.


slenkar(Posted 1+ years ago) #37
only the openlibs command seems to be wrapped.

also this function : lua_tostring:Byte Ptr( L,i )

returns a byte ptr instead of a string

how do i get the string?


N(Posted 1+ years ago) #38
is there a way to open individual libraries in the LUA module?

Read the BlitzMax language reference on Strings.


Htbaa(Posted 1+ years ago) #39
Even better, luaL_newstate() returns an int, instead of a Byte Ptr. To me the Lua module is unusable and I moved both pub.lua and brl.maxlua to some other directory so I can use axe.lua. Which to me seems by far a better (documented) module than the current implementation.

Couldn't a module like this being added to, I don't know, brlextra.mod ? That way other modules (such as axe.lua) don't conflict.


N(Posted 1+ years ago) #40
I'll be sticking with Axe.Lua, since I've already invested a fair amount of time into it and I've never had any issues. Plus, returning an int instead of a pointer seems like a good way to mess up future pointer sizes (64-bit pointers).


slenkar(Posted 1+ years ago) #41
I get the error that compiles every module too,

Im using two OpenGL canvasses in my map editor and it works with shared pixmaps.

The threading stuff looks nice!


When I enable threaded build it says I dont have bah.libxml module when I try to use it in an unthreaded program.(but I do have the module of course)

this is how to get the string(from the axe module)
  Function lua_tostring:String (lua_state:Byte Ptr, index:Int)
    Local Length:Int
    Local StringPtr:Byte Ptr = lua_tolstring(lua_state, index, Varptr Length)
    If (StringPtr = Null) Then
      Return Null
    Else
      Return String.fromBytes(StringPtr,Length)
    End If
  End Function



Zeke(Posted 1+ years ago) #42
BRL.MaXLua is VERY usefull... THANKS.. well i told that. but THAANKs again...


Htbaa(Posted 1+ years ago) #43
I think you still need to do a threaded build for those modules.


slenkar(Posted 1+ years ago) #44
/\
Oh OK, so that means you cant use bah.libxml in a threaded program unless brucey updates it?


Htbaa(Posted 1+ years ago) #45
No, you need to compile a threaded version yourself. Which you can when you've got MinGW32 installed.


JoshK(Posted 1+ years ago) #46
Im using two OpenGL canvasses in my map editor and it works with shared pixmaps.

A pixmap is just a length of system memory in which pixel data is stored. That will be slower than images stored on the GPU, and won't allow blending or color effects.


Ked(Posted 1+ years ago) #47
BlitzMax V132 for Windows and MacIntel now up!

Awesome! Thanks!

Sadly, I wasn't able to get the MouseSpeed functions fully tested. So I'll just be using some code archive examples until then. :(


slenkar(Posted 1+ years ago) #48
@Leadwerks

I use a pixmap for the tile-selector
then I create a Tmap and fill that with images that are pieces of the big tile-selector pixmap,
-to draw the actual map in the map editor
it works so far.


ImaginaryHuman(Posted 1+ years ago) #49
I can see that you might want multiple canvasses in an o/s gui-based/maxgui application. But if you're in fullscreen with your own graphics gui, you only need 1 context for the whole screen and then virtualize its use.


Ked(Posted 1+ years ago) #50
OK. I have the same problem as QuickSilva did, but I'm XP. I'm not sure what I should do. Any help?


slenkar(Posted 1+ years ago) #51
how do you build a threaded version of a module?


marksibly(Posted 1+ years ago) #52
Hi,

> I use multiple GL contexts all the time.

Just uploaded a new Win32 version with a new 'GLShareContexts' command - put this at the top of the app to enable old style context sharing behaviour. Please let me know if it works.

> thanks but when is linux 64bit avaiable?

There are no plans for a 'native' 64 bit version as it would be a massive mission compiler wise...

> rebuild modules rebuild all modules every time you click it.

Not for me - I wonder if you have NZ timestamps on your files or something? Is it still happening now?

> Edit: Wonderful... axe.lua conflicts with pub.lua.

Ah yes, apologies for this - what was I thinking!?! Anyway, best idea is probably for me to replace the Pub.Lua module with the Axe one and fix BRL.MaxLua to work with that instead.

Is this latest axe.lua?

http://www.andreas-rozek.de/BlitzMax/lua.bmx

Stay tuned!

> I've just installed 1.32 and now Im having problems now loading some (but not all)
> meshes in minib3d

Yes, a bug in ReadBytes has been fixed - it used to 'sometimes' throw an exception when not enough bytes could be read. Now it always does (I hope). MiniB3D may need to be modified to handle this.

> how do you build a threaded version of a module?

] bmk makemods -h blah

...or have 'threaded build' enabled in the IDE when you build/rebuild modules.


JoshK(Posted 1+ years ago) #53
My application works correctly with the GLShareContexts() command called. Thanks!


xlsior(Posted 1+ years ago) #54
There are no plans for a 'native' 64 bit version as it would be a massive mission compiler wise...


Which is really, really unfortunate since supposedly Windows 7 is going to be the last version that comes in a 32-bit flavor -- after that everyone will be on 64-bit and would end up going through the WOW64 thunking layer....

If nothing else any additions/modifications probably should keep future 64-bit readyness in mind?


N(Posted 1+ years ago) #55
Ah yes, apologies for this - what was I thinking!?! Anyway, best idea is probably for me to replace the Pub.Lua module with the Axe one and fix BRL.MaxLua to work with that instead.

Is this latest axe.lua?

I'm just going to say this is the latest for now: http://www.blitzbasic.com/Community/posts.php?topic=83936


Filax(Posted 1+ years ago) #56
Hi

I get problems with threads : http://www.blitzbasic.com/Community/posts.php?topic=83938

But threads are very appreciated ! Thanks for this release.


Jur(Posted 1+ years ago) #57
Great update! Thanks!


Nigel Brown(Posted 1+ years ago) #58
Mark, Just built modules again using CTRL+D and yet again they re-built. the time stamps look valid. Anything you would like me to check?


Pharmhaus(Posted 1+ years ago) #59

Not for me - I wonder if you have NZ timestamps on your files or something? Is it still happening now?


ok, seems to be working now.
thanks mark!


Tachyon(Posted 1+ years ago) #60
Not listed in the fixes: Graphics windows (on Win32) now auto-center upon creation. Thank you Mark!


slenkar(Posted 1+ years ago) #61
thanks for the info and update

the modules dont recompile everytime now, I probably had threading checked


Retimer(Posted 1+ years ago) #62
If nothing else any additions/modifications probably should keep future 64-bit readyness in mind?


Like threading which came out of the blue, i'm sure mark will surprise us again one day with 64-bit support, just not any time soon.

We'll have to start 1500 more threads in General Discussion about adding the support first =p


Htbaa(Posted 1+ years ago) #63
Yes Mark http://www.andreas-rozek.de/BlitzMax/lua.bmx is the latest of axe.lua. Although the Lua version is a bit "old", so I updated it to use Lua 5.1.4 http://www.htbaa.com/files/axe.mod.lua.mod-5.1.4.zip

Edit: Sorry for my earlier response, didn't mean to be that negative. I'm happy to see a new release of BlitzMax with all the new features.


JoshK(Posted 1+ years ago) #64
Which is really, really unfortunate since supposedly Windows 7 is going to be the last version that comes in a 32-bit flavor -- after that everyone will be on 64-bit and would end up going through the WOW64 thunking layer....

You actually believe that?


d-bug(Posted 1+ years ago) #65
Nice update so far, but...

before updating BlitzMax to Version 1.32 everything was okay, but after...


Just uploaded a new Win32 version with a new 'GLShareContexts' command - put this at the top of the app to enable old style context sharing behaviour. Please let me know if it works.


Can we have it for OSX too? :)
Reverting to 1.30 till then.


xlsior(Posted 1+ years ago) #66
you actually believe that?


...Why not? a very significant percentage of new computers is already getting shipped with Vista 64 these days -- would it be that hard to believe that After Windows 7 they won't bother with a native 32-bit compile anymore?

Just like under 'normal' XP 16 bit programs are thunked through the WOW32 process, the same happens to 32 bit programs under Windows 64 bit. (Using WOW64 instead)

all I'm saying is that the migration to 64 bit is already in progress, so it doesn't hurt to keep it in the back of your mind...


SebHoll(Posted 1+ years ago) #67
Every time I restart version 1.32 I am asked to rebuild the docs which fails at the end. Here is what I am getting,

Mark, Just built modules again using CTRL+D and yet again they re-built. the time stamps look valid. Anything you would like me to check?


I experienced these problems too when I had UAC turned on, but they disappeared after disabling it...


Grey Alien(Posted 1+ years ago) #68
Does anyone know what the Unicode support improvements are? Does the file system (IO) now support Unicode chars? Thx.


EdzUp[GD](Posted 1+ years ago) #69

You actually believe that?


natural progression will see 32bit dying out the same way 16bit did and 8bit before that. Weve had 32bit for years if not decades now so its time it was 'put out to pasture' in favour of releasing more speed with applications that use 64bit natively. This hopefully will be when someone gets thier finger out and does all the drivers etc for the next OS.

On the BlitzMax 1.32b front brilliant stuff mark, im away for a few days and ya release a new build.


Plash(Posted 1+ years ago) #70
... The update link for BlitzMax Win32 just changed from 'BlitzMax132a' (which I installed) to 'BlitzMax132b', and I just got done compiling a load of modules :-(

Any chance we'll get a new post with the list of changes?


Grey Alien(Posted 1+ years ago) #71
It's good though that a b version has been made. I'm very grateful that "early adopters" try it out and that we get a quick fix to any issues (there are bound to be some after all).


N(Posted 1+ years ago) #72
I'm more curious why only Windows needed a b.


Ked(Posted 1+ years ago) #73
The update link for BlitzMax Win32 just changed from 'BlitzMax132a' (which I installed) to 'BlitzMax132b'...

Now it's "BlitzMax132rc2".


marksibly(Posted 1+ years ago) #74
Hi,

New versions up!

Mac OS X PowerPC version available too now, but still no Linux...coming very soon, there are just a few issues to iron out.

I've renamed them 'rc2' - ie: 'release candidate 2'.

I think doing release candidates like this is the way to go with BlitzMax updates, as there's just no way I can realistically guarantee that an update wont have some kind of negative effect on someones code somewhere out there - and that there wont be a quick fix following shortly afterwards!

If you're on a tight deadline (or have a huuuuuge number of modules to recompile or something...) you might want to skip initial release candidates - but they should work pretty well in general.

Anyway, major changes:

Pub.Lua is now Axe.Lua (or vice versa). Removed the Import BRL.Retro that was in there.

BRL.MaxLua modified to work with new Pub.Lua

New GLShareContexts command re-enables OpenGL context sharing.


markcw(Posted 1+ years ago) #75
Thanks Mark Sibly, for your great, nay excellent product support. I await the Linux release with baited breath..


DreamLoader(Posted 1+ years ago) #76
any tutorials about how to use thread in bmax?


Ked(Posted 1+ years ago) #77
Redownloaded and installed and rebuilt, but I still have an error when rebuilding docs. I'm on XP. BRL.Threads seems to kick it.


marksibly(Posted 1+ years ago) #78
> Redownloaded and installed and rebuilt, but I still have an error when rebuilding docs

Anyone else?

> BRL.Threads seems to kick it.

Umm...what?

[edit]
Have you tried uninstalling;manually deleting program files/blitzmax folder;reinstalling?
[/edit]


N(Posted 1+ years ago) #79
Forgot to change LUA_RELEASE in the Pub.Lua module to 5.1.4 >_>


marksibly(Posted 1+ years ago) #80
> Forgot to change LUA_RELEASE in the Pub.Lua module to 5.1.4 >_>

Is it important, ie: worth an rc3 on its own? Never used axe.lua, just dropped in the 'latest' version...


N(Posted 1+ years ago) #81
I wouldn't bother, just noting it for anyone who cares.


Plash(Posted 1+ years ago) #82
Anyone else?
Not in 1.30a, but I will not be installing any of the release candidates (hard to work on something when you have to wait 2-3 hours for module compiling).


Grey Alien(Posted 1+ years ago) #83
@marksibly: I support the release candidate method. It works best for me to wait for RC2 or 3 at the moment.


Nigel Brown(Posted 1+ years ago) #84
Sorry, clean install of RC2 Windows XP and Ctrl+D still build all modules and re-builds...


GfK(Posted 1+ years ago) #85
Just a tiny small suggestion.

Would it be massively difficult to have a more prominent list of latest version for BlitzMax (and plus, and 3D) somewhere on the homepage?

In account history it still says v1.32, even though there's actually been three different versions of 1.32 so far; a, b and rc2. Only by going back and looking again and again, or by trawling this thread, can I find out that there were versions newer than the original release.

Also, why not use the odd numbers for release candidates?


taumel(Posted 1+ years ago) #86
A question regarding the threading in BlitzMax 1.32:

Do you also benefit from it on something like a P4 system (1 CPU but HT)?


N(Posted 1+ years ago) #87
Yes. It's not the same, obviously, but the OS should manage the threads well enough.


QuickSilva(Posted 1+ years ago) #88
I seem to have lost the initial help page that is displayed when you load Bmax. I am now getting a blank page. Everything else works properly though including all other help pages. I have tried a fresh reinstall and it still isn`t there.

Any ideas as to why this has happened (I`m on Vista). It was fine to start with now all versions 1.32a and upwards do the same. Strange?

Jason.


taumel(Posted 1+ years ago) #89
@Nilium
Okay, i'll have a try.


Htbaa(Posted 1+ years ago) #90
> > Forgot to change LUA_RELEASE in the Pub.Lua module to 5.1.4 >_>

> Is it important, ie: worth an rc3 on its own? Never used axe.lua, just dropped in the 'latest' version...

LUA_VERSION as well. No need to do a special RC. If it's fixed with the final release all is fine I suppose :-).


N(Posted 1+ years ago) #91
LUA_VERSION as well. No need to do a special RC. If it's fixed with the final release all is fine I suppose :-).
Actually, LUA_VERSION should remain as 5.1.


Tricky(Posted 1+ years ago) #92
Something is horribly wrong with 1.32.
At least on MacOS X in PPC, since in Windows Vista everything went well, and since I didn't change one line of code since my update to 1.32 I quite sure the evil must lie there. (I also kept my 1.30 version for backup reasons. I tried it there, and there it works without any misery).

In my new project I have a complex image system. I will admit that.
I have a big structure of TMaps containing pictures. I have also a GUI with multiple canvasses. Now when I start rendering my screen, everything gets screwed up. Some pictures just become blank rectangles, or sometimes just showing the wrong picture or showing parts of other pictures.

DrawText also seems affected by the same manner. In one canvas it gives correct text. In the others each character becomes a rectangle just as long and wide as the character should be. But the character is (of course) no longer readable.

I cannot provide sample code, since that will take too long to replicate it. I don't wanna throw my source on a public forum either. If you need I can zip my source and e-mail it, so you might see what went wrong (though I must note that it's pretty poorly documented. A terrible flaw of mine when it comes to coding).


Ked(Posted 1+ years ago) #93
Have you tried uninstalling;manually deleting program files/blitzmax folder;reinstalling?

Just did; That's what I needed to do. :)

Umm...what?

:P I just meant that the IDE shuts down when it gets to BRL.Threads, and it says "Unable to read from stream" or something similar.


marksibly(Posted 1+ years ago) #94
> :P I just meant that the IDE shuts down when it gets to BRL.Threads, and it says
> "Unable to read from stream" or something similar.

Is this fixed with the 'extreme' reinstall? Or just the build modules issue?

> Something is horribly wrong with 1.32.

Tricky, try adding a 'GLShareContexts' at the top of your program before any graphics are created.


Ked(Posted 1+ years ago) #95
Is this fixed with the 'extreme' reinstall? Or just the build modules issue?

I didn't have a build modules issue, I had a build documentation issue. But, yeah, it's fixed now after I uninstalled BlitzMax and reinstalled it.

EDIT:
Also, has there been a speed boost or something to the IDE and compiler? Because, the IDE loads up fast and the compiler rebuilds modules faster than I remember it could.

EDIT:
Nevermind, I think it's the new rich edit control. I just read Seb's post in the bugs section.


Htbaa(Posted 1+ years ago) #96
Ah yes you're right Nilium.

LUA_COPYRIGHT should be updated as well :-) ('Copyright (C) 1994-2008 Lua.org, PUC-Rio')


BladeRunner(Posted 1+ years ago) #97
I would recommend using SVN again as this would cover such issues.
I now get compiling errors:
C:/BlitzMax/mod/brl.mod/glgraphics.mod/glgraphics.release.win32.x86.a(glgraphics.bmx.release.win32.x86.o): undefined reference to `bbGLGraphicsGetSettings'
C:/BlitzMax/mod/brl.mod/glgraphics.mod/glgraphics.release.win32.x86.a(glgraphics.bmx.release.win32.x86.o): undefined reference to `bbGLGraphicsClose'
C:/BlitzMax/mod/brl.mod/glgraphics.mod/glgraphics.release.win32.x86.a(glgraphics.bmx.release.win32.x86.o): undefined reference to `bbGLGraphicsGraphicsModes'
C:/BlitzMax/mod/brl.mod/glgraphics.mod/glgraphics.release.win32.x86.a(glgraphics.bmx.release.win32.x86.o): undefined reference to `bbGLGraphicsAttachGraphics'
C:/BlitzMax/mod/brl.mod/glgraphics.mod/glgraphics.release.win32.x86.a(glgraphics.bmx.release.win32.x86.o): undefined reference to `bbGLGraphicsCreateGraphics'
C:/BlitzMax/mod/brl.mod/glgraphics.mod/glgraphics.release.win32.x86.a(glgraphics.bmx.release.win32.x86.o): undefined reference to `bbGLGraphicsSetGraphics'
C:/BlitzMax/mod/brl.mod/glgraphics.mod/glgraphics.release.win32.x86.a(glgraphics.bmx.release.win32.x86.o): undefined reference to `bbGLGraphicsFlip'

Which is weird as the App I compile doesn't even use OGl.
I'll give a second reinstall a try, but this is very unpleasant.


Ked(Posted 1+ years ago) #98
I would recommend using SVN again as this would cover such issues.

I'd be even more happy if we got syncmods back. It was a lot smoother than using SVN.


Tricky(Posted 1+ years ago) #99
Tricky, try adding a 'GLShareContexts' at the top of your program before any graphics are created. 


That indeed did the trick.
Thanks a lot, Mark.
Do I need to do this for all Max2D OpenGL based apps, or only for multiple-canvas ones like I'm doing now?


marksibly(Posted 1+ years ago) #100
> Do I need to do this for all Max2D OpenGL based apps, or only for multiple-canvas ones
> like I'm doing now?

Only multi-canvas ones.


BladeRunner(Posted 1+ years ago) #101
Another ReInstall killed the compiling issues.


yoko(Posted 1+ years ago) #102
Hi,

I can't find MaxIDE source in the src folder, will it be available in the final 1.32 version? I usually modify the source to make the MaxIDE work with my portable version of MinGW.


FantomKite(Posted 1+ years ago) #103
Can't find that 'product updates' section :) Help, help!


Uncle(Posted 1+ years ago) #104
Click on the ACCOUNT link at the top of this page. Then you should see below it a link to product updates.


markcw(Posted 1+ years ago) #105
rebuild modules rebuild all modules every time you click it.

rc2 works fine here on xp.


xlsior(Posted 1+ years ago) #106
rebuild modules rebuild all modules every time you click it.


I had the same problem, except the rebuild all had a hard time finishing. It would blow up at arbitrary points in time complaining that some .a file already existed.

After doing both bmk makemods -a and bmk makemods -a -h numerous times from the command line, they finally both had a run without errors, and the continuous recompiles stopped.

(Never had this issue with previous Blitzmax releases, including the SVN one)


Which is weird as the App I compile doesn't even use OGl.
I'll give a second reinstall a try, but this is very unpleasant.


If you don't use the Framework command and explicitely import the modules you are using, Blitzmax will include *all* modules under the BRL and PUB trees, which includes all the openGL stuff -- whether you use it or not. You can use Framework Assistant to help determine which modules your program actually uses.


QuickSilva(Posted 1+ years ago) #107
@Mark Sibly:

Hi Mark, great update!

Can I quickly ask if anything else was changed apart from the centering of windows, graphics wise, as I am now seeing a slight stuttering of my images every now and then with both flip 0 and flip 1.

This is only in windowed mode and fullscreen is still silky smooth. I have tried both OGL and DX drivers and both produce the same issue. I have just tested my code in version 1.30 again and the problem goes even though I`m running the same program unchanged.

I can send the two .exes (from 1.30 and 1.32) if you would like to try on your system?

Thanks again for the update.

Jason.


Tachyon(Posted 1+ years ago) #108
I am having the same artifacts as QuickSilva: in Windowed mode, my once smooth scrolling isometric engine now appears to have a bit of a stutter. Any ideas what could have changed between 1.30 and 1.32 to cause this?


marksibly(Posted 1+ years ago) #109
Hi,

> I can send the two .exes (from 1.30 and 1.32) if you would like to try on
> your system?

Exes aren't much use - can you reproduce the problem with some short source code? Does it happen to any of the samples?


N(Posted 1+ years ago) #110
Any ideas what could have changed between 1.30 and 1.32 to cause this?
You could do a diff of the two versions. That'd be a good start to figuring out what exactly changed.


Tachyon(Posted 1+ years ago) #111
This seems to show the stutter:
SuperStrict

Local x:Int

Graphics 1024,768

'// Make some garbage
For Local n:Int = 1 To 500
    SetColor Rand(255), Rand(255), Rand(255)
    DrawOval Rand(-500,1000),Rand(-400, 700),Rand(100,300),Rand(100,300)
Next

'// Grab it & convert it
Local screen:TPixmap = GrabPixmap(0,0,1024,768)
Local Img:TImage = LoadImage(screen)

SetColor 255,255,255

Repeat
    Cls
    DrawImage Img, x, 0
    DrawImage Img, x+1024, 0
    x:-1
    If x = -1025 x = 0
    Flip 1
Until GetChar()

I don't have 1.30 installed anymore so I can't compare the difference first hand, however I can say that this scrolling graphic stutters much like my game does, on my system. (Vista32, GeForce GTX280)


QuickSilva(Posted 1+ years ago) #112
Mark, Tachyon`s code above reproduces the problem exactly, smooth most if the time but with the occasional stutter even when nothing seems to be happening in the background.

Incidentally the effect does not happen in Blitz 3D windowed mode on the same machine using practically identical code. Not sure if that helps at all?

Please let us know if you are getting the same thing.

Jason.


Tachyon(Posted 1+ years ago) #113
Ironically, today after a fresh reboot, I tried the above code and it was "mostly" smooth- the stutter was still there but very infrequent and hardly noticeable. However, last night when I made the code and tested it, the scrolling stuttered so badly it was nowhere close to being smooth. It looked really horrible.


QuickSilva(Posted 1+ years ago) #114
It would be nice to hear if Mark gets the same problem or not in windowed mode.

Currently, I am running my game in windowed mode with flip false (as flip true results in the stutter) and full screen with flip true. Ideally, I would like to be able to set the windowed mode to flip true as well.

Maybe this is not possible? Is there a reason as to why windowed mode would stutter without using flip false?

Jason.


QuickSilva(Posted 1+ years ago) #115
Could a few other people please try Tachyon`s code (post #111) and post saying whether or not they are having the same problems with stuttering. I`m starting to think that I am the only one.

Thanks,

Jason.


Pete Rigz(Posted 1+ years ago) #116
I too am getting stuttering since upgrading, definitely noticed in my app despite timing code. Tried Tachyons code and lots of stuttering there too in dx/gl.

Running vista 64 here with nvidia 8800gts.


QuickSilva(Posted 1+ years ago) #117
I just wanted to point out too that I get the stuttering with and without the my timing code enabled.

Jason.


kenshin(Posted 1+ years ago) #118
Tachyons code shows no differences here. It's not perfectly smooth, just a little jumpy, but it's the same in v1.30 (with no mods) and v1.32

I find I need to do the "Adjust for best performance" in Win7 to get it perfectly smooth in a window. Fullscreen is always smooth regardless of performance settings.

Hope this helps.


QuickSilva(Posted 1+ years ago) #119
Interesting. If I do the same thing in Vista, adjust for best performance, I still get the slight stuttering.

Jason.


Tachyon(Posted 1+ years ago) #120
...It's not perfectly smooth, just a little jumpy, but it's the same in v1.30 (with no mods) and v1.32

Why would this be? Certainly it is drawing the two images in a fraction of a millisecond, then waiting for vsync. It should appear silky smooth, right?


kenshin(Posted 1+ years ago) #121
Should, but it doesn't.

I narrowed it down to one Win7 performance option. When I have "Use visual styles on windows and buttons" enabled it jumps around noticeably. If it's disabled, silky smooth. All other options can be enabled and it's silky, just this one causes jumps.

I asked wifey is she noticed too, just in case I was being picky or seeing something that's not there. She noticed it easily, and also agreed that it's smooth with that one option disabled.

It's definitely something to do with window themes or Aero. Rebooting doesn't fix either.


GaryV(Posted 1+ years ago) #122
kenshin: BMax does not natively support DX9. Have you tried using the third-party DX9 driver?

You need to remember that Vista and 7 do not support DirectX 7. DX7 API calls are translated at runtime to calls for the special version of DX9 that is used for Aero (which is DX9 based).


kenshin(Posted 1+ years ago) #123
I tried this:
Import dbs.d3d9max2d
SetGraphicsDriver d3d9max2ddriver()

at the head of Tachyons code.

It improves the situation a little, but is still not as smooth as when I disable that visual style. I'll try updating my nvidia drivers, see if that makes any difference.

I never noticed this before as I'm not working in windowed 2D gfx, only gui/3D and mostly fullscreen. I don't get any jumping problems there as long as I'm not dragging, clicking, using menu's etc.


QuickSilva(Posted 1+ years ago) #124
I thought that it could be DirectX as well but the same problem seems to happen with OpenGL too.

It would be interesting to see if any Mac users could run the code and see if they are getting the same thing.

Even Grey Aliens Framework does the same thing in Windows mode, super smooth with flip false but the very slight jerk (every couple of seconds or so) with it set to flip true.

It appears that this is not a new problem after all but I`m sure that I read that it had been sorted out some time back?

At the end of the day it`s nothing major but for 2D games I`d rather be setting flip to true in both full screen and windowed modes.

Jason.


GaryV(Posted 1+ years ago) #125
I thought that it could be DirectX as well but the same problem seems to happen with OpenGL too.
In what kenshin describes, it could still be DX, as Aero is DX9 regardless of what driver you are using to display the BM window.?


therevills(Posted 1+ years ago) #126
Just tried Tachyon code on 1.30 and 1.32rc2 and I cant see the difference (apart from that the window is centered in 1.32)... Running on XP SP3, seems pretty smooth... although if I stare at it for a while there is a slight stutter now and again in both versions.


kenshin(Posted 1+ years ago) #127
Drivers made no difference. The only difference I see is when I disable the style in control panel. Only then is it smoothest.

I watched closely and can now see the slight stutter therevills has mentioned, although that's nothing compared to the jerking I get by enabling the style in control panel.

I'm wondering if other 2D languages, like PB have this problem too.


QuickSilva(Posted 1+ years ago) #128
Well after testing Blitz 3D and Blitz Plus I can say that neither of those have the same problem. Just tried Pure Basic (demo) and that seems OK too.

I would much rather be using BMax though so I hope that there is a solution.

Jason.


Grey Alien(Posted 1+ years ago) #129
Tachyon's code is smooth on my XP PC (Bmax 1.30) with a tiny 1 pixel glitch about every 2-3 seconds.

When I wrote my first draft framework it looked great on my PC (I only have about 3 things loading in startup so the PC is free from lots of background tasks but windows still has some insidious crap going on I'm sure) but then I tried it on other PCs and was horrified at the jerkyness! Then I kept on tweaking (and adding jitter correction) until it was improved on other PCs but it was never perfect on all PC - many are fine, but many are not to varying degrees of crapness.

It just seems to be a fact of life about PC programming that cannot be escaped from. Many games have totally crappy unsmooth scrolling anyway even on my PC, but still seem to sell fine. I have had to swallow my perfectionism and say that at least my games look great on some PCs (as I intend them to look) and that I've done the best I can to make them work on other PC. The main thing is still making the game a) Fun and b) Finished :-)


QuickSilva(Posted 1+ years ago) #130
I`ve come to this conclusion too. It seems unavoidable. Getting back into 2D programming lately may have reminded me a little too much of my beloved Amiga which always seemed to run super smoothly.

Jason.


Pete Rigz(Posted 1+ years ago) #131
I went into nvidia driver settings and set the slider under "Image Settings with Preview" to performance rather then quality and now everything is completely smooth - at least in my app with timing code, Tachyons example still judders slightly but nowhere near as bad.


Johnsprogram(Posted 1+ years ago) #132
I'm glad that the window now gets to be on the center of the screen. It was just weird and awkward to have the window to the upper-left all the time.
I have a question: by any chance that adding an icon to the upper-left corner of the window had improved with the new version?


Blueapples(Posted 1+ years ago) #133
I'm getting this error trying to compile modules on Mac OS X, specifically bah.database:

Compiler Error
Identifier 'TMap' not found


This sounds bad...


Brucey(Posted 1+ years ago) #134
Some of the module dependencies have been tidied up in 1.32.
Where one module may have previously imported BRL.Map, which it didn't actually need, this Import has been removed.

Of course, any modules that didn't import modules that they needed, might find they need to import them now ;-)

This particular one is fixed in my SVN.


Arowx(Posted 1+ years ago) #135
@Brucey Do any of the IDE's provide a framework test?

There is a framework checker program but just wondering if it has been incorporated into the community IDE?


Blueapples(Posted 1+ years ago) #136
@Brucey So you're saying I have to actually update my modules? :-p boo sounds like work. Thanks for pointing that out the import thing though. :)


alban Read(Posted 1+ years ago) #137
Tried the example to see if it stutters on Intel Mac; seems perfectly smooth.


Playniax(Posted 1+ years ago) #138
@Mark When I upgraded to version 1.33 and turned on Threading (don't use it in my code yet) my games start to stutter sometimes. They all work fine when I turn it off or run on older versions. I think it's the Threading support. And one question:

Is there a plan for an x-box version or Playstation 3? OK, Playstation is maybe to much because of the big differance in hardware but the x-box is kind of a PC with dx no?


GaryV(Posted 1+ years ago) #139
Playniax.com: Why would you do something like turn it on if you are not actually using it. You are using a GC designed for threaded apps, instead of the GC you should be using. Don't enable threading if you are not going to use it.


Plash(Posted 1+ years ago) #140
Is there a plan for an x-box version or Playstation 3?
Highly unlikely, for both platforms. Don't expect a response from Mark either.


Playniax(Posted 1+ years ago) #141
@GaryV Thanks, I did not have the time to look into the details yet. I was just responding to early posts about the stutters. Threading looks promissing by the way.

@Plash I'm just saying that it could be an interesting market. Also depends how much work this will be for Mark ofcourse.

Cheers!