#RastPort.AreaInfo
12 messages in this thread
Unfortunately that is probably what you will have to do, try to make it system
friendly though. There is a book (I think called amiga 3d graphics), printed in
the UK that has details on fast filled vectors. I haven't tried any of it yet
(I wish I had the time), but some of it looks good (some of it could be coded
to run quicker). Basically though, programming the blitter and using interrupts
for parralel execution of drawing and calculations and using lookups for
everything that can possibly be looked up will severely increase your frames
per second. Actually, thinking about it. With an A4000/40 it might be quicker
to forget about the blitter for polygon drawing. Does anyone know a fast
processor fill routine?
Phillip
You woulding happen to know the name of that amiga 3d graphics book
would you? I would like to get a hold of it. At the moment I have to book on
3D graphics but it isn't amiga specific.
>> You woulding happen to know the name of that amiga 3d graphics book
>> would you?
Amiga Realtime 3D Graphics. From Sigma Press.
– Jim, on AP!
>> There is a book (I think called amiga 3d graphics), printed in the UK
>> that has details on fast filled vectors.
Amiga Realtime 3D Graphics from Sigma Press, right? Beat ya by two months. <g>
I did type in the first program (and learned a little more about the blitter),
but:
– I can only run it on my A4000 with caches off and OCS enabled.
– I have to assemble using 68000 code; can't set Devpac for 68040.
– I only get 80 polys/sec with that one as opposed to 160 with my ROM-calling
one! 🙁
>> Basically though, programming the blitter and using interrupts for
>> parralel execution of drawing and calculations and using lookups for
>> everything that can possibly be looked up will severely increase your
>> frames per second.
That's what I thought. Now to figure out how…the AA blitter's differences
and lack of documentation won't make it any easier.
>> Actually, thinking about it. With an A4000/40 it might be quicker to
>> forget about the blitter for polygon drawing.
I thought of that too — just chunky-to-planar those graphics every thirtieth
of a second or so. I don't know much about fast filling, though — I can't
even get my bookstore to order me a 680×0 programmers' guide! 🙁
Of course, I haven't worked much on this since I posted that last letter. <g>
– Jim, on AP!
If I remember correctly the polygon fill doesn't use the blitter line draw
which might speed the process up on a slower machine. Don't forget of course
that you won't just be drawing polygons anyway. The rest of the code is going
to be just as important, and if you can get the two working in parralel (i.e.
the drawing for one frame and the calculation for the next) then it might give
an overall speed increase. I did start looking at writing a fast fill on the PC
(no blitter anyway of course), and unless anyone else can come up with a
quicker way, you could draw the polygon by calculating both sides using two
bresenham lines each side and filling between the two points. That may be a
quicker way, whether after drawing the polygon in one plane you would use the
blitter to copy to the other blitplanes or use the processor (you would have to
check that one out). Doing chunky to bitplane conversions of the whole screen
may not be optimal If you have a fast good hidden surface removal. If you don't
do any removals then the chunky planes may be the way to go (do the chunky
screens in fast ram with 32bit long aligned accesses where possible). It all
depends on how much time you want to spend trying things out (If only it was
easy). Of course if you have to disable the caches on your a4000 it is going to
be alot slower (did it really have self modifying code, I don't remember seeing
any). How fast does the ROM version go when running without AGA or caches? What
you want to do is talk to Jez San who did Starglider II and the mario chip
(Can't remember the offical name) for StarWing/StarFox on the Super Nintendo.
He used to do alot of Amiga stuff (got a mention in the 2.04 ROM kernal manuals
I belive.
>> If I remember correctly the polygon fill doesn't use the blitter line
>> draw which might speed the process up on a slower machine.
It doesn't use it, so that might help on an A500…but my A4000…. <g>
>> Don't forget of course that you won't just be drawing polygons anyway.
Well, yeah — but if I can't get more than 80 or 160/sec by concentrating 100%
on drawing anyway, I won't even get that close when running the other parts of
the program too.
I did notice that the program in the book is constantly waiting for the blitter
before proceeding. With two image buffers, blitting one while outlining the
other is possible — but then, we have to wait for the blitter to finish so we
can clear the buffer, unless we devote CPU time to clearing it.
>> …you could draw the polygon by calculating both sides using two
>> bresenham lines each side and filling between the two points. That may
>> be a quicker way, whether after drawing the polygon in one plane you
>> would use the blitter to copy to the other blitplanes….
Isn't that what the book does?
>> Doing chunky to bitplane conversions of the whole screen may not be
>> optimal If you have a fast good hidden surface removal.
I was thinking more along the lines of letting the '040 do all the polygon
drawing work when I said that. It's much faster than even the AA blitter,
especially in fast RAM. It would also be able to do things like texture-
mapping better.
>> (If only it was easy)
<g> And if only I had more time to play with it.
>> (did it really have self modifying code, I don't remember seeing any)
I didn't really notice anything either; it just doesn't run right with caches
on.
>> How fast does the ROM version go when running without AGA or caches?
Um…couldn't make it run like that. <g>
The version from the book runs slower on the A500 than on the A4000, though.
>> What you want to do is talk to Jez San who did Starglider II and the
>> mario chip (Can't remember the offical name) for StarWing/StarFox on the
>> Super Nintendo.
Now why didn't I think of that…Jez is here on CIS. He checks into the
Vidgames forum from time to time. Maybe I'll send him an E-mail.
(That chip is the FX Chip, BTW. 😉
– Jim, on AP!
Officially it's called the FX chip, but the name on the chip was (alledgedly)
Mario. The polygon fill that I (badly) described is completely different from
the way the book works. For a start you need to be working with convex polygons
(internal angles less than 180 degrees). Then you need to draw it as a series
of horizontal lines. Start at the top line, calculate the x coords of either
side and draw a line, then the x coords of the second line etc. Each time you
move to the next line you move the x coord closer to the target. The way you
move to the target is slightly different to the standard bresenham in that you
only ever calculate the points downwards, never across. So you may end up with
stepped lines, because you are filling though this doesn't make a difference.
This method (if you understand it, I don't think I would) should be faster than
drawing the lines then filling IF you are using the processor. Another BIG
problem with my idea though is that from a list of lines you have to sort them
into a list of two lines with y coords in decending order. Whether it goes into
the list for the left hand side of the object or the right is what you would
have to work out (I could never really figure that one out). The book only drew
a line at a time and filled at the end, this way it is constantly filling but
calculating points along two lines simutaneosly. Got that? I hope so. Sorry if
this is really badly written but I am using the online editor (telnetted from
unix), during my lunch break and I am supposed to be looking around the NOVELL
area really.
>> Officially it's called the FX chip, but the name on the chip was
>> (alledgedly) Mario.
Ah yes. I remember now.
>> This method (if you understand it, I don't think I would) should be
>> faster than drawing the lines then filling IF you are using the
>> processor.
Okay, I think I see what you're saying. If I'm using the CPU, I should do
this:
*
***
*****
***
*
instead of this:
* *
* * ***
* * -> then fill -> *****
* * ***
* *
Yeah, that makes sense.
>> The book only drew a line at a time and filled at the end, this way it
>> is constantly filling but calculating points along two lines
>> simutaneosly.
That's what I saw. It seems that using the blitter to fill and calculating
points in parallel should make things _quick_, though. The book isn't at all
quick, at least not in the first example — a 286-12 is more competent! And
yes, I know that the first example only used one buffer, so it wasn't doing
much parallel processing. But for parallel processing to speed it up very
much, the "line" drawing would have to take about the same amount of time as
the blitting. If the blitting takes a lot more time than the line drawing,
putting the line drawing in parallel won't speed things up very much, and vice
versa. :l
>> Sorry if this is really badly written but I am using the online editor
>> (telnetted from unix), during my lunch break and I am supposed to be
>> looking around the NOVELL area really.
Hey, you have my sympathy. I know what a pain that online editor is. 🙁
And I hope your boss doesn't visit this forum much. <g>
BTW, sorry for the lag in my response. I just got over two exams. 😛
– Jim, on AP!
Actually, I haven't had much time to read my messages lately anyway. The only
person here that is ALLOWED to use compuserve is now off work, so I cannot
pretend that the phone calls are his :-(. Anyway, how is it going. Have you
made any progress? Have you also thought about only drawing the changes to the
polygons? So keep each polygon seperately in memory, as each one changes you
could draw/erase the bits that need to be. Actually this is probably too heavy
to think about let alone code. Merge them and there you have it??? My brain
exploded thinking of that one. Did you ever manage to contact Jez San. He was
interviewed on teletext on channel 4 in the UK. There are another 5 SuperFX
games coming out. The reason there aren't more is that the chip adds $10 to
each game. The question on everones lips is, could someone get hold of them,
stick them on an expansion board and then you could use that. Anyway, good luck
and let us know how you get on.
Phill on UNIX (urgh).
Coming soon: Microsoft(tm) Government.
Hi, Phill! Sorry for the delay in the response. I had three exams this week
— two hard ones on the same day! 😉 But it's spring break now, and I actually
don't have any papers to write! Yahoo! <g>
>> The only person here that is ALLOWED to use compuserve is now off work,
>> so I cannot pretend that the phone calls are his :-(.
<g> If you subscribe yourself, you can use AutoPilot on your Amiga. No more
Unix blues (or is that monochrome greens? <g>)! B)
>> Anyway, how is it going. Have you made any progress?
I haven't even _tried_ to make progress — I've been too busy with other
garbage, such as studying. :l I should have some time this summer, though. (It
starts in May for me :). Or perhaps I'll spend some time on it next week —
that's doubtful, though, as I need to do a lot of learning about how to program
the custom chips directly, as well as other things.
>> So keep each polygon seperately in memory, as each one changes you could
>> draw/erase the bits that need to be.
Uh….
>> Actually this is probably too heavy to think about let alone code.
You got that one right. <g> Sounds _very_ memory-intensive, though.
I wish I could get my bookstore to order me a 680×0 programmer's guide. They
can't ever seem to find any. 🙁
>> Did you ever manage to contact Jez San.
I haven't tried yet.
>> The question on everones lips is, could someone get hold of them, stick
>> them on an expansion board and then you could use that.
Theoretically, yes. But Nintendo would never license them to anyone. 😉
– Jim, on AutoPilot!
Had another idea, using the blitter you could have a tripple buffer display,
displaying one, drawing one, clearing one. That may iron out some speed
problems. Or you could draw the screen with the processor and calculate the
maths using the blitter/copper/FPU (brain melted).