Click Here
home features news forums classifieds faqs links search
5753 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
26 crawler(s) on-line.
 19 guest(s) on-line.
 0 member(s) on-line.



You are an anonymous user.
Register Now!
 amisteph:  5 mins ago
 Georg:  12 mins ago
 BigD:  19 mins ago
 zipper:  27 mins ago
 MEGA_RJ_MICAL:  37 mins ago
 newlight:  49 mins ago
 DiskDoctor:  49 mins ago
 SusanBarnes:  1 hr 20 mins ago
 wakido:  1 hr 26 mins ago
 clint:  1 hr 28 mins ago

/  Forum Index
   /  Amiga Development
      /  MLS, a new graphics system
Register To Post

Goto page ( Previous Page 1 | 2 | 3 )
PosterThread
NutsAboutAmiga 
Re: MLS, a new graphics system
Posted on 25-Jul-2020 10:42:53
#41 ]
Elite Member
Joined: 9-Jun-2004
Posts: 11384
From: Norway

@Fl@sh

WriteChunkyPixels(…)

My suspicion about this functions seems to be correct, first of all its slow.. here is the quote from the autodocs.

“Since WriteChunkyPixels is not (currently) particularly fast on
systems without the chunky-to-planar hardware, time critical
applications (games, etc) may want to use their own custom conversion
routine if GfxBase->ChunkyToPlanarPtr is NULL, and call
WriteChunkyPixels() otherwise. “


http://amigadev.elowar.com/read/ADCD_2.1/Includes_and_Autodocs_3._guide/node033C.html


So modern hardware likes byte size pixels, it does not like bit sized pixels, modern GPU shaders can only do floats, so I guess for GPU’s pixels should be float sized.

I guess most ideal formats are byte-plains, or float-plains. Anyway, float is not good for older graphic cards without shaders, a floats are big, the biggest issue we have now is bottleneck problem, or transferring data to graphic cards sometimes without OS support for DMA, and Gart.

Modern graphics has grown fat, because technology has driven by development is photo realistic photos. And not by memory efficiency and size.

The most ideal outcome is a byte per plain per pixel, even so we need to do it on the CPU, there is no readymade transformation routine, well there is chunkyplains2, but I felt it was worth barking down that path, wasted too many CPU cycles, only in special cases where plains did not line up, was it worth it, and majority of cases that never happened.

Last edited by NutsAboutAmiga on 25-Jul-2020 at 10:51 AM.
Last edited by NutsAboutAmiga on 25-Jul-2020 at 10:43 AM.

_________________
http://lifeofliveforit.blogspot.no/
Facebook::LiveForIt Software for AmigaOS

 Status: Offline
Profile     Report this post  
Hypex 
Re: MLS, a new graphics system
Posted on 25-Jul-2020 18:09:58
#42 ]
Elite Member
Joined: 6-May-2007
Posts: 9977
From: Greensborough, Australia

@saimo

Quote:
When I write "planes" I mean "bitplanes". Just shortening for convenience So, yes, the layers are made of bitplanes.


Okay that makes sense.

Quote:
The only practical solution is not using all the planes (at most 4 on OCS/ECS and 7 on AGA), but that would reduce greatly the power and the beauty of layers, thus defying the purpose of having layers in first place.


If you only wanted 4 or 7 layers it may work. Or even less.

Quote:
That said, it is technically possible to add sprites support. If that happens, the features will be as follows.


Okay, looks fine there.

Quote:
This is what I was referring to with this piece from a previous post (sorry, again I'm too exhausted):


That fine, no need to repeat yourself. By the looks of it the horizontally scrolling would need to be in blocks of 16 pixels at a time. Since they don't have their own scroll offset. That's understandable. Since they make up the entire bitmap.

Quote:
MLS doesn't use the Blitter.


Yes I realised that. I'm just thinking up ways around it. Using the blitter to scroll each layer.

Quote:
EDIT: only now I realized what you referred to with this (I'm too tired, sorry). Yeah, I was quite annoyed, to put it mildly. But it didn't burn exaggeratedly much at the moment: rather, it kept on stinging me through the years.


Fair enough. Thanks for explaining.

BTW, when AGA came out I recall these simple demos. They used to display digitsed pictures and fade between them. It was one of the cool effects AGA could do. Well I only noticed it being done on AGA. I always wondered how it was done. Does MLS use a simlar technique?

Last edited by Hypex on 25-Jul-2020 at 06:23 PM.

 Status: Offline
Profile     Report this post  
Hypex 
Re: MLS, a new graphics system
Posted on 25-Jul-2020 18:20:06
#43 ]
Elite Member
Joined: 6-May-2007
Posts: 9977
From: Greensborough, Australia

@NutsAboutAmiga

Quote:
My suspicion about this functions seems to be correct, first of all its slow.. here is the quote from the autodocs.


It doesn't mention it specifically, rather implied, but what it would be talking about is Akiko. CD32. Only Amiga released with chunky to planar hardware. Though on examination they would have been better doing it the VGA way. Chunky pixel write to bitmap planar hardware conversion.

Quote:
So modern hardware likes byte size pixels, it does not like bit sized pixels, modern GPU shaders can only do floats, so I guess for GPU?s pixels should be float sized.


That's interesting, it must be like the music industry, where it's all turning to floats. Well, floats can fit in 32-bits. But, in the end, it looks like Commodore may have been right, with 32-bits per gun. Like SetRGB32(). We're not there yet. But pushing RGB integers into RGB floats may push that over the line.

Quote:
I guess most ideal formats are byte-plains, or float-plains.


A packed plane. Like a wide plane I guess. Instead of multiple Z planes like on Amiga, it has an X plane with bits stored across.

 Status: Offline
Profile     Report this post  
saimo 
Re: MLS, a new graphics system
Posted on 25-Jul-2020 18:46:53
#44 ]
Elite Member
Joined: 11-Mar-2003
Posts: 2303
From: Unknown

@Hypex

Quote:
Quote:
The only practical solution is not using all the planes (at most 4 on OCS/ECS and 7 on AGA), but that would reduce greatly the power and the beauty of layers, thus defying the purpose of having layers in first place.


If you only wanted 4 or 7 layers it may work. Or even less.

1 bitplane less = half the number of colors available -> most of the times, not worth it (especially OCS/ECS). MLS is layers-oriented, so it makes little sense to sacrifice layers for sprites. For the moment being, they're out.

Quote:
That fine, no need to repeat yourself. By the looks of it the horizontally scrolling would need to be in blocks of 16 pixels at a time. Since they don't have their own scroll offset. That's understandable. Since they make up the entire bitmap.

16 pixels is too coarse a resolution: it causes scrolling to be way too jumpy and/or too fast. On AGA, to benefit from the 4x fetch mode, that's even worse: 64 pixels.

Quote:
Quote:
MLS doesn't use the Blitter.


Yes I realised that. I'm just thinking up ways around it. Using the blitter to scroll each layer.

That slows hugely everything down. Anyway, if the programmer doesn't (need to) care about the frame rate, MLS doesn't stop him from using the Blitter.

Quote:
BTW, when AGA came out I recall these simple demos. They used to display digitsed pictures and fade between them. It was one of the cool effects AGA could do. Well I only noticed it being done on AGA. I always wondered how it was done. Does MLS use a simlar technique?

Cross-fading is possible also on OCS/ECS, it's just that there are less colors available and the color resolution is inferior. And yes, it's exactly the same effect: calculating the palette so that the colors "mix".

 Status: Offline
Profile     Report this post  
_Steve_ 
Re: MLS, a new graphics system
Posted on 28-Jul-2020 18:04:21
#45 ]
Team Member
Joined: 18-Oct-2002
Posts: 6768
From: UK

@ppcamiga1

Quote:

ppcamiga1 wrote:
@saimo

AMOS never was fast enough on original hardware.
For games and demos You have to have something better.


That is your opinion, and you are entitled to it. I am sure many others would disagree with that sentiment. It was used in some commercial games, and some PD ones as well as a few demos (Syntex made several of note - and yes I am aware that several of those integrated ASM code into AMOS to help speed things along).

Quote:
Quote:

I'm doing what I'm doing because of what explained in the opening post, i.e. personal fun/satisfaction in AMOS Professional.


Thats ok.
I hope nobody else use it.


Again your opinion. Not everybody has the ability to learn or make something useful in other high or low level languages (be that C, C++, E, asm). If someone wanted to use the engine to make something that is their choice. You don't have to download or play around with it.

Quote:

Nobody made worth playing game in it, in last thirty years.


Again - that is your opinion, and there will be many others who disagree. Valhalla and Jetstrike / Jetstrike AGA didn't do too badly considering they were made in AMOS, and they didn't play too badly on original hardware.

There is no need to be so harsh towards this project from Saimo just because you see no merit or use from it.

_________________
Test sig

 Status: Offline
Profile     Report this post  
Hypex 
Re: MLS, a new graphics system
Posted on 1-Aug-2020 17:14:27
#46 ]
Elite Member
Joined: 6-May-2007
Posts: 9977
From: Greensborough, Australia

@saimo

Quote:
1 bitplane less = half the number of colors available -> most of the times, not worth it (especially OCS/ECS). MLS is layers-oriented, so it makes little sense to sacrifice layers for sprites. For the moment being, they're out.


Ah ok, yes can cause damage to the pallette. Well, apparently the Atari ST had no sprites, so it isn't always needed. They went from an 80's stable to a decline towards the 90's.

Quote:
16 pixels is too coarse a resolution: it causes scrolling to be way too jumpy and/or too fast. On AGA, to benefit from the 4x fetch mode, that's even worse: 64 pixels.


Ouch. That would be no good. Not much can be done there.

Quote:
That slows hugely everything down. Anyway, if the programmer doesn't (need to) care about the frame rate, MLS doesn't stop him from using the Blitter.


It would for a whole screen. I typed is some ASM code from an Abacus book that demonstrated a scrolling blitter plane. It was fast and smooth on my A500. For ECS, with six planes and two hardware scrolling, four would need blitter scrolling. For AGA with 8 planes, six would need it. Fully independent planes, depth 8, AGA would need 8 whole screen blits. That could get slow.

But with parallax, not all planes would need to scroll at once, at the same speed. The fastest planes would use the scroll position registers, using the odd and even positions, if they can be used outside of dual playfield mode. Then it would go down the line, the next fastest being blittted, to the slowest in turn. Taking into account hardware positions.

A repeating pattern could speed it up. It could also be a whole screen across or two. Best would be a pattern of limited lines. Likely copper would be needed for modulo control and possibly switching bitmap patterns, so bitmap is a smaller block, but repeated on display. Another idea, is using prerendered scroll bitmaps, to simulate scrolling. Speed at the expense of space.

Quote:
Cross-fading is possible also on OCS/ECS, it's just that there are less colors available and the color resolution is inferior. And yes, it's exactly the same effect: calculating the palette so that the colors "mix".


It was hard to tell if it was HAM or another trick. Dual playifeld could do it with a copper list. I don't know what mode they used.

 Status: Offline
Profile     Report this post  
saimo 
Re: MLS, a new graphics system
Posted on 1-Aug-2020 17:57:42
#47 ]
Elite Member
Joined: 11-Mar-2003
Posts: 2303
From: Unknown

@Hypex

Quote:
Quote:
That slows hugely everything down. Anyway, if the programmer doesn't (need to) care about the frame rate, MLS doesn't stop him from using the Blitter.


It would for a whole screen. I typed is some ASM code from an Abacus book that demonstrated a scrolling blitter plane. It was fast and smooth on my A500. For ECS, with six planes and two hardware scrolling, four would need blitter scrolling. For AGA with 8 planes, six would need it. Fully independent planes, depth 8, AGA would need 8 whole screen blits. That could get slow.

But with parallax, not all planes would need to scroll at once, at the same speed. The fastest planes would use the scroll position registers, using the odd and even positions, if they can be used outside of dual playfield mode. Then it would go down the line, the next fastest being blittted, to the slowest in turn. Taking into account hardware positions.

Even blitting a single plane eats a lot bus cycles, especially on OCS/ECS machines. It's a huge expense. Again, if that fits the program's timing, the programmer is free to use that solution.

Quote:
A repeating pattern could speed it up. It could also be a whole screen across or two. Best would be a pattern of limited lines. Likely copper would be needed for modulo control and possibly switching bitmap patterns, so bitmap is a smaller block, but repeated on display.

The Copper can't help overcome the fact that the modulo registers must be the same for all bitplanes.

Quote:
Another idea, is using prerendered scroll bitmaps, to simulate scrolling. Speed at the expense of space.

Yes, but that, except for very special cases, it's just too unpractical.

Quote:
Quote:
Cross-fading is possible also on OCS/ECS, it's just that there are less colors available and the color resolution is inferior. And yes, it's exactly the same effect: calculating the palette so that the colors "mix".


It was hard to tell if it was HAM or another trick. Dual playifeld could do it with a copper list. I don't know what mode they used.

No HAM: again, it's just a matter of calculating the palette. The Dual Playfield does not help and, actually, would make the effect impossible (if one needs all the bitplanes, that is). The Copper isn't strictly necessary and, actually, it would make the CHIP bus busier and thus slow everything down (the advantage of using the Copper is that it frees the CPU from synchronizing with the raster beam, but in some cases it's best to do things with the CPU).

 Status: Offline
Profile     Report this post  
Hypex 
Re: MLS, a new graphics system
Posted on 2-Aug-2020 17:21:17
#48 ]
Elite Member
Joined: 6-May-2007
Posts: 9977
From: Greensborough, Australia

@saimo

Quote:
Even blitting a single plane eats a lot bus cycles, especially on OCS/ECS machines. It's a huge expense. Again, if that fits the program's timing, the programmer is free to use that solution.


I suppose it comes down to what works in the given limitations. The CPU could also be used but that would be rather inefficient. And real classic Amiga games didn't spend time redrawing the whole screen.

Quote:
The Copper can't help overcome the fact that the modulo registers must be the same for all bitplanes.


No, so they would need to be linked up.

Quote:
Yes, but that, except for very special cases, it's just too unpractical.


It could be. Given the data is in effect shifted across between each frame, it would be somewhat redundant. The only reason I can think to really use it is to generate a 3d scrolling effect on a graphic block. Basically animating a graphic really. So it looks more realisitic.

Quote:
No HAM: again, it's just a matter of calculating the palette. The Dual Playfield does not help and, actually, would make the effect impossible (if one needs all the bitplanes, that is). The Copper isn't strictly necessary and, actually, it would make the CHIP bus busier and thus slow everything down (the advantage of using the Copper is that it frees the CPU from synchronizing with the raster beam, but in some cases it's best to do things with the CPU).


Okay, but how do you fade between two different images by just calculating a palette? They would have had to be using at least 8-bit depth. Since they were fading from one real picture to another. It needed lots of colours to begin with.

 Status: Offline
Profile     Report this post  
saimo 
Re: MLS, a new graphics system
Posted on 2-Aug-2020 17:37:17
#49 ]
Elite Member
Joined: 11-Mar-2003
Posts: 2303
From: Unknown

@Hypex

Quote:
It could be. Given the data is in effect shifted across between each frame, it would be somewhat redundant. The only reason I can think to really use it is to generate a 3d scrolling effect on a graphic block. Basically animating a graphic really. So it looks more realisitic.

Unless I misunderstood, your initial idea was having prerendered frames to simulate scrolling by simply changing the planes pointers, right? So, yes, it's simply an animation. As such, the animation can be used for just about everything (memory constraints aside). For example, think of the tunnel sections in (Super) Stardust.

Quote:
Okay, but how do you fade between two different images by just calculating a palette? They would have had to be using at least 8-bit depth. Since they were fading from one real picture to another. It needed lots of colours to begin with.

You put a picture on a given number of planes, then the other picture on the remaining planes, and recalculate the values to write to the COLORxx registers according to the pictures palettes and the degree of opacity of the front picture. Executing the effect boils down to changing the opacity from 100% to 0% while recalculating the palette at each step.
(Sorry, I can't go into the details because I just don't have the time to.)

Last edited by saimo on 02-Aug-2020 at 05:37 PM.

 Status: Offline
Profile     Report this post  
Georg 
Re: MLS, a new graphics system
Posted on 3-Aug-2020 8:06:33
#50 ]
Regular Member
Joined: 14-May-2003
Posts: 442
From: Unknown

@saimo

Horizontal scrolling: certain kind of backgrounds can be scrolled smoothly even if from hw side you only have possibility to set it's start in 16 pixel steps. Think of the background layer in Amiga game "Rock n Roll". If the gfx used 17x17 pixel sized pattern instead of 16x16 then depending on which start address for the planes you set, you get different horizontal shifting. So you would have a single extra wide stripe (~ (320+16*16) width x 17 pixel height) in memory and set plane pointer to (plane + (viewx % 17) * 2).


1234567890ABCDEFG1234567890ABCDEFG1234567890ABCDEFG1234567890ABCDEFG1234567890ABCDEFG
^...............^...............^...............^...............^...............^....

 Status: Offline
Profile     Report this post  
saimo 
Re: MLS, a new graphics system
Posted on 3-Aug-2020 12:19:22
#51 ]
Elite Member
Joined: 11-Mar-2003
Posts: 2303
From: Unknown

@Georg

Quote:
Horizontal scrolling: certain kind of backgrounds can be scrolled smoothly even if from hw side you only have possibility to set it's start in 16 pixel steps. Think of the background layer in Amiga game "Rock n Roll". If the gfx used 17x17 pixel sized pattern instead of 16x16 then depending on which start address for the planes you set, you get different horizontal shifting. So you would have a single extra wide stripe (~ (320+16*16) width x 17 pixel height) in memory and set plane pointer to (plane + (viewx % 17) * 2).


1234567890ABCDEFG1234567890ABCDEFG1234567890ABCDEFG1234567890ABCDEFG1234567890ABCDEFG
^...............^...............^...............^...............^...............^....

That's true, but those are very specific cases, but maybe they are not worth the extra clutter in the code. I mean, at the moment there is just a single procedure that sets the X offset for all the layers. If I were to allow per-layer offsets, there should be (also) a procedure that sets the fine X offset (0 ... 15|63) for all the layers, and a procedure for the coarse X offsets (0, 16|64, 32|128, ...) for each layer: that would be quite uncomfortable (especially for the less expert programmers); alternatively, the single procedure could be changed to affect the fine X offset globally and the coarse X offset on a per-layer basis, but this could be again confusing for the less expert programmers. On top of everything, handling per-layer X offsets has also a little impact on performance, as a vector of values needs a bit more computing than a single value - but it's a marginal performance hit, indeed.
I'm not sure whether to add this feature. I have to ponder on it.

 Status: Offline
Profile     Report this post  
Hypex 
Re: MLS, a new graphics system
Posted on 4-Aug-2020 16:40:15
#52 ]
Elite Member
Joined: 6-May-2007
Posts: 9977
From: Greensborough, Australia

@saimo

Quote:
Unless I misunderstood, your initial idea was having prerendered frames to simulate scrolling by simply changing the planes pointers, right? So, yes, it's simply an animation. As such, the animation can be used for just about everything (memory constraints aside). For example, think of the tunnel sections in (Super) Stardust.


Yes, you understood fine, that was the idea. I was just thinking, if some kind of scrolling was to be effected by animating in place, might as well think outside the box and use it for extra effect. So I thought an animated 3d panned image would look good. Like the old 3d copper effect, but with more depth, and chip ram of course.

Quote:
You put a picture on a given number of planes, then the other picture on the remaining planes, and recalculate the values to write to the COLORxx registers according to the pictures palettes and the degree of opacity of the front picture. Executing the effect boils down to changing the opacity from 100% to 0% while recalculating the palette at each step.


That sounds reasonable. I just didn't know how it was done, with a limited palette, where both images look like real HAM images. I'm going from memory so might not have looked as good as I remember.

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

[ 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