To simplify all this, here is a brief description of what this topic has become:
MenuetOS needs 32-bit bitmap, including support for the alpha channel.

We would use this for conversion of PNGs and other images into 32-bit BMPs (as photoshop doesn't incorporate the alpha channel in 32-bit BMPs)
http://www.slavasoft.com/paintexpress/

and here is more info on BMPs:
http://guildhall.proboards15.com/index.cgi?board=Art&action=display&num=1059710103

By giving MEnuetOS 32-bit BMP support, it would solve many future issues of anti-aliasing, layers, trabnsparency, and such.

Read the rest of this topic to understand more on how/why I have come to this conclusion, enjoy!

----Old Post---
Yeah, I'm trying to learn assembly (on my own, which is kinda hard) in my robotics class and I found MenuetOS to be the only thing written for DOS in ASM that could achieve 32bpp with a decent resolution (800x600 or above); so I've decided once I learn ASM I'm gonna try to see if I can program a few things for MenuetOS!

Yeah, as you may now know, I'm a n00b and every n00d has their "suggestions", being a programmer I know not to say crap like "we need MenuetOS to run Java and can we put Winamp in MenuetOS"...no my suggestions are some that you guys would want to consider as it could have a long-term advancement of MenuetOS.

Here they are:
-Get rid of the bmp format, if it's too hard to do at least try building off of it, add some features similar to the PNG format...this can help you later on when you will be preparing for transparency and anti-aliasing...
If you can build the core around anti-aliasing and transparency abilities, the kernel will be slower, but any graphical apps will be way more eifficient.
(I'm not saying get all this done, but you may want to prepare the kernel for a change like this if you want MenuetOS to do anything graphically advanced)

-Form transparency is nice, but try to incorporate it with a bit more...see if you cold have two window "rendering" systems, one with smoothed windows and such and another with those square windows like you have now. What I mean is basically have the kernel decide whether windows need to have transparent edges before it tries to add transparency. Basically I'm saying add custom GUI shapes, but make it optional.

-Tell windows when the've lost focus, I've seen some coding and you have it set to detect if the click is on a certain window, why not tell a window when it's not being clicked on!? This would be usefull for like the taskbar app, when it loses "focus", make the menu close.

-Try to make some Visual GUI makers for ASM, like WYSIWYG stuff for creating forms and windows...(Yeah, if I ever finish learning ASM, you can expect me to make some stuff like this, I'm really good at making tools for simplifying a task) What would be real useful is a mix of coding tools (like to convert other languages to ASM) along with a whole bunch of ASM code optimizers. Even though MenuetOS is not related to Linux and Windows in any way, we can still use Win32 and Linux programmers to make ASM coding tools, it doesn't matter what you use to code it...it all get;s compiled to the same thing, lol

Yeah, as you can see...basic n00b requests.
Just don't get too annoyed, it's all good-willed!
All I can say is I like what I see in MenuetOS, and I want to see more!

You can get that graphic size in the boot sector of a floppy (512bytes). see "CdPod.zip"
http://board.flatassembler.net/topic.php?t=2164&start=50

\\\\||////
(@@)
ASHLEY4.

Batteries not included, Some assembly required.

huh, I really don't care about graphic size, that's not my point.
The BMP format is very limited, it's good if you want photos without any compression, but that's it.

What I'm saying is PNG supports transparency, something vital for anti-aliasing...if you want to layer images and anti-alias them, why not start by using a better suited image format.

I really don't know how to properly explain this...
Well, uh, a BMP is based on RBG color scheme, well a PNG has RBG plus an Opacity value. Basically, for future purposes, it would be better to give the kernel support for tranparency then have it try to anti-alias the images through processing.
Basically, if you were to use PNGs, the images would need to be anti-aliased.

I know it's sounds complex, but if you guys could go by this concept...the OS would be more graphically capable and could have a better looking or more grapically complex interface.

Trust me, if I already knew ASM, I'd be working on something like this myself, but I still have a long way to go before I can achieve any level you guys are at. Maybe in a month or so I'll know enough about ASM to show you guys an example.

Huh, do you not remember what you said, huh,
Huh, MenuetOS is not written for DOS, huh,
Huh, lots of things achieve 32bpp resolution (800x600 or above), even small program can
achieve it ,huh.

\\\\||////
(@@)
ASHLEY4.

Batteries not included, Some assembly required.

So does bmp, I have used this prog for editing "transparency" in bmp images for years http://www.mnwright.btinternet.co.uk/ (BmpExt) although it was for FS98 back then.
I agree that MeOS could benefit from png support (I think jpelczar already has some support for png) http://menuet.2.forumer.com/index.php?showtopic=370
But to say is a bit much. If you want the best quality use bmp, for icons you could use png or ico (already supported)

Actually when I said get rid of bmp, I was refering to using another format...or building on top of the bmp format.
And I do know that bmp supports some transparency, but it's very limited...I mean multiple level of transparency would be beneficial.

I know bmp will always have the best quality, and that is why it's so great...but bmp is not the ONLY uncompressed image format out there.


Also refering to MenuetOS running on DOS...well I guess you're right about it not being mean for DOS; I guess it is meant for the core of an x86 PC.
I just don't know what you would call that? Is it just called x86, cuz I know it all runs on DOS as nearly every PC has some DOS system in it.

Well, you definately have to read more about .bmp format. 32bit bitmap contains normal alpha chanel. Using of this channel depends only by imlpementation of the display routines.

The main purpose of the bitmaps is for internal representation of the graphic in the RAM (especially in Windows, but any other OS will benefit of using non-compressed format for internal representation - bmp or not).
It is simply a matter of speed. You can put the bitmaps in video memory and use hardware accelerator functions to show them on the screen with big speed. You can manipulate uncompressed data easy and you can't manipulate compressed data without uncompressing it first.

Regards

PNG uses a compression which does not affect the image quality in any way (unlike for example jpeg).
It's simply the best format around..

/ Christoffer

ok, I didn't know PNG used compression...so yeah, that wouldn't be good for the OS.

Anyways, yeah I know bmp is best for speed, but I didn't know it had a alpha channel in it, I thought it just supported basic transparency (like how GIFs have one transparent color).

I'll check it out...

----Edit----
I looked into it and found that only 32-bit bitmaps have the full alpha channel. so now we just need MenuetOS to support 32-bit bitmaps in full.

I also found (and read) from other people that photoshop supports very limited use of this, so I did some experimenting and Photoshop only support one transparent color, and all opacity data is removed.

Take a look here:
http://guildhall.proboards15.com/index.cgi?board=Art&action=display&num=1059710103

But I have found a peice of software that claims to support full 32-bit alpha features:
http://www.slavasoft.com/paintexpress/

----Edit2----
I tried out PaintExpress and it does support the extra alpha channel, but I hate the way it displays it, you can't realy see what the opacity is until you use the color picker (it doesn't show a grid in the background)
It also converts PNGs to BMPs with alpha channels, so we basically could use other programs and use PaintExpress to convert to bitmaps.

I thought we already had transparency support in menuet. Look at "Colour Demo" app or "Transparent" app. These two programs are included in the official distrobution. Also, if you look at the "circle" app there is rudamentry non-boxy form support for windows. I am sure this could be built upon to make full 32-bit graphic skins with transparent areas anywhere for any window.

an interesting page http://www.wotsit.org/default.asp

ok, I didn't know PNG used compression...so yeah, that wouldn't be good for the OS.

Yeah, today CPUs are still to slow to decode PNGs at OS runtime.

"Yeah, today CPUs are still to slow to decode PNGs at OS runtime."
If it can decode movies it should be able to handle png-images, don't you think? But maybe it's just Menuet that's to slow..

I think it was a joke about modern processors are slow to decode PNG at runtime

ahahaha....
Real funny, it's that d@mn attitude that will always make linux (a C system) faster than menuet (an ASM system)!

Yeah, I tried MenuetOS thinking oh wow, it will run fast on a few computers...well I was wrong, you guys didn't even code it well!
*I've seen so many complaints about poor coding and you guys all rip on them!

Who cares if modern PCs can handle it, aren't you guys making an OS to be faster and all around better!? Process everything with an alpha channel and it then you can Bypass many 24 to 32 bit conversions.
This will save speed and if you program it right, it will allow you to use an out-of-the-box PNG for custom form shapes AND better, more powerfull anti-aliasing (this includes fonts).

I've personally been looking to make my own OS, but I cannot seem to find a suitable start...Basically I need an ASM core that boots and loads a true-color 32-bit graphics mode.
I'd take it from MenuetOS and show you guys my ideas, but the boot system to Menuet is too complex with the GUI integrated too far...it would take me (who barely knows ASM) to even extract what I want!

Well, if anyone knows ASM and is interested in my ideas, I'll be glad to share them if someone would help me achieve them!

My idea is basic, yet has huge advantages...
You can basically make the OS layer everything as a "PNG", pretty much everything would have an alpha channel...then for final display it would all be combined and converted to 24-bit for display.

This would bypass the following:
transparent form algorithms
form shapng algorithms
font anti-aliasing (it would pretty much be pre-rendered)
form anti-aliasing (i'm sure you ahven't thought of that for form shapes but I would enver go without it!)
many 24bit to 32-bit conversions

I've also had gui ideas, but now that I saw linux...I noticed some of that aren't anything new...
But if anyone is interested...my GUI idea pretty much combines the best of Linux, Mac, and windows!
It would involve:
- Linux's multiple desktop features of KDE
- Windows Simplistic taskbar look (linux has almost too much crammed in it)
- The Mac Dock, have you ever actually used a mac for more than just 5 min...the dock is genious, just needs more multi-tasking functionality!
- Of course the Mac Espose feature...expose all windows for quick multi-tasking!

@dCool101d, You can try my "CdPod", it boots to full 32bit graphic mode and is less then 512bytes.
http://board.flatassembler.net/topic.php?t=2164&start=50
Or you can try my other demo that not only lets you boot to full 32bit graphic mode, but also lets you switch modes
http://board.flatassembler.net/topic.php?t=3368
called "DemoVesa.zip"
Or "Dex4u" for simple windowing

http://falconrybells.co.uk/
http://dex.7.forumer.com/
Note: i was called ASHLEY4. then.

Thanks Dex4u...it's great but not exactly what I want.

I know I'm too picky...
What I need is a VERY basic asm program that will enter 1024x768 32bpp mode.
Then I need instructions on how to control individual pixels and draw lines and lines all set!
As I said, I barely know any ASM, so I need something that simple.
I feel I know enough to do what I want if I get the right environment.

Axtually if you're interested, I thought of an amazing idea for an OS...
I would revolutionize the way people see operating systems and provide COMPLETE cross-campatability will ALL it's apps!!!
I told some others about it and they instantly became interested in learning more of my idea. Simple and complex at the same time, writing the GUI would be just as easy as making a complex web page!!! (almost literally)
*I'm actually afraid of who I tell my idea, as it could really be that easy and powerfull if done correctly.
All I can say is the core would be all flat out ASM, pretty much all code "emulating" a gui sort-of. Basically designing the system GUI would be in a WYSYWIG environment!!! A Nice GUI could be designed ground-up within a couple of hours! (hypothetically of course)

I just wish I knew enough ASM to make this stuff happen!

Just start reading some tutorials and start playing with your own bootsector and you'll understand it sooner then you might think.
It's a great feeling to look back to the times when i could stare at a asm program and wonder wtf it did, and now it's as simple as ABC..

While experimenting with my 2D rendering engine (5 ticks/pixel sustained for 32-bit SRC alpha ) I found TGA to be best format for 32-bit graphics. Most apps handle it properly, unlike 32-bit BMPs.. and header is even simpler. Anyway, I just cann't understand reason for making _all_ code in assembly language. It is not even always more compact (espesially is not compared with C-likes, but with, for example, FORTH) it isn't faster as well ( hours of thinking and instruction swapping are sometimes required to get significant advantage over modern compilers ). So, why bother?

lol, I think it's just the feeling of accomplishment alongside it...
Anyways, what does this have to do with this topic really?

But thanks for the tip with TGA...so I'm guessing TGA supports a full alpha channel (hence 32-bit)?
I never knew, I just thought it was an outdated format that tried to compete with BMP...very interesting

Maybe EVERYTHING in menuetos should be done in TGA instead?!

E}I{: I would like to know more about your graphics programming, you may have just what I need (as in source code & knowledge) to finally start a project I've wanted to do in years!