@Fl@sh

Quote:

Hi Simone, as said in another forum your engine looks very promising ad optimized.

Thanks.
Optimized... well, relatively speaking, yes. But, of course, a really performing system would have to be written in assembly.

Quote:

I don't know if will be ever possibile to make a 2nd version using chunky logic for RTG systems

I don't have any technical knowledge of RTG on Amiga, but I'd be very surprised if Picasso96/Cybergraphics/whatever don't offer functions for blitting with alpha channel: with that, simulating multiple layers is trivial; and even without it's easy to write those functions for one's own needs anyway.
EDIT (forgot the conclusion): hence, it's pointless to use AMOS+MLS on RTG to implement layers.

Quote:

maybe something like it will be more future proof.

Why, is AMOS stuff not future proof? AMOS stuff is made for classic Amigas, and classic Amigas (and emulators) won't suddenly disappear and leave their users without their AMOS stuff ;)

Quote:

About AMOS development maybe some dev could "call" another and say "Hey we are developing same thing.. why not join forces and make one project where compatibility is main goal?" In this way anyone could develop new stuff targeting for classics and/or NG, without loose compatibility.

As I tried to explain already, there are different people doing different things for different reasons, and (partial) compatibility is the objective of only one of them. That's just fine.
Also, when it comes to games, compatibility between classic and NG Amigas is rather a problem than an advantage: the two platforms are intrinsically different, so compatibility can be obtained only at the (huge) price of sacrificing something. What's the point? Classic games can be played on classic hardware and, thanks to UAE, on a decent range of modern platforms, so it's best to let them exploit the classic hardware as much as possible.

Last edited by saimo on 17-Jul-2020 at 08:15 PM.

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

@OlafS25

Thank you!


@IridiumFX

Quote:

I have just watched the video. Awesome. Thanks for your hard work Just a question about the tech capabilities which I could not totally get. Can you have n "layers" of arbitrary depth or once you decide a depth is the same for all of them ?

Thank you!

Short answer: no.

Long answer: the layers do not need to have the same depth. The restrictions are:
· maximum number of defineable layers: 8
· maximum number of planes for a layer: 6
· maximum number of visible layers: OCS/ECS, HIRES mode: 4; OCS/ECS, LORES mode: 6; AGA, any mode: 8

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

@saimo

ok, that's for the maximum limits which, for an AGA machine, would disclose endless possibilities.
But could I have, let's say, an AGA machine rendering 5 layers of these depths?
layer-1: 4 bits;
layer-2: 2 bits;
layer-3: 6 bits;
layer-4: 6 bits;
layer-5: 4 bits;

4 layers, at most 6 bits, all 5 visible since AGA ?

thanks

@IridiumFX

Quote:

ok, that's for the maximum limits which, for an AGA machine, would disclose endless possibilities. But could I have, let's say, an AGA machine rendering 5 layers of these depths? layer-1: 4 bits; layer-2: 2 bits; layer-3: 6 bits; layer-4: 6 bits; layer-5: 4 bits; 4 layers, at most 6 bits, all 5 visible since AGA ? thanks

Nope, that's far beyond the AGA capabilities. The total depth can be at most 8 on AGA (and 6 on OCS/ECS).
For example, the demo in the video uses these depths from the backmost to the frontmost layer: 2 2 2 1 1.

EDIT: clarified this in the opening post; thanks for the question!

Last edited by saimo on 17-Jul-2020 at 06:31 PM.

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

@Fl@sh
Quote:

I don't know if will be ever possibile to make a 2nd version using chunky logic for RTG systems, maybe something like it will be more future proof.

Maybe, but comes with a cost if it has to be done by the CPU, it tried implement quasi-solution to planar emulation in of one of my projects kind of successful, but not perfect.

I had two projects where the quasi-solution done two ways.

“chunky_plains” did masking and shifting on etch pixel write.

(Some things I should say this was in P96 I’m sure wrote directly to video memory. This might not be ideal.)

“chunky_plains2” used 8 buffers and mixed the result after, you drawn it.

Etch technique had their own issues, mostly it costed CPU speed one way or the other. I did not even try rearrange bits.

So yes sure, maybe but comes at a cost.

In my judgment “chunk_plains” worked OK, but I did not want the automatic masking for retroMode library, as it was costly. What I ended up where set of simple pixel plot command for XOR, AND & OR logical operations, this can produce affects you most commonly associate with planar graphics, but I do not have individual buffers, and do not try mix layers, you set a palette as you normally did.

Yes you do some effects with alpha blending, I do not know you actually emulate color palette with it. I suggest figuring out how to make GPU shader, to convert picture from one format into another, not sure how, but should be possible somehow.

Full UAE graphic emulation will most likely kill all the fun.

Last edited by NutsAboutAmiga on 17-Jul-2020 at 09:22 PM.
Last edited by NutsAboutAmiga on 17-Jul-2020 at 08:15 PM.

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

VIDEO PREVIEW #2

This second preview shows 3 layers scrolling horizontally and vertically, while the resolution cycles continuously from LORES to HIRES to SHRES. More precisely, the background layer scrolls horizontally only, whereas the middle and foreground layers scroll both horizontally and vertically.

The sharp-eyed viewers will have surely noticed that, vertically, the layers scroll indipendently from one another, but horizontally they scroll together: that's due to an unfortunate limitation of the Amiga hardware.
(Note: the only way to overcome such limitation is to restrict the layers number to just 2, basically obtaining a "super" dual playfield which, in addition to the standard dual playfield, provides alpha values for layers and colors; however, implementing such special case in MLS would complicate code beyond what I find pleasant and recommendable, so I'll leave that for a future project.)

Notes about the layers:
* background layer: 32 solid colors;
* middle layer: 3 partially transparent color + 1 transparent color;
* foreground layer: 1 partially transparent color + 1 transparent color.

P.S. While writing a little game to test MLS, I convinced myself more than ever that sprites, in this system, are just too unpractical, so I decided to put their implementation on hold. At the same time, I decided that, after all, horizontal scrolling should definitely be implemented, despite the aforementioned hardware limitation. I have updated the specifications in the opening post accordingly.

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

@saimo

Surely emulated machines would have an upper limit beyond Classic base rates.
Eg RaspPie Amos

Why can we not have n layers ? can we not switch memory banks into virtual layers ?

Also I like the Amos developments, I do see potential :

Seperation of Amos Engine /compiler + IDE - so anyone can create a new IDE in future.

Compile on Linux or Windows using IDE of choice etc.

I do hate the CAPS ONLY variables in Amos, I wish it was CamelCase.

Does Amos have AVI capture / record ?

Great work indeed.

_________________
Download 499.26 Mbps, 659.94 Mbps Upload :)

@asymetrix

Quote:

Surely emulated machines would have an upper limit beyond Classic base rates. Eg RaspPie Amos

If one needs more power than what classic Amigas offer, he/she shouldn't go for classic Amigas in first place

Quote:

Why can we not have n layers ? can we not switch memory banks into virtual layers ?

There are two restrictions:
* number of defined layers: 8;
* number of visible layers: 6 on OCS/ECS, 8 and AGA.

The first restriction is due to the fact that MLS turns AMOS screens into layers and AMOS only allows to create at most 8 screens. The layers must be screens because that way it is possible to render bobs, icons, texts, etc. on them normally. Therefore, banks can't be turned into layers. However, there isn't much use in having more than 8 layers, given the second restriction.
The second restriction is given by the maximum number of bitplanes allows by the hardware: when each layer consists of just 1 bitplane, the number of layers coincides with the number of bitplanes.

Quote:

Also I like the Amos developments, I do see potential : Seperation of Amos Engine /compiler + IDE - so anyone can create a new IDE in future. Compile on Linux or Windows using IDE of choice etc. I do hate the CAPS ONLY variables in Amos, I wish it was CamelCase.

All of this is out of the scope of MLS (MLS only intends to be a library of procedures that let developers have fun with layers while keeping on using AMOS as always) so please excuse me if I don't discuss your points.
Just a little piece of information, though: actually the IDE and the compiler are already separated.

Quote:

Does Amos have AVI capture / record ?

Nope.

Quote:

Great work indeed.

Thank you

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

@saimo

Quote:

Also, when it comes to games, compatibility between classic and NG Amigas is rather a problem than an advantage: the two platforms are intrinsically different, so compatibility can be obtained only at the (huge) price of sacrificing something.

But do we need something that will be incompatible and still not worth of use?
AMOS was released thirty years ago.
developers who use AMOS never ever made any worth playing game for Amiga.
It was always either too slow for real classic hardware either has too crappy graphics.
It is better to leave original AMOS as it is and use it for what it was designed.
AMOS is very nice BASIC for beginners.
It is also nice tool to quick made some simple software.
It is cool that it may be used on RTG by Amos Kiitens.

games for classic it is better to use c or asm.

Last edited by ppcamiga1 on 22-Jul-2020 at 02:59 PM.

@ppcamiga1

Quote:

games for classic it is better to use c or asm.

Or Blitz Basic 2 / AmiBlitz!

_________________
"Art challenges technology. Technology inspires the art."
John Lasseter, Co-Founder of Pixar Animation Studios

@ppcamiga1

Quote:

But do we need something that will be incompatible and still not worth of use?

To begin with, I don't care about compatibility with non-native Amiga systems: I'm doing what I'm doing because of what explained in the opening post, i.e. personal fun/satisfaction in AMOS Professional.
That aside, whatever (if anything) will be made with AMOS+MLS:
* will be compatible with classic Amigas, so users of such systems will be happy to have something more to try;
* will be worth using if the overall result is valid, which depends on many more factors other than the programming language.

Quote:

AMOS was released thirty years ago. developers who use AMOS never ever made any worth playing game for Amiga. It was always either too slow for real classic hardware either has too crappy graphics.

While AMOS is certainly limited, the quality of products made with it depends on the authors. Knowledgeable hands can do marvels also with AMOS.
Also, it isn't true that no AMOS game is worth playing: besides being a subjective matter, there are games which are objectively well done (first example that comes to mind: Breed96)

Quote:

It is better to leave original AMOS as it is and use it for what it was designed. AMOS is very nice BASIC for beginners. It is also nice tool to quick made some simple software.

AMOS was designed to create stuff without deep knowledge of the Amiga. Check out the covers of the boxes:





Here I'm exactly using it do to what it was designed for

Quote:

games for classic it is better to use c or asm.

It depends on the kind of game and on the objectives, preferences and skills of the author(s).

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

@ppcamiga1

There are few games I think are impressive

https://www.youtube.com/watch?v=K5dOTx_JIwA

https://www.youtube.com/watch?v=uSRhuwa2wmw

Amos Pro / Turbo Plus game

https://www.youtube.com/watch?v=Os0lKwL6J0A

DreamWeb

http://hol.abime.net/431

Vulcan

Valhalla

http://amigacoding.com/index.php?title=AMOS:CreatedWithAMOS

Last edited by NutsAboutAmiga on 22-Jul-2020 at 04:46 PM.
Last edited by NutsAboutAmiga on 22-Jul-2020 at 04:42 PM.

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

@ppcamiga1

Quote:

still not worth of use? AMOS was released thirty years ago.

It covers pretty much all it has too, expect network support, XML, and JSON.

It can technicality be developed into direction for making programs and apps, if its easy to use for beginners then its easy to use for experts.

Yes, their things experts are use to that you do not have in AMOS, And things that be backwards to do in AMOS, but then again its about finding the right tool for the job.

Don’t try to use a hammer to as screw driver.

There lots developer who writes phyton scripts, not because they don't know how to write C code, but because C is not required.

Last edited by NutsAboutAmiga on 22-Jul-2020 at 10:33 PM.
Last edited by NutsAboutAmiga on 22-Jul-2020 at 10:32 PM.
Last edited by NutsAboutAmiga on 22-Jul-2020 at 10:31 PM.

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

@saimo

Quote:

To begin with, I don't care about compatibility with non-native Amiga systems:

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

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.

Quote:

While AMOS is certainly limited, the quality of products made with it depends on the authors.

Quote:

It depends on the kind of game and on the objectives, preferences and skills of the author(s).

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

@NutsAboutAmiga

Quote:

https://www.youtube.com/watch?v=K5dOTx_JIwA

Very good graphics, on uae it is cool game on real hardware too slow.

Quote:

https://www.youtube.com/watch?v=uSRhuwa2wmw

Quote:

https://www.youtube.com/watch?v=Os0lKwL6J0A

This is what I wrote fast enough but poor quality graphics.

@NutsAboutAmiga

AMOS is nice BASIC for beginers and nice tool for quick made simple software.
There is no reasons to made not compatible extension while it will be still to slow for games and demos.

@saimo

I'm still trying to get my head about it. At first I thought the layers were bitplanes that were intelligently managed to act as seperate layers. But the layers can be made of planes. Now I'm lost. No sprites. Are the sprites also acting as layers?

Suppose planes could be locked together for scrolling, even and odd. For a strange dual playfield effect. The blitter may be too slow to scroll layers independently. But it would be in hardware with layer being one blit operation.

I can't imagine losing that work. Even knowing what you did. It would be tedious to rewrite it for memory. I would compare it to a lost forum post, story or sound module. You can try to recreate what was lost but I find it's never the same, it lacks that edge of being in the moment, and if the moment is lost I find the inspiration is as well.

@Hypex

Quote:

I'm still trying to get my head about it. At first I thought the layers were bitplanes that were intelligently managed to act as seperate layers. But the layers can be made of planes. Now I'm lost. No sprites. Are the sprites also acting as layers?

When I write "planes" I mean "bitplanes". Just shortening for convenience So, yes, the layers are made of bitplanes.
Sprites are not used as layers because it is not possible to have partial transparency with them.
Also (quoting a little piece of text from the manual, because at the moment I'm exhausted) they have been put aside because it is very hard or even impossible to draw and use them in conjuction with layers. In fact, it is natural to use all the planes available to have as many layers and colors as possible; consequently, all the color registers are set automatically as needed by the layers; given that the hardware assigns some of those registers also to the sprites according to a very limiting scheme, it is not possible to set the sprites colors freely. 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.
That said, it is technically possible to add sprites support. If that happens, the features will be as follows.

OCS/ECS/AGA:
· 3- and 15-color sprites
· LORES 16-pixel wide sprites
· selectable sprites-planes priority

AGA:
· SHRES resolution sprites
· SHRES sprites horizontal positioning
· 32- and 64-pixel wide sprites
· selectable sprites color bank
· sprites in border

Quote:

Suppose planes could be locked together for scrolling, even and odd. For a strange dual playfield effect.

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

The sharp-eyed viewers will have surely noticed that, vertically, the layers scroll indipendently from one another, but horizontally they scroll together: that's due to an unfortunate limitation of the Amiga hardware.
(Note: the only way to overcome such limitation is to restrict the layers number to just 2, basically obtaining a "super" dual playfield which, in addition to the standard dual playfield, provides alpha values for layers and colors; however, implementing such special case in MLS would complicate code beyond what I find pleasant and recommendable, so I'll leave that for a future project.)

Quote:

The blitter may be too slow to scroll layers independently. But it would be in hardware with layer being one blit operation.

MLS doesn't use the Blitter.

Quote:

I can't imagine losing that work. Even knowing what you did. It would be tedious to rewrite it for memory. I would compare it to a lost forum post, story or sound module. You can try to recreate what was lost but I find it's never the same, it lacks that edge of being in the moment, and if the moment is lost I find the inspiration is as well.

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.

Last edited by saimo on 24-Jul-2020 at 09:54 PM.
Last edited by saimo on 24-Jul-2020 at 09:53 PM.
Last edited by saimo on 24-Jul-2020 at 09:48 PM.

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

@saimo

I was thinking maybe to add rtg support you could add another Last step and copy everything In 8bit gfx memory for a fast rendering with a writechuckypixel function.
Instead of bitplanes or as you call them layers all previous passages can be done allocating simple memory areas. In this way you could adapt your engine for rtg screens in a fast way.

My2cents.

_________________
Pegasos II G4@1GHz 2GB Radeon 9250 256MB
AmigaOS4.1 fe - MorphOS - Debian 9 Jessie

@Fl@sh

Quote:

I was thinking maybe to add rtg support you could add another Last step and copy everything In 8bit gfx memory for a fast rendering with a writechuckypixel function. Instead of bitplanes or as you call them layers all previous passages can be done allocating simple memory areas. In this way you could adapt your engine for rtg screens in a fast way. My2cents.

See, the point is that MLS is a little product for development of classic stuff, with a classic language, for classic machines. Even more importantly, it is made to exploit the core nature of the classic hardware. RTG is out of the scope, it's a different world, and in that world there are other and better ways to achieve similar results.

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