@Hypex

Just stay with Hyperion OS4 then. Some people will stay with Hyperion OS4, some other people will switch to System54 So what?
Stay on the system you like and dont get angry about the other systems.

@Hypex

Quote:

Hypex wrote: @V8 Quote: And who is going to port "the browser" to OS4 when it has switched to x86_64? Whoever is porting the browser now. But, it would be a lot easier. It's harder now, because porting a browser requires to port a browser coded for little endian to big endian. When the endian issues are taken away it's easier to port across.

Nonsense.
Writing endian-neutral code is trivial. You just have to be aware of what endianess means.
Same is for writing code for platforms where the size of an int differs between say 32 and 64 bits.

One codebase I maintain as a hobby is deployed to ~300-500m installs, across systems with different endianess and int-sizes. Even saving/loading datafiles between then are no problem.
For professional paid work I mostly work on code that has been shipped to >1b installs. Even there endianess is not really a problem at all. It just works, you just code for it and it just works. Really.

Maybe all the "endianess problems" are rather excuses on why no one is doing the work rathr than actual technical problems?

Last edited by V8 on 13-May-2022 at 12:51 PM.
Last edited by V8 on 13-May-2022 at 12:50 PM.
Last edited by V8 on 13-May-2022 at 12:39 PM.
Last edited by V8 on 13-May-2022 at 12:38 PM.

Endianness only becomes an issue when you are dealing with a fixed layout (e.g. network packets or a fixed format binary file) that may or may not differ from your target, or you are knowingly doing something that depends on it, e.g. messing around with unions of different word sizes, accessing the same memory range with different pointer types etc, e.g. the sort of thing you might do when writing an emulator, for instance.

For everything else, it's irrelevant.

_________________
Doing stupid things for fun...

@paolone

Quote:

Dozens of AROS developers took 20 years to reach a good reimplementation of OS 3.1 plus the necessary modernizations here and there, while Apollo team took much lesser time to strip its M68K flavour to let it properly target classic hardware.

Right on. Not only that but coding a portable version that's endian agnostic. Supporting multiple CPUs and dealing ABI's as well as bootloader to partition format. And this is just OS3.1 which these days would be considered a simple OS. The result being source compatible with Amiga code with few changes. Guess AROS is kinda like a ColdFire OS that way, source compatible with Amiga code.

But with the 54 thing, not only is all this needed, but doing it to an OS4.1 FE Update 2 level. Now, they are targetting the same CPU, so they don't need to worry about technical dfferences in user code. But that will still be a heap of work.

Quote:

The question is why, WHY, and again W-H-Y some one else should DO IT AGAIN AND AGAIN, just in order to keep it closed into a commercial version that will NEVER EVER recoup the time and the money needed to do a proper job. AmigaOS 4 isn't even able to pay its developers, let alone the 3.2 version that's been brought to light with volounteer efforts.

That's exactly what I've been asking. I've been asking it for so long that I've gone from asking why they are doing an AROS 4 to joking that they are creating another MorphOS. Suppose it could be MorphOS 54 or AROS 54. LOL.

I should shut up. After all, I've bought two AmigaOne models in their lifetimes. What a strange thing to do.

Quote:

Classic retrogaming market barely lets getting some money from new games, while the so-called NG market is far smaller and just too much vertical to keep itself alive. So why are these little companies still beating the damn dead horse sooo sickly? To be able to sell another half working pricey and shamefully underpowered PPC machine in... 10 years? really?

Classic Amiga is where the heart and soul of Amiga remains. OS4 was good at the start as it was new and exciting as a platofrm of its own. But that tapered off and now it's gone stale. Not helped by declining hardware market and state of OS affairs. Of top of internal politics they don't hide very well from an end user product.

I mean, there are even Power 9 users, that are blogging about another AmigaOne you don't want. (X5000.) Putting that into perspective, someone bought a mini POWER 9 server, instead of a Ryzen (or Intel 11+) which would still more likely be faster and cheaper and not make you look weird in front of your developer mates; and they are hanging crap on the X5000!

Ha?!

but

A POWER9 is the only "modern" system that can finally kill off the G5 lett behind. And leaves a "modern" quad X5000 system in its wake. And unlike the PPC laptop you could buy it. But when a POWER user picks on a new PPC AmigaOne they need to stand up and notice or Skate and Die!

Quote:

Sorry to say that, but if you're looking for the people who killed the Amiga, well, they are exactly the ones who are struggling to 'keep it alive'. Let it go like sane dead companies did (amstrad, sinclair, commodore for the 8 bit machines...) and maybe it could flourish again as a retrogaming platform. If AmigaOS sources were published and GPLed 20 years ago, maybe today we'd already have had a modern reimplementation running anywhere.

You know, this reminds me of a question I was going to ask years ago but didn't. That is, has OS4 ruined the legend of Amiga? And that is going back years ago. When things were just going wrong with it. For OS4, I would say yes, but for the Amiga itself, I would say no as it stands on its own and even less people in the world would even know what an OS4 is.

@V8
Well said V8. There is a very good choice. The world isn't going to end when V54 comes on the market.

As to the big question this thread poses I have two answers. The short answer is no.The reason is that more computing power will not bring you a better web browser. You need to fix the graphics system first before you can make use of better processors.

The long answer is a bit more complex. I was hoping that the Morphos Team and A-EON would share common hardware. There is a lot of interaction between the Morphos team and A-EON. Deadwood for example developed his version ofSMP on a X5000 computer. He also did quite a bit of work onU-boot on the X5000. These are but two examples of the cooperation between the two groups. There are many others.

What will happen in the end remains to be seen. The first order for business though, for A-EON is V54.

@paolone

Quote:

paolone wrote: @cdimauro Quote: Right. But it should have been made much better: there were a lot of bad design decisions for the Amiga chipset, which crippled it. Right: cost/benefit and technology/era wise, they proved to be the best decisions Miner & co. COULD take.

I don't agree. Miner himself said that instead of bitplanes he could have implemented packed/chunky as graphical format.

In fact, choosing the bitplanes was the worst design decision ever. The Blitter implementation was easier, but it complicated the rest (and required more resources, including more registers in the chipset).

AGA further and clearly shown how so bad was the decision to use the bitplanes.
Quote:

Problem is: time lasts and situations CHANGE.

It took 3 years to finalize the project and sell it...
Quote:

When situations change, cost/benefit ratio changes as well, and peole should understand why, change attitude, and stop fighting change.

It should be.

@Hammer

Quote:

In the real world, the bulk of the 3D raytraced render workload has been shifted on bounding volume hierarchy (BVH) hardware capable raster GPUs e.g. free Blender 3D, Autodesk Maya, and Arnold.

It was likely pushed by the gaming market. So makes sense for a 3d renderer to use 3d hardware. Especially hardware designed for live use which would allow a renderer to increase quality without the burden of time constraints.

The Amiga must have had hardware 3d the past 20 years but I recall any software that used it. Lightwave and Imagine dropped the ball before they became available. I'm not aware of any PPC optimised 3d renderers using Warp3d in the later years when the PPC was promoted as being ideal for it.

Quote:

I prefer GPU accelerated web browser experience, and many users weren't happy when AMD released unstable 2017-era and early 2018 GPU drivers for 1st gen mobile Ryzen APUs that resulted in BSOD with Google Chrome and Microsoft Edge Chromium.

That's how it should be. The OS uses the GPU. So it makes sense a browser would too.

Quote:

Pure CPU focus wasn't the original Amiga's idealogy.

No but it lost it somehow. 3d renderers were CPU only in the Amigas time. And later on 3d games were purely CPU focused like Doom which made poor games that didn't use the hardware.

@cdimauro

Quote:

Then what about building the compilers themselves: is it possible to do it on an OS4 machine? I mean, building GCC (LLMV is completely out of scope, of course), for example.

I don't think so. GCC is included in the SDK but no way could it be built on OS4. It would need configure scripts and they don't work. There is no working POSIX shells.

Other ones like VBCC should build on OS4. But I don't know know if it does. I don't know about others.

Quote:

It's hard for whom? Because MorphOS has a modern browser which is constantly updated, and that it was created / maintained by a SINGLE PERSON.

For whomever is updating it. It looks like MorphOS has better support for depends than OS4. Because since Odyssey the MOS version is always first, the best, and then has to be backported to OS4 which is lacking somehow.

Quote:

Well, this PoC was PAYED! So, are you telling that people that financed it were cheated?

No, as that depends on what they signed up too. And if the description and fine print matched the end result . I think a lot of people that financed it would have felt cheated because there was no full end user product. There was a demo that needed so much work that by the time it came out it was obsolete. The brothers always maintained they fulfilled their end of the bargain and got it working, with the source being there and it was up to Amiga developers to maintain it from now on. However, a lot of people expected a fully working port before they walked away, so they felt cheated. If the purpose was a fully working version, and not a buggy beta, then they were cheated. But the bounty was closed, so it was considered complete, and I don't know what the purpose was.

Quote:

What do you expect? It's normal in the OS4 land.

Is it but it looks sloppy. CLI windows opening on Workbench. That's sloppy. However AmigaOS seems to be the only OS where custom or foreign GUI ports look fake. On Windows and Linux a non native GUI looks and works like a normal UI. On OS4 it's fake.

Quote:

You're already used to interfaces instead of the single interface which Amiga introduced and founded everything on top. You're used to the shared objects from Linux & co, which are completely alien to the Amiga o.s.. And you're used to bank switching to access more than 2GB or memory, like old 8-bit computers and even worse than 8086 segmented memory!

All the Amiga interfaces build on top of Intuition but after gadtools it became a mess with no OS standard used consistently. Shared objects on OS4 aren't shared and should work like a shared library which isn't so alien. Currently I don't actively use any apps using ExtMem but at that point AmigaOS is backwards running on CPU that is more forwards.

Quote:

You're already using an alien o.s. compared to the one which we were used at the Amiga time...

Still, it's still similar in operation, and unfortunately very similar in some operations.

@V8

Quote:

Just stay with Hyperion OS4 then. Some people will stay with Hyperion OS4, some other people will switch to System54 So what? Stay on the system you like and dont get angry about the other systems.

Oh I'm not angry. My OS4 works as it should. If and when replacement components work the same without any bugs and I don't need to pay for them I'll consider updating.

Quote:

Nonsense. Writing endian-neutral code is trivial. You just have to be aware of what endianess means. Same is for writing code for platforms where the size of an int differs between say 32 and 64 bits.

That's irrelevant when they don't do it. There is examples of open source code written to assume a specific CPU endian which messes up code and not be portable. What's nonsense is to expect endian-neutral code to be written just because it can be done. In the outside world they won't care.

Case in point: ppc64el. Later releases of PPC Linux are little endian as it solves a lot of endian problems by working around it and running the CPU in the same endian as the software was written for.

Firefox used to be stable on my A1/XE. But in Jessie I can't trust it. ESR included is slow and even a Google will crash it. I don't know but I suspect it's an endian problem.

Quote:

One codebase I maintain as a hobby is deployed to ~300-500m installs, across systems with different endianess and int-sizes. Even saving/loading datafiles between then are no problem. For professional paid work I mostly work on code that has been shipped to >1b installs. Even there endianess is not really a problem at all. It just works, you just code for it and it just works. Really.

That's you and you are obviously aware of it and code accordingly. But other people don't care or are sloppy coders. Do you maintain any browser ports?

Quote:

Maybe all the "endianess problems" are rather excuses on why no one is doing the work rathr than actual technical problems?

I've read it a lot. It tends to be specific to the JS interpreter in how it stores data in tables. But the only other technical problem is OS4 itself which hard to compile for.

@Hypex

Quote:

Hypex wrote: @cdimauro Quote: Then what about building the compilers themselves: is it possible to do it on an OS4 machine? I mean, building GCC (LLMV is completely out of scope, of course), for example. I don't think so. GCC is included in the SDK but no way could it be built on OS4. It would need configure scripts and they don't work. There is no working POSIX shells.

OK, but you said this:

"If I need a PC to compile OS4 programs, then at that point, using OS4 become completely pointless to me."

and it means that OS4 became pointless. Why do you still use it?
Quote:

Other ones like VBCC should build on OS4. But I don't know know if it does. I don't know about others.

VBCC is super simple and lightweight, so it should be possible to compile it even on an Amiga (with memory expansion).

However it's a C compiler: not a C++ one.
Quote:

Quote: It's hard for whom? Because MorphOS has a modern browser which is constantly updated, and that it was created / maintained by a SINGLE PERSON. For whomever is updating it. It looks like MorphOS has better support for depends than OS4. Because since Odyssey the MOS version is always first, the best, and then has to be backported to OS4 which is lacking somehow.

Is OS4 which requires more effort, or it's about OS4 developers which aren't as much skilled as MorphOS ones?
Quote:

Quote: Well, this PoC was PAYED! So, are you telling that people that financed it were cheated? No, as that depends on what they signed up too. And if the description and fine print matched the end result . I think a lot of people that financed it would have felt cheated because there was no full end user product. There was a demo that needed so much work that by the time it came out it was obsolete. The brothers always maintained they fulfilled their end of the bargain and got it working, with the source being there and it was up to Amiga developers to maintain it from now on. However, a lot of people expected a fully working port before they walked away, so they felt cheated. If the purpose was a fully working version, and not a buggy beta, then they were cheated. But the bounty was closed, so it was considered complete, and I don't know what the purpose was.

It should be simple to know it, and it should be enough to answer to this question: was the Firefox OS4 port a PoC or not (so: a regular application)?
Quote:

Quote: What do you expect? It's normal in the OS4 land. Is it but it looks sloppy. CLI windows opening on Workbench. That's sloppy. However AmigaOS seems to be the only OS where custom or foreign GUI ports look fake. On Windows and Linux a non native GUI looks and works like a normal UI. On OS4 it's fake.

This happens to Windows as well. It depends on the UI toolkit used by applications.
Quote:

Quote: You're already used to interfaces instead of the single interface which Amiga introduced and founded everything on top. You're used to the shared objects from Linux & co, which are completely alien to the Amiga o.s.. And you're used to bank switching to access more than 2GB or memory, like old 8-bit computers and even worse than 8086 segmented memory! All the Amiga interfaces build on top of Intuition but after gadtools it became a mess with no OS standard used consistently.

The lack o.s. standards doesn't justify the introduction of a completely alien technologies: interfaces were NEVER been part of o.s. in its entire life (I mean: Amiga life).
Quote:

Shared objects on OS4 aren't shared and should work like a shared library which isn't so alien.

Yes, they don't share anything: a (new) copy is loaded for each application which uses them...

It's totally alien both the Linux shared objects and specifically to the Amiga libraries.
Quote:

Currently I don't actively use any apps using ExtMem but at that point AmigaOS is backwards running on CPU that is more forwards.

Sure, but the point is that OS4 introduced this horrible technology which has NOTHING to do with our beloved Amigas.

We were used to make jokes against the PC and 8086 processors (and o.ses) because of the segmentation, and OS4 ended up to implement something which is even worse...
Quote:

Quote: You're already using an alien o.s. compared to the one which we were used at the Amiga time... Still, it's still similar in operation, and unfortunately very similar in some operations.

But if the criterion is to just have something similar to the original Amiga o.s., then Linux with a GUI similar to that should be good enough, right?

@cdimauro

Quote:

I don't agree. Miner himself said that instead of bitplanes he could have implemented packed/chunky as graphical format.

I've read this before. It seems unthinkable as bitplanes are entrenched in the Amiga as much as 68K and big endian. Tied to the hardware.

Though I think if it were packed the bandwidh would have limited it to 1,2 and 4 bits. So hi res no change. But low res would lack 32 and EHB 64 colour modes. Unless it was byte aligned which would have wasted space. If 8 bits would have been possible then it made sense.

OTOH the audio was packed/chunky.

Quote:

In fact, choosing the bitplanes was the worst design decision ever. The Blitter implementation was easier, but it complicated the rest (and required more resources, including more registers in the chipset).

The design was said to be optimised for 2d with layers. A lot of Amiga tricks like splitting playfields would only be possible with bitplanes.

But I think there should have been a hybrid design with a variable pixel width. At 1 bit packed and planar is exactly the same. So for packed they could have used a 1 bitplane but increased pixel width. After research I believe this is the correct way of interpreting it. A chunky bytemap is still a plane but the plane extends across as it has it is only one depth.

Quote:

AGA further and clearly shown how so bad was the decision to use the bitplanes.

AGA took it to the max. And the real max for bitplanes is only 8. Trying to take it beyond like all the Commodore ideas of 16 bit planar are ridiculous. Made worse by 24 bit planar IFF formats that made no sense!

I can see sense in hybrids like three planes of 8 bit packed for RGB based on hardware constraints. But not going beyond 8 bit as planar is only suited to CLUT. Even the HP printers can use packed, planar or hybrid in the form of planar major or pixel major.

What I think should have been done in AGA at the latest was to use the EGA write methods. EGA was around in 1984 so surely they would have known about it. And that is, since EGA also used a planar format, it had a feature where a value could be written to multiple planes at once. It seems almost a short sight after finding this out. They chose planar as the bitmap format but provided no means of hardware acceleration for writing pixels.

Last edited by Hypex on 14-May-2022 at 01:31 PM.

@Hypex

Quote:

Hypex wrote: @cdimauro Quote: I don't agree. Miner himself said that instead of bitplanes he could have implemented packed/chunky as graphical format. I've read this before. It seems unthinkable as bitplanes are entrenched in the Amiga as much as 68K and big endian. Tied to the hardware.

It's unthinkable because you were used to the bitplanes, and cannot think of anything else for the Amiga.

However packed/chunky could have been exactly the same thing it they were chosen instead of bitplanes.
Quote:

Though I think if it were packed the bandwidh would have limited it to 1,2 and 4 bits. So hi res no change. But low res would lack 32 and EHB 64 colour modes. Unless it was byte aligned which would have wasted space. If 8 bits would have been possible then it made sense.

No, you can use ANY pixel size with packed/chunky: 1, 2, 3, 4, 5, 6, 7, 8.

And you don't need to waste space with byte alignment: just pack (!) them all together. Only raster lines needed to be 16-bit aligned, EVENTUALLY.
Quote:

OTOH the audio was packed/chunky.

Well, here it's a requirement: you cannot think about audio using bitplaces.
Quote:

Quote: In fact, choosing the bitplanes was the worst design decision ever. The Blitter implementation was easier, but it complicated the rest (and required more resources, including more registers in the chipset). The design was said to be optimised for 2d with layers.

You can do EXACTLY the same with packed graphic.
Quote:

A lot of Amiga tricks like splitting playfields would only be possible with bitplanes.

No, on the contrary it's possible to have playfields (even more than 2) much easily and much more efficiently with packed graphics.

You had 6 pointers with the Amiga only because of the bitplanes, but with packed graphics you could have used just one pointer per single playfield. So, two playfields needed? Use two pointers. And with a MUCH better flexibility: you could have decided how many bits to be used per playfield.
Quote:

But I think there should have been a hybrid design with a variable pixel width.

Not hybrid: see above. This is natural using packed graphics. Much more natural compared to bitplanes, where you were forced to have similar pixel widths for both playfields.
Quote:

At 1 bit packed and planar is exactly the same. So for packed they could have used a 1 bitplane but increased pixel width. After research I believe this is the correct way of interpreting it. A chunky bytemap is still a plane but the plane extends across as it has it is only one depth.

Correct.
Quote:

Quote: AGA further and clearly shown how so bad was the decision to use the bitplanes. AGA took it to the max. And the real max for bitplanes is only 8. Trying to take it beyond like all the Commodore ideas of 16 bit planar are ridiculous. Made worse by 24 bit planar IFF formats that made no sense!

No, I wasn't referring to the 8 bitplanes made available with AGA. Rather, to the fetch bandwidth: 64-bit (and 32-bit) compared to the 16-bit of OCS/ECS.

This was a HUGE waste of bandwidth... and space... and sprites!!!
Quote:

I can see sense in hybrids like three planes of 8 bit packed for RGP based on hardware constraints. But not going beyond 8 bit as planar is only suited to CLUT. Even the HP printers can use packed, planar or hybrid in the form of planar major or pixel major.

CLUT made sense only up to 8 bits.
Quote:

What I think should have been done in AGA at the latest was to use the EGA write methods. EGA was around in 1984 so surely they would have known about it. And that is, since EGA also used a planar format, it had a feature where a value could be written to multiple planes at once. It seems almost a short sight after finding this out. They chose planar as the bitmap format but provided no means of hardware acceleration for writing pixels.

No, this mechanism from EGA was good for this card only because of how EGA works.

But it's not suitable for a packed Amiga hardware.

@Hypex

Jay Miner is on record as saying that planar pixels were a mistake in hindsight*. The designs for Hombre did not include any planar bitmap support, at one point there was some discussion around including some AGA support.

*It may be this speech that I saw him say it, but I've not watched it fully so it may not be: https://youtu.be/daQNJMZblZ8

_________________
Doing stupid things for fun...

@cdimauro

Quote:

I don't agree. Miner himself said that instead of bitplanes he could have implemented packed/chunky as graphical format. In fact, choosing the bitplanes was the worst design decision ever. The Blitter implementation was easier, but it complicated the rest (and required more resources, including more registers in the chipset). AGA further and clearly shown how so bad was the decision to use the bitplanes

You're basically confirming exactly what I wrote: Miner took the bnest decision he COULD take at the time: when having a fast andf flexible blitter was a thing. Amiga got a fair good reputation in the gaming community for its 2D graphics, and it beated everything which was around at its time.

THEN, AGA showed how bad this decision was in realiy. But AGA was born when chunky graphics were used by other platforms to do fake 3D things, actually obliterating Amiga among gamers. And other 68K based hardware like the SEGA MegaDrive had better games than Amiga had.

But, youi know, Miner went planar in 1984. SEGA Megadrive was released many years after.

@paolone

Quote:

paolone wrote: THEN, AGA showed how bad this decision was in realiy.

Nope.

AGA proved that no HW improvements and no useable API did lead to everyone hitting the HW for games and that the Amiga really should have been a 1 generation system (HW wise).

Or in other words, something like MorphOS/AROS should have been ready by 1990 running either on of the shelves GFX-HW or something very similar designed in house.


Bitplanes were 100% o.k. for what the Amiga was designed to be and to do in 83-85.

_________________
- We don't need good ideas, we haven't run out on bad ones yet
- blame Canada

@paolone

Quote:

THEN, AGA showed how bad this decision was in realiy. But AGA was born when chunky graphics were used by other platforms to do fake 3D things, actually obliterating Amiga among gamers. And other 68K based hardware like the SEGA MegaDrive had better games than Amiga had.

The problem with AGA was that in some ways it was like the NG C128 trying to be a C64. They took a 16-bit based chipset and extended it to 32 bits. Where the chipset used 4 bits they bank switched it. Of course they needed it to be compatible. But AGA was held back by not being a fresh design and it also made it complicated. And this is before looking a audio, floppy and slow CIAs.

But also, I think the biplanes were a great idea not taken to full potential. I mean, in their basic configuration, you've got bitmap layers all super imposed on each other. 1 bit they may be. This configuration could have been extended to max it out. Imagine 8 planes of 8 bit packed pixels. 2d drawing would have had hardware acceleration. And 2d games would have been over the top!

By AGA the Amiga sprites and setup was too complicated and couldn't do what consoles did. It had no tilemap modes and not enough sprites. And only two layers of 4 bpp deep didn't exactly cut it. I don't know what exact bitmap or not formats consoles had as the info is too simple. Even if I avoid Wikpedia entries that aren't technical enough what I do find still seems to lack this info which I would consider basic info myself. Maybe the world itself is too simple. The music player on my phone doesn't even have a clock counter or FF/REV buttons. How dumbed down is that!

@paolone

Quote:

paolone wrote: @cdimauro Quote: I don't agree. Miner himself said that instead of bitplanes he could have implemented packed/chunky as graphical format. In fact, choosing the bitplanes was the worst design decision ever. The Blitter implementation was easier, but it complicated the rest (and required more resources, including more registers in the chipset). AGA further and clearly shown how so bad was the decision to use the bitplanes You're basically confirming exactly what I wrote: Miner took the bnest decision he COULD take at the time: when having a fast andf flexible blitter was a thing.

As I've already said, it was NOT the best decision at the time. In fact, Miner lately said that he wanted to use packed graphic: why this statement if bitplanes were the best decision? It doesn't make sense. This sentence only makes sense if bitplanes were NOT the best decision.

In fact, the Blitter was NOT fast and flexible. It was only simple to design (at the hardware level). Which does NOT mean that it was good / better.
Quote:

Amiga got a fair good reputation in the gaming community for its 2D graphics, and it beated everything which was around at its time.

The fact that Amiga had a good reputation at the time does NOT mean that using bitplanes was the best decision. Paolone, this is a logical fallacy: the first is NOT a consequence of the second.

The main problem is that you clearly do NOT know how the Amiga hardware worked neither how to program it to make videogames (and possibly to squeeze the most from the hardware).

At the time you were only taking videogames and reviewing them. I, on the exact contrary, was writing videogame: so I know what I'm talking about. Fightin' Spirits was released (and maybe you know it), and I was the coder which has written its graphic engine. Unfortunately USA Racing wasn't released, but technically he could have shown its strengths as well.

Anyway, I don't want to fall to another logical fallacy (the argument from authority); I and other colleagues are close to reopen a technlogical blog (Appunti Digitali). Once we start I'll write two articles: one which (mathematically) proves that packed/chunky graphics is almost always better than bitplanes, and another one which shows how bitplanes are used on the Amiga and how they crippled the platform due to this decision (instead of having packed graphics) while also making the life much worse to coders.
Quote:

THEN, AGA showed how bad this decision was in realiy.

See above it: the situation was already very bad. AGA "just" exacerbated it.
Quote:

But AGA was born when chunky graphics were used by other platforms to do fake 3D things, actually obliterating Amiga among gamers. And other 68K based hardware like the SEGA MegaDrive had better games than Amiga had. But, youi know, Miner went planar in 1984. SEGA Megadrive was released many years after.

It doesn't change the picture: packed/chunky graphics was much better than bitplanes even for 2D games.

Just using packed graphics could have improved A LOT the Amiga video games, both 2D and 3D (you know how 3D videogames where made for the Amiga? Using the Blitter to draw lines and filling polygons, ONE bitplane at the time: 16 colors on screen -> the Blitter has to draw lines and fill polygons FOUR times).

@Hypex

Quote:

Hypex wrote: @paolone Quote: THEN, AGA showed how bad this decision was in realiy. But AGA was born when chunky graphics were used by other platforms to do fake 3D things, actually obliterating Amiga among gamers. And other 68K based hardware like the SEGA MegaDrive had better games than Amiga had. The problem with AGA was that in some ways it was like the NG C128 trying to be a C64. They took a 16-bit based chipset and extended it to 32 bits.

Not even that: the chipset remained mostly 16-bit. Only the display engine (playfields and sprites) was updated to 64-bit. Everything else, Blitter included, was left exactly as it is (16-bit).
Quote:

But also, I think the biplanes were a great idea not taken to full potential. I mean, in their basic configuration, you've got bitmap layers all super imposed on each other. 1 bit they may be.

See above (my previous reply to you): it was NOT a great idea. Rather, it was the WORSE idea.
Quote:

This configuration could have been extended to max it out. Imagine 8 planes of 8 bit packed pixels. 2d drawing would have had hardware acceleration. And 2d games would have been over the top!

Here you're already talking of packed graphics, and not bitplanes anymore. Bitplanes != pointers. Bitplanes needed pointers, but a pointer can point to a bitplane area or a packed area.
Quote:

By AGA the Amiga sprites and setup was too complicated and couldn't do what consoles did. It had no tilemap modes and not enough sprites. And only two layers of 4 bpp deep didn't exactly cut it.

Tilemap was too much different from the Amiga graphic engine, so you it was difficult to introduce it at the time (and would have required a completely different coding).
Quote:

I don't know what exact bitmap or not formats consoles had as the info is too simple. Even if I avoid Wikpedia entries that aren't technical enough what I do find still seems to lack this info which I would consider basic info myself. Maybe the world itself is too simple.

Some consoles used packed, some other bitplanes. Anyway, bitplanes was the worse format even on consoles, but using sprites and tiles have reduced the impact of using bitplanes.

@Karlos

Quote:

Karlos wrote: @Hypex Jay Miner is on record as saying that planar pixels were a mistake in hindsight*. The designs for Hombre did not include any planar bitmap support, at one point there was some discussion around including some AGA support. *It may be this speech that I saw him say it, but I've not watched it fully so it may not be: https://youtu.be/daQNJMZblZ8

I finally had time to watch it.

Yes, it says (@19:41: https://www.youtube.com/watch?v=daQNJMZblZ8&t=1181s ) that he would have implemented packed graphics (it calls it pixel graphics), but only because it's more standard.

Unfortunately he says that bitplane graphics is much faster, and makes an example of moving 16 bits at the time with the bitplanes which should be faster compared to the packed graphics.

Unfortunately both statements are plainly wrong.

I'll take my time to write an article about the bitplane vs packed/chunky topic, to mathematically prove that those are just urban legends.

BTW, I've already did it on Olaf's forum, around 10 years ago, but unfortunately he closed it.
Many people were very skeptic (especially Gunnar), but they changed their mind when I proved it, giving also examples with numbers. Math cannot be duped...

@cdimauro

I don't think there is a particular need to provide a formal proof. In the end, if there was a real benefit to having planar graphics, then GPU vendors would have capitalised on it. And every Amiga used in a professional productivity role of any kind generally ended up with a graphics card installed in it. Personally, my productivity increased dramatically once I installed an RTG card.

Bitplane graphics are fun for a number of retro effects. I remember the whole trippy effects of repeating patterns in planes that were then overlapped at different offsets and assigning various interesting palettes to it. They were also good for creating some cheap polygon translucency effects, again by assigning logically blended colours to the right palette entries. So, a blue colour in index 1, red in 2 and magenta in 3, you could draw polygons into a pair of bitplanes, one blue, one red and magenta where they overlap.

Fun, but not exactly productive.

Last edited by Karlos on 15-May-2022 at 01:36 AM.

_________________
Doing stupid things for fun...

@Karlos

Quote:

Karlos wrote: @cdimauro I don't think there is a particular need to provide a formal proof.

I'll do it only because this topic is constantly popping when talking about Amigas, and completely wrong information is continuously reported about it.
Quote:

In the end, if there was a real benefit to having planar graphics, then GPU vendors would have capitalised on it. And every Amiga used in a professional productivity role of any kind generally ended up with a graphics card installed in it. Personally, my productivity increased dramatically once I installed an RTG card.

Indeed.
Quote:

Bitplane graphics are fun for a number of retro effects. I remember the whole trippy effects of repeating patterns in planes that were then overlapped at different offsets and assigning various interesting palettes to it. They were also good for creating some cheap polygon translucency effects, again by assigning logically blended colours to the right palette entries. So, a blue colour in index 1, red in 2 and magenta in 3, you could draw polygons into a pair of bitplanes, one blue, one red and magenta where they overlap. Fun, but not exactly productive.

Exactly. Accessing single bitplanes is the ONLY advantage that this graphic format had compared to packed/chunky.