BlitzMax V132 for Windows and MacIntel now up!
BlitzMax Forums/BlitzMax Programming/BlitzMax V132 for Windows and MacIntel now up!
| ||
| 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. |
| ||
| 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. |
| ||
| THANK YOU! threads and LUA was just what i wanted.. |
| ||
| Much faster mergesort now used for linked list sorting. Hell yes. Can finally stop using my hack. |
| ||
| > Hell yes. Can finally stop using my hack. Thanks for the inspiration! Didn't realize how cool mergesort is for linked lists. |
| ||
| 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. |
| ||
| Thanks Mark, this looks like a great update. I always look forward to you releasing them :) Jason. |
| ||
| Fab! The TList changes are very satisfying. |
| ||
| thanks |
| ||
| 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 ! |
| ||
| 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 ? |
| ||
| Finally, I can replace my damaged svn-version with something new. Cheers. |
| ||
| Thank you, Mark. |
| ||
| Thank you! |
| ||
| 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. |
| ||
| @ 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? |
| ||
| 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: |
| ||
| 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). |
| ||
| 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. |
| ||
| @GaryV, there you go, I should be less excited about new release and read the instructions :-) |
| ||
| Ctrl+D to re-build modules, re-builds BRL and PUB modules every time as if you have done a re-build all modules? |
| ||
| 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. |
| ||
| 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 |
| ||
| 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 |
| ||
| 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. |
| ||
| 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..! |
| ||
| Threading support is awesome! BlitzMax is now officially my personal favorite programming language. Thank you! |
| ||
| Is the demo version going to be updated too? The main website link is to BlitzMaxDemo130.exe |
| ||
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. |
| ||
| 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... |
| ||
| 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. |
| ||
| 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. |
| ||
| 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. |
| ||
| 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. |
| ||
| 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. |
| ||
| is there a way to open individual libraries in the LUA module? Please read the Lua manual. |
| ||
| 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? |
| ||
| is there a way to open individual libraries in the LUA module? Read the BlitzMax language reference on Strings. |
| ||
| 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. |
| ||
| 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). |
| ||
| 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 |
| ||
| BRL.MaXLua is VERY usefull... THANKS.. well i told that. but THAANKs again... |
| ||
| I think you still need to do a threaded build for those modules. |
| ||
| /\ Oh OK, so that means you cant use bah.libxml in a threaded program unless brucey updates it? |
| ||
| No, you need to compile a threaded version yourself. Which you can when you've got MinGW32 installed. |
| ||
| 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. |
| ||
| 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. :( |
| ||
| @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. |
| ||
| 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. |
| ||
| OK. I have the same problem as QuickSilva did, but I'm XP. I'm not sure what I should do. Any help? |
| ||
| how do you build a threaded version of a module? |
| ||
| 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. |
| ||
| My application works correctly with the GLShareContexts() command called. Thanks! |
| ||
| 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? |
| ||
| 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 |
| ||
| Hi I get problems with threads : http://www.blitzbasic.com/Community/posts.php?topic=83938 But threads are very appreciated ! Thanks for this release. |
| ||
| Great update! Thanks! |
| ||
| 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? |
| ||
| 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! |
| ||
| Not listed in the fixes: Graphics windows (on Win32) now auto-center upon creation. Thank you Mark! |
| ||
| thanks for the info and update the modules dont recompile everytime now, I probably had threading checked |
| ||
| 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 |
| ||
| 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. |
| ||
| 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? |
| ||
| 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. |
| ||
| 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... |
| ||
| 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... |
| ||
| Does anyone know what the Unicode support improvements are? Does the file system (IO) now support Unicode chars? Thx. |
| ||
| 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. |
| ||
| ... 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? |
| ||
| 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). |
| ||
| I'm more curious why only Windows needed a b. |
| ||
| The update link for BlitzMax Win32 just changed from 'BlitzMax132a' (which I installed) to 'BlitzMax132b'... Now it's "BlitzMax132rc2". |
| ||
| 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. |
| ||
| Thanks Mark Sibly, for your great, nay excellent product support. I await the Linux release with baited breath.. |
| ||
| any tutorials about how to use thread in bmax? |
| ||
| Redownloaded and installed and rebuilt, but I still have an error when rebuilding docs. I'm on XP. BRL.Threads seems to kick it. |
| ||
| > 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] |
| ||
| Forgot to change LUA_RELEASE in the Pub.Lua module to 5.1.4 >_> |
| ||
| > 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... |
| ||
| I wouldn't bother, just noting it for anyone who cares. |
| ||
| 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). |
| ||
| @marksibly: I support the release candidate method. It works best for me to wait for RC2 or 3 at the moment. |
| ||
| Sorry, clean install of RC2 Windows XP and Ctrl+D still build all modules and re-builds... |
| ||
| 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? |
| ||
| 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)? |
| ||
| Yes. It's not the same, obviously, but the OS should manage the threads well enough. |
| ||
| 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. |
| ||
| @Nilium Okay, i'll have a try. |
| ||
| > > 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 :-). |
| ||
| 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. |
| ||
| 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). |
| ||
| 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. |
| ||
| > :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. |
| ||
| 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. |
| ||
| Ah yes you're right Nilium. LUA_COPYRIGHT should be updated as well :-) ('Copyright (C) 1994-2008 Lua.org, PUC-Rio') |
| ||
| 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. |
| ||
| 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, 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? |
| ||
| > 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. |
| ||
| Another ReInstall killed the compiling issues. |
| ||
| 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. |
| ||
| Can't find that 'product updates' section :) Help, help! |
| ||
| Click on the ACCOUNT link at the top of this page. Then you should see below it a link to product updates. |
| ||
| rebuild modules rebuild all modules every time you click it. rc2 works fine here on xp. |
| ||
| 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. |
| ||
| @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. |
| ||
| 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? |
| ||
| 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? |
| ||
| 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. |
| ||
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) |
| ||
| 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. |
| ||
| 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. |
| ||
| 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. |
| ||
| 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. |
| ||
| 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. |
| ||
| I just wanted to point out too that I get the stuttering with and without the my timing code enabled. Jason. |
| ||
| 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. |
| ||
| Interesting. If I do the same thing in Vista, adjust for best performance, I still get the slight stuttering. Jason. |
| ||
| ...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? |
| ||
| 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. |
| ||
| 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). |
| ||
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. |
| ||
| 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. |
| ||
| 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.? |
| ||
| 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. |
| ||
| 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. |
| ||
| 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. |
| ||
| 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 :-) |
| ||
| 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. |
| ||
| 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. |
| ||
| 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? |
| ||
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... |
| ||
| 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. |
| ||
| @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? |
| ||
| @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. :) |
| ||
| Tried the example to see if it stutters on Intel Mac; seems perfectly smooth. |
| ||
| @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? |
| ||
| 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. |
| ||
| 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. |
| ||
| @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! |
   |