- Welcome to The MASM Forum.
News:
Masm32 SDK description, downloads and other helpful links
Message to All Guests
NB: Posting URL's See here: Posted URL Change
Recent posts
#41
The Workshop / Re: A useful tool: BMP data vi...
Last post by NoCforMe - November 24, 2024, 11:04:38 AMQuote from: _japheth on November 23, 2024, 06:51:34 PMQuote from: NoCforMe on November 23, 2024, 10:21:06 AMIf anyone knows anything about either of these two things, could you reply and post what you know here? It would be much appreciated.
Can't do a comment on those 2 things, because the program crashes - feeding it with a very simple 16bpp bitmap (attached). I'm using WinXP 32bit, in a VM under Linux, though. Seems the crash is due to "TextBuffer" being too small...
Crash was due to the program being totally confused by 16bpp images. That has been added and it now works with them. New version attached here. Could you give it a whirl to check it? Thanks.
BTW, that BMP you used was originally generated by my BMPfromText program, but it's been modified. Did you use my program to create it? That program creates 32bpp BMPs, but yours somehow got converted to 16bpp: what did you use to do that? I don't think I have anything here that's capable of doing that; Paint Shop Pro only creates 24bpp BMPs.
There's another little wrinkle here: your 16bpp file has 65,536 in the "colors used" field (the biClrUsed member of the BITMAPINFOHEADER structure). Micro$oft has this to say about that member:
QuoteBitmaps that are 16-, 24-, or 32-bpp do not require color tables, but may have them to specify colors for palettized devices. If a color table is present for 16-, 24-, or 32-bpp bitmap, the biClrUsed member specifies the size of the color table and the color table must have that many colors in it. If biClrUsed is zero, there is no color table.
Except that in the case of the file you attached, this member is not zero, and yet there is no "color table" (palette). ????? So in my code I'm just ignoring this field not being zero and assuming there's no palette in 16bpp BMPs.
Anyone know more about this?
#42
The Workshop / Re: A useful tool: BMP data vi...
Last post by sinsi - November 24, 2024, 08:25:58 AMI inserted some code at the start of ProcessBitmapData which just wrote a char to the edit window in an endless loop to simulate a busy thread and found the window was responsive :shrug:
#43
The Workshop / Re: A useful tool: BMP data vi...
Last post by zedd151 - November 24, 2024, 07:07:08 AM## UPDATED ##
I made a little test program of my own. It simply opens a pre-defined bitmap file (included), processes the bitmap bytes, writes the data to a file then exits. It is very fast, your mileage may vary. There is a huge 24 bit bitmap file 5MB+ used for testing the program included in the zip file.
This code is only for proof of concept, and useless otherwise.
meaning, I don't want to hear anything about possible flaws/bugs in it. 
just kiddin'.
stride and header size are hard coded for this test, and a table for byte to string conversion is used for speediness.
The code has been revised a bit...
Now formatted for 8 RGB sequences per line, and is finished!
a few changes made...
I made a little test program of my own. It simply opens a pre-defined bitmap file (included), processes the bitmap bytes, writes the data to a file then exits. It is very fast, your mileage may vary. There is a huge 24 bit bitmap file 5MB+ used for testing the program included in the zip file.
This code is only for proof of concept, and useless otherwise.
meaning, I don't want to hear anything about possible flaws/bugs in it. just kiddin'.stride and header size are hard coded for this test, and a table for byte to string conversion is used for speediness.
The code has been revised a bit...
Now formatted for 8 RGB sequences per line, and is finished!
a few changes made...
#44
The Workshop / Re: A useful tool: BMP data vi...
Last post by zedd151 - November 24, 2024, 01:15:32 AMQuote from: NoCforMe on November 23, 2024, 07:54:26 PMI'm really starting to think that this might have something to do with the dialog manager. I was considering using IsDialogMessage(), but since I don't have a message loop that won't do much good.Have you thought about foregoing the dialog box and using either a Window, or even writing to stdout, in a console version? - At least for only the bitmap data...
I would isolate only the bitmap processing functions (you would still have to calculate where the bitmap data starts, of course - for the different flavors of bitmaps), omitting the header info display, and the mini bitmap display, to concentrate solely on making the bitmap data processing faster (use some form of timing mechanism, to verify just how much faster one algorithm is, versus another)
You already know that your bitmap headers info processing, and miniature bitmap processing works okay.
After you get that as fast as possible, then you can finish up the GUI code.
that's my tip/suggestion of the day. #45
The Workshop / Re: A useful tool: BMP data vi...
Last post by NoCforMe - November 23, 2024, 07:54:26 PMThanks, @_japheth: I should have that format (16bpp) handled by tomorrow.
Any clue on the non-responsiveness? I'm really starting to think that this might have something to do with the dialog manager. I was considering using IsDialogMessage(), but since I don't have a message loop that won't do much good.
Any clue on the non-responsiveness? I'm really starting to think that this might have something to do with the dialog manager. I was considering using IsDialogMessage(), but since I don't have a message loop that won't do much good.
#46
The Workshop / Re: A useful tool: BMP data vi...
Last post by sinsi - November 23, 2024, 07:21:04 PMIt is a lot faster, but still not responsive.
_japheth found a BMP that's in a format rarely seen nowadays (though perfectly valid) - 16 bits per pixel, which your code doesn't allow for.
_japheth found a BMP that's in a format rarely seen nowadays (though perfectly valid) - 16 bits per pixel, which your code doesn't allow for.
#47
The Workshop / Re: A useful tool: BMP data vi...
Last post by _japheth - November 23, 2024, 06:51:34 PMQuote from: NoCforMe on November 23, 2024, 10:21:06 AMIf anyone knows anything about either of these two things, could you reply and post what you know here? It would be much appreciated.
Can't do a comment on those 2 things, because the program crashes - feeding it with a very simple 16bpp bitmap (attached). I'm using WinXP 32bit, in a VM under Linux, though. Seems the crash is due to "TextBuffer" being too small...
#48
The Workshop / Re: A useful tool: BMP data vi...
Last post by NoCforMe - November 23, 2024, 10:21:06 AMNew version attached.
I've eliminated all wsprintf()s at least from the most compute-intensive code (the pixel-displaying stuff); I'm doing all the number conversions (decimal & hex) by myself, so it's a wee bit faster. Still sloooow on large BMPs. I don't see much room for improvement in my code.
Also corrected the address display for lines of pixels.
But there are still (at least) two things that bother me:
1. I still see memory usage slowly but steadily climbing while this runs, and I can't figure out why. I am doing absolutely no memory allocation in the pixel-display code, nor am I using any Win32 functions; it's all just code working with variables.
I wonder: if you allocate a large buffer using HeapAlloc(), is it possible that as you use more and more of the buffer, the OS is actually doing some kind of incremental allocation? I always thought that if you allocate, say, 8 MB of memory that you're given an 8 MB chunk in one fell swoop. But maybe it doesn't work that way: maybe that 8 MB is only marked out as being allocated, but as you use more and more of the buffer (by making memory references to it), it is physically allocated by page faults. I don't know enough about the innards of Windows to answer this, but it would explain the steadily increasing memory usage I'm seeing. (Calling Raymond Chen!)
2. Still don't know why the program goes non-responsive while cranking through all that data, since that code is in a separate thread now. Apparently that's not sufficient to prevent the compute-intensive code from bogging down the rest of the program. The program uses a dialog as the main window; maybe the dialog manager doesn't play well with my thread?
If anyone knows anything about either of these two things, could you reply and post what you know here? It would be much appreciated.
As it is, this is still a useful tool. And maybe that long wait is deserved: after all, anyone who makes that large a BMP is just asking for trouble ...
I've eliminated all wsprintf()s at least from the most compute-intensive code (the pixel-displaying stuff); I'm doing all the number conversions (decimal & hex) by myself, so it's a wee bit faster. Still sloooow on large BMPs. I don't see much room for improvement in my code.
Also corrected the address display for lines of pixels.
But there are still (at least) two things that bother me:
1. I still see memory usage slowly but steadily climbing while this runs, and I can't figure out why. I am doing absolutely no memory allocation in the pixel-display code, nor am I using any Win32 functions; it's all just code working with variables.
I wonder: if you allocate a large buffer using HeapAlloc(), is it possible that as you use more and more of the buffer, the OS is actually doing some kind of incremental allocation? I always thought that if you allocate, say, 8 MB of memory that you're given an 8 MB chunk in one fell swoop. But maybe it doesn't work that way: maybe that 8 MB is only marked out as being allocated, but as you use more and more of the buffer (by making memory references to it), it is physically allocated by page faults. I don't know enough about the innards of Windows to answer this, but it would explain the steadily increasing memory usage I'm seeing. (Calling Raymond Chen!)
2. Still don't know why the program goes non-responsive while cranking through all that data, since that code is in a separate thread now. Apparently that's not sufficient to prevent the compute-intensive code from bogging down the rest of the program. The program uses a dialog as the main window; maybe the dialog manager doesn't play well with my thread?
If anyone knows anything about either of these two things, could you reply and post what you know here? It would be much appreciated.
As it is, this is still a useful tool. And maybe that long wait is deserved: after all, anyone who makes that large a BMP is just asking for trouble ...
#49
The Workshop / Re: A useful tool: BMP data vi...
Last post by daydreamer - November 23, 2024, 05:14:34 AMYou should read in filesize first and allocate memory according to that and free memory after finished
For hex editing bmp and other files,there are already qeditor binary load/save functions
I used this binary load bmp after creating and saving 'empty' bmp with paint,just to copy and paste bmp file headers into my programs that "draws" isometic 3d and saves as bmp witt same size and bitness as previous empty bmp
with lots of optimizers here that can help you
For hex editing bmp and other files,there are already qeditor binary load/save functions
I used this binary load bmp after creating and saving 'empty' bmp with paint,just to copy and paste bmp file headers into my programs that "draws" isometic 3d and saves as bmp witt same size and bitness as previous empty bmp
with lots of optimizers here that can help you
#50
The Campus / Re: Fatal error A1000
Last post by TimoVJL - November 23, 2024, 03:35:54 AMQuote from: Baroooo on November 23, 2024, 02:24:41 AMYes man, I have got a bunch of compilers like gcc plus python and java as well and some other languages also sousing basic rules helps, like keep good care of enviroment variables like PATH,INCLUDE,LIB helps a lot.. I just wanted to know that am I the only person facing this problem? Nobody seems to facing this and I think there is some problem with the Environment variables but thing is, theoretically it should work, the assembler is present, cmd can find it, it isnt even showing wrong code, it directly says A1000 or file not found, yet it absolutely is there. Complete sorcery.
masm32 design is problematic, but sometimes SUBST helps.
Code Select
SUBST /D M:
SUBST M: C:\code
M:
PAUSE