Suggestions for learning

[gilgamesh]

Somehow you will have to take perspective correction into account. I was not aware of that. Hm, tricky...

EDIT: There is still the option of breaking the facets into tringles, and checking these for hidden points. But there ought to be a more elegant way...

[pmc]

Originally Posted by gilgamesh

But there ought to be a more elegant way...

You're right, there should be and there is. I avoided searching for "proper" ways to do hidden line removal as I wanted to try my own ideas (and, as it turned out, yours too gilgamesh ) first.

I've been playing around with tying my go at hidden lines with yours but all I'm doing is hacking at bits of code trying to squeeze a working hidden line cube out of it. That's ridiculous - even if I get it working it won't work for any other objects so it has to stop!

Instead I googled hidden line removal and found a short wikipedia article that mentioned an algorithm by a fella called Arthur Appel: "The Notion of Quantitative Invisibility and the Machine Rendering of Solids".

Time to investigate how to do it properly.

[gilgamesh]

that sounds fun

Originally Posted by Blinn

All problems in computer graphics can be solved with a matrix inversion.

Originally Posted by Knuth

Premature optimization is the root of all evil.

[StingRay]

Originally Posted by pmc

You're right, there should be and there is. I avoided searching for "proper" ways to do hidden line removal as I wanted to try my own ideas (and, as it turned out, yours too gilgamesh ) first.

While that is good I wouldn't waste too much time trying to find a solution that in the end (if at all) will only work for one object (the cube in that case). (NB: Are there any other objects than cubes? I don't think so! Cubes == awesome \o/).
Anyway, inform yourself about normal vectors and you shouldn't have much problems to implement proper HSR then. Normal vectors are useful for light sourcing too btw.

[gilgamesh]

Originally Posted by StingRay

Anyway, inform yourself about normal vectors and you shouldn't have much problems to implement proper HSR then.

As long as it is convex.

[StingRay]

Originally Posted by gilgamesh

As long as it is convex.

There are a lot of things that can be done for inconvex objects. However, so far we're still speaking about cubes here. And since no other objects than cubes exist (this is a fact :P) there is no problem anyway.

[pmc]

Originally Posted by StingRay

And since no other objects than cubes exist (this is a fact :P) there is no problem anyway.

LOL. If I extrapolate from this universal truth that cubes are the only vector object it must also be true that, seeing as I made a vector cube, I must already be a vector graphics guru! Woohoo for me \0/

Originally Posted by StingRay

Anyway, inform yourself about normal vectors and you shouldn't have much problems to implement proper HSR then. Normal vectors are useful for light sourcing too btw.

I've read about using vectors which are normal to an objects faces for determining visibility and intensity of illumination in the book Amiga Realtime 3D Graphics.

Unfortunately I think hidden lines has to be solved by alternate means but I read that Appel guy's paper on hidden lines and increased my knowledge of the subject by about 0.0001%, perhaps less - too complex for me - I need words of one syllable.

I've kind of got this feeling hidden lines might defeat me for now...

By the way Sting, not sure how far you read back in this thread but I posted an optimised version of my original 3D cube routine. Any chance you could run this through your speed tester program you used on my original source so I can compare how much quicker I made the routine by optimising?

No worries if you're busy / too bored of my amateur routine to bother () I was just curious.

[StingRay]

Originally Posted by pmc

LOL. If I extrapolate from this universal truth that cubes are the only vector object it must also be true that, seeing as I made a vector cube, I must already be a vector graphics guru! Woohoo for me \0/

Everyone who can draw realtime vector cubes (shameless plugs ftw :P) is awesome. :P

Unfortunately I think hidden lines has to be solved by alternate means

True indeed, didn't read the thread properly

I've kind of got this feeling hidden lines might defeat me for now...

Then try something else. You've got your basic vector routine working, there's a lot you can do with it. =)

By the way Sting, not sure how far you read back in this thread but I posted an optimised version of my original 3D cube routine.

Only quickly checked page 3 this morning when I saw Gilgamesh's post. =)

Any chance you could run this through your speed tester program you used on my original source so I can compare how much quicker I made the routine by optimising?

Will do when I'm back home.

No worries if you're busy / too bored of my amateur routine to bother () I was just curious.

Nah, I'm not bored, it's interesting to follow your progress! Reminds me of a time long gone by when I, instead of sleeping, (tried to) code(d) various things in the night and went to school next morning w/o any sleep. :P Those were the days.

[pmc]

Originally Posted by StingRay

Everyone who can draw realtime vector cubes (shameless plugs ftw :P) is awesome. :P

I'd have to say that those who can draw loads of them all spinning at once under a cool spinning logo with music and text writers and scrollers are just that little bit more awesome though. Fixed by Grandpa Sting. LOL

Originally Posted by StingRay

Then try something else.

Gonna have to - otherwise my wire vectors part of the top secret Retro Megademo I'm making with Vortex will suck way too much ass to be included.

Originally Posted by StingRay

Only quickly checked page 3 this morning when I saw Gilgamesh's post. =)

Originally Posted by StingRay

Will do when I'm back home.

No worries man - that would be much appreciated.

Originally Posted by StingRay

Nah, I'm not bored, it's interesting to follow your progress! Reminds me of a time long gone by when I, instead of sleeping, (tried to) code(d) various things in the night and went to school next morning w/o any sleep. :P Those were the days.

Cool. Wasn't it nice to only ever have to worry about school and coding though! In my schooldays I was way too lame to be coding anything and now, as punishment, I have to try to squeeze the coding in around a whole load of other boring grown up shit like working and paying the mortgage.

[Leffmann]

Originally Posted by pmc

I've read about using vectors which are normal to an objects faces for determining visibility and intensity of illumination in the book Amiga Realtime 3D Graphics.

Unfortunately I think hidden lines has to be solved by alternate means but I read that Appel guy's paper on hidden lines and increased my knowledge of the subject by about 0.0001%, perhaps less - too complex for me - I need words of one syllable.

You're just a tiny bit of structure and a few dot products away from drawing (convex) hidden line objects. Don't think in lines, think in faces. You have all the code and knowledge to make it work, you just need to determine if a face is hidden, and if it is you just don't draw it.

[pmc]

Thanks for the encouragement Leffman - don't worry, my journey will continue!

What I wanna know is when are we gonna see your latest production?

[Leffmann]

Oh I'm struggling with procrastination and a lack of focus you've never heard the likes of Here's my "latest" stuff though from mid 90's or so: [ Show youtube player ] and I'll be sure to post any updates

[pmc]

Coooool routines Leffman!

Man, this gets depressing - every other coder on here kicks my ass!

[StingRay]

Originally Posted by pmc

I'd have to say that those who can draw loads of them all spinning at once under a cool spinning logo with music and text writers and scrollers are just that little bit more awesome though. Fixed by Grandpa Sting. LOL

I am 100% sure that you will be able to do the same too! You can code scrollers and you have your vector routine, there's not much more in that intro! =)

Originally Posted by pmc

No worries man - that would be much appreciated.

The result of the speedtest is attached.

Originally Posted by pmc

Cool. Wasn't it nice to only ever have to worry about school and coding though! In my schooldays I was way too lame to be coding anything and now, as punishment, I have to try to squeeze the coding in around a whole load of other boring grown up shit like working and paying the mortgage.

Yeah, great were those days, fridge magically filled "itself" , nothing much to worry about and just having a lot of time. Damn, where have 'em days gone?

Originally Posted by Leffmann

Oh I'm struggling with procrastination and a lack of focus you've never heard the likes of Here's my "latest" stuff though from mid 90's or so: [ Show youtube player ] and I'll be sure to post any updates

I'd like to see some new stuff from you too. And I still like that infinite chesstunnel, chessboards are as awesome as cubes. \o/ Oh, and some of the comments (like the one from "Tdarkshadow") crack me up

[pmc]

Thanks for doing that speedtest again StingRay, really interesting - top man.

It does leave me with some questions though:

I misread the results of the first speedtest - I read them as: you've taken 88 lines out of a max available of 91. I see now from this second test that it means something more like: it takes between 88 and 91 rasterlines to execute.

So, first dumb question is: how many rasterlines max are there actually available for a vbl interrupt routine to run in?

Second dumb question is: how comes taking away 68 or so muls from the first routine only saves 12 or so lines worth of execution time? I was thinking I'd probably have saved more.

EDIT: I forgot to say, yeah Leffman - StingRay's right - that chessboard zoomer thing rules! It was definitely my favourite.

[Leffmann]

Your VBL interrupt simply starts at line 0 and keeps running until you return from it regardless of how many lines and frames it needs to finish. In some cases you might want to take into account that your bitmap display starts at line $2c or whatever, but meassuring code in rasterlines is not really correct because ultimately it's about clock cycles and their contingency.

All devices (CPU, blitter, bitmaps, sprites, copper, audio, disk) share the chip memory but only one can access it at any given time. The CPU has after the blitter the lowest priority, and a piece of code that needs 10 lines to complete during your VBL period (or any other part of the frame where there's equal amount of DMA going on, the VBL period and running code in interrupt mode is no different in these regards) might need 100 lines when run during a time when other devices with higher priority might need to access the memory a lot, f.ex in the middle of a 6 bitplane display.

One good thing is that the CPU often spends more cycles working internally than accessing the memory (at least in an A500 chip mem only context) and so other devices can get access to the memory and work in parallel. With lengthy instructions, such as MULS and DIVS that might need 1 cycle to read the memory and another 50 or more cycles to do internal processing, you could "earn" many clock cycles by f.ex letting the blitter work in parallel during this time. This is probably why your 68 less MULS don't make a bigger difference.

[StingRay]

Originally Posted by pmc

I misread the results of the first speedtest - I read them as: you've taken 88 lines out of a max available of 91. I see now from this second test that it means something more like: it takes between 88 and 91 rasterlines to execute.

Yep, that's correct. First value shows the currently used raster time, 2nd value shows the maximum needed raster time.

Originally Posted by pmc

So, first dumb question is: how many rasterlines max are there actually available for a vbl interrupt routine to run in?

You have 312 (or was it 313?) raster lines per frame.

Originally Posted by pmc

Second dumb question is: how comes taking away 68 or so muls from the first routine only saves 12 or so lines worth of execution time? I was thinking I'd probably have saved more.

12 raster lines can make all the difference in the world! See Leffmann's post below.

Originally Posted by Leffmann

but meassuring code in rasterlines is not really correct because ultimately it's about clock cycles and their contingency.

And how do you want to show the used cycles on screen? The more clock cycles the code needs the more raster lines are used so it's a good approximation to get an idea of how fast the code is! 100% accurate speed measuring is impossible anyway.

[pmc]

Originally Posted by StingRay

You have 312 (or was it 313?) raster lines per frame.

OK cool. Thanks for confirming.

Originally Posted by StingRay

12 raster lines can make all the difference in the world!

In that case all hail me and my expert optimisation!

@ Leffman - nice explanation. Basically it seems to come down that code execution speed is a pretty inexact science due to there being so many factors that can effect the execution time of the same bit of code.

Bearing this in mind, the rasterline timing approach seems to me to be the best way of getting some kind of tangible idea of a routine's execution time. As the rasterline timing is measuring across a routine's complete execution time you're at least getting a better idea of delays introduced by competing DMA access during execution etc. than you'd have if you just added up the cycle times of all the 68k opcodes in the routine.

[Leffmann]

Yeah I actually agree with both of you, it's a good visual indicator which in the end it tells you what you want to know: will this run in 1 frame or not? I just think it's important to know the inner workings of things because it allows you do adapt your code to become more efficient.

[Toni Wilen]

Semi-offtopic:

You can use latest winuae betas 'v' debugger command to see exactly how DMA and CPU use bus cycles. (undocumented feature: use 'V' to see current frame, 'v' always shows complete previous frame)

It should be very very accurate now (major rewrite few weeks ago). Pre-1.6.2 cycle exact was only approximately cycle-exact, now it is real, proper cycle-exact emulation. Believe it or not