A.D.A. Amiga Demoscene Archive

Hi to all.

So, my question is it: how i can support in my demo cgx,p96 and aga ? like as ephedrena demos. These demo work nice on cgx/p96/aga. How it works ? Maybe loaderror here ? Do you use only ASM or C ?

I just want create fast demo, which work nice on real amigas, winuae and a1/pegasos (real amiga 060/66 minimum), and want to use C only (sasc basically).

So, i think it would be like this:

a). Open screen/window by intuition.library
b). Write to window some stuff by cybergraphic.library (as i know p96
emulate cybergraphics, and it must works. But what about AGA?)


Next questions about work with graphics. cybergraphics.library is good ? For example i want create one picture 640x380x24b as bitplane and want to rotate some vectors on these bitplan. What i need to use for it ?

Thanks a lot.

@modun:
Welcome :)

I think that Ephidrena uses the demo startup-system coded by Cyborg/Industry (which is freely available here). It is written specially with compatibility for AGA/CGX/P96 in mind.

Can't answer the other questions (i'm not a coder) but some use ASM all the way, some use C and include ASM for time-critical things or things that need to be executed very fast. (Psycho/Loonies talked about that some time ago on Amigaworld saying that his intro The Castle was mainly written in C with some stuff in ASM, i seem to remember).

With compatibility to Pegasos/A1 in mind, i think C is the only option.

> Next questions about work with graphics. cybergraphics.library is
> good ? For example i want create one picture 640x380x24b as bitplane
> and want to rotate some vectors on these bitplan. What i need to use
> for it ?

Hello . I used to write my own chunckystartup (also on aminet, but it has one or two bugs about the ASL screen requester,so use cyborg's one.)

You should code for "cybergraphics.library" . Picasso emulates it, but offer extra stuffs if you use the picasso way, but for demo it's OK. When you use cybergraphics, It must be completely OS-Friendly, but you can also code OS-Friendly with just AGA the same way.

cybergraphics.library offers a VERY LITTLE numbers of additionnal functions to graphics.library . (I have not their exact name here, but it looks like that.)

-One to find a modeID according to a screen mode description (size, pixel format). (note: there is a function like that into graphics.library that can return CGX mode if present. )

-some to check if a mode ID belong to cybergraphics, or the size or pixel format.

-One to get informations (lockscreentaglist..) about the screen AT A GIVEN MOMENT: You got to unlock as soon as possible. It is possible to ask for hardware chunky pointers with it and do your hacks on the screen like a bad guy. (lock/draw/unlock)

- a 24 bit version of WriteChunkyPixel which is only 8 bit with graphics.library.

An that's all.
Usually, demostartup check if we are AGA or CGX and get CGX if openlibrary(cybergfx) fails. Then there are "switch" with different codes.
In the absolute sane amiga way of coding, it is possible to get NO SWITCH, exept for the use of the 24bit writechunkypixel(). usually, demo startups don't do that for their refresh routines. They do their own pixel writing (let's call it c2c :-)

So a CGX refresh pass must looks like:
- LockScreenTagList( I ask for all the screen info )
we got:
+ a pointer of the start of the screen
+ THE REAL HARDWARE SCREEN WIDTH IN BYTES <-check it, lots of bugs when you dont.
+ the pixel format (no trouble with 8bits modes, but with 16bits, you got to manage 8 DIFFERENT Pixel FORMATS, RGB BGR, RGB little endian, etc...)
+ The real screen dimension (unrelated to the hardware width.)

- use the c2c to draw (according to the parameter get.)
- unlock(handle)
(end of the refresh pass)

unlock in no case before drawing !!! bad error !!! all drawing must be done within a lock. Important: under CGX, the same screen can (REALLY !!!) change its chunky pointer at ANY TIME (exept within a lock)
so getting a harware screen pointer at the beggining and keeping it once for all is a BIG MISTAKE !!! Also, a screenlock can FAIL, test it.
A trick from me: at the begining of the CGX refresh, use the intuition base (or graphics?) to check if the screen you have to draw is FRONTMOST. if it is not, DONT DRAW IT. BE aware that CGX can use(or not) a single memory chunk for ALL intuition screens. From a system to another, the way cgx manage screen changes.

You want to get ride of all those screen lock and checks for pixel format ?
use the 24b (or graphics's 8bit) writechunkypixel(), it does it the best way possible (or should). I wonder why i have such a mess in my startups.

Last IMPORTANT precision:
For the moment you can do DOUBLE BUFFER CORRECTLY

ouppss. excuse me, here is the sequel of the previous post.

For the moment you * CANT * do DOUBLE BUFFER CORRECTLY under CGX. So the whole dblbuffer story is:

1 - There is for ages (OS3.0) a nice double/triple buffer screen implementation WITHIN intuition.library, using another very nice dblbuffer implementation WITHIN graphics.library.

2 - unfortunately, I've never seen a cgx implementation able to perform this OS friendly double buffering: it doen'st work under CGX4 / BVision i can tell, and other confs...

3 - some sceners has tryed the old PC DOS demo patch: asking a screen with double height size, but with a normal height mode, and in the refresh swap them with a scroll-dontnowwhatfunction() from graphics.librray. It worked in a minority of configurations, and is fucked up with SOME SCREEN MODES. so don't. Never forget the CGX modes are completly re-editable in their hardware behavior, while on AGA everything was fixed.

btw, never use a FIXED CGX MODEID with cgx !!! modeid and their meaning VARIES !!! they are abstract handler. (when it was fixed under AGA.)

> With compatibility to Pegasos/A1 in mind, i think C is the only option.

no it isn't :-), but i encourage you to code with C.
karate's startup is asm 68k and works fine everywhere.

A possible error is:
When returning from a OS function doing to test NULL:

jsr.l CGX_Lock(a6)
beq.s .error


it works with 68k but it's an error. A compiler never do that. Always tst.l your funcs:

jsr.l CGX_Lock(a6)
tst.l d0
beq.s .error

and it will work JIT-emulated everywhere.

If you are looking for the assembler include for cybergraphics (they lack in the CGX devkits) look at my startup on aminet or the karate sources, I had to do it myself.

Thank you if you use the system.

Thanks for answers.

krabob:

Well, i am use asl request for screenmode choice. Easy case for me with aga/cgx switch is it: open cybergraphics.library, if fail - switch to aga. Next, i am use WritePixelArray() from cybergraphics.library, and paste my buffer to screen. Next, i am write RGBPixel, and refresh all my screen (1024x768x24b picture). It's too slow. Very slow. If i want rotate some vectors, and every loop refresh screen, it's will be like a slideshow. If i read old screen pixel, store it, write new pixel, and back old pixel back, it's solve problem with speed, maybe?

I have read notes about cybergraphics.library/LockBitmapTagList():

--------
NOTES
Only use this call if you really NEED the rendering speed, DON'T lock the
bitmap longer than for one frame. DON'T use any library calls while the
bitmap is locked! This function is considered low level.
--------


Well, i can speedup refresh if i use LockBitmapTagList? You said: "- use the c2c to draw (according to the parameter get.) " Sorry for lame question, but what is it c2c ? chunky2chunky ? It will be OS friendly ? But if i just want to rotate only 1 pixel by Sin/Cos. c2c must be too ?

yes, c2c means "chunky2chunky", in opposition to c2p.
By now, Keep your WritePixelArray().

What does the code in your drawing loop look like ? Are you doing a call to math.h sin() and cos() functions for each pixels ? In that case your rotation can be accelerated by some faster algorithm, with only 2 additions by pixels. What is your hardware configuration ?


> chunky2chunky ? It will be OS friendly ?

In the conditions I told in the previous posts, it will. But it is easy to code something bad with it.

>DON'T lock the bitmap longer than for one frame

this sentence in the doc is obviously senseless. :-( you can't tell if your drawing will take more or less than 'one frame'. BTW graphics/WaitTOF() is still 50Hz with CGX, it's an aberation, it should be Waitting the top of frame of ... your CGX screen rate...

krabob, thanx agayn for your answers.

WritePixelArray() is too slow as function. I think it uses slow memset() in work.. on 060/66/mediator/voodoo3 is too slow . on 040 cpus i think it can't works with 16/24/32bits data. Can i do write buffer directrly to video memory by cybergraphics functions ?

--------------
cybergraphics.library/LockBitmapTagList() - Lock supplied BitMap for a short amount of time to allow direct memory access
--------------

So, if i just Lock some memory by this func, i can to have OS frendly direct video memory access ? For example if i use this code:

buffer_for_screen=(char *)malloc(640*480*4);
if((LockBitMapTags(buffer_for_screen,LBMI_BASEADDRESS,&myaddr,TAG_DONE ))==0)
{printf("can't locked!\n");};
memset(myaddr,0xfeedface,640*480*4);
UnLockBitMap(buffer_for_screen);

i will to have some shit 640x480x4 on my screen ? And can fast rendering my data ?

Do you know any OS frendly way for direct video memory access, maybe ?
For example i want to put 2 buffer to video memory,and swith with it.
I tryed this:

for(i=0;i<20;i++){
WritePixelArray((char*)buffer_for_screen,0,0,1920,&screen->RastPort,0, 0,640,480,RECTFMT_RGB);
WritePixelArray((char*)buff2,0,0,1920,&screen->RastPort,0,0,640,480,RE CTFMT_RGB);
};

and it's so slow on 060/mediator. On winuae its work fine, but 040/400mhz is a mess. I hope if i can map video memory directly, i can use memset to video direclty (memset as example)..

btw, do you know any link on C sources with proff work with cgx/truecolor under OS ? demo/ezine/anyapps. Scrolling, some effects maybe, etc.

And last qestion, what about vsync and hsync ? Can i do use it with WritePixelArray, or must to have direct memory access by LockBitmapTagList ?

Ok i'll try to be clear and exact now:

> Can i do write buffer directrly to video memory by cybergraphics
> functions ?

Yes, that's what "LockBitMapTagList" is about, but your exemple was wrong with lots of errors: LockBitMapTagList return an abstract "handle" just used to close it afterward. Also it ask for an INTUITION SCREEN STRUCTURE POINTER. the video memory chunk pointers and other info to return are defined in the tag list you pass to it:

It must look like:
UBYTE *myChunkyScreenPointer=NULL;
int myHardwareScreenWidthInBytes;
int myPixelFormat;
{

// this is the chunky buffer where to draw:
buffer_for_screen=(char *)malloc(640*480*4);

// ok, draw some shits in it :-)
memset(buffer_for_screen,0xfeedface,640*480*4);

int handle = LockBitMapTags( myIntuitionScreen,
// the tags:
LBMI_BASEADDRESS, &myChunkyScreenPointer,
LBMI_BYTESPERROW, &myHardwareScreenWidthInBytes,
LBMI_PIXFMT, &myPixelFormat );

if( handle != 0 )
{
// here, you can use myChunkyScreenPointer and
// myHardwareScreenWidthInBytes ,....
switch( myPixelFormat )
{
case PIXMFT_RGB:
ChunkyToChunky_RGBA_To_RGB(buffer_for_screen,
myChunkyScreenPointer,
myHardwareScreenWidthInBytes );
break;
case PIXMFT_RGBPC:
ChunkyToChunky_RGBA_To_RGBPC(buffer_for_screen,
myChunkyScreenPointer,
myHardwareScreenWidthInBytes );
break;
case PIXMFT_BRG:
ChunkyToChunky_RGBA_To_BRG(buffer_for_screen,
myChunkyScreenPointer,
myHardwareScreenWidthInBytes );
break;

default:
// insuported mode !!!
break;
}

UnLockBitMap( handle );
}

And the OS code for WritePixelArray must be close to it.
... so you see, with 8bit modes you got to do simples copies, but with 15/16/24/32 bits you gor to manage ALL POSSIBLE MODES with a different copy. the pixel format ending with "PC" refer to "Little Endian" modes. Really half of the amiga hardwares offers only little endian modes.
Also, don't believe the screen width you asked has a relation with "myHardwareScreenWidthInBytes". It doesn't. The c2c must write lines with your screen width length, but you jump to the other line with myHardwareScreenWidthInBytes.


> And can fast rendering my data ?

Maybe: there is no reason why WritePixelArray() should be slow, if the drivers are well done. Compare your pixel format commin'in and the screen pixel format: if they are not the same (RGBA != RGB,...), be warned this function doesn't make a copy, but may have to make bit swaping a sad way !!!.
Also, you manage 24/32 bit modes, so you had 3 or 4 more memory amount to manage, it is obviously slower than 16 bit or 8 bit pixel modes.

If you like to hack, You can try to manage a double buffer with your screen using the "double-height screen + scroll" technique, It will allow you to DRAW DIRECTLY your effect on the video memory instead of using a pre-buffer. It is possible to synchronize pixel writing and calculation, but you will not be able to READ pixels from video screen: it's dam too slow.
(Never do that, you loose pixel format abstraction, and your code will be fixed for one.)

krabob, big thanks for answers.

Do you have video card on your amiga ? Bvision ? Can you write little example for me with direct memory access by cybergraphics, and little rotate effect (2,3 vectors by sin) ? If yes, it will be very good. I just want to try this on 640x480x16b screens on 040 and 060 amigas with mediator.
Maybe i do something wrong, but my code too slow.

Thanks in advance.

Now i am looking at MadWizards demos (on my ppcx166/040x33/voodoo3) Such demos as kruelkarma, coolbaazaar, etc. All demos in 640x480x16bit. And have fade in/out, alpha. etc. And it work fine on my config. I think on 060/66 only (but with same voodoo), it must work good too. But, it too slow. I can watch as refresh my screen. So fade can't be in this case .. But here is direct memory access, etc.. Maybe problem in slowly memcpy func ?

So, most concrete questions:

1. Where is the best way for copy data from buffer to direct video memory ? As faster as possible ?:)
2. How i can do fade >=16bit picture ? Have OS any fucntion with work video gamma registers ? Maybe it's way for fast faiding on 68k/mediator. Anyway where best way for fade in/out on >=16bit picts ?
3. How i can do 'fast horisontal scroll' 640x480x16bit picture on 040/060 cpus. And vertical too.
4. How i can do it any effects on 640x480x16bit picture on 68k cpus ? I mean:
a). write buffer on video memory (as faster as posible, how?:) ).
b). write some vectors on this picture (memcpy agayn ?:( ).
c). start rotate. Do i need refresh all picture, or only 'dirtys place' ?

many hours of research, and i think warp3d best choice for fast work with video boards on 68k cpus. Like rebirth 4k intro by exploder, and like mawi demos (but ppc). OS frendly hardware acceleration best way, i think. It will work on old 68k amigas with video board, on old with ppc + video, on a1 (warp3d here too), and maybe on mos too (have warp3d too ?)

>think. It will work on old 68k amigas with video board, on old with ppc + >video, on a1 (warp3d here too), and maybe on mos too (have warp3d >too ?)

yes, mos emulate warp 3d, so by coding 68k+w3d it should work on a lot of config. but I will not be able to help you there, I've never code a single w3d line :-). Crisot/Universe (french demo coder) is actually beta testing the OS4 warp3d version, and is quite a new w3d coder. mdw/encore seems to be a warpos 3d king , as kiero/mawi. But Just refer to the docs anyway ! I know at the time(1998) you had to do your screen clipping yourself but it must had evolved.