Roto Zooming

[Mike Halliday]

Can't remember if I have ever shared this code with you all, but with NickNack's plasma code I thought I would give you it.

Rotozooming.

For some reason PPL seems to be quite a bit slower than say QBasic when it comes to direct screen access :(

See what you all think of this.

Ta

Mike.

[lopez1de]

Looks nice, but it's ultaslow on my machine. 2 fps.

[Mike Halliday]

Looks nice, but it's ultaslow on my machine. 2 fps.

Yep, slooooow. Not sure if it is optimisable. Maybe one kind soul will have a go

[zehlein]

I had a go and managed to double the speed :D

I created an array for the sinus and cosinus stuff and kicked the lockinf.pixels$ out of the poke(). Those structures usually slow PPL heavily down.
Using the profiler I learned that it is not the poke() that slows the code, it is the maths.
Poke() as such takes 24% CPU time only, the computing of the address and value for the poking nearly takes the rest...
Replacing the for loops with while loop didn't have an effevt on speed...

Edit: ok, just played around a bit further. Using G_SetPixel without computing the poke-address and without locking/unlocking the screen gave me another 30% speed booooost :-)

[Mike Halliday]

Excellent.

With G_Setpixel and not locking the screen it runs at about 5 frames a second.

More impressive, but not like the original code.

I guess that its an issue with running under windows. - The original code is from QBASIC for DOS, which even running in a DOS Window still ran at over 25 FPS.

Not sure why PPL would be so much slower?

Oh well

[Nicknack]

i give a quick&dirty try to do the same, but used surfaces instead of pixel.
this doesn't solve your problem, but still it's a faster way to rotozoom :D

[Mike Halliday]

Wow, Yours is much faster. Surfaces look like the way to go.

I will further examine your code and see what gollities I can come up with.

Thanks

Mike

[zehlein]

YEAAAH!!

Took the code again, and guess what? Boosted it up to 18 fps!

So where is the miracle? I realized that using global vars slows the code down. I simply did a copy&paste with the code from the timer section to the paint section and used the vars as local. That's the job! Runs pretty smooth now.... :D:D

Edit: Replace the for-loop with the while loop. On my machine the app runs even at 21 fps now!

[Mike Halliday]

The math is definately the problem.

I tried to pre-calculate the colours into an array, and 10 mins after running the code I decided that it was taking too long. :(

Maybe the answer is to read the colour table in from a text file???

[Mike Halliday]

Can be made a bit quicker again by doing the math before the setPixel command.

Not much of an improvement, but it all counts,

Im sure there must be other optimisations we can do!

[zehlein]

This is the fastest I can get: 22fps, employing the while-loop trick.

[Mike Halliday]

Much quicker, but still not good enough to include in anything :(

Maybe NickNack's surfaces version could be incorporated to make it unbelievably quick?

[johnpetersen]

The roto zooming is really easy once. The basic idea is that you select an area in texture space that you will have to map onto the screen. The area you choose in texture space can have any shape, but things are much easier if you select a 4 sided polygon. Another possible simplification is to perform orthonormal roto-zooming, which means you map your texture from a rectangular area.
------------------
johnpetersen
Social marketing (http://www.drivenwide.com)

[Mike Halliday]

The roto zooming is really easy once. The basic idea is that you select an area in texture space that you will have to map onto the screen. The area you choose in texture space can have any shape, but things are much easier if you select a 4 sided polygon. Another possible simplification is to perform orthonormal roto-zooming, which means you map your texture from a rectangular area.
------------------
johnpetersen
Social marketing (http://www.drivenwide.com)

In theory yes, in practice a bit more difficult. NickNacks texture based zoom is the quickest so far. It is not possible at present to map a texture to a rectangular/polyagonal area as PPL does not support mapping textures (Only via surfaces)

If some kind soul were to write a 3d library for PPL that would help greatly!