@Atheist

It is rediculous what you are all argueing about, and the same is too often seen in too many forums.

There are different languages out there to solve different problems.
A beginner might prefer Basic, an expert prefers C. If i do a small project, I have different needs than if I do a large project.

In a large project, defining variables helps me to save a lot of time, whereas it feels to much overhead if I am programming a three-liner.

Do you get this?

Atheist: The choice of language depends on your experience level, on what you want to do and to what extent you can make compromises.

If it is ok for you to set a pixel to pen #7 on an AMOS-screen, that's fine. If you want to set a pixel on any screen, at any colordpeth, on any platofrm, AMOS is useless, or, will result in a comparable amount of code than C, just looking uglier.

You can not put programming languages into an order like

C > Amiblitz > AMOS > AREXX > Perl.

Doesn't make sense without defining your needs.

P.S.: And doesnt make sense to compare languages with a one-liner like "number=5".

About the BlitzBasic thing:

BlitzBasic, now Amiblitz3, is way to huge to make a statement like "Amiblitz3 is slow/fast/hardware banging/system conform etc.".

It all depends what you do and how you do it.

Anything that can be written in C or ASM can be written in Amiblitz too. I think a good hint about any programming language is to look at what Projects have been done already and how powerful they are. Of course C out-perfromes all, since this is the most common language on Amiga.

But here are some random screenshots of projects of mine (one person, job, family) in Amiblitz3, to show off a bit what's possible (there is much more, but I dont want to bother you loading even more GFX, sorry for the huge pics). Try to do this in other languages in your spare time, or shut up blaming Amiblitz for being slow/lame/hardware banging/complicated/buggy/worse than language <xyz>.

HD-Rec (System friendly, speed critical)
http://www.hd-rec.de/HD-Rec/pics/screenshots/hdrec_spectrum.png

VoxelEngine with post-effect
http://www.amiforce.de/screenshots/test_blur2.jpg

VoxelEngine...
http://www.hd-rec.de/pics/_mirror.jpg

MapEdit (MapEditor, system friendly)
http://www.hd-rec.de/pics/EE_shot.jpg

NTUI Toolkit (system friendly)
http://www.hd-rec.de/pics/ntuistatus6.png

AHI Audio Player with skin GUI (system friendly)
http://www.hd-rec.de/pics/TKPlayerSkins.png

Toadies, Worms Clone, hardware banging
http://www.hd-rec.de/pics/Toadies_Rocks1.png
http://www.hd-rec.de/pics/Toadies_Cheeseland.png
http://www.hd-rec.de/pics/Toadies_Choclate2.png

Edit: Please do not post large images in the forum, they tend to mess up the forum layout.

If you want to program a game without learning a lot about Amiga Internals, a game that works on all platforms (execpet AROS) and is fast, you probably want to use Amiblitz3.
(hey, it is NOT an old-tool and NOT hardware banging)

It provides the flexibility, ease of use and speed you need for a game. The only alternative I see would be Hollywood, but I dont know enough about it to recommend or not-recommend it.

However, from a Programmers point of view, C is quite a nice language and not hard to learn at all. It is much harder to kearn the AmigaOS API, which you must do in every language that does not provide fancy commands like image_Blit, image_Load for you. Amiblitz3 gives you both possibilities.

Sorry that I have to say that, but the GUI looks horrible.
You are breaking almost every design law for GUIs in order to gain some Eye-Candy, but all you gain is confusion and an inconsistent, diletant look.

Too many font styles, too many colors, to many different borders, randomly-made layout and on top of all a fake Window Manager for the status window. And probalby it all falls into pieces if you choose a different font (if supported at all).

Amos is crap. Amiblitz alone is crap too, if you want to do serious developing nowadays. But it is written in itself and very flexible and has a very good IDE. Now there are the "Includes". They give you the power and the speed what you expect from an allround language. If anyone want to create a new language, maybe the API and Source of the includes would a good start.

@Mason

I am currently creating a new GUI Toolkit. While doing some test GUIs, I found many problems with the AISS images (or mabye I am using them in a wrong way?).
I know it is hard to satisfy all people, but...
But you sorted the images accordings usage, e.g. File Management. If you really use the images like you suggest, the result might be the following:



Look at the toolbar at the bottom. All copy, copyas, move, move as, rename etc. look almost identical for the user. They should disriminate among each other much more.

Would you be willing to change some images, if I point out where the problems are like in this example?

@Mason

Yes, I got it, thanks.
I am working on a AISS enabled version of HD-Rec. Thanks for the Icons!

@orgin

It is quite similar to this, were the AISS images are stamped into an aqua bubble. (only that the aqua bubble would be the icon, and the icon would be the emblem) also, there is adding glow, color manipulation (darkening, tinting, saturation etc.), and high quality resizing.



Would be easy with this code, unfortunately it's Amiblitz3, 68K and OS3.

@klesterjr

If I am allowed to request some icons, I'd love to have icons for

- HD-Rec
- MapEdit (a tile-based Game level editor)
- ScreenCam (screen video)
- TKPlayer updated (see the skins it has now)
- TuiTEd, I am not so happy with the current Icon. I would preferre something based on the Green Editpad icon.
- Amiblitz3 (here is the logo: http://amiblitz3.amiforce.de
- ActionPaint (comming when its done...)
- PerlinFX (fraktal Texutre generator)
- TreeGen (Tree gfx generator)
- Giga Voice (TTS Engine)

Keep up making cool icons! I really like them...

@klesterjr

http://www.five-star.com/kens_icons/downloads/kens_icons_v4.lha

Those Icons are working fine under AfA.

What I can see on the AfA Screenshot is, that the whole Alpha Blitting is not working correctly. The Directory doesnt habe shadows. Check if you have the correct icon_library.exe in AfA_Libs:

@Mason

So i'd like to see the images (if not present already):

* musical notes 1/1, 1/2, 1/4, 1/8 1/16 1/32 1/64

* toolbar: clone, duplicate, fx-box, fx-apply, monitor audio(pre-listen audio), new drawer, audio settings,

*tape-control (preferably black, 2:1 size, e.g. 32:16)
play, stop, pause, ffw, fbw, next, prev, stop&play, play-range, loop

* zoom: plus, minus, fit, zoom vertically (widthout magnifier glasses)

* listview: expanded node, collapsed node

* status images: midi, midi-in, midi-out, multi-purpose LEDs in various colors, also some very tiny ones

@Mason

Here is an improved version.

I am surprised how seemless you can mix icons and AISS images. The icons are much larger in their original size (46x46).

I improved the zoom quality (no false-shadows at the borders), and now most of the images look like as if painted at this resolution. Try to compare this with a usual scaling algorithm in your favourite GFX program, it will screw up.

The largest aqua bubble in the example uses 46x46 icons. The bubble sizes are automatically adjusted to the "en-bubbled" image.
The aqua bubble image itself is 64x64 bitmap and zoomed to the needed size. Doesn't need to be an aqua bubble though, any background/forground can be used.

The very small images (e.g. 14x14) could operate as listview images, while the medium ones (e.g. 24x24) can be toolbar images of large toolbars. If your toolbar has only a couple of buttons, the icons' size (e.g. 36x36) would be nice.

Only downscaling works well, of course. upscaling gets either blurry or blocky. One could think about another algorithm, like X2, but downscaling is usually easier since destroying information is easier than creating. That's why it would be cool to have the AISS images larger. downscaling can be always performed.

Maybe Mason could provide a test-image in 48x48 and 24x24, and we can compare the manual drawing 24x24 and zooming from the 48x48.

Ok, lets get visual...



I changed the API a bit, because caching gets quite difficult if the app programmer manipulated the bitmaps himself.

Now you can do


wheras style and state can be...



more styles will be added.
So the App programmer can the user select the style.
There is still the "lowlevel" interface to manipulate the images individually, but they can't be cached and it is much more work...

@joerg

Yes, I know. I'd love to run OS4.1, but I can't (we dont want to discuss the details in this thread, I guess). Still waiting for better days.
Till then, I am stuck with the greatest common divisor, and that's the OS3.1 API "pimped" up with a picture.datatype V43 and AHI.

Therefore, I have to implement things often twice, or find an elegant way that works everywhere. As GUI Toolkit, I implemented "TUI". It works on OS4 and MOS too, and it has Alpha transaprent buttons. E.g. HD-Rec uses that, as well as most other progs from me.

@joerg

Yes, OS4.1 might have scaling for icons, as well as AfA OS 4.2 does.
But what's the use of it if you are an app programmer?
Do you want to limit yourself to OS4.1?
I don't want to cause a flame war now, but I like my apps run everywhere. (it's a pain that I can't compile for x86 AROS). If OS4.1 would be the majority of people, and if I could run it on my machine, I would say ok. But for now the systems are too wide spread. That's why my library offers a bit mask as well, in case you are using 256 colors or AGA. You don't have fancy alpha effects then, but the program doesn't refuse to work, just looks a little less nice.
The code in my library is tested on OS4, MOS and OS3.x (RTG & AGA). I will probably use it to give Buttons to TuiTED, so everybody can enjoy it. That's the way to go, at least for me.

@joerg

I see. i didnt know that, since I don't use ReAction and MUI.
The initial idea I had was that you load the image with your favourite GUI Toolkit, but add an optional size, and the file will be created on the fly if it doesnt exist.
Also the look could be created on the fly, accoding to user-preferences (Background, Gow-Effect, Size, Shadow, Embross/Grey for ghosted etc.)

Like (peudo Code)

LoadBitmap(TBImages:cut24x24);

or

LoadIcon("MyIcon.info",24,16)

would load the icon in the specified (maximum-)size.
You, as the application developer dont care about it's actual size.
This is very handy for toolbars and everywhere you display Icons, when you want to force them to have uniform sizes.
But that would require some kind of Handler or Pipes thing.
So I decided to put it into a library. But if MUI and Reaction access the images by themselves, this only has a benefit if you need the resizing and/or effects.

Yes, an Amiblitz Library would do it for OS3.9 and a proove of concept. OS4 and MOs would have to re-write it if they want it native, but the 68k lib works there are well for a first try.
Cairo could surely be used for some speedup of the operations.
But the main point is not the image processing thing.
The main point should be to make easily nice GFX Buttons available for programs. (nevermind if they use GadTools, MUI, Reaction, Feeling or whatsoever)
E.g. you write a little gui for de-compressing or something. If you write everything from scratch, you spend hell more time on coding and debugging the button code than on anything else. Result is usually a GUI with text buttons. That should be different with this lib, when an image button gets nearly as easy as a text button. Or displaying some Icons or images, just for fun or more informative gui, e.g. place a nice, alpha-blended logo in the About requester.

The idea with this Library was not to "route" the AB3 functionality to the outer world. I don't think that somone would make use of such a library as an image-processing library, unless he codes in Amiblitz and then he doesn't need a library. If you code in C, you don't want to use a 68K Library for main things.

The idea is to complete AISS by having an interface to access the images. Not everybody is firm in laoding and blitting images with alpha channel.
There are a lot of glitches if you want to make it work 100% correctly on OS4, MOS and OS3.
The library provides scaling and caching, so that two programs won't load the same images 2 times. The images processing is just a gimmik for those who feel they want to manipulate the images. The most important here is to make the selected state easily identifiable, e.g. with a glow effect or a color change with tinting or background., and do the background/foregroudn composing for you like Mason suggested with the Aqua bubble.
It really should be something that deals with your GUI images. I think e.g. of a filemanager, that can display the icons scaled to the fontsize next to the filename etc., or has different views like the windoze explorer with different icon sizes.

I know that this is no real magic, but the library can do this for you in high quality and you dont have to fiddle around with datatypes, icons and scaling code.

I never programmed Reaction, so I dont know how to this and I dont know how to write boopsi classes. It will anyway not be accepted unless it is "native". So I think the most flexible is to provide the BitMap that can be used for further processing.

Sure it is OpenSource.
But I doubt that EVIL 68K library can get "standard".
So someone would need to do a C port.
It is not much Code in Amiblitz, just a bunch of lines. The power comes from the so called "Includes", which part of them would need to be ported to C.

@saimo

yes, renamed AISS => TB for now.

(toolbar.library)

I hope there is no toolbar.library out there yet...