maximum memory
BlitzMax Forums/BlitzMax Programming/maximum memory
| ||
| blitzmax stick on loading half of my image no matter in which order i load them. I load one thousand of them and at the end my process end up using 20Mb memory. Is there any memory limit? Can I increase the limit? thanks! Version 1.24 (please don't ask me to upgrade, thanks :) ) |
| ||
| Well, first off, why are you using a version of Blitzmax that's years out of date? I'm not asking you to upgrade, but expect stuff to be broken if you don't. Also, what can you possible need a thousand images for? I'd wager that its using a hell of a lot more than 20MB. Oh and for the record, I don't attribute this.... behaviour to the ancient version of Blitzmax you're using. I'm 99% sure its your method of asset management that's causing the problem. |
| ||
| Well, first off, why are you using a version of Blitzmax that's years out of date? I'm not asking you to upgrade, but expect stuff to be broken if you don't. > 1.26 and 1.28 caused too severe problems and i'm not able to work with GUI at version 1.30. I never had any problem with 1.24 and i programmed for years on it. I need thoses images for a 2D game with semi-smooth graphics. The process uses approximativly 20 000Ko (it varies between 19000 and 21000) and some other processes uses more than this. EDIT: another similar game from a massive project i did go up to a whole 50 000k memory usage and works fine. it uses 860 images (bigger on average than the game i'm making) and 80 sounds. That's wierd, because this old project success in loading all of thoses image, i wonder what's going on with my current project. |
| ||
| I can say with some confidence that an application that uses 20MB of resources is not the problem here. Mine uses over 100MB and runs perfectly well. There are other factors involved but without seeing code, and without knowing specific details about the images you're using (quantity, dimensions, etc), its difficult to speculate further. |
| ||
Two files for each image. one is ".dat" and contain primary informations about how my game will handle further on.
Const GRAPHICSPATH:String = "imgdat/"
Global debugcount=0
Type graphic
Field width:Int
Field height:Int
Field handlex:Int
Field handley:Int
Field handlemx:Int
Field handlemy:Int
Field image:TImage
Method draw(x:Int,y:Int)
SetImageHandle image,handlex,handley
DrawImage image,x,y
End Method
Method tile(x:Int=0,y:Int=0)
SetImageHandle image,handlex,handley
TileImage image,x,y
End Method
Method load(name$)
Local in:TStream = ReadFile (name$+".dat")
If in
width=ReadInt(in)
height=ReadInt(in)
handlex=ReadInt(in)
handley=ReadInt(in)
handlemx=ReadInt(in)
handlemy=ReadInt(in)
EndIf
image=LoadImage(name$+".bmp")
debugcount=debugcount+1
DebugLog debugcount+":"+(image<>Null)
End Method
Function loadcomplete(data:graphic[])
Local i:Int
For i=0 To Len(data)-1
data[i]=New graphic
data[i].load(GRAPHICSPATH+"ID"+Right("000000"+i,6))
Next
End Function
End Type
Global imgdat:graphic[2048]
graphic.loadcomplete(imgdat)
and the debug shows it always stop at the same point. =( [...] DebugLog:502:1 DebugLog:503:1 DebugLog:504:1 DebugLog:505:1 DebugLog:506:1 DebugLog:507:1 DebugLog:508:1 DebugLog:509:0 DebugLog:510:0 DebugLog:511:0 DebugLog:512:0 [...] |
| ||
| 1.24 ? Ouch. |
| ||
At first glance, something that was immediately apparent was that you don't appear to be closing the TStreams when you're done with them. That alone could be causing a problem....
If in
width=ReadInt(in)
height=ReadInt(in)
handlex=ReadInt(in)
handley=ReadInt(in)
handlemx=ReadInt(in)
handlemy=ReadInt(in)
CloseFile(in) ' <<<---------
EndIf |
| ||
| owies! indeed. let's check... YES! this was because of it. thanks! Edit: why "ouch" for my version? It works fine. :D The only think i can't do are "glows" with max2d, like having every pixel of an image turn blue when i use setglow 0,0,255. or like: when you get hit, you turn red (your char is only draw with 255,0,0(rgb) red pixels) then slowly go back to normal. other than that I just can do anything ;D |
| ||
| No probs. |
| ||
| ...there's a SetGlow command?? [edit] No, apparently there isn't. You can easily fake glow effects in a variety of ways, though. |
| ||
| Edit: why "ouch" for my version? It works fine. :D Perhaps, kinda-sorta, but in addition to a bunch of new features, there have been a LOT of bugfixes since 1.24: ***** 1.34 Release ***** ::::: IMPORTANT ::::: This will be the last release to support Win95/98/ME. * Added SA_RESTART to sa_flags in blitz_thread.c to fix wait(pid) dying when GC stops world. * Mac OS 10.6 tweaks. * Removed BDWGC garbage collector entirely. * Updated FASM to 1.68. * Fixed debugger string escaping. * Improved ToLower/ToUpper unicodeness. * Changed default installation dir to C:\ * Tuned MS GC significantly. * Added MouseX/Y/ZSpeed() functions to brl.polledinput. * Fixed fasm2as bug. * Linux/Macos mutexes now recursive as per Win32. * Fixed Win32 RequestDir initial directory. * Restored hwndOwner=GetActiveWindow() to RequestFile/RequestDir; * Added MS (Mark Sibly) garbage collector! * Fixed enet_peer_address - was using completely wrong struct offsets * Fixed Linux StopTimer - was releasing timer multiple times * Fixed OpenAL delete buffer leak ***** 1.33 Release ***** Major unicode fix release! * MacOS/Linux/Win2K/XP/Vista: Full unicode support has been added to the BRL, Pub and MaxGUI modules! * Win95/98/ME: MaxGUI now provides unicode support but requires unicows.dll to run: http://www.microsoft.com/downloads/details.aspx?FamilyId=73BA7BD7-ED06-4F0D-80A4-2A7EEAEE17E2&displaylang=en You will need to copy the included unicows.dll into your BlitzMax directory to run the MaxIDE under 95/98/ME, as MaxIDE uses MaxGUI. Max apps that use MaxGUI will also need unicows.dll to run under Win95/98/ME. Unfortunately, unicows cannot legally be redistributed with apps so you will need to notify users in a readme.txt file or similar. The BRL and Pub modules DO NOT support unicode under Win95/98/ME and do not require unicows. * MaxIDE now does a quick test to see if it can write to necessary directories when it starts up. This should detect any potential problems with admin/user modes on Vista. Note: If you install Blitzmax to the default "program files" directory on Vista, you will need to use 'run as administrator' to run MaxIDE. Installing BlitzMax elsewhere (for example, good old "c:\") will allow you to run MaxIDE as a non-admin user. * Several changes to BRL.System and Pub.Stdc - many interfaces that previously used $z and $w params now just use plain Blitz strings. This will hopefully not affect client code in any way! * AppDir and AppFile detection code moved from BRL.AppStub to BRL.Blitz. * TChannel Playing() methods in BRL.OpenALAudio and BRL.DirectSoundAudio modified to return False if channel is paused. * Linux glgraphics window close button now generates EVENT_APPTERMINATE (AppTerminate() in polled mode...) ala Win/Mac instead of just closing/dying. * Linux glgraphics window size now locked ala Windows, Mac versions. * Removed exception handling for SIGILL, SIGSEGV, SIGABRT, SIGTERM. These used to get converted to Max style 'Throw's - but only on some platforms and in a quite probably unrecoverable way. Best just to leave these to the OS/debugger to deal with. * Enabled gcc implicit-function-declaration warnings in BMK. * Implemented FlushJoy. ***** 1.32 Release ***** ***** 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 ***** Removed BRL.Retro dependancy from Axe/Pub.Lua. Added Axe.Lua module to Pub - ie: it's now Pub.Lua. Added Mark's/Brucey's higher level BRL.MaxLua module. ***** 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 ***** Added GLShareContexts to enable sharing of OpenGL contexts - should be called before any OpenGL graphics are created. 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. ***** 1.30 Release ***** Major sanity check release! MaxGUI has been moved to its own module, maxgui.mod. This means you will now have to manually import maxgui, eg: Import MaxGUI.MaxGUI 'import maxgui core Import MaxGUI.Win32MaxGUI 'import win32 version Import MaxGUI.CocoaMaxGUI 'import macos version Import MaxGUI.FltkMaxGUI 'import linux version The default audio driver for Windows has been changed to DirectSound. This means if you don't call SetAudioDriver(), the DirectSound driver will be used. For Mac/Linux, FreeAudio is still the default driver. Syncmods has been disabled and is no longer supported by BRL. MaxGUI modules are now available in zip form from the 'product updates' page of the 'account' section at blitzbasic.com Internal changes: Lots of MaxGUI fixes from Seb. Added advadpi32 to bmk win32 link Debugger fix for out of scope objects. bbGCValidate() added to blitz_gc.c MaxIDE updated Brucey's patch: LoadSound method added to TAudioDriver Fixes and updates from Seb Fixed GC and final methods reflection bugs Removed nan/inf docs Added missing EVENT_HOTKEY ToString case (skid) Dragbar canvas fix for win32maxguiex compatability GNet now uses 32 bit floats Added -bind_at_load to bmk mac linkopts Fixed blitzmaxpath looping forever Default win32 audio driver now directsound Fixed getmodulehandlea/w param Added exception to loadbytearray/loadstring etc Sped up replaceall Fixed macos-version issue with PPC 10.4 Changed to maxgui.mod ***** 1.28 Release ***** Maintenance release. Internal changes: + (BMK/BRL.CocoaMaxGui/Pub.FreeProcess) Fixed various Leopard issues. + (BRL.Blitz) Fixed array downcasting. + (BRL.GLGraphics) Reverted mac version to fix windowed/fullscreen swap problems. + (BRL.FileSystem) Implemented 'FixPath' fix to allow for 'incbin::' style paths. + (BRL.Win32MaxGui) Fixed textview flicker issue. + (BRL.Reflection) Fixed issue with array TTypeId losing type desc byte ptr. + (MAKEDOCS) Fixed missing examples. + (BCC) Added check for concatenation of multidim arrays - not allowed! + (Brl.CocoaMaxGui) Implemented Brucey's fixes. + (BMK) Implemented Brucey's modifications. + (MaxIDE) Got rid of console text stream. + (BRL.DirectSoundAudio) Fixed premature release of sound buffer. + (BRL.OpenALAudio) Fixed faulty detection of 'finished' channels and handling of channel exhaustion. + (BMK) Added experimental speedup hack. Some issues with deleted bmx files, so off by default for now. To enable, create an env var called BMK_SPEEDUP set to 1. See bmk_make.bmx for details. ***** 1.26 Release ***** Mingw is the collection of C/C++ compilers and tools used to build BlitzMax on Windows. You only need to install Mingw if you plan to rebuild Blitz Research or third party modules. BlitzMax can be used 'as is' to create applications without having to install Mingw. BlitzMax now uses the latest version of Mingw. The Mingw auto installer is available here: http://sourceforge.net/project/downloading.php?group_id=2435&use_mirror=jaist&filename=MinGW-5.1.3.exe&2597933 Select 'current' when asked which package to install. Select 'MinGW base tools' and 'g++ compiler' when asked which components to install. Vista users: Once installed, you will need to copy the contents of the MinGW\libexec\gcc\mingw32\3.4.2 directory into MinGW\bin. Finally, make sure to add C:\MinGW\bin (or equivalent) to your system PATH environment variable. This can be done on most versions of windows by right-clicking 'my computer' and selecting properties/advanced/environment variables. + (MaxIDE) Fixed debugger =$ in strings causing crash. + (BCC) Added 'Not' to conditional compilation system, eg: ?Not Debug + (BCC/BRL.Reflection) Reflection support added + (BRL.Win32MaxGUI) Clamped selection length to actual text length + (BCC) Souped up auto arrays. + (BCC) Added array concatenation. + (BRL.Blitz) Added String.Join$( bits$[] ) and String.Split$[]( separator$ ) Also, as far as memory limits are concerned: Images are actually stored in video memory, not RAM -- so the memory used by them will not be visible in the Taskmanager. Plus depending on the size of the images they may actually take up more video memory than on disk, because they are stored in video memory in uncompressed, 32-bit format, rounded up towards the nearest power-of-2 dimensions. Which means that a 400x373 pixel JPG file that takes up 52,991 bytes on disk, will actually end up taking 512 x 512 x 4 = 1,048,576 bytes, is 1 MB. now load a hundred of those, and you need 100MB of dedicated video memory to hold them (in addition to however much memory your desktop and game video context take up on their own) You can force the program to use your normal system memory instead by loading and drawing pixmaps, but that's a LOT slower than using images because it keep converting and transferring them to video memory each time you try to draw one. |
| ||
| Yeah, the memory reported by task manager isn't useful when you're dealing with images as they are stored in video memory. I remember in old Blitz there was a function to tell you how much video memory was in use, but I couldn't find it in BlitzMax. |
| ||
| I remember in old Blitz there was a function to tell you how much video memory was in use, but I couldn't find it in BlitzMax. There isn't one in Blitzmax... |
| ||
| There isn't one in Blitzmax... yeah, isn't it blitz3d that does that? Otherwise...lets get that function back =p Version 1.24 (please don't ask me to upgrade, thanks :) ) As for using the old 1.24 version, we aren't going to 'ask' you, just 'suggest'....i'm pretty sure you would be safe with the latest version....perhaps even safer than your current. |
| ||
| ...i'm pretty sure you would be safe with the latest version....perhaps even safer than your current. Depends -- there have been quite a few memory leaks fixed since 1.24... |
| ||
| Version 1.24 (please don't ask me to upgrade, thanks :) ) Saying this was just inviting it in my opinion.. |
| ||
| if you have all of your images as Bitmaps, their size will tell you how much graphics memory you are using. |
| ||
| Or would it not give a lower estimate, as images are stored in sizes that are a power of 2 (or something)? |
| ||
| Or would it not give a lower estimate, as images are stored in sizes that are a power of 2 (or something)? Yup. and in addition to that: - The BMP would store the info in 24 bit, not 32, so add more for that - BMP can use RLE compression (run-length encoding), so if that's enabled the numbers will be off even further |
   |