A Bitmap Editor

[BytePtr]

When i open any file and modify it.. then when i close app, it does not ask u to save changes user made, also when u open new file or create new file.
BUG!!.

Otherways good work.

[EddieB]

Bug?

Or the feature hasn't been implemented yet? :P

[Darrel]

You almost successfully reverse engineered all the features mighty mspaint had

I'm not certain I understand what you mean by reverse engineering. If you mean disassemble and/or look at the machine code in some manner, then no, it is not reverse engineered.

Thanks for pointing out GDI+.

When i open any file and modify it.. then when i close app, it does not ask u to save changes user made, also when u open new file or create new file.

Just hasn't been done yet. I have just recently considered adding this option and will do so hopefully in the near future.

Regards,

Darrel  :8)

[ramguru]

I'm not certain I understand what you mean by reverse engineering. If you mean disassemble and/or look at the machine code in some manner, then no, it is not reverse engineered.

Definitely not that  meaning, it's a process of analysis of an object in order to make your object work that way  :wink

[Darrel]

Definitely not that  meaning, it's a process of analysis of an object in order to make your object work that way  :wink

OK, yes I designed it to have the look and feel of paint because I do like paint's layout it just doesn't do enough for me.

Regards,

Darrel  :8)

[Darrel]

Program now prompts the user if they want to save changes to bitmap.

Regards,

Darrel  :8)

[TheGreatJason]

And the big pixel grid to work in is useful sometimes but not absolutely necessary.

Would a Zoom of 1600% suffice and/or do we want an actual grid?

How about both! :bg Also, I would like to see Custom zooming and Auto zooming as well (scale it up as big as possible to fit on the screen).

There are a few noticable problems with yours at the moment though.  Main one for me is how it handles the multiple image icons.  Not that it handles them very much at all yet...  You see when you open a multi-image icon they all appear on the side.  That's great!  Exactly what we want it to do.  To change onto one you have to double-click on it.  Single-click would be better I think...  No big problem there though.  But if you edit one of them and then change to another, all the edits you have made suddenly disappear on the icon size you were editing...???  And if you try to save the file itself to stop this happening, you find that only the image that was selected is saved, by its poor little self.  We want the whole collection to be saved.

Sometimes when we grab the mouse, we unintentionally click it, this is why I made the change to take place on a double-click.

Nah, if we can get it so you don't lose edits when you change images, and the collection is treated as a collection and not just a list of images to open, then accidental image switching is no longer important, and you don't need to prompt for changes either on switching images (so don't implement that).

Do we want to automatically save changes to an image of a multiple image file, when we select another image or do we want to express our disire to save the changes?

We don't want to save any changes when we select another image.  We simply want it to be retained in memory so if we switch back to that image the changes will still be there (and shown in the list of images on the side).  In fact you seem to have removed the preview in the multiple images thing for now.  I can understand why, but it will be changed back when things are working...

Do we want to be able to save a multiple image file under another name or overwite the existing file?

Doesn't that relate to Save/Save As?  I suppose we could add a 'Save Single Image' Option if you wanted to just save one image out of it.

Is it okay if we are limited to changing the pixel data (Not be able to change size or color depth.) of an image in a multiple image file?

When you're designing icons the size certainly doesn't change in a single icon, and I don't suppose there's any need to support changes in the colour depth either.  So that's one useless feature that we don't need to add!

Other noticable problems: when you move the paintbrush around the highlighted pixel to edit lags WAY behind the pointer (my PC is slow so it picks up program performance problems really well...).

Does a selected portion of the bitmap or pasted bitmap with transparency lag as bad when you move it around the surface of the main bitmap?

Now that's really interesting! :eek OK, I was experimenting with the diagonal line paintbrush (5x5 pixel size one) and copying it with and without transparency in 800x zoom.  (Turns out that the higher the zoom factor is the worse the performance)  The copied version of the 5x5 bitmap containing the shape had almost no lag at all. The paintbrush version of the shape did have lag.  If you moved it around quickly you could see big gaps between them.  The transparent version of the bitmap had abysmal drawing problems.  It takes up to 2 seconds just to move it to a different position.  There's something seriously wrong with this part of the program and you'll have to review it.  By the way, in MSPaint, at the same zoom level, NONE of these operations have ANY lag.

Too bad we can't just 'reverse engineer' Paint in the actual sense and see what algorithm they have used... :bdg

Also, when you move the paintbrush off the image, the pixel just stays there.

Microsoft's Paint program does the same thing if you have another window partially covering it. I will work on a fix tho.

Very true (although the only window I usually have over the others is my WinTV 2000).  It would be quite nice if we could fix that one somehow...  Best way I can think of is to remove the paint whenever a mousemove event is received outside the drawing editor, and also include a periodical test running constantly in the program (maybe once every second) for last mousemove and where the pointer is now, and if it's not the same place then remove that paint!  In VB you can use a Timer Object to run that testing code, but I have no idea if there is a similar set up for assembly or you have to do it differently.  (I'm guessing the second option...)


OK, the text inserting works properly now!  Now then, can it be done so that you don't have to be in 100x zoom?  Consider double-buffering or any other technique you can think of...

Don't know how much time I have invested. Been working on it a Year and a half, off and on.

:clap: Usually when I go off, I find it hard to get back on.  Quite annoying really.  Well done to you.

Jason :toothy

[hutch--]

Hi Darrel,

I downloaded and had a quick play with the app and it looks good for this stage of development. I regularly use Paintbrush for 16 colour images so your did have a familiar feel to it. Something that waould be a nice add in is a pallette with more choices than the pbrush style one that you are currently using. A 256 colour pallette would be "nice" and perhaps a similar technique for 24 bit images.

[PBrennick]

Darrel,
Hutch makes a good point here. I would suggest that pallette selection be selectable as it is in PSP. Eventually you should impliment selectable transparencies. I like the eye dropper method used by PSP, it is very simple for a user to select a colr in that manner. This ensures that the color selected for transparency exists in the image as your current method does, also.

What do you think? Just ignore the temptation to RE, some people...

Paul

[u]

Nice Paint2, Darrel, - well done  :U  !
I used to draw a lot with MS Paint, loved it. Until GIMP2 came out ^^" .
Your remark about OpenGL usage in the "to do" list... I doubt you'll need it, I doubt it can improve performance or add features. Its limits to 2096x2096 (on most GPUs) will just be a stumble.

A thing, really missing in ABitmapEditor, is shortcuts for the tools. Shortcuts like "r" for rectangle-selection, "v" for line, "n" for pencil, "f" for bucket, "b" for brush, are important for any graphics app.  Note that they are mostly to the left part of the keyboard layout (on qwerty). You basically draw faster and easier with those. Because you don't have to move the mouse or your right hand. Also, +/- or other keys - for zoomin/zoomout (they needn't be keys on the left part of the keyboard, since after a zoomout you anyway have to move the mouse again... unless you make the zoomin/zoomout dependent on cursor position [would be great] ).

Layers - are the best feature you can add (requires alpha-channel). But not complex layers like in PhotoshopCS, that have runtime-computed effects (shadow, bump) ; such layers just make the artist use a hundred layers to do anything useful. But AFAICS, layers are not something you'd like in ABitmapEditor.

I experienced a bug, that crashed the app (but I forgot to copy the register values). I managed to reproduce the bug once, but this time the app exited silently. Thus, I think it's either a garbled ESP/EBP (wrong number of parameters passed to a call), or somewhere ESI/EDI/EBX are not preserved in a callback. The two times, the bug happened when I performed "Paste From", and had a rectangle selected in the bitmap, then after some drawing/selecting, performing a PasteFrom again. I wasn't able to reproduce the bug in the next dozen attempts, though.

[Darrel]

In fact you seem to have removed the preview in the multiple images thing for now.

No, I didn't. I just checked it on Win '95 and it works.

I will probably add an alpha-channel paste routine.

I am currently working on the printing aspects.

Thanks for everyone's input, all things will be considered.

Regards,

Darrel

[TheGreatJason]

In fact you seem to have removed the preview in the multiple images thing for now.

No, I didn't. I just checked it on Win '95 and it works.

I meant of course while you're editing an image from a multi-image icon the side preview DOESN'T change with it.  That's what it used to do.  We only want it to do this when we can save the multi-image icons properly though...


Another barrage of criticisms for you:

The paintbrush is ALWAYS black.
The thumbnail doesn't jiggle about when the paintbrush is on.
When the paintbrush tool is on, things generally get a bit slooooooow...  (If you have a decent size bitmap on screen, not that 400x400 size is that big...)
Things are generally slow in general (OK, that's just too general to be constructive really)
When you make the bitmap size large enough it crashes (I got it to crash at 1000x1000)
The buttons act on MouseDown, and not MouseUp, the standard way.  You probably want them to work in the same way that the huge X button on the top-right of every single window does.
When you rotate an image by a custom amount, the bitmap always changes size, which is unsuitable for use in icons.  (Also, the default background colour to fill with is black in this case, rather than the actual set background colour...)

Looks like you've got some REthinking to do.  And how about an About dialog when you've sorted everything else!? :U :lol And then to complete it a help file of course.


Contrary to Ultrano's argument, I would say that usage of OpenGL would drastically improve performance based on what it does now, referring to the painting to screen, and there would probably be some useful features in there too.  Besides the fact that 2096x2096 barely works in this editor at the moment anyway, I'm sure there's an easy way to cheat and get around that problem so you can use bigger bitmaps.  Isn't it possible to store most of the bitmap in memory and only work on what is on screen?  Also, I think independent keyboard events should never have anything to do with the mouse pointer.  Although a possible way to do it would be to use shift for zooming.  Shift+LMB = Zoom in to pointer; Shift+RMB = Zoom out from pointer; Shift+Drag LMB = Zoom Selection Box.  Or maybe you could use Ctrl instead.

Seems to be a lot more to a bitmap editing tool than meets the eye ay? ::)

[u]

There are 2 reasons for these problems:
1) Allocating memory for an unnecessary back-buffer and front-buffer
2) Simple undo/redo manager


Instead of keeping a back-buffer and front-buffer, just do a StretchBlt/BitBlt to the device-context, given by BeginPaint/GetDC.

For an undo/redo manager, I've recently made exactly what you need (attached is the complete version). Just give a pointer to pointer of your bitmap before any drawing  with XURM_DynArray(). The manager will clone the bitmap-data, then just before your next change to the image it'll compress quickly via XOR+zip. Thus, instead of saving/keeping the whole bitmap, it'll find where the modifications start, where they end, and will compress in a smart and fast way only the modifications (more precisely, their deltas).
I was thinking of using this UndoRedoMgr in a GIMP clone, but then I was forced to get a better PC, where GIMP is not starting-up for 20 seconds... so my only reason to start the project was gone ^^". Btw, set HEAP1= handle of the heap you use, before calling any URMgr procs. 


[attachment deleted by admin]

[Darrel]

Fixed a problem with the *.jpg writer, added Print support, added an About Box.

I saved a file that was 4096 X 3072.

Regards,

Darrel

[Darrel]

Fixed some performance lag problems. Now drawing with the brush or moving a transparent selected or pasted bitmap looks good on my Win '95 75 MHz computer.  :dance:  :clap:

Brush disappears when cursor is moved off working area.

Will work on line, curve, rectangle, and ellipse drawing next.

Regards,

Darrel   :8)