Click Here
home features news forums classifieds faqs links search
6071 members 
Amiga Q&A /  Free for All /  Emulation /  Gaming / (Latest Posts)
Login

Nickname

Password

Lost Password?

Don't have an account yet?
Register now!

Support Amigaworld.net
Your support is needed and is appreciated as Amigaworld.net is primarily dependent upon the support of its users.
Donate

Menu
Main sections
» Home
» Features
» News
» Forums
» Classifieds
» Links
» Downloads
Extras
» OS4 Zone
» IRC Network
» AmigaWorld Radio
» Newsfeed
» Top Members
» Amiga Dealers
Information
» About Us
» FAQs
» Advertise
» Polls
» Terms of Service
» Search

IRC Channel
Server: irc.amigaworld.net
Ports: 1024,5555, 6665-6669
SSL port: 6697
Channel: #Amigaworld
Channel Policy and Guidelines

Who's Online
22 crawler(s) on-line.
 123 guest(s) on-line.
 1 member(s) on-line.


 zErec

You are an anonymous user.
Register Now!
 zErec:  4 mins ago
 amigakit:  5 mins ago
 BigD:  7 mins ago
 OlafS25:  13 mins ago
 retrofaza:  27 mins ago
 kolla:  42 mins ago
 edwardsjethro:  1 hr 33 mins ago
 joeyunderwood:  1 hr 35 mins ago
 Sikharubel:  1 hr 38 mins ago
 Musashi5150:  2 hrs ago

/  Forum Index
   /  Classic Amiga Hardware
      /  Bit Plane Technology
Register To Post

Goto page ( Previous Page 1 | 2 | 3 | 4 | 5 | 6 Next Page )
PosterThread
saimo 
Re: Bit Plane Technology
Posted on 22-Jul-2018 12:31:51
#41 ]
Elite Member
Joined: 11-Mar-2003
Posts: 2450
From: Unknown

@Karlos

Quote:
I'm sure that if the Amiga had supported packed pixel formats (e.g. 2, 4 and 8 bits per pixel) most of the features we ascribe to bit plane graphics could still have worked just fine, given that scrolling was achieved by setting horizontal offsets and not by actually moving any data around.

Again, I haven't said that parallax scrolling (and other effects) can only be achieved through bitplanes (the way the Amiga implements them): as an answer to the initial question, I only said that, as a matter of fact, bitplanes (and associated features) are what makes the Amiga good at parallax scrolling.
Now, if we consider the alternatives you propose, I agree provided that multiple planes of the suggested depths were available (however, 8 bit deep planes would not have been possible without multipling the AGA bandwidth by as many times as the number of planes; fun fact: the AAA chipset that had 3 byteplanes). The key is the *planes* concept. With a single chunky raster, free parallax (and trasparencies, and masking, etc.) are gone - the only possibility to obtain those effects would be performing heavy data manipulation through CPU, Blitter, GPU, and whatnot. Sure, that's how one would do it using modern hardware, but back then that was not an option.

That said, it looks like I need to clarify one more thing: I'm not saying that the Amiga bitplanes are the best thing in the world, that they are superior to chunky rasters, that they are magic, or whatever. All I intended to do is to provide an answer that made it clear that it's thanks to them that parallax scrolling (and other effects) can be obtained on the Amiga without effort.
Actually, I hate the added complexity and inefficiency bitplanes cause for horizontal alignments, not to mention the pain for single-pixel-oriented graphics manipulation (in fact, they are the main reason why the Amiga can't do 3D graphics efficiently, which, while I personally don't care about 3D, is one of the many things that killed the Amiga, eventually).

Quote:
As a historical footnote, Jay Minor once said that in hindsight, the choice to use planar was a mistake. I don't have the reference to hand but it's on YouTube somewhere. Personally I would have loved to have packed pixel modes but only in addition to fully supporting planar modes too.

Well, I wonder if they had a choice: the first and foremost purpose of bitplanes is to save RAM and bandwidth, and back then those were crucial issues. If he regretted the choice, it almost sounds like that they could have gone for an alternative while still staying within the economical and technical constraints... but one should know his exact words and know all about the context to really understand.
For sure if the Amiga had offered also chunky modes, possibly mixed with the planes concept, it would have been great. But, c'mon, the Amiga architecture was already a huge leap forward, and asking it to do right from the start what AAA was supposed to do would be too much

BTW, as a proof that I would have loved byteplanes too, at the end of the 90s I wrote a special graphical engine for AGA that allowed to have 2 byteplanes with full transparency control and possibly a transparent color for the foreground plane, both natively (but with horizontal resolution halved, as two consecutive pixels were spaced by a sort of color-average pixel) or with some CPU [+Blitter] intervention for full horizontal resolution. I had even released it, but it didn't receive attention; eventually, I retired it because I first wanted to rewrite entirely the documentation and make some improvements. Hopefully, one day... In the meanwhile, if anyone is interested, I might make a video... just ask
Lately I have pulled out my A1200 out of the closet and had a lot of fun with the same core idea, and produced a variety of funky chunky modes (and a 24 bit mode - check this out). I'm planning (itching) to make a (mini-)game with at least one of them, but first I have to finish SkillGrid (and a game that, by coincidence, features the first and only full-screen, full-frame, full-color, speed-unlimited, scrolling engine for the C64, to which, after releasing a 16 kB version of the game, I have added also a little parallax effect; but this game is going to take ages to complete, so probably I'll go for the Amiga mini-game first).

Last edited by saimo on 22-Jul-2018 at 12:38 PM.

_________________
RETREAM - retro dreams for Amiga, Commodore 64 and PC

 Status: Offline
Profile     Report this post  
saimo 
Re: Bit Plane Technology
Posted on 22-Jul-2018 13:04:25
#42 ]
Elite Member
Joined: 11-Mar-2003
Posts: 2450
From: Unknown

@cdimauro

Quote:
Unfortunately I couldn't draw BOBs in one go, because they used only 32 colors (instead of the 64 available with the EBH). The first 16 color entries in the CLUT were reserved to the backgroud, and changed all the times. So, drawing BOBs required 6 blits...

I understand the need to have some freely-defineable colors for the backgrounds and, at the same time, ensuring that all the characters work on all backgrounds, but how does this affect the blitting? The bobs used colors 16-31 and 48-63, so the only thing special about it is that either plane 4 or plane 5 always had a bit set; hence, the bobs had to be blitted on all the planes anyway (no shortcut of the kind clear-only-on-some-planes). If it was necessary to make separate blits, then it must be because the graphics were not interleaved... or was it there some other reason?

Edit:
* removed this leftover: "If the bobs had been in just";
* "either plane 4 or plane 5 always had a bit set" is wrong: it's just plane 4 that had to be set always to ensure the colors started from 16 (when plane 5 was clear) or 48 (when plane 5 was set).

Quote:
I've considered both solutions, but the required effort wouldn't have payed the bandwidth saving.

The big BOBs were split in very small rectangles (usually squares) in order to reuse as much as possible the graphic for the animations, basically acting like tiles. So, we already had to do several blits (repeated 6 times, as I've said before), and introducing the BPLCON1 + Copper would have complicated a lot the code (which had to deal with the double buffer and the special horizontal scrolling too).

Unfortunately only a few bottom lines are usually not affected by BOBs, but it wasn't a general rule, as you can see here: https://www.youtube.com/watch?v=K4jdNPsbdow&t=14m07s where you can see at the bottom left that some background animation covered the last lines of the screen.

Ah, yes, the code would have become really a mess and it wouldn't have been worth it for just a few rasterlines.
The tile-based characters are a remarkable solution (both from the coding and pixelling point of view).

Quote:
Anyway, at the end my parallax code didn't went in production because the graphic artist refused to change again all background screens.

Ah, I had thought I had forgotten about the parallax in FS, but instead I simply have never seen it

Quote:
He also refused to change the backgrounds to accomodate the idea which I had for special lighting of the night scenarios.

I don't know his reasons, but considering the complexity of the graphics and the sheer amount of work he had done, I wouldn't be surprised if it was because he couldn't take more of the pixelwork...

Quote:
It was a pity, because Fightin' Spirit could have been much better technically (and visually) speaking, but we were youngs at the time, and made a lot of mistakes.

The game is already visually excellent. If I remember correctly, the only glitches I ever saw in screenshots/videos, is that sometimes some pixels in the floors used colors in 32-63, thus the shadow effect didn't work on them.
But it's normal not to get everything perfect, especially with little experience.

Last edited by saimo on 22-Jul-2018 at 09:21 PM.

_________________
RETREAM - retro dreams for Amiga, Commodore 64 and PC

 Status: Offline
Profile     Report this post  
Karlos 
Re: Bit Plane Technology
Posted on 22-Jul-2018 13:13:35
#43 ]
Elite Member
Joined: 24-Aug-2003
Posts: 4394
From: As-sassin-aaate! As-sassin-aaate! Ooh! We forgot the ammunition!

@cdimauro

Packed only graphics would have made it difficult to support colour depths that weren't an even divisor of a byte, like 8 and 32 and 64 colour modes. I like the idea of a hybrid solution here. For example you could have had a 64 colour display by having wither 6 1-bit planes, 3 2-bit packed layers or one 4-bit packed layer with one 2-bit packed layer or any other combination yielding a total of 6 bits per pixel.

_________________
Doing stupid things for fun...

 Status: Offline
Profile     Report this post  
cdimauro 
Re: Bit Plane Technology
Posted on 22-Jul-2018 21:04:31
#44 ]
Elite Member
Joined: 29-Oct-2012
Posts: 3621
From: Germany

@saimo

Quote:

saimo wrote:
@cdimauro

I understand the need to have some freely-defineable colors for the backgrounds and, at the same time, ensuring that all the characters work on all backgrounds, but how does this affect the blitting? The bobs used colors 16-31 and 48-63, so the only thing special about it is that either plane 4 or plane 5 always had a bit set; hence, the bobs had to be blitted on all the planes anyway (no shortcut of the kind clear-only-on-some-planes). If it was necessary to make separate blits, then it must be because the graphics were not interleaved... or was it there some other reason? If the bobs had been in just

The graphic was interleaved, and yes: plane 4 (fifth) was always set (it was the mask).
However the characters had the possibility to change some colors from some basic palettes, in order to allow 2 players to use the character, but with some different colors to distinguish them. So, you cannot directly blit the BOBs as they are.
Quote:
I don't know his reasons, but considering the complexity of the graphics and the sheer amount of work he had done, I wouldn't be surprised if it was because he couldn't take more of the pixelwork...

Yes, the needed changes required A LOT of work, and you know the effort with pixel art.
Quote:
The game is already visually excellent. If I remember correctly, the only glitches I ever saw in screenshots/videos, is that sometimes some pixels in the floors used colors in 32-63, thus the shadow effect didn't work on them.
But it's normal not to get everything perfect, especially with little experience.

Unfortunately sometimes the frame rate dropped to 17fps when there was too much graphic to be drawn.

@Karlos

Quote:

Karlos wrote:
@cdimauro

Packed only graphics would have made it difficult to support colour depths that weren't an even divisor of a byte, like 8 and 32 and 64 colour modes.

It's difficult for the CPU, but for the display controller and the Blitter basically it doesn't change so much: you shift & mask the data (and you directly have the palette index too: no need to combine all fetched bits from the various bitplanes).
Quote:
I like the idea of a hybrid solution here. For example you could have had a 64 colour display by having wither 6 1-bit planes, 3 2-bit packed layers or one 4-bit packed layer with one 2-bit packed layer or any other combination yielding a total of 6 bits per pixel.

Too much complicate to handle, and not needed: there isn't a real advantage in almost all cases.

Having packed graphic, it was enough to have only 2 "packed planes" to allow DP mode.

 Status: Offline
Profile     Report this post  
saimo 
Re: Bit Plane Technology
Posted on 22-Jul-2018 21:31:53
#45 ]
Elite Member
Joined: 11-Mar-2003
Posts: 2450
From: Unknown

@cdimauro

Quote:
and yes: plane 4 (fifth) was always set (it was the mask).

Ah, right. This just made me realized I wrote some nonsense in my previous post (at some point I totally ignored the fact that one needs to add 16 to 32 to obtain 48 ). Fixed.

BTW, did you use the blits on plane 4 for Blitter-based collision detection? Given the plane-by-plane blits, that came for free.
Edit: on secound thought, that would halve the colors available to backgrounds, so I guess that the answer is no.

Quote:
However the characters had the possibility to change some colors from some basic palettes, in order to allow 2 players to use the character, but with some different colors to distinguish them. So, you cannot directly blit the BOBs as they are.

Hmmm... Do you perhaps mean that one of the plane 3 was used as an offset to address two separate palette ranges (16-23 plus 48-55 / 24-31 plus 56-63)?

Quote:
Quote:
I don't know his reasons, but considering the complexity of the graphics and the sheer amount of work he had done, I wouldn't be surprised if it was because he couldn't take more of the pixelwork...

Yes, the needed changes required A LOT of work, and you know the effort with pixel art.

Yep, that's precisely what I meant.

Quote:
Quote:
The game is already visually excellent. If I remember correctly, the only glitches I ever saw in screenshots/videos, is that sometimes some pixels in the floors used colors in 32-63, thus the shadow effect didn't work on them.
But it's normal not to get everything perfect, especially with little experience.

Unfortunately sometimes the frame rate dropped to 17fps when there was too much graphic to be drawn.

Ah, I haven't seen it much in action (I've mostly seen screenshots), so I had not noticed that. Yeah, with so many planes, big bobs, and animations, that's understandable.

Last edited by saimo on 23-Jul-2018 at 09:31 AM.
Last edited by saimo on 23-Jul-2018 at 09:31 AM.
Last edited by saimo on 22-Jul-2018 at 09:32 PM.

_________________
RETREAM - retro dreams for Amiga, Commodore 64 and PC

 Status: Offline
Profile     Report this post  
Hypex 
Re: Bit Plane Technology
Posted on 23-Jul-2018 7:45:51
#46 ]
Elite Member
Joined: 6-May-2007
Posts: 11180
From: Greensborough, Australia

@saimo

Quote:
The matter is not what other possibilities are there to obtain parallax scrolling. Of course there are, but the initial question is whether it's thanks to the bitplanes that the Amiga does parallax scrolling, and your statement "It was said because of the planar format why the Amiga was good at parallax scrolling. However, I don't think the pixel format really has any bearing on this", which was supposed to be an answer to the question, is wrong because bitplanes are the key to obtain parallax scrolling (and the Dual Playfield) on the Amiga.
Your statement rather answers the question "Are bitplanes necessary to obtain parallax scrolling?".


That's because it's how I interpreted the question. Sure there are a few ways of performing parallax scrolling but the dual playfield came to mind first.

Quote:
Sure, those are features that allow scrolling in first place. But how does that counter the fact that it's the bitplanes-based architecture that allows parallax scrolling in the Amiga?


It would come back to the two independent playfields since it is what my focus was on. Since I was thinking of each playfield as one image. Knowing full well the technical layout below the surface.

Quote:
Again, neither I nor the OP were talking about alternatives.


No, but I was imagining how it would be done with packed pixels. And looked out for an example.

Quote:
Yes, but that's a totally different story from your initial statement, which is: "But, because it was planar, it could fill in blocks on the edge incrementally until they came into view. Such as blitting 16x16 blocks at a time. The blitter was made for transferring images of different sizes onto a full screen bitmap " and which was supposed to be an answer to the OP question.


It is here in the scrolling, using a wider bitmap, where the bitplanes are tied to the pixel format as well as the odd and even split of the bitplanes between the playfields. I just touched on the surface.

Quote:
I stand corrected: I was thinking of byte-chunky pixels only.


I must say I enjoyed throwing that "Wrong" back to you. All in good humour of course.

Yes we tend to think in 8-bit chunks. But I examined the C= 8-bit bitmap format and found it was 2-bit chunky in MCM. Except the pixel width matched the 2-bit data width so unlike normal chunky. Normal bitplane or bitmap in standard colour modes.

Quote:
(Yes, I know how the C64 works, I make games for it.)


Could you port those games to a 264? Not that mine work. All my C16s and Plus/4s being broken.

 Status: Offline
Profile     Report this post  
saimo 
Re: Bit Plane Technology
Posted on 23-Jul-2018 9:24:47
#47 ]
Elite Member
Joined: 11-Mar-2003
Posts: 2450
From: Unknown

@Hypex

Quote:
Quote:
The matter is not what other possibilities are there to obtain parallax scrolling. Of course there are, but the initial question is whether it's thanks to the bitplanes that the Amiga does parallax scrolling, and your statement "It was said because of the planar format why the Amiga was good at parallax scrolling. However, I don't think the pixel format really has any bearing on this", which was supposed to be an answer to the question, is wrong because bitplanes are the key to obtain parallax scrolling (and the Dual Playfield) on the Amiga.
Your statement rather answers the question "Are bitplanes necessary to obtain parallax scrolling?".

That's because it's how I interpreted the question. Sure there are a few ways of performing parallax scrolling but the dual playfield came to mind first.

But your interpretation was wrong, and the answer you gave (also in your interpretation) was wrong. Look at it again:

Quote:
Quote:
Trekiej:
Is Bit Plane Technology why the Amiga is good a Parallax Scrolling?

You:
It was said because of the planar format why the Amiga was good at parallax scrolling. However, I don't think the pixel format really has any bearing on this. Each playfield on the Amiga has it's own scroll offset. The main reason it was good at this was because it supported two separate screen layers super imposed on each other with the sprites.

You state that:
* it is not because of the bitplanes that the Amiga was good at parallax scrolling - that's wrong, because it's precisely the fact that the Amiga has (almost totally) separate graphics layers that allows parallax without effort;
* it is thanks to the Dual Playfield that the Amiga was good at parallax scrolling - that's wrong because even if the Amiga had not had the Dual Playfield, still it would have been able to do parallax scrolling (and actually even implement the Dual Playfield exactly as it is); all that the Dual Playfield does is making it easier to set up the palette (restricting what one can do with it, though).

This issue had to be addressed to let the question have a correct answer avoid and that misinformation spreaded.

Quote:
It would come back to the two independent playfields since it is what my focus was on. Since I was thinking of each playfield as one image. Knowing full well the technical layout below the surface.

That's no answer. The fact that you were thinking of Dual Playfield does not make it true that it's Dual Playfield that makes the Amiga good at parallax scrolling. It's the bitplanes that do that and that make Dual Playfield possible (as shown above).
For convenience, here's the whole sequence:

Trekiej: Is Bit Plane Technology why the Amiga is good a Parallax Scrolling?

You: Each playfield on the Amiga has it's own scroll offset. The main reason it was good at this was because it supported two separate screen layers super imposed on each other with the sprites.

Me: The Dual Playfield mode is possible precisely thanks to the bitplanes, so again it's the fact that the graphics are based on bitplanes that makes parallax scrolling easy.

You: You've got scroll offsets and plane pointers.

Me: Sure, those are features that allow scrolling in first place. But how does that counter the fact that it's the bitplanes-based architecture that allows parallax scrolling in the Amiga?

You: It would come back to the two independent playfields since it is what my focus was on. Since I was thinking of each playfield as one image. Knowing full well the technical layout below the surface.

Quote:
Quote:
Yes, but that's a totally different story from your initial statement, which is: "But, because it was planar, it could fill in blocks on the edge incrementally until they came into view. Such as blitting 16x16 blocks at a time. The blitter was made for transferring images of different sizes onto a full screen bitmap " and which was supposed to be an answer to the OP question.

It is here in the scrolling, using a wider bitmap, where the bitplanes are tied to the pixel format as well as the odd and even split of the bitplanes between the playfields. I just touched on the surface.

I can't make heads or tails of this last answer of yours. But still it doesn't change the fact that your statement But, because it was planar, it could fill in blocks on the edge incrementally until they came into view:
* is wrong because the fact that graphics can be drawn on edges beyond the visible area is not thanks to the planar nature of the raster, but thanks to the possibility of making the raster bigger than the visible area, and that's a property that does not depend on the pixel format;
* is totally unrelated to the question to which it was offered as an answer ("Is Bit Plane Technology why the Amiga is good a Parallax Scrolling?").

Quote:
Quote:
I stand corrected: I was thinking of byte-chunky pixels only.

I must say I enjoyed throwing that "Wrong" back to you. All in good humour of course.

No problem with humour and no problem with the correction to my false statement - actually, it's good that you corrected it, otherwise it would have been left lingering around spreading false information.

Quote:
Yes we tend to think in 8-bit chunks. But I examined the C= 8-bit bitmap format and found it was 2-bit chunky in MCM. Except the pixel width matched the 2-bit data width so unlike normal chunky. Normal bitplane or bitmap in standard colour modes.

This needs to be expanded on because who isn't knowledgeable about the C64 graphic modes might get several wrong ideas.
The C64 has a 5 graphic modes, and the bitmap mode is one of them.
The bitmap mode can be both monochrome (i.e. 1 bit deep, with a resolution of 320x200) and multicolor (i.e. 2 bits deep, with a resolution of 160x200 because pixels are visually 2x1 due to the packing.
But the same goes for the standard character mode: it can be both monochrome (character resolution 8x8) and multicolor (character resolution 4x8, with pixels being 2x1).
Moreover, the same concept applies to sprites: they are either monochrome (1 color + transparency, 24x21) or multicolor (3 colors + transparency, 12x21).

Quote:
Quote:
(Yes, I know how the C64 works, I make games for it.)

Could you port those games to a 264? Not that mine work. All my C16s and Plus/4s being broken.

The TED doesn't have sprites and my games rely heavily on them, so it would not be possible. But, even if it had been, I wouldn't have done it because porting is terribly boring and, moreover, time is limited and I have plenty of original projects to work on.

Last edited by saimo on 23-Jul-2018 at 09:25 AM.

_________________
RETREAM - retro dreams for Amiga, Commodore 64 and PC

 Status: Offline
Profile     Report this post  
Hypex 
Re: Bit Plane Technology
Posted on 23-Jul-2018 9:59:56
#48 ]
Elite Member
Joined: 6-May-2007
Posts: 11180
From: Greensborough, Australia

@saimo

Quote:
Again, I haven't said that parallax scrolling (and other effects) can only be achieved through bitplanes (the way the Amiga implements them): as an answer to the initial question, I only said that, as a matter of fact, bitplanes (and associated features) are what makes the Amiga good at parallax scrolling.


Also, the blitter can be used for scrolling. Now, it is more time consuming, but it can be performed on single bitplanes. An Abacus scrolling example does this IIRC. This could be used to some effect. As well as using sprites for 'parallaxing" with their internal plane based format.

Quote:
For sure if the Amiga had offered also chunky modes, possibly mixed with the planes concept, it would have been great. But, c'mon, the Amiga architecture was already a huge leap forward, and asking it to do right from the start what AAA was supposed to do would be too much


I think it would have needed practical limitations. It's all too easy to think of bitplane depth and think of it as being exactly like colour depth, but they aren't exactly the same, even if they both describe the same pixel depth. What I mean is the bitmap depth in the Amiga was exactly that, the depth of bitplanes themselves, how many bitplanes deep. But for packed pixel data, it still sits on a plane, with pixel width. Except there is only one plane but the pixels have different data widths per pixel. So there is planar, on a Z axis; and chunky on an X axis. Planar is layers. Chunky is linear. We could also say, planar goes into, chunky goes across.

When you compare 1 bit planar with 1 bit chunky they are equals. They are both formatted as a bitmap. Extending the pixel bits to 2, 4, 8 and so on is where they diverge. Planar then stacks another bitmap for the next level of bits chunky where as just stacks the bits across.

So, for an Amiga packed mode, I think they all would have needed the depth set to one for one bitplane, With a variable packed pixel width as another setting. For bitplanes it would always be set at one for a true bitmap. Dual playfield possibly but limited to 3-bit CLUT index in pixel nibbles. Or 4-bit max for standard single mode. On AGA increased to 8-bit packed data per plane. But in dual mode maybe just 4-bits per plane. They would have been mutually exclusive in this sense; multiple bitplanes per image would only work for planar format; multiple pixel width would only work for one plane. It fun to think of hybrid modes with mixed planes of different pixel widths but practically would have been too superfluous.

When I found how the Amiga organised the bitplanes with the depth and how there were different layers going into the screen I thought "Wow, I'm blown away, that's so cool man..." Or something similar. The organisation has this cool factor the way it works with the depth. But packed or chunky? Meh, boring, looks a bit ordinary.

I once examined an RTG BitMap structure and saw that the depth was always set to one which seemed strange as it had more colours. But it light of the above this would be correct, one plane of pixel data, but packed across. A BitMap also does not contain a direct width but only BytesPerRow so is quite forward compatible this way to packed formats. However, it lacked extensions to contain direct width and RTG flags.

Quote:
TW, as a proof that I would have loved byteplanes too, at the end of the 90s I wrote a special graphical engine for AGA that allowed to have 2 byteplanes with full transparency control and possibly a transparent color for the foreground plane, both natively (but with horizontal resolution halved, as two consecutive pixels were spaced by a sort of color-average pixel) or with some CPU [+Blitter] intervention for full horizontal resolution. I had even released it, but it didn't receive attention; eventually, I retired it because I first wanted to rewrite entirely the documentation and make some improvements. Hopefully, one day... In the meanwhile, if anyone is interested, I might make a video... just ask




Okay, I'm asking...

I also like the sound of byteplanes.

Quote:
Lately I have pulled out my A1200 out of the closet and had a lot of fun with the same core idea, and produced a variety of funky chunky modes (and a 24 bit mode - check this out).


You've got my attention now. A few years back I was playing with some ideas for a 12-bit or 24-bit framebuffer mode on AGA. Which, funnily enough, looked more plausible than an 8-bit CLUT chunky mode. I was looking into the copper, and 2-bit resolution copper chunky modes, displaying a super low res like image and modifying it. I thought of how the bitmap could display sequential colours from the palette and setting these the line before for half the colours. Then setting all the rest on the next line. As you can tell it suddenly runs out of room, since in the display there is only 160 words that can be written , in the viewable display area. Although the colours can be set up earlier in the palette. It would have been a mix of CLUT for one pixel and copper changing background or similar for next. To provide 1:1 pixel mode. I also thought of running a raster interrupt on the lines in parallel, so the operation was dual threaded, with the copper writing to one half of the palette registers and CPU being used to write to the other half. But I never experimented with it.

 Status: Offline
Profile     Report this post  
Hypex 
Re: Bit Plane Technology
Posted on 23-Jul-2018 16:12:19
#49 ]
Elite Member
Joined: 6-May-2007
Posts: 11180
From: Greensborough, Australia

@saimo

Quote:
But your interpretation was wrong, and the answer you gave (also in your interpretation) was wrong. Look at it again:


You may be right there but that's what happens when you misinterpret something. Perhaps I should delete my original response.

Quote:
You state that: * it is not because of the bitplanes that the Amiga was good at parallax scrolling - that's wrong, because it's precisely the fact that the Amiga has (almost totally) separate graphics layers that allows parallax without effort;


The bitplanes are entrenched in the hardware, so statements about Jay considering chunky don't make sense; but I wonder, is a planar architecture the best for parallax scrolling?

Quote:
* it is thanks to the Dual Playfield that the Amiga was good at parallax scrolling - that's wrong because even if the Amiga had not had the Dual Playfield, still it would have been able to do parallax scrolling (and actually even implement the Dual Playfield exactly as it is); all that the Dual Playfield does is making it easier to set up the palette (restricting what one can do with it, though).


So how would dual playfield be implemented exactly as it is without using the dual mode?

Quote:
That's no answer. The fact that you were thinking of Dual Playfield does not make it true that it's Dual Playfield that makes the Amiga good at parallax scrolling. It's the bitplanes that do that and that make Dual Playfield possible (as shown above).


I can only tell you what I was thinking at the time.

Quote:
For convenience, here's the whole sequence:




Quote:
I can't make heads or tails of this last answer of yours. But still it doesn't change the fact that your statement But, because it was planar, it could fill in blocks on the edge incrementally until they came into view:


I was pointing out (or trying to) the odd planes and even planes used in the dual playfields and how a wider bitmap would be used to scroll graphics into view with the planar format using a certain amount of bytes across for images.

Quote:
No problem with humour and no problem with the correction to my false statement - actually, it's good that you corrected it, otherwise it would have been left lingering around spreading false information.


Slight technical difference with normal packed pixels but yes.

Quote:
This needs to be expanded on because who isn't knowledgeable about the C64 graphic modes might get several wrong ideas.


Thus why I had to explain what I meant as well.

Quote:
The TED doesn't have sprites and my games rely heavily on them, so it would not be possible. But, even if it had been, I wouldn't have done it because porting is terribly boring and, moreover, time is limited and I have plenty of original projects to work on.


Doom was popular on hardware that had no sprites as well. So without sprites the Plus/4 was ahead of its time. Ha.

Someone thought it would be good port Kikstart from the C16 to the C64. I don't know why. C64 already had Kikstart and is said to always have the better games. They would have to add sprites or maybe not in this case. And reduce the colours. It also adds insult to injury. The one gem the C16 had but the C64 people weren't happy to have everything and so had to take that as well. The poor get poorer, the rich get richer.

 Status: Offline
Profile     Report this post  
saimo 
Re: Bit Plane Technology
Posted on 23-Jul-2018 17:28:04
#50 ]
Elite Member
Joined: 11-Mar-2003
Posts: 2450
From: Unknown

@Hypex

Quote:
Quote:
TW, as a proof that I would have loved byteplanes too, at the end of the 90s I wrote a special graphical engine for AGA that allowed to have 2 byteplanes with full transparency control and possibly a transparent color for the foreground plane, both natively (but with horizontal resolution halved, as two consecutive pixels were spaced by a sort of color-average pixel) or with some CPU [+Blitter] intervention for full horizontal resolution. I had even released it, but it didn't receive attention; eventually, I retired it because I first wanted to rewrite entirely the documentation and make some improvements. Hopefully, one day... In the meanwhile, if anyone is interested, I might make a video... just ask




Okay, I'm asking...

Here you go:

https://www.youtube.com/watch?v=936iaHv_Vzs

This video shows some features of a chunky true-color system for AGA Amigas that I developed from 1996 to 2003. Namely, it focuses only on the Cross Playfield and Dual Cross Playfield modes.
More precisely, this is what is shown:
1. rotation and zooming of a 256 colors texture on an 8-bit chunky raster (raster 1);
2. zooming of a 256 colors texture on an 8-bit chunky raster (raster 2);
3. displaying of rasters 1 and 2 in Cross Playfield mode, where raster 1 is the front playfield and raster 2 is the background playfield;
4. dynamic variation of the foreground playfield opacity (from 0 = totally transparent, to 256 = totally opaque); note that the playfields coexist, so the blending is not achieved by pixel data manipulation, but by means of palette recalculation;
5. displaying of an 81 colors texture on an 8-bit chunky raster (raster 3);
6. displaying of raster 2 and 3 in Dual Cross Playfield mode, where raster 3 is the front playfield, with a color entirely transparent, and raster 2 is the background playfield;
7. variation of the foreground playfield brightness (from 0 = totally dark, to 256 = full brightness).

_________________
RETREAM - retro dreams for Amiga, Commodore 64 and PC

 Status: Offline
Profile     Report this post  
saimo 
Re: Bit Plane Technology
Posted on 23-Jul-2018 17:57:05
#51 ]
Elite Member
Joined: 11-Mar-2003
Posts: 2450
From: Unknown

@Hypex

Quote:
The bitplanes are entrenched in the hardware, so statements about Jay considering chunky don't make sense; but I wonder, is a planar architecture the best for parallax scrolling?

Depends. Nowadays, one would just use the capabilities of graphic cards.
Anyway, the planar and chunky concepts are not mutually exclusive - again, think of byteplanes.

Quote:
Quote:
* it is thanks to the Dual Playfield that the Amiga was good at parallax scrolling - that's wrong because even if the Amiga had not had the Dual Playfield, still it would have been able to do parallax scrolling (and actually even implement the Dual Playfield exactly as it is); all that the Dual Playfield does is making it easier to set up the palette (restricting what one can do with it, though).


So how would dual playfield be implemented exactly as it is without using the dual mode?

It's only a boring matter of setting up the palette - all the rest just stays the same.
Examples for a 4+4 dual playfield (for simplicity, let's ignore bank and LOCT switching):
* the background colors 0-15 have to be written to the registers 0 1 4 5 16 17 20 21 64 65 68 69 80 81 84 85;
* assigning color 1 of the foreground a given RGB value -> write RGB value to color registers 2 + list of registers above (i.e. 2, 3, 6, 7, 18, 19, 22, 23, 66, 67, 70, 71, 82, 83, 86, 87);
...
* assigning color 15 of the foreground a given RGB value -> write RGB value to color registers 170 + list of registers above (can't bother doing the maths )

_________________
RETREAM - retro dreams for Amiga, Commodore 64 and PC

 Status: Offline
Profile     Report this post  
Karlos 
Re: Bit Plane Technology
Posted on 23-Jul-2018 22:29:51
#52 ]
Elite Member
Joined: 24-Aug-2003
Posts: 4394
From: As-sassin-aaate! As-sassin-aaate! Ooh! We forgot the ammunition!

Came for nerd pr0n. Left satisfied.

Totally unrelated, I once messed around trying see if I could fake 15-bit colour precision in OCS/ECS by displaying HAM PAL LORES mages on an interlaced screen, splitting each pixel in 2 and modifying the 12-bit upper and lower halves to give the extra bit per channel by averaging.

Aside from the general nightmare of fringing, it looked like it might work. I had thought that with some half decent C2P, it might be useful on older machines.

_________________
Doing stupid things for fun...

 Status: Offline
Profile     Report this post  
Trekiej 
Re: Bit Plane Technology
Posted on 24-Jul-2018 1:40:22
#53 ]
Cult Member
Joined: 17-Oct-2006
Posts: 890
From: Unknown

@saimo

Outside of having a wider bus, is having a multi-stage pipeline able to get the bit-planes to the screen faster?

_________________
John 3:16

 Status: Offline
Profile     Report this post  
saimo 
Re: Bit Plane Technology
Posted on 24-Jul-2018 8:25:55
#54 ]
Elite Member
Joined: 11-Mar-2003
Posts: 2450
From: Unknown

@Karlos

Quote:
Totally unrelated, I once messed around trying see if I could fake 15-bit colour precision in OCS/ECS by displaying HAM PAL LORES mages on an interlaced screen, splitting each pixel in 2 and modifying the 12-bit upper and lower halves to give the extra bit per channel by averaging.

Aside from the general nightmare of fringing, it looked like it might work. I had thought that with some half decent C2P, it might be useful on older machines.

Now that's a scary idea - two nightmares (HAM and interlacing) combined Congratulations for coming up with it and, more importantly, for the courage!
But would it have been practically usable? I mean, HAM alone requires a lot of work to get an acceptable output, but then adding an extra dimension to it would complicate the logic quite much.

Footnote: since the day, when I was a teenager, it almost blacked me out, I quite simply wish that interlacing was never invented (I had been pixelling a logo on an interlaced 640x512 screen for quite some time and then, all of a sudden, I almost fell off the chair and lost consciuosness). The only thing I would ever use it for is a smooth sub-pixel vertical scroller (where everything scrolls, otherwise the flickering would be visible).

_________________
RETREAM - retro dreams for Amiga, Commodore 64 and PC

 Status: Offline
Profile     Report this post  
saimo 
Re: Bit Plane Technology
Posted on 24-Jul-2018 8:35:23
#55 ]
Elite Member
Joined: 11-Mar-2003
Posts: 2450
From: Unknown

@Trekiej

Quote:
Outside of having a wider bus, is having a multi-stage pipeline able to get the bit-planes to the screen faster?

I wouldn't say that data has to arrive "faster", but rather "on time".
Anyway, sure, pipelining could help. For example, a machine that has 8 planes could do with an 8 bit bus and an 8 stage pipeline: while 8 pixels are being drawn, it could fetch the 8 bytes needed for the next 8 pixels.
For AGA, the engineers went for a different solution: the machine has a 32 bit bus and is also capable of making twice the amount of accesses to RAM in the same time (double CAS), which is what allows heavy screens (e.g. SHRES 1280x256 in 256 colors) and 64 pixel wide sprites.

_________________
RETREAM - retro dreams for Amiga, Commodore 64 and PC

 Status: Offline
Profile     Report this post  
Trekiej 
Re: Bit Plane Technology
Posted on 24-Jul-2018 15:27:54
#56 ]
Cult Member
Joined: 17-Oct-2006
Posts: 890
From: Unknown

@saimo

Interesting.

_________________
John 3:16

 Status: Offline
Profile     Report this post  
Hypex 
Re: Bit Plane Technology
Posted on 24-Jul-2018 16:09:46
#57 ]
Elite Member
Joined: 6-May-2007
Posts: 11180
From: Greensborough, Australia

@saimo

Quote:
Here you go:






Quote:
This video shows some features of a chunky true-color system for AGA Amigas that I developed from 1996 to 2003. Namely, it focuses only on the Cross Playfield and Dual Cross Playfield modes.


Where did you release this TCS? Can you describe how it works? Or is it a Trade Code Secret?

 Status: Offline
Profile     Report this post  
saimo 
Re: Bit Plane Technology
Posted on 24-Jul-2018 16:27:08
#58 ]
Elite Member
Joined: 11-Mar-2003
Posts: 2450
From: Unknown

@Hypex

Quote:
Quote:
This video shows some features of a chunky true-color system for AGA Amigas that I developed from 1996 to 2003. Namely, it focuses only on the Cross Playfield and Dual Cross Playfield modes.


Where did you release this TCS? Can you describe how it works? Or is it a Trade Code Secret?

It's no secret, but there's no quick way to explain it all and I just don't have time (plus I'm in a total real-life mess, from all points of view). Again, when/if I'll release it again, it will come with full documentation.
BTW, starting from it, I've made the 24-bit thing mentioned in an earlier post; while working at that, I've come up with key improvements that also TCS would benefit from. Now, more than ever, I feel I should rework TCS (not that it's bad, it's just that I'd do a few things differently and better), but there are too many other (Amiga) projects first.

_________________
RETREAM - retro dreams for Amiga, Commodore 64 and PC

 Status: Offline
Profile     Report this post  
Hypex 
Re: Bit Plane Technology
Posted on 24-Jul-2018 17:10:17
#59 ]
Elite Member
Joined: 6-May-2007
Posts: 11180
From: Greensborough, Australia

@saimo

Quote:
Depends. Nowadays, one would just use the capabilities of graphic cards.


Now days, yes, but I was thinking of back then.

Quote:
Anyway, the planar and chunky concepts are not mutually exclusive - again, think of byteplanes.


Yes, like my ideas as well, for what a plane can be.

Quote:
It's only a boring matter of setting up the palette - all the rest just stays the same.
Examples for a 4+4 dual playfield (for simplicity, let's ignore bank and LOCT switching):


Okay so a bitplane colour trick it seems. But what about scrollng?

Last edited by Hypex on 24-Jul-2018 at 05:14 PM.

 Status: Offline
Profile     Report this post  
Hypex 
Re: Bit Plane Technology
Posted on 24-Jul-2018 17:33:51
#60 ]
Elite Member
Joined: 6-May-2007
Posts: 11180
From: Greensborough, Australia

@Karlos

Would that be by a different palette per field?

Reminds me of that C64 colour mode trick to create the illusion of more colours by shifting fields every frame.

 Status: Offline
Profile     Report this post  
Goto page ( Previous Page 1 | 2 | 3 | 4 | 5 | 6 Next Page )

[ home ][ about us ][ privacy ] [ forums ][ classifieds ] [ links ][ news archive ] [ link to us ][ user account ]
Copyright (C) 2000 - 2019 Amigaworld.net.
Amigaworld.net was originally founded by David Doyle