Demos using a GFX mode please !

[Crumb]

@darkcoder&carls
There's no difference between the way coders make demos for AGA and RTG these days... most of the demo is 3D stuff, and the only thing the coder does with AGA is a chunky2planar, and that's all. So the simplest way to add RTG support is to copy that chunkybuffer to the gfx ram. The first method unexperienced coders will use will be WritePixelArray()... but that's quite slow (but usually faster than AGA). If the coder has a clue about RTG coding he will get the address of the screen as MagicSN has described and write directly to the graphic mem, boosting the speed. I do a trick that sometimes speeds up quite a lot some effects, I use a 32 bit to store the 4 8bit pixels I'm going to write and I put pixels in that variable until it has the 4 pixels, then I copy it to the gfx ram, as I only do one access to write a 32bit number instead of writing 4 times, the speed is higher. Yes, that works (at least with rotozooms), and it's fast.

But what's the point in forcing my friends with a 2060/CV3D to sell their equipment to see AGA demos if I can make them compatible with both really easily?
I don't care if it's a bit slower or faster, that's not going to change the quality of the production. Some people may say ooohh but it's designed for AGA+060... so what? some 040/40 users try to run 060 demos, they run slowly but they are happier than if the code was 060 only and they couldn't watch the demo at all. And I have an A4060 with a picasso4, why can't I see the effects more smoothly if my computer can really do it?
 If you don't want to do tricks like storing 4 pixels in a variable, there's no problem, just write to the gfx ram instead of your fast-ram chunkybuffer.
Ummm one, note, the only OS functions you will use will be those used to get the address of the gfx ram and ScrollVPort for the double buffer. That's all. I think that those demos still will be amazing stuff. The demo can be designed/optimized for AGA but at least it should run in RTG hardware.
Mankind for example does that with some of their productions and they run in 68k and are RTG compatible.
Just my thoughts...

ummm yes, if you are a bit lazy the group Mankind has uploaded their init&c2p code to aminet (it supports RTG and AGA) I can't remember the name of the archive... :-( you'll have to search a little :-/

[Crumb]

Ummm what I have said also applies to sound... demos should be Paula AND AHI compatible...

[Crumb]

@Darkcoder:
> First of all I don't understand why you (and also Elwood who started this post) want to force people do what you want.

No one is forcing you with a gun to add support, we are expressing our opinions. In my opinion the effort needed to add RTG support is so small that it is a pity that it's not included in most of demos. (that sounds better for you ummm? as english is not my native language I didn't want to make it sound like "everyone should code rtg-compatible stuff or be executed". I mean that it's a good idea because it requires very little effort)

>I am sure that you are all nice guys but
you sound a little bit arrogant.

well, now read again the first lines of your first post in this thread.

You say that demos are not made to impress. Well they are made for fun and to impress. Isn't impressive to see how much can be done with little resources? And one of many people all-time-favourites, State of the Art was designed to impress, not showing the machine limits but a great design. I think that SOTA only moves a little polys most of times and that a A500 can do that without many problems (World Of Commodore for example was made to impress with its code more than its design, for example the rotozoom of the horned demon head is quite impressive for an A500)

You say that you don't know where are the limits. One of the limits is the bandwitch to the graphic card. As Carl has said in his system it's slower than AGA in most of programs, well the Zorro2 bandwitch is a limit, isn't it? As the Zorro3 is (you won't get more speed of pci cards with mediator or prometheus because it goes through the zorro3 bus). But for example most of things (eg games) are faster using Zorro3 cards than AGA.

With 68k systems the main limit from my point of view is the raw cpu power. Of course, the bandwitch to fast ram and to gfx ram are big bottle necks. But now demos are mostly 3D and that needs raw cpu power. For example ppc games like quake run a lot faster even thought that they are using AGA. With AGA and a good c2p you can put 25fps at 320x200 without too much effort. The problem is the 3D stuff you want to show. Some demos run almost equally with AGA or gfx cards because the cpu is the biggest limit now.

>What you call "a simple copying of data into a screen" is crucial for the speed of the demo. And it
differs from one board to another. I don't think that you would obtain the same speed and the same visual apperence from a PicassoIV and a Radeon 7000. What RTG is missing, is *a clear limit*. Without a clear limit you cannot reach the limit.

well, the little tests I've done run at more or less the same frame rates in every graphic card. I've tested with my program a 060 my Picasso4, a Voodoo5 and a CV64. The fastest of the three was the CV64 because it uses Zorro3 to the limit. But it was only slighly faster. The clear limit for AGA and RTG stuff is (90% of times) the CPU. Well I haven't tried a CybervisionPPC, in theory it should be the fastest (but only slightly)

What I call simply copying is that: simple copying. Your graphics will look the same in a Ateo Pixel 64, in a CV3D, a CV64, a Picasso4, a Voodoo3 if you use a 8bit screen. With >8bit ones you will need to check the screenmode to see if its RGB BGR or whatever.

 I admit that with 16bits it is more complicated. But many AGA demos only use 8bit. And it's easy to support.

I repeat that no one is ordering you anything, just saying that adding RTG support is quite easy. But that not implies that RTG coding is done with functions (if you use functions it will be faster than AGA but not as fast as it can be)

don't get upset so easy

I have fun coding RTG stuff, the only reason I'm adding AGA supportis for erm tradition, compatibility and well, because it's easy and I can, and some people still don't have a gfx card and I found a bit arbitrary to stopping them from watching what I want to do. I mean that it's easy if you use a chunkybuffer and a c2p routine (like me) because sprites and bitplanes aren't used much these days. If you do demos that use bitplanes etc... well that's harder than a gfx card for most of effects.

DISCLAIMER: I've only expressed my opinion, people who don't agree MUST NOT be fussilated ;-D

[Crumb]

While am coding an effect, my only concern is enjoy myself doing something
difficult and proving to myself that I can solve the problems. I don't think to
people's reaction when they see my demos.

Of course, I agree with you in this: I code for fun. If it wasn't funny I wouldn't do it, but what people thinks about a production is important (although not as important as the fun I have coding). For example in the last Euskal Party I may have been the second in the intro compo because only one intro was going to be presented. But I only had a rotozoom and some plasma with no music and I thought that althought I had fun doing the code, it had not the quality to be presented. The effects are quite optimized (although they are in C) but showing two effects with no music sounds pretty crap for me. My AGA support was crap (I used WritePixelArray) because I couldn't mix asm with my code then. Now I'm adding an asm c2p (but it's done by Azure). I hope someday I show something of quality. But now I'm learning and I still can't.

that "more or less"is not satisfactory to me. The "simple copying" of data is
often done using the gfx card blitter, wich is not accessible to the coder.

The simple copying of data is done by the cpu in 3D demos as people does when they copy their c2p buffer from fastram to chip memory.

When you copy data from the fastram (or you write it directly to the gfx ram) you do it at maximum speed if you have coded it correctly. If I write a 32bit word to gfx ram that is going to run at the maximum speed regardless of if it is running in Zorro3/PCI/AGP.
Ok I think there are some special transfermodes for AGPs but they are only used by the card to take textures from fastram when it has its memory full. That doesn't help if I'm writing pixels directly.

With AGA I can decide wich resolution and which refresh rate I
want to use. Gfx board allows each different resolution and rates, hence I
cannot reach their limit.

With a gfx card you can force it to run at one resolution, you may force it to only use one refresh rate, but it's better to read the frecuenzy of the screen and use that value for the maximum fps. That way you will achieve the limit.

You can use blitter functions for RTG if you want, but most of people don't use them because most of demos are 3D and don't use special custom chip magic ;-D

I respect a lot coders (like you) who still get the max of the chipset. I understand you when you say that you aren't going to support RTG because you use AGA to the max. That's very reasonable because making it work with RTG would be a lot of work.

But I think that you should agree with some of us when we say that with 3D demos it's very easy to add RTG support. When you do 3D stuff and you do a function that uses your cpu at 100% you will get little speedup using RTG. You will have reached the maximum speed because the bottleneck is the cpu.
And if the zorro2 bus has less bandwitch you will have reached the max speed still, because it will not be possible to get more speed.

A1 and Peggies and PC with emulators have PCI and AGP cards. I guess in
some months we will see programs (maybe demos) requiring DE FACTO AGP cards.
This is good for Amiga in general, but not for demo scene

That will not change my point in any way, because a 68k version of that demo still will use the bus to the maximum. You don't do different code for cards with different buses, you code them in a similar way pc users did in MS-DOS, you get the address of the screen and you have almost full control. You have the added bonus of being able to use RTG functions like they do with DirectX, so you have the good things of both worlds.

Moreover, I heard (but maybe I am wrong) that there are 2 different RTG standrd,
the Picasso96 and the CyberGfx. So one should even support 2 different
standards?

no, you don't have to add support for both if you don't want. Picasso96 is CyberGraphX compatible, so you can get the address of the screen with CGX only if you want. I have support for both but I don't see any speedup so supporting CGX will be more than enough.

So with AGA I can do BOTH CPU-only chunky effects AND chipset supported funny
tricks. And you can join these techniques together.

Ok, as I have said I agree with you in not supporting RTG if you use special AGA features like the copper etc... but most of demos are 3D only these days.

(BTW, how many of these "new
generation coders" are able to proper initialize audio state machine to begin
audio output?)

I don't know but "new generation demos" work a lot better in every machine that "old generation demos". I don't have any problem with audio initialization with 99% of modern demos. That can not be said of old demos.

I have an A4000 and some people didn't support us in the old times, so it's funny to read that. The "new generation coders" support everything. That's fine for me.

With RTG, instead I can only do one sort of effects. I think the
real progress is not the contraposition of old and new, but rather a synthesis of
old (in this case coding techinques) and new.

You can do every kind of effects but you will have to use the cpu and gfx card blitter instead of AGA. You loose the copper, that's right. :-/

Sometimes you have to use different techniques with AGA and RTG, RTG effects sometimes are more difficult (for example with a selected palette it's easier to simulate transparency with AGA using bitplanes, but you will have to work hard to make it moove smoothly with RTG) It's fun because you are also limited. :-)

When I see a 3D only demo I only think: Umm they may have done it RTG compatible, that would have made it run smoother. For example Loonies did a great job with "The Castle" supporting both AGA and RTG.

Talk to coders that do stuff for both AGA and RTG and you will see that if your demo is 3D only, they way the code looks is similar and you reach the maximum speed of the machine.

Anyway, keep on milking the power of AGA :-)
I love to see AGA prods that use AGA to the max.

Best Regards ;-)

[Crumb]

umm just some words more, when I talk about 3D demos I'm not talking about 3D hardware accelerated demos that use Warp3D/OpenGl, I was talking about software engines...

[Crumb]

@lempkee

i cant say that doing em RTG only would do any real changes in where the scene is atm.

no one has talked about making these productions RTG only. The only suggestion is that you can add RTG support to your production easily.

Also i have seen comments about how all make em rtg now because of the 3d stuff, bleeeeh LOL guys , did you ever consider that its done ONLY because its actually coded
for both systems in 1 go?? , ie leaving out all HWbashing and implementing a 2 way system (ie first for AGA then do it for rtg also...)

nahhhhh ROTFL guys should read what I write, I talk about adding RTG support without dropping AGA because you can do this easily and release a dual demo...

I'm always reading that "scene is dead", but I don't care. I was reading that when there were lots of spanish groups alive and kicking and many people said that scene was dead.

Scene will be alive for me if people still tries to optimize and always try to improve their coding/gfx/music skills.

I like 3D stuff in slow machines because goals difficult to achieve are exciting. For example watching the c64 version of second reality was quite funny, other demos show gouraud shaded cubes with only 0.98 Mhz... well, that's amazing.

I am still waiting for a RTG production that makes me say, wow! I didn't think my 060 with gfx card could do that.

I don't care about pc emulators. PC sceners don't make demos for 8086 to run them in pc-task ;P why should we care about that? they should improve their emulators and that's all.

Even using AGA, the Amiga is not really fixed hardware now, with 030/50,040/33,040/40,060/50, 060/66, 060LC/75. You are almost coding for your machine only. The nice effect you are coding may run in one frame in a 060/60 but not in a 060/50. Your excelent and super optimized 882 FPU code may run very well with a 882 but may be dead slow with a 040...

Anyway making a demo for a 800mzh system and to IMPRESS some one, how is that possible??

making stuff that would require a much more powerful machine.

WHAT makes a good demo...GOOD code or good textures or high RES ?.

All that mixed together ;-D
and don't forget the music! :-)

for me the fun is in coding with a limited resources, optimizing so much, that what people thought that was impossible to do, becomes possible. trying to break the limits set by someone...

anyway i am sick of 3d.... i want the 2d back

yes, I liked 2D, but many things have been already invented and it's difficult to find a original 2D new effect. I'd like a mix of that, mixing 2D and 3D, new and old techniques like Darkcoder said.

[Crumb]

That sound a bit strange to me. The cards are connected with the system by means of the Zorro/PCI or AGP bus. Hence the speed at which you can write to them is that of the bus. But Zorro, PCI and AGP have diffrent speed. And also the card's memory are different both in size AND speed! So haw can you write always at the same speed? and which is the speed?

well, my suggestion of adding RTG support is for pure 3D demos, so you will open a screen with twice the width or height of the visible screen and use that as double buffer. So the only thing that will change from one card to other will be the speed of the bus. Well, the speed of the ram also, but it's so fast that the bottleneck is in the bus if we talk about graphic cards. With zorro3 that is arround 9MB/s, but I know that the CV64 is faster (is one of the few cards that use the bus to the limit). With a 040/25 the speed was really slow (12fps? I can't remember, it was SLOW)

I did that test writting rubbish directly to the screen and counting the fps. I got arround 140 (I don't remember the exact number but I saw that bus speed wasn't going to be a bottleneck) With the A4000 PCI solutions the limit is the same because it goes through the Zorro3 bus. With the mediator 1200 the bandwitch to the gfx card may be higher. With an AGP card the speed of gfx memory writes will be amazing... but... the limit here is the cpu (of course I think there's plenty room in my code to run faster) and maybe also the fast ram speed. With a 603/200 it ran a little faster (60fps), i'd like to try it with a cyberstorm MK3, because they have faster memory access and I will see if it's due to the fast-ram memory access or lack of cpu power. I guess that it's due to the bandwitch from the cpu to fast-ram. That would be the reason because it ran at similar speeds with a voodoo5/ppc than with a picasso4/060. But my point is that the speed of the gfx bus doesn't seem to be the limit (if I achieved 140fps filling the screen with my cpu with rubbish I think that the limit is not due to the gfx mem bandwitch speed)
With AGA I think that the limit writing to chip mem is 1.8 MB/s, I think that reading is 4 times faster. That gives us 28fps in 320x200. Quite enough to be smooth :-)
The problem is the effect we are trying to show, I think that the bottleneck is the cpu. If the cpu can show the effect at 25fps, there will be small differencies between the speed of the AGA and the speed of the RTG version... of course the bandwitch to the gfx mem helps, and the RTG version may have a pair of extra frames. The bandwitch to the gfx ram will not help much with complex effects and scenes. If the CPU can do more than 28fps, AGA will reach its limits (talking from a bus bandwitch view, without using any trick) and gfx cards will be able to show that extra frames.
All that is not applicable to gfx cards if the demo is not 100% 3d
For 2D stuff to be 100% sure that the 2D gfx are in gfx ram, there are other methods. As you may do in other system you will set a minimum of ram to make your demo work. The extra ram can be used to store more graphics and sve the time to move them over the bus.
I've talked a lot (maybe too much) :-D
I don't know if I've made the things more clear for you or if I've confused you more :-/
Anyway it's quite fun to talk about this things in Amiga.org, I don't usually saw scene related threads.
:-)

[Crumb]

@lempkee

as the mediator (and OS4) doesnt use the old p96 direct code (which all CGX people belives (STILL) that it do...

Do you mean that direct mem access using p96 doesn't work? with 8 bit screens it seems to behave correctly with mediator and voodoo5 (with OS4 I don't have a clue). If the problem appears with 16bit screens I guess that the problem is the way bits are aligned in CGX/P96, for example the coder may assume that the screenmode is bigendian when it's littleendian and if there's no specific code it may give problems. I can't talk much about that because I haven't tried the 16bit modes... the first Mankind productions that where CGX compatible didn't show the colours correctly, it may be due to the fact that if p96 doesn't emulate correclty the behaviour of cgx and gives wrong info about the aligment of the screen, the colours will look bad.

Although many people has a graphic card I think that those with AGA and real interest in demos will switch the monitor output :-)

I tried the DCE scandoubler of the CV3D and saw that the colours of the demos wasn't perfect (because it wasn't fully 24bits) and thought that I would never use a non-24bit scandoubler/flickerfixer. I think that I will always keep my 4000 to watch AGA demos in the real thing. :-)

I've talked with a friend that just has bought a 060, he has told me that once he has released all the power of the 060 in some prods, He will go back to do plain A500/A1200 demos/intros
It would be nice to see new prods for A500 :-)

[Crumb]

Excuse me, how have you got these numbers?

Give a look here: http://list-archive.gin.cz/amiga/0010/msg00426.html

there are results of many speed tests. With AGA I think your numbers are wrong.

Yes, the AGA numbers are wrong, I thought that the 1.8MB/s were writing longwords, but it was writing bytes. thank you for the URL, it's quite interesting.

well it seems to me that THERE IS a difference! And these are all ZIII boards!
Then there is CVPPC and Bvision which I think are different because they are
directly connected to the CPU with a custom bus (in fact they require CybPPC /
BlizzardPPC).

The use of the custom bus only affects the driver, they way of coding it is the same. Yes, they only work with ppcs or cyberstormMKIII. Ok, each card has different bandwitch, but the bandwitch is enough to do effects in one frame even with the slower cards.

But basically (with AGA machines) we only have:
1) 020 at 14Mhz (1200)
2) 030 at 50Mhz (many boards)
3) 030 at 25Mhz (4000/30, not many)
4) 040 at 25Mhz 4000/40
5) 040 at 40Mhz some boards but very rare
6) 060 at 50Mhz CybStorm

I think that most of demos require at least a 030/50... BTW 040/40 is quite common in Spain.
Here the absolute minimum people has is a 030/50, but they usually don't use much their Amigas (they were quite common a few years ago). Most of the remainder Amigans have 040/40 at least and a gfx card. In my local usergroup the only person who has not a gfx card has the slowest computer with a 040/40. I haven't seen demos designed to run well with a 020 in years.

Yes, 90% of optimization and a 99% compatibility is ok for me :-)

have we got too many CPUs? well, I hope we have one more family soon: the coldfire of the ColdFusion accelerators ;-D

[Crumb]

@Carls
yes, you have more productions in their web page:
Spaceballs Web page
I agree, having stylish designs with optimized code running in that legendary machine is cool :-)

[Crumb]

@Carls
Olli_hd is the person who is designing the board, the project seems to be going well, if you want more information you can join the yahoo mail list Amigacoldfire@yahoogroups.com. The 1200 version will probably be released after the 4000 one.

[Crumb]

@Darkcoder

Anyway since you are good coder, may I ask you infos (if you want by email) about Aki's c2p code?

Do you find important differences between the Azure and Aki c2p? They seem to achieve very similar speeds, acording to the URL you posted with slow computers (for example a 040/25) Azure's c2p seems to be slightly faster, and the situation inverses with faster computers. Aki's C2P is used in ADoom, Quake etc...

[Crumb]

@Darkcoder:
yes, AFAIK Aki's c2p is public domain, at least that is what is written in the comments of the header. The chunky to planar sources are included in sources of games like adoom in Aminet. You can take a look. I haven't compared both because I know little asm.
You can download adoom's sources from here. There are more c2p done by aki in the shapeshifter gfx driver TurboEVD. This is published with the GPL licence instead of being public domain.

[Crumb]

@psycho
thanks for joining the thread

you actually have to differ between 1260 and 4060.

I've seen that 1240/40 is slower than a 4040/40 writing in chipram, so I understand that. But looking at the web page of speeds provided by Darkcoder, the speed of a blizzard 1260 & a an CS4060 MK2 seems to be quite similar. I guess you do that because Apollos 1260 seem to write more slowly in chipram. Now I see why you use 2 different c2p :-)

1) mode changes is a bad idea. So no hires (ham8) pictures etc..

what about using an ASL requester before starting the demo? mmm although I guess you do it because some monitors need too much time to switch from one mode to other.

2) no hardware sprites. So overlays have to be rendered on top of the buffer, which is slower and doesn't allow smoth interrupt driven movement on top of a less smooth routines.

And if you use BltBitMapMaskRastPort() with a image you have in the gfx card mem? The blitter of gfx cards is usually faster, doesn't it help? Couldn't be made an interrupt server each 1/50 second for example that makes a BltBitMapMaskRastPort() with the image we want to write? I think that would work at 50fps and we may have a slow routine in the background that goes at 15fps for example that may be interrupted to paint our bob, the slow routine then would continue painting its screen. This is just an idea of how I would try to do it... I haven't tried and I don't have a clue... it may work or not, but I think that it should work.

3) No well known refresh rates. So you can't do an exactly 25/50fps effect, and remember that exactly 25fps on a 50hz display would usually look smoother than 35fps on hz display. (ie. I can only recommend TheCastle.cgx to noaga or winuae ppl).

Yes that's difficult to make with a gfx card :-/
I would try to read the actual hz of the screen and would choose the closest submultiple to the one I want to use. For example, with a 72hz screen I would try to use 24fps. With a 60hz screen 20 or 30, it depends if you want it smoother or think that your graphic functions and graphic buffer will help enough. There's a function called WaitTOF that should help to keep the graphics syncronized with the vsync (afaik the bad point is that some gfx card don't have a vsync interrupt at all). Then you may use all the gfx ram as a buffer as you did in "The Castle". The test to get the maximum fps should be done once you have opened the screen. Anyway AGA is more elegant to do that...

no palette-synchronization (ie a new palette for every frame in an effect).

If you wait until the frame is completed and change the palette it wouldn't work? :-(
And with WaitTOF()?
I'm talking about 8bit screens, with 16bits it would be a lot of work... gfx cards seem to be quite fast changing the palette, I thought that It would be possible to change it in every hz.

I'm sorry for the mistakes I've comitted but I have not much experience. What do you think of some of my ideas? I hope at least one of them works ;-D

@darkcoder:

You say it's better to do:

write 4 long
some instrucions
write 4 long

??

That may be thanks to the small cache the procesor has to write in burst mode? That may be easy to do in asm, but I'm not sure if I could do that in C... maybe using a pointer to the cache address? I'm not sure. I use a 32bit variable that will probably be stored in a register... I don't know how to control with so much detail the cpu cache in C...
I have another doubt... when I write something to ram  it goes to the burst cache (I think it's also called write pending buffer), but is it copied to ram if I try to write another longword? or the cpu waits until the burst cache is full? I've read somewhere that when the cpu access zorro3 the caches are flushed.

Best Regards from a newbie ;-D

[Crumb]

Last time I checked (ok, it's a long time ago) BltBitMapMaskRastPort was not accelerated.

I haven't tried much... you are probably right (but it's a pity that it's not accelerated). With 16bit screens I guess that it will be done by the cpu, with 8 bits it may be different.

Thanks for the tips about using WaitBOVP() instead of WaitTOF() ;-)