krabob
Member |
Hi all again !
Winden contacted me privately 3 monthes ago about a speed up that could be implemented on karate , with AGA intuition screens. He knows of a trick to do with AGA intuition screen, by adding some copper instruction to it I guess by using some OS function, ... It has been done in a intuition C-Lous intro at the time (I don't remember the name.) and a diskmag he said...
Can someone explain me about the whole thing ? Why is it faster ? Does it affect some bus use ? Does is touch some video frequency thing ? How does it act ? And most of all: seeeend the stuuuuuf ASAP !!!
Actually, I tested karate recently with a vanilla1200 (no fast,68020, 2Mb chip). First I discovered I left some "fast forces sections" in the startup, which forbid the use :-( (Yes, you know I suck so muccch.) . I corrected that, and to my surprise, I could even throw the lightwave object tutorials !!! It seems to run at 8-10 frame per sec, which is more or less close to the result with a 68030 and fastmem, when the cache fail all the time: it is quite normal, because most optimisation in the C2P and texture mapping work in this configuration. However I was not expecting such a result.
Actually, It woke up my interest for a 100% vanilla AGA demo. (still compatible with new PPC amiga of course. )
(... the second problem is the memory, 400Ko are left by the exemple... but it uses the system datatypes, and karate memory management could be optimised... Then I could even thing about a karate disk-based vanilla demo, by addding a gif picture loader plugin to get rid of the system.)
... But actually I work on something completly different by now, so It will come slowly.
|
winden
Member |
Halllloooooooooooooooooooooo Victorien!!! :)))
I guess the mail got somehow mishandled, since I just did a search and i've got a mail i tried to send you with all 3 sources:
1. some .c source by touchstone/essence which replicated what he had done to make R.O.M. fully multitasking while beign able to have split screens with full pallete and scroll and even system-dragging. I think he published it somewhere on usernet.
2. some .asm source I coded following touchstone's technique, but in my case i hooked the copper interrupt in a system-friendly way so that my code got to run at the specified scanline i wanted.
3. some .asm source I coded, which created a system-friendly screen and a new thread with very high proiority. this thread would sync to the frame by using WaitTOF() (which doesn't burn CPU like WaitBOVP()) and then just test which screen was the frontmost by consulting intuition. if it was my screen, then it did a switch-out of the screen (loadview(0) & set my own copper), but if it detected another screen was frontmost, then did a switch-on (loadvied(saved-view) & set system copper). net effect is a source that can use copper freely while remaining 100% multitasking due to not killing system interrupts.
The possible speed-up I mentioned was doing a raster-syncronized c2p, like it was mentioned on some #amycoders article... you may get know that there are 312 scanlines per frame, let's say that you show 200 scanlines of data... then sending data to chipmem is slower while you are on these 200 scanlines than in the rest (because the graphics-chip has to read from memory to know what to show ;)
framesync c2p involves using copper interrupts to make an small multitasking system which switches between a c2p-thread and a calc-thread... for example on lines 0..49 and 250..312 the c2p-thread would have more priority and thus get the speedboost while on 50..249 calc-thread would have more priority and thus use fastmem to the most.
AFAIK this technique was first released in "When we ride on our enemies" from Skarla, but I remember talking with peskanov/capsule about it around april 1997 (maybe he used it for his "Quicktro" demo) and also later on using it also on "Crossing the deadline" from Network... probably many top-demos since 1998 or so are using this... and probably also loonies technique for one-frame chunky on "Hotstyle takeover" is some variant for this one.
Duhh this is getting big... XD
I'll close just saying anoyone interested in these sources should get in touch with me and I'll send them in, they are not very big and the last one is even selfcontained since I just coded it for test but never used it finally.
|
