coding

[H.Hannig]

If your list has anything like a bitmap in, the OP will corrupt the data, it updates things like position and start address within the OP list each pass.  So you either have to rebuild or copy the old list back each frame.

 

But as a stop doesn't have either of these I think you may be able to get away with simply slapping a list containing a stop in there which should keep the op happy till you get ready to use it.. I haven't tried this tho, just an idea I have had

 

Isn't there a possiblity to turn the OP off before the real startup and turn it on later so the predefined list isn't corrupted before the startup code is executed?

 

The code that does OL buffering and restoring after the startup should work as Lars had no problems with his jag setup and my binaries.

 

@all in this thread:

Thanks to all of you for your kind help and hints.

I'll try some things when I have the time.

 

Regards

Holger

[LinkoVitch]

not sure if turning the OP off is a good idea, I am sure I have read in the Dev manual (in the faq section) that turning the OP off is a bad thing to do, it's mentione din reference to outputting a blank screen.

 

Never tried so can't comment from my own experience, just read that it was bad and never tried it

 

(no sense of adventure anymore )

[Starcat]

Hi Linkovitch !

 

The OP is turned off in the startup.s by atari at the very beginning to avoid that the OP might start before it has a list to process...

 

I think Doom also turns off the OP in each VBL, then copies the list and then turns it on again... At least that's what I remember seeing in the code...

 

So I am not sure if turning the OP off is really a bad idea..

However I think you are right about the OL pointer.. I don't think you really need to use the GPU for that. It seems to work flawlessly with 68k.

I can' tell yet if it is 100% safe, though.. But it should really be safe if you turn the OP off or set the OLP in the VBL.

 

The startup as it is today (last changes in 95) was not there back in the days... Some games used it, but most games use different ones.

Afterall back in 1993 when the first games came out, the tools, docs and examples were still in early stages. So back then many developers wrote their own stuff, without anything like the examples we have today.

 

Regards, Lars.

[LinkoVitch]

I spose anyway with a bit of care it should be possible to construct your OP lists close enough to each other so that you only need to change the least significant word of the address anyway, which would mean a single 68K write and also a minor speed improvement in your code eg

 

lists at addresses

 

$FF8240 and $FF8A40

 

would only need the last word changing in the address

[Symmetry of TNG]

Hi! =)

 

The OP is turned off in the startup.s by atari at the very beginning to avoid that the OP might start before it has a list to process...

 

 

No it is not! ....If I/we are to trust atari the OP can NEVER be turned off once it is running (not safely anyway).

And this is what atari stressed and always told developers to do (and i strongly sugest any coder to do)

 

This is why it has to be 2 branch objects before each bitmapobject, this is why some of the hardware video registers have to have specific values, and so on, not to cause the OP to stop....

 

There is a difference between pointing the OP to a stopobject, writing $ffff,VI and turning the OP OFF!!

The 2 first is ok, the lastone is not.... IF you are to trust atari.. and i do! =)

 

my 2 cents in the interest of facts =)

 

Btw Wellcome Holger! =) always nice to see coders that can do a bit of 3D (is that pure 68K all the way? ...including "after glow" ? or do you use the blitter?

 

cheers

/Sym

[H.Hannig]

Hi! =)

Btw Wellcome Holger! =) always nice to see coders that can do a bit of 3D  (is that pure 68K all the way? ...including "after glow" ? or do you use the blitter?

 

cheers

/Sym

 

Hi Sym,

both programs are as I said in my first post just plain and simple "hello worlds". I just chose the simplest thing that came to my mind to get a quick result.:-)

When I have the time I'll try to do something more interesting in 3D.

The code is pretty much straight forward with almost no optimization.

Both programs don't use the blitter, pixel processing is done by the GPU, the rest is 68k.

 

regards

Holger

[Starcat]

Hi! =)

 

The OP is turned off in the startup.s by atari at the very beginning to avoid that the OP might start before it has a list to process...

 

 

No it is not! ....If I/we are to trust atari the OP can NEVER be turned off once it is running (not safely anyway).

And this is what atari stressed and always told developers to do (and i strongly sugest any coder to do)

 

This is why it has to be 2 branch objects before each bitmapobject, this is why some of the hardware video registers have to have specific values, and so on, not to cause the OP to stop....

 

There is a difference between pointing the OP to a stopobject, writing $ffff,VI and turning the OP OFF!!

The 2 first is ok, the lastone is not.... IF you are to trust atari.. and i do! =)

 

So there is a difference between turing the OP off and disabling the VI ?

And turning off the VI is ok and can be done whenever you like ? Or also just at the beginning once ?

What atari does in the startup.s is turning the VI off once.

 

move.w #$FFFF,VI ; disable video interrupts

 

So that can be done without problems as long as it's only once ?

 

Regards, Lars.

[Symmetry of TNG]

Hi! =)

 

Well... i guess i am "splitting words" a bit.. but it is not turned off by writing that value to VI just that the irq will be 65536 halflines away.. ie it will "never happen" =) but the op is always running..

 

same thing with other "do not touch" registers... was it VBE (?)... vertical blank end... that needs to be big enough so that it will not stop the op.

 

I see no reason why one should not be able to alter VI more than once (in the beginning)... just that it will "muck up the screen" =) ..or turn it black

 

As long as there is 2 branches before each object pointing to a stopobject it should be ok..

The only thing that happens when you write to the VI is that you "delay" the VBL interrupt.. ie the routine that resets your OLP (&fixes altered object values).. just that the V&H count will be so off that the to branches2Stop will allways occure..

 

But Use atari setup & be safe! =)

[Symmetry of TNG]

Hi! Holger

 

>When I have the time I'll try to do something more interesting in 3D.

 

look forward to it ! if u want to talk about 3D dont hesitate to throw out a question =)

 

 

>Both programs don't use the blitter, pixel processing is done by the GPU, the rest is 68k.

 

So the "averaging" to get the "afterglow" is done by GPU? ...=) it can be done with the blitter BlittSchnell u know ...by using the sourceshade function..

Ahh well.. its still a nice thing.. i 4 one like wireframe.. gives me retro atari demo feelings =) keep up the good work.

cheers

/Sym

[LinkoVitch]

/me makes mental note to download these demos, they sound excellent

[H.Hannig]

Hi sym!

 

look forward to it !  

I'm quite busy right now with other things to do so it will take some time till I'll start to try the next thing on the jag.

 

if u want to talk about 3D dont hesitate to throw out a question =)

Thanks for your help. It's good to know people you can ask some questions before you need to ask.

 

So the "averaging" to get the "afterglow" is done by GPU? ...=) it can be done with the blitter BlittSchnell u know ...by using the sourceshade function..

Yes it's done with the GPU and even with the GPU it could be a lot faster. It's just getting warm with the hardware.

In facts it's done in a dumb and slow pixel by pixel way but it was fast enough for this small test prog so I did no further optimization.

At least now I know better what I can expect from the GPU even in a worst case scenario.

 

Thanks for the blitter info. I don't know much about the jag blitter yet. Did you use the blitter in your small "fire" prog to do the "averaging"?

 

Ahh well.. its still a nice thing.. i 4 one like wireframe.. gives me retro atari demo feelings =) keep up the good work.

I prefer retro effects. It reminds me on the good old days when I was younger :-)

It's sad that the jag pretty much lacks a demo scene

 

cheers

holger

[Symmetry of TNG]

Hi! ..and pardon the realy slow replye... but as you said there are other things in life than hanging out at this forum

 

 

>Thanks for the blitter info. I don't know much about the jag blitter yet.

 

It is one of the most powerful chip in the jaguar... but also one of the buggiest

 

>Did you use the blitter in your small "fire" prog to do the "averaging"?

 

No... well not exactly... it is a "true fire" average.. ie average of sum of top & three below. ...so that is done with gpu... but in order to get some kind of fps (ie avoid external loads!!) i used circular buffers & blitted the table into the gpu in phrasemode (and later the result back to screen).

And also did a quite nonunderstandable optimized "two pixels at a time" average with the gpu... in a "DSP" kind of fasion (where you prep the loop so it becomes a loopable thing later).

 

Thats the fastest way i know howto on the jaguar... (except if you go to 8bit grafix.. then it might be done faster... ...if you doo your loop for 4 pixels at a time ...but.... no =)

 

 

But to make a "afterglow" kind of average in the other demos i made (warum & warum Texturemap) i used the blitter. and that is what you do in your demo (i think .... just draw on 2 screens (without clear) and then every frame subtract a constant value from the previous screen (with saturate) ..and this is exactly what the SRCSHADE thing does in the jaguar. and it can be done in phrasemode (ie 64bits or 4 pixels at a time).

 

Ahh well.. using the gpu is NEVER bad! =) stick to it & use it always to learn it good.... it will be worth it!. =)

 

 

>I prefer retro effects. It reminds me on the good old days when I was younger

 

haha =) yes... we all have our reasons for liking retro stuff

...though i must agree... =) "the good old days"...

 

>It's sad that the jag pretty much lacks a demo scene

 

Must agree with your sadness.... in my oppinion the jaguar is the most powerfull atari EVER made, and it could make amasing demos!... running on 790Mb CD... blowing your mind away for hours.... *sigh* well i can dream... =)

 

keep it up!

cheers

/Sym

[H.Hannig]

Hi Sym

 

 

No... well not exactly... it is a "true fire" average.. ie average of sum of top & three below. ...so that is done with gpu... but in order to get some kind of fps (ie avoid external loads!!) i used circular buffers & blitted the table into the gpu in phrasemode (and later the result back to screen).

And also did a quite nonunderstandable optimized "two pixels at a time" average with the gpu... in a "DSP" kind of fasion (where you prep the loop so it becomes a loopable thing later).

 

Thats the fastest way i know howto on the jaguar... (except if you go to 8bit grafix.. then it might be done faster... ...if you doo your loop for 4 pixels at a time ...but.... no =)

 

Both of my progs use 8 bit graphics . The cube demo has even only 32 different shades of blue.

 

But to make a "afterglow" kind of average in the other demos i made (warum & warum Texturemap) i used the blitter. and that is what you do in your demo (i think .... just draw on 2 screens (without clear) and then every frame subtract a constant value from the previous screen (with saturate) ..and this is exactly what the SRCSHADE thing does in the jaguar. and it can be done in phrasemode (ie 64bits or 4 pixels at a time).

 

Ahh well.. using the gpu is NEVER bad! =) stick to it & use it always to learn it good.... it will be worth it!. =)

/Sym

 

In fact the cube prog is very much like a oldschool "real" fire.

I rotate and draw a wireframe and do a small (only pixel and surrounding 4 pixels) fire like "average". I don't draw to 2 screens. Just one screen, no screenclear :-)

The "hotspots" are the lines of the wireframe.

 

regards

Holger

[justclaws]

Hello Holger,

 

It's nothing special but some kind of experiment about the "feeling" of the Jag from the coder's point of view. So these are just two quick "hello world" like hacks.

 

Since there aren't that much homebrew Demos for the Jag yet I decided to release them to the public.

Have you got any updates on your experiments with Jaguar? Source?

 

You can find the binaries at:http://home.t-online.de/home/Holle.Hannig/

No longer it seems - do you have a new home-page for your stuff?

 

Fortunately I uploaded the files to the Yahoo Jaguar-Homebrew

group files area previously, but I'd like to update your link too.

 

Cheers,

JustClaws.

[H.Hannig]

Hello Richard,

 

No longer it seems - do you have a new home-page for your stuff?

Fortunately I uploaded the files to the Yahoo Jaguar-Homebrew  

group files area previously, but I'd like to update your link too.

 

My ISP changed his policies. The 10 MB webspace I used to have for free is gone.

(Now they charge extra money for Webspace)

I intended to upload them to the Yahoo Jaguar-Homebrew

group myself (is this possible?) but forgot it.

 

 

cheers,

Holger

[justclaws]

Hello Holger,

 

My ISP changed his policies. The 10 MB webspace I used to have for free is gone. (Now they charge extra money for Webspace)

Well for the people who didn't see your stuff, I'm adding it to my JustClaws DevCats pages, and here are a couple of screenshots which of course cannot demonstrate the movement, but do give some idea.

 

I intended to upload them to the Yahoo Jaguar-Homebrew  

group myself (is this possible?) but forgot it.

I've handled that, they are still available from the Yahoo groups Files area of the Jaguar-Homebrew group.

 

I look forward to that promised next game/demo, great news!

 

Cheers,

JustClaws.

[justclaws]

Hello Holger,

How about a quick look at what you are working on these days?

A hint would be cool...

Cheers,

JustClaws.