Suggestions for learning

[seuden]

My PC is in the living room

I have printed out some tutorials as I would really like to start coding but I know she'll need "entertaining" all of a sudden if I'm doing something.

[pmc]

Well, if you ever need a hand getting started coding then drop me a note and I'll try to help you out.

[pmc]

Originally Posted by Leffmann

there are two other quirks in the blitter line draw mode you have to work out before it will draw outlines that can be filled correctly:

First, you have to normalize your lines so they are drawn either always upwards, or always downwards

Per the tutorial nature of this thread I thought I'd clarify as to what I found this means in practice just in case anyone wants to do this with their line draw code.

Taking it that in this case we want to draw all our lines upwards, you have to always make sure that y1 < y2. If not, you have to swap y1 and y2 around to force y1 < y2.

Now, *if* you have to swap y1 and y2 around, then you *also* have to swap x1 and x2 around before you draw the line. If no swapping is required you can just draw the line.

Additionally, you only need to choose between four of the eight possible line draw octants using this method as there are only four that fall in the upwards direction.

[pmc]

Et voila - one filled cube.

[gilgamesh]

Beautiful.

[BippyM]

I bow

[pmc]

Thanks chaps but there's still definitely some additional work required.

Currently this runs with 3 bitplanes (8 colours max) and the blitter work required to clear the screen, draw the lines and fill the polygons means that, along with the vector calculations as they stand, there isn't very much raster time left - I couldn't make the cube much bigger for example.

Also, currently it can only draw / fill in three colours - colour 1, colour 2 and colour 4. Basically this is because, using these colours, it only has to draw lines once to each of the separate bitplanes ie. no dual drawing of lines into two or more bitplanes to get intermediate colours works at the moment.

Still much more work and probably some rewrites to do on the routine as a whole before I can get anywhere near a lightsourced cube I reckon...

[gilgamesh]

I'm trying to get my mind around the chipset atm, and I can't see the problem with more than three colors. (Probably because I don't understand the matter.)

I mean, an opaque cube can show 4 sides max at one point in time. Can't you compute the shade (by the normal's angle to "lightsource", no funky phong stuff, just one color per side), write it to the first four color register and that's all?

EDIT: Ok, not the first four color register but 1,2,4,8.

[pmc]

Originally Posted by gilgamesh

I'm trying to get my mind around the chipset atm

Why...? Gonna start making demos...?

Originally Posted by gilgamesh

Can't you compute the shade (by the normal's angle to "lightsource", no funky phong stuff, just one color per side), write it to the first four color register and that's all?

Yep, you certainly compute the colours like that for simple lightsourcing - that's the way I intend to do it anyway - compute colours, write to regs, draw faces & fill.

However to draw an "in between" colour (col 3, 5, 6 or 7) in a three bitplane display you have to write the same lines into two or more bitplanes which obviously takes more time than just writing the lines to one bitplane.

Also, using the blitter to clear the screen and fill the polygons takes more and more time the more bitplanes it's doing this for.

That's what I was getting at in regards to rewrites and additional work to do - I was more thinking in terms of gaining speed and therefore time available to do more on the screen at once other than just the cube. I'm always thinking in terms of demos you see.

[gilgamesh]

Originally Posted by pmc

Why...? Gonna start making demos...?

Maybe a little microdemo someday. Right now I'm learning how the chipset works and write it down in the wiki. The Wiki would benefit from your knowledge, btw.

Originally Posted by pmc

However to draw an "in between" colour (col 3, 5, 6 or 7) in a three bitplane display you have to write the same lines into two or more bitplanes which obviously takes more time than just writing the lines to one bitplane.

Also, using the blitter to clear the screen and fill the polygons takes more and more time the more bitplanes it's doing this for.

As far as I understand it, the palette can have empy spaces. Therefore you can do something like this:

1. clear screen
2. compute colors c1,...,c4
3. set registers COLOR01:=c1, COLOR02:=c2, COLOR04:=c3, COLOR08:=c4
4. start blitter to paint cube, using only COLOR01, COLOR02, COLOR04, COLOR08

Of course you sacrifice memory for speed by that. Then each bitplane controls one and only one color. Right?

[pmc]

Originally Posted by gilgamesh

Maybe a little microdemo someday.

\o/

Originally Posted by gilgamesh

Right now I'm learning how the chipset works and write it down in the wiki. The Wiki would benefit from your knowledge, btw.

I know this is gonna sound dumb but: what wiki...?

I'm sure there's guys here (StingRay, Leffman etc.) who are much better qualified to give you worthy insights but anything I can give, you're more than welcome.

Originally Posted by gilgamesh

As far as I understand it, the palette can have empy spaces. Therefore you can do something like this:

1. clear screen
2. compute colors c1,...,c4
3. set registers COLOR01:=c1, COLOR02:=c2, COLOR04:=c3, COLOR08:=c4
4. start blitter to paint cube, using only COLOR01, COLOR02, COLOR04, COLOR08

Of course you sacrifice memory for speed by that. Then each bitplane controls one and only one color. Right?

Exactly correct.

Looks to me like you think in exactly the right way to do some nice code - I'm looking forward to your first demo!

That's step by step what I'm gonna add to the filled cube routine next so it becomes a lightsourced filled cube routine. Hopefully I can post the working result here soon.

[StingRay]

Originally Posted by pmc

Currently this runs with 3 bitplanes (8 colours max) and the blitter work required to clear the screen, draw the lines and fill the polygons means that, along with the vector calculations as they stand, there isn't very much raster time left - I couldn't make the cube much bigger for example.

Some obvious speed up tips:

- store min/max values of your object (can be done in your line drawer or in some little extra routine) to create a "bounding box", that way never have to clear/fill the whole screen

- use interleaved bitplanes so you can fill/clear several bitplanes with one blitter start

Originally Posted by gilgamesh

As far as I understand it, the palette can have empy spaces. Therefore you can do something like this:

1. clear screen
2. compute colors c1,...,c4
3. set registers COLOR01:=c1, COLOR02:=c2, COLOR04:=c3, COLOR08:=c4
4. start blitter to paint cube, using only COLOR01, COLOR02, COLOR04, COLOR08

Of course you sacrifice memory for speed by that. Then each bitplane controls one and only one color. Right?

While this is correct you will need an additional bitplane. Not always what you want.

[pmc]

Originally Posted by StingRay

store min/max values of your object (can be done in your line drawer or in some little extra routine) to create a "bounding box", that way never have to clear/fill the whole screen

Kind of along these lines I manually set my clear and fill blits to only clear / fill the parts of the bitplanes that contain the cube.

Originally Posted by StingRay

use interleaved bitplanes so you can fill/clear several bitplanes with one blitter start

Probably me being stupid again but how do you mean interleaved bitplanes?

Originally Posted by StingRay

While this is correct you will need an additional bitplane. Not always what you want.

I agree, I don't want to add another bitplane - in fact I probably couldn't speed wise.

Besides, I'm not sure I really need a fourth separate colour - my cube only ever shows three sides maximum at any one time so three colour regs should be fine for my needs and I'm already using three bitplanes.

[gilgamesh]

Originally Posted by pmc

what wiki...?

Read what happens to people who don't know about the wiki...

http://eab.abime.net/showthread.php?t=51243

from #28 onward

[WayneK]

pmc: interleaved bitplanes are just using your screen buffer as:
<screenwidth pixels of bitplane 0>
<screenwidth pixels of bitplane 1>
<etc.>

This way you just adjust your modulo values and you can write to them as if they were 'normal', but you get the advantage of being able to clear with only 1 blitter start (as Sting said). Also good for blitting multicolour bobs etc. quickly... multiple uses

[pmc]

Ah, OK. Makes sense. Thanks WayneK.

Now that I've done a few things with wireframe vectors I definitely need to rewrite my vectors routines so they're more suited to filled stuff.

From what I've discovered so far they need to be better optimised to gain as much speed as possible for the additional work required and I also need to add extra functionality, for example clipping so I can move things around the screen and stuff.

Now just need to get to feel like I can be bothered to actually do it.

While I'm here though I might as well ask another question:

All this stuff so far has been fine for convex vectors, but what about concave (sometimes called inconvex - usually in Anarchy demos ) vectors?

I take it some kind of sorting / painter algorithm is needed that draws things that are further away first and then overwrites them with things that are closer?

[pmc]

Well chaps, check the attached Amiga executable for a light sourced filled cube.

The code for this one is a complete and utter ugly hack but it works and in doing it I've learned some interesting things.

So, does this mean I'm 1337 now then Stinger...?

[gilgamesh]

What? I could watch this on end! Great work

I don't know if z-buffer is possible on an Amiga. So I looked for examples and thought of "Alone in the Dark" to be the first. This lead me to Alpha Waves (Matt Barton mentioned it...) and know what? The whole source code for 68k assembler is on the net.
Video & Discussion
Source

[pmc]

What's z-buffer...?

I'm too lazy to spend any proper time or effort understanding other people's sources - trying to work out what they've done with their data and why they're manipulating it this way or that way. Too boring. I'd rather try coding it myself! \o/

[StingRay]

Originally Posted by pmc

So, does this mean I'm 1337 now then Stinger...?

Lightsourced vector cube == you're an official elite coder now.

Originally Posted by gilgamesh

I don't know if z-buffer is possible on an Amiga.

If you understand how z-buffer works you'll realize that Z-Buffer is possible on Amiga but you don't want to do it on 68000.

Originally Posted by pmc

What's z-buffer...?

It's a very simple algorithm to draw correctly sorted objects. You store the z-values of the objects in a buffer (the z-buffer). For each(!) pixel you compare the value in the z-buffer with the actual z-value of your object and draw the pixel if act-z<z-buffer. Very simple to do and very slow (in software anyway) which is why it's not suitable for 68000 (and obviously it only works in chunky mode).

Attached is the source of my old z-buffered texture mapper, reading the source should make it very easy to understand how z-buffering works (and why it is slow).