I think everybody apreciates Masons artwork. What we are discussing here is on a technical level how to make the most use out of it.

From a programmers point of view, any effect that is pure post processing without manual interference should be left out. This are e.g. the guidelines for Android and iOS icons, so the OS can decide if a shine effect is added or not. On iOS, even the entire shape (the round corners) is procedural.

And the problem here is, does the manual pampered glow effect outweight the posibilities that arise if the Glow wasnt hardcoded/rendered.

EDIT: and my 2,5 cents about the example mason posted is, that I find it way more imperfect if the shadow is cast on top of the glow (ever seen a shadow on a flame?) that the arrow not having its own, adjusted glow.

I do have great respect for your artwork, and I know the claim for perfection as a part of me is an artist as well.

But let me put it this way:

Take 10 random people from the street and show them 1) vs. 2).
probably 8 will not notice any difference. One will notice a difference and will find them equally beautiful. And one, maybe, will like 1) better if you explain at what detail he has to look at.

I am not saying that 2) is better than 1). Of course is 1) better, but is this

a) worth the time
b) worth 2x memory requirements and loading time
c) worth to hardcode the glow effect and loosing the posibility to configure

BTW, I like the glow effect. But 99% of the time icons are displayed in the normal state. So glow yes, but does it need to be that highly optimized?

BTW2: If you like perfection, I noticed that your glow effect does not take into account that the Shadow ist actually behind the glow. Look at the bottom of the icon, you see the shadow darkening the glow. My implementation in Imageconverter takes this into account give me the PNG with alpha channel, and I can show you what I mean.
Also, it would be nice if the glow "overglows", means goes over 100% when close to the icon outline and gets from yellow to white. The OS3.9 icons do that, IIRC.
Another nice feature in my implementation is that the glow also affects the inside of the outline a little bit. That adds a lot more lifelyness and "heat" to the glow, similar to what the what the glow on the arrow does in 1).

The more I work on NTUI, the more I realize how important AISS is for the future of AmigaOS. Without AISS, Apps would look really poor.
I think this is more important than yet-another-bunch-of-icons.

BTW, have you tried to make the listview version by scaling?
I do this all the time in NTUI and it looks quite well.

Bonk!

Here is another suggestion for AISS:

If the Assign Script for "TBImages:" would assign the "Sys:Classes/ToolbarImages/Contrib/" folder FIRST, the user could easily override AISS images with custom ones.

Right now, it is the opposite, the "Default/" drawer is assigned first and has precedence. Means there is no way to transparently override default AISS images, if not replacing the original ones.

If Mason is reading this, I would like to point out some images that have not worked well for me, including the explanation why, so you could consider improving them.

There also a few missing for my upcoming AIDE app.

All in all I must say, AISS is quite a good collection of icons. I made some experiments, overriding AISS images with different icon sets, e.g. OpenIcons, but they all look either only good in high resolutions and screw up in 24x24, or just look old, boring, unrecognizable and inconsistent.

Conclusion: good job, Mason. AISS is awesome!

Right, if the software should be AOS4 only, the picture.datatype might have a consistent behaviour.

I haven't looked at the sub forum, my bad.

Still, the issue remains that it saves IFF-ILBM by default, and most DT implementations dont bring a saver with them.

If it works for your setup, it doesnt mean it works on others setups. E.g. on OS3.x it wont save 24bit bitmaps. Under AfAOS (and AROS) it is (at least was some time ago) completely broken and crashes. There are also various pictrue.datatype implementations/updates/sidegrades etc. out there with different behaviour. So if you want to relase your program to the public, avoid datatypes for saving.

If you code in C, there are many PNG and jpeg libs out there, I would use them.
You can not save the bitmap structure as-is, in most cases you will need to create PixelArray out of the bitmap that has a well-defined pixel format, such as PFMT_ARGB, depending on what the lib needs. You typically need a RastPort on the bitmap and then call ReadPixelArray().

Forget Datatypes. They work only for loading. Saving is broken on most systems, and will result in crash, broken IFF file or sonmething else unpredicatable.
Believe me, I have tried this. Even if saving works (it works with *some* datatype), it will be only IFF, and often only color index. Still, you functionality is heavily dependent on what the user has installed, and you cannot verify it for correctness.

So again, dont even try to mess with datatypes.

If you want to save jpeg, use the jpeg.library. This is relatively easy, reliable and fast, and you can make your programm complain about it if not installed.

If you use Amiblitz3, you have savers for IFF, PNG, JPEG and BMP build in. You could also write your own BMP saver, which is rather trivial, and then call an external image converting tool to produce the desired format.

The result from graphics looks realistic. QT seems very slow.
Do both render their text "blocky", mean with a solid background color? That affects the speed a lot, if the text is rendered transparently.
Also, the font of course has an impact.

Yes, as I wrote I have the same trouble under WinUAE. That made me wondering if I made a mistake when implementing ChangeScreenBuffer. But ChangeCPBitmap behaves exaclty the same, and this is entirly different code.

And if I use e.g. BlitBitmap Methode, it runs at 500FPS, and when I set the timer to WaitTOF() or WaitBOVP(), it also slows down to 30Hz. (which is half the monitor).
That implies that the bug is in WaitTOF()/WaitBOVP(), which is probably used by the self-timed double buffering functions.

But I am pretty sure, that I had a WinUAE configuration once, that did 60Hz. But I cannot reproduce it right now.

If you are interessted, I can give you the code of the demos for download. Actually the code is in the Amiblitz3 distribution, but the timing demos "main" is not.

EDIT: you seem to be quite knowledgable with Picasso96 internals. Did you develop drivers or somethingß

It is this one:

http://aminet.net/package/util/libs/zlib-library

But I can compile a version without zlib, if this makes problems.

Here we go:

http://www.hd-rec.de/Archive/dbl_test3.lha

It contains several binaries using several double buffering methods.
In addition to that, you can select the syncing method when the demo is running.
For ChangeScreenBuffer and ChangeVPBitmap, always use no sync, since they do their own syncing.

Strangely enough, I get only half the Monitor Refresh rate when using the those two dbl Methodes, as well when I use WaitTOF() or WaitBOVP() for syncing. Must be something wrong in WinUAE?
I am pretty sure, when I tried this yesterday, I got the correct rate... hm...

Yes, this is correct. ChangeScreenBuffer and ChangeVPBitmap are both synced to the Monitors refresh rate and therefore the FPS is clamped. The actual speed has to be messured by adding more and more objects till the FPS starts to break down.

However, at least under my WinUAE, it is not the real refresh rate, it is some pseudo timer that is close, but not exact the Monitor Refresh. So scrolling is not smooth, it shows some tearing.

I will prepare a demo showing all variants of double buffering. I am quite interested how that works on NG Amigas.

I have mesured it by observing the frames-per-second with various amounts of object moving on the screen.

I dont know exact numbers anymore, but the numbers were something like this: (using smart object refreshing, not full screen refresh, means I did not restore the background with a full screen blitbitmap, I restored only regions that have been damaged, which is very fast if there are only few and small objects)

0 Objects:
1. single buffering ~ >> 100000 FPS (hard to messure)
2. blitbitmap ~ 500 FPS
3. ChangeScreenBuffer ~ 490 FPS

100 Objects:
1. single buffering ~ 50 FPS
2. blitbitmap ~ 40 FPS
3. ChangeScreenBuffer ~ 40 FPS

The conculsion is, that single buffering has almost no overhead (obviously), while blitbitmap and ChangescreenBuffer have suspiciously similar overhead. If ChangeScreenBuffer would just change the pointer, one would asume an overhead close to single buffering, not close to a full-screen bitmap swap.

And as you see, I have not only tried ChangeScreenBuffer(), also the lower-leveled ChangeVPBitmap() and ScrollVP(), all have performance in a very similar range. I was even desperate enough to try an auto-scroll oversized screen with double height and scrolled it, but that was ridicously slow.

If this is interesting topic for anyone, I could provide a demo with all those methods and you can run this on your Amiga to see the performance. But I have done this before, I doubt you will generate different results.

This is my conclusion after extensive speed tests.

I have tried



..and sadly enough, BlitBmapRastPort with an off-screen bitmap is the fastest (apart from single buffering of course), but all are in comparable ranges.
That lead me to the conclusion that P96 actually doesn't change pointers, but does a full-screen blit too. It might not be P96 directly, but at least the driver does it that way. I have tested WinUAE, Amithlon and Cyberision 64 3D on a Classic.
That doesnt mean that there is still a huge difference for OCS/AGA. But all RTG Systems I have tried are not faster than blitting the Bitmap, and even more sadly, they dont do vblank sync anyway.

1 .Broadblues is right.

No, there is no such thing like double buffering for windows. And you also dont want to flip the bitmaps, that makes only sence if the bitmap pointers are exchanged synched with the vblank, like on OCS/AGA possible.

Nowadays, you still have 2 bitmaps, but one is for rendering, and once done, you blit it to the window. That kind of double buffering, but better called "off-screen" bitmap or "off-screen" rendering. The blit to the window should be fast. After some tests I came to the conclusion that P96 also does the same thing with screen bitmaps, even if you "think" you would swap the bitmaps, it actually copies the bitmaps.

So what you do is allocateing a friend bitmap, create a rastport and layer on it (CreateUpFrontLayer) and draw there, once done, blit it to the windows rastport.
Doing it that way, the window doesnt even need its own bitmap, it can be simple refresh, that saves you some memory.

2. You dont need hooks for that. You can get app events though a MessagePort.

3. I remember lots of trouble with Flood. I would write my own drawing routines. If you know the shape of the area you want to fill, you can do it faster with lines anyway.

No plans explicitly for PPC.

There are no plans with this Voxel Engine whatsoever.

If someone is seriously interessted, I can provide the code, but better thant that, I can advice how to write this.
The code itself is not very helpful, without understanding what is going on.

It is not using any polygons or OpenGL. This is software rendered. I think it can be done on NG Amigas or WinUAE in acceptable speed at good quality.

The reflections are traced with the landscape upside-down, and are mixed with the blue-water-tinted ground of the water.

Such things usually consist of a heightmap (a grayscale image where the brightness corrsponds to the height in the terrain) and a texture on top. The shadows are precomputed based on the heightmap and the sun position.



Put a skye dome at the horizont and some fogging, your done.
The technique is often referred as Raycasting, or 2.5D. This is the very same technique used in many voxel scene demo or in the Doom game serie. Probaly NemacIV as well.

Each vertical line on the screen is a trace through the terrain, starting from the cameras 2D coordinates.

Using Z-Buffering, it is easily possible to place 2D sprites in the terrain (like the game sprite someone spotted in some pics above).

The technique pretty simple and nothing groundbreaking, every skilled programmer can do that in a week or so. The nice look comes from the nice artwork.

I use perlin noise to generate the "fractals".
The "man-made" stuff in painted in ArtEffect.

For the perlin noise, I have written a tool called "PerlinFX". You can generate heightmaps as well as textures.
http://www.hd-rec.de/HD-Rec/index.php?site=contributions

Examples:

Wow, I didnt expect such a positive feedback. However, I dont want to hijack this thread, sorry for that.

It's a pseudo-Voxel engine using a heightmap and a 2D texture written in Amiblitz3.
For real Amiga HW, the implementation is too slow. Even on WinUAE, I get only 5-10 FPS in good quality. Such an Engine could be implemented more efficient, but this was my first 3D experiment. It some years old now and I dont have any plans for that (lack of time).

It doesnt have to be pure fractals, upon the fractals you can draw "man-made" elements.

Yeah, me too.