Demos using a GFX mode please !

[lempkee]

@mdhw2: thanx for pointing out that issue, and if you had bothered to read it all then you would understand why i said it, anyway i will give you a few hints

i was a c64 user from 1983->1995 , and i find the c64 still impressive (even with hw upgrades) , the whole point of the discussion is "WHY dO WE WANt DEMOS on A1 (more or less) or pc...
and as i wrote earlier, i havent seen 1 pc demo (which naturally require + 1ghz) in ages, and its all about making a 3d engine, and i dont find 3d impressive at all (except for maybe in games) (3dmark is a kinda good idea)
on top of all , AGA code wasnt impressive AT ALL if you ask me or any real coders from the oldschool times, in 94/5 it all started to look better (but then alot had left) , that was when 2d and 3d became a STYLE and the mission to make the most interesting 2d*3d demo
and back then it was impressive, anyone remebers TINT ? , i remeber that they showed the demo 7 times at TG96 (after it was said "best demo , etc) , if you look at it now....it looks dated but it still have the quality wich makes u want to watch it again.

Anyway i dont see any reason to make demos on pc or on A1 , because unlimited specs and there is nothing secret hiding except for general design, since 1995 pc have been mixed into amiga demo compo's , please tell me why amiga have mostly won or got very good rankings compared to the pc ones,
and the pc had specs that was double or tripple (or like now x20) and still the amiga ones win? , also they dont say if its AMIGA or PC , they quitted that a long way back.


@crumb: the P96 bug with elbox, its because of the changes (its not documented, it has to be seen to be understood) , anyway the p96 devkit (the orginal one) doesnt work on mediators etc, like Openscreentaglists etc , the problem u mentioned about little and big endian is not a prob as v4 and v5 have reversed colormodes.
        the main problem is actually opening the main screen , in other words "alot of cgx stuff doesnt work , like Adescent(wos),ADoom(wos),Amhuhn (any),Joyride(all),Alot of demos.....  i have heard uncomfirmed rumours that cgx v4.x have a fix for this + documented but i have looked everywhere and no one have given me a good answer, and i wont buy cgx4 mainly beause i cant use it.

[lempkee]

@dagon: Ok since you say it this way , please explain to me why the SCENE is dieing? , please tell me where you get the inspiration from? , have you been to a party the last 3 years (excluding MEKKA) ??..

Have you noticed that a gamer gets more money in the compo compared to the demo/intro ? , have you noticed that pixel compo is very underrated now?

anyway what you say about c64 vs AMIGA back in 88 , and yes this was a big discussion but thats why C64 and AMIGA was never in the same compo,
and besides the c64 was more a hit than the amiga (until 91) if you count the scene activity.

anyway i dont see any reason to be entusiastic and optimistic about any of this but if making demos makes you happy then please do so,
and since i am too oldskool means that i should just shut up and let the newbies or midskool have some fun,
but one last argument 9 productions on asm 02, 4 products on TP02 ,0 producs at mekka 03, 0 products etc from now on doesnt amaze me at all and ofcourse i wish that the scene will be back but i doubt it , unless its a small party like kindergarten/trasc (which is good parties, but its about friendship and not about making demos (in the same way as MEKKA atleast)

good luck to all who wants to continue, i might continue if i see a reason , but making demos for either pc or Amiga1 atm is to me....useless , i would rather do as i do now (developing games for em).

[carls]

@lempkee

People have been saying that the scene is going to die "real soon now" ever since I first heard about the scene back in 1992. The scene is not dead and it's not going to die! New coders and artists arrive to the scene every year. Amiga demos still win in a lot of compos, there are even parties dedicated only to the C64/Amiga/Atari scene.

Just because there's a lot of Quake players at the bigger parties doesn't mean there's no demo scene!

If you're no longer impressed by demos, then I feel truly sorry for you but the only thing you really can do to change this is to sit down and produce something impressive yourself! THAT is what the scene is about. This is a discussion that has been going on for as long as I can remember.

As far as I'm concerned, the scene isn't dead as long as someone is out there and works hard to put pixels on my screen.

[darkcoder]

So I decided to post again mainly to answer to lempkee.

But first @dagon:
you cannot say we are close-minded saying cliche, I think we gave good arguments for our positions, I wrote many long messages explaining why I don't like doing RTG demos and nobody said that you can't do demos on RTG. I only said that you can't do 100% optimization on RTG and I gave many arguments. You can fight my arguments like Crumb and others did and we had an interesting technical discussion but here everyone is speaking with his brain attached.

@lempkee
I agree with you that sadly scenein a sence *is* dieing since there are fewer and fewer parties and productions and people. But as Carls says in another sense is not dieing since as long as you have in your heart the spirit to do (or try) funny and nice and optimized work.
Anyway since you are good coder, may I ask you infos (if you want by email) about Aki's c2p code?

bye!

[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...

[darkcoder]

yes exactly. I am curious about diferences. I coded by myself a routine similar to that of Azure, after reading his tutorials on amycoders.
(but only after I did my routine I looked at his source code ;-). My routine seems to be a very little faster than the azure one (at least of the PUBLIC Azure code) on 060 but it's a little bit slower on 040.
But now I am curious about the Aki routine. Is the technique similar or different? Is the source code of Aki public?

[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.

[mdwh2]

Regarding optimisation, I think it's worth remembering that there are different styles of optimisation. Doing things like hand optimising in assembler, trying to optimise every single low level instruction, and using things like fixed point arithmetic are a lot less likely to be useful on modern machines, than something like the A1200. But at the same time, there are still other ways to worry about optimising (usually more related to the algorithms being used), so it's not like one can get away with writing unoptimised code. I guess different programmers will find different things enjoyable.

lempkee wrote:
its all about making a 3d engine, and i dont find 3d impressive at all (except for maybe in games)

*nods* Well I guess this is the point; different ppl prefer different things, and there are those who find 3D stuff impressive.

since 1995 pc have been mixed into amiga demo compo's , please tell me why amiga have mostly won or got very good rankings compared to the pc ones,
and the pc had specs that was double or tripple (or like now x20) and still the amiga ones win? , also they dont say if its AMIGA or PC , they quitted that a long way back.

Presumably they are rating based on creativeness or originality or interest of the effects; if they don't know what machines it is running on, they can't be rating it on how well it's been optimised (well, unless all the PC entries were completely crap;). Indeed, if competitions can be held with demos running on differently specced machines without the viewers knowing which machine each was running on, then surely this further proves the idea that you don't need a single fixed standard platform to run demos on.

Regarding c2ps..

the aki c2p in the turbo archieve looks pretty standard imho, with the exception of the deltabuffer (which are probably smart for ui stuff like shapeshifter but not for a demo where  most of the screen is changed every frame) (*)

Regarding c2p speed in general (well.. I'm talking 060 here,  or at least a fast 040, where the conversion itself is faster than copyspeed, and therefore it's mostly a question of a fast->chip copying scheme), you actually have to differ between 1260 and 4060.

For 1260 the best thing to do is to preload as much data as possible into the cache and then c2p and write to chipram (just write 4 longwords at a time, as they become ready..).  

For 4060 it's totally different. Here a simple loop like: c2p'ing,read16, write16,c2p'ing, read16,write16 would work pretty well, and should in theory be about 5% faster than the optimal 1260 c2p. (I know.. I  SHOULD finish that article on the topic..

We are ourselves usually using 2 c2ps and choose the fastest one at startup. One for 1260, which prefetches 640 bytes before c2p'ing/writing, and a special one blueberry did a long time ago, which has a loop of less than 256 bytes (good for 030..) and has a copying scheme that works pretty well for 4060 (and escpecially for CSMK2).

(*) Actually it's worth mentioning that the screencopy scheme I did in E2140 would be quite a bit faster than turboevd's
 - maybe I should even consider it for a general c2p solution

ohh.. and on the topic in question.. After Valhalla in 99 I decided not to limit myselfes to rtg demos, but on the other hand make a rtg version if possible/easy. I'm not doing RTG only demos, so an RTG version is considered extra on top of the aga version.

These are the basic problems with RTG (as opposed to aga) in demos:

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

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.

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).

4) No copper effect (not that we do that a lot) and no palette-synchronization (ie a new palette for every frame in an effect).

5) (ok. this is mosly for adaption of aga demos). For 2D effects we get more and more effects operating without
a chunky buffer at all (doing scanline or block c2p from the cache to chipram), which would therefore need rewriting for a RTG version.

[darkcoder]

@psyko
many thanks for your interesting comments about c2p!! I hope not to disturb you too much by asking some clarification

>For 1260 the best thing to do is to preload as much data as possible into the cache and then c2p and write to chipram (just write 4 longwords at a time,


I always tried to put as much c2p instructions as
possible between any two longwords write, i.e.

write 1 long
some instruction
write 1 lone
etc.

You say it's better to do:

write 4 long
some instrucions
write 4 long

??

>For 4060 it's totally different. Here a simple loop like: c2p'ing,read16, write16,c2p'ing, read16,write16 would work pretty well, and should

erm..what do you mean with read16 aand write16?
You mean using the MOVE16 instruction?!
I always thought that such instruction was not supported by Amiga architecture, so never used it!
If this is true shame on me and I think I change my nick to crappycoder!!
Does it works in both chip and fast ram?

>special one blueberry
this short one also does cache preloading?
Can you tell me how much bytes? :-)

I use a c2p who preloads 128 bytes, like Azure tutorial. I have almost the same speed as Azure on 060 but I am a little slower on 040. Do you have any hint?
It you will finish the article on this topic, where can I read it?? :-)))

thanks for you help and congratulations for your
wonderful work!

[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

I always tried to put as much c2p instructions as possible between any two longwords write

The write buffer of the 060 takes up to 4 longwords, so 4 writes only takes 4 cycles, and won't stall the cpu as long as you don't make another (noncached) mem operation before they are all done. However, in general it is still a good idea to put in a single instruction between each write because of the superscalarity.

erm..what do you mean with read16 aand write16?

just the reading of 16 bytes from fastram.

You mean using the MOVE16 instruction?!
I always thought that such instruction was not supported by Amiga architecture

Move16 is supported for fastram but not for chipram (because of the burst mode)

this short one also does cache preloading?
Can you tell me how much bytes?

There is no preloading there, and it's not 060 specific (ie. the writes are distributed over the loop), it just happens to be fast on 4060, especially CSMK2 - it's a bit weird as it doesn't fit our theory

I have almost the same speed as Azure on 060 but I am a little slower on 040. Do you have any hint?

Maybe because it is cpu conversion and not memory limited on 040, and that azure's is better pipeline optimized.  Azure's is very fast on 040.

It you will finish the article on this topic, where can I read it?? ))

I guess that it will at least be on loonies.dk and in some mag..  Actually I feel like writing it

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.

Hmmm.. blizzard1260 (and CSMK1) (at 50mhz) is really the slowest 060 card when it comes to chipram, although it has improved through the different revisions (at least we've seen 3 different speeds for b1260/50). The CSMK2 has the usual 7mb/s chipram write speed but is quite slow in the fastram interface.

And if you use BltBitMapMaskRastPort() with a image you have in the gfx card mem?

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

If you wait until the frame is completed and change the palette it wouldn't work?

Maybe..  Btw. on rtg you have to use WaitBOVP() as WaitTOF() is still just waiting for the 50hz interrupt.

[darkcoder]

@crumb
I think that the CPU tries to write to the ram when the bus is available. Meanwile it keeps values to be written in the write pending buffer.
If the write pending buffer becomes full, and the bus is not yet free to copy values in ram, then the CPU has to stall.

[darkcoder]

@psyko

>>rm..what do you mean with read16 aand write16?

>just the reading of 16 bytes from fastram.

So you suggest that on 4060 cache preloading is not useful? I have a CSMk3 and my routine works better with cache preloading.

> guess that it will at least be on loonies.dk and in some mag.. Actually I feel like writing it

we all wait for it!!
I'll check on the website!