Perspective 3D Graphics

[stevepoole]

Hi Xora and All,
As requested I will post program updates on the subject here now, ( previously posted under the SQLUX section....)

Here is an example of simple output from the Wrapper3D_bas program : ( QL Graphics can be mixed with text and image files, and then all wrapped as textures ).

Regards, Steve.

[stevepoole]

Hi Folks,

Here is sample multiple output using tonights version :

Next will come some wrapping onto solid objects.

Steve.

[polka]

Hi !
I showed here
viewtopic.php?f=3&t=3238&p=33721&hilit= ... ive#p33721
a perspective transform method NOT using trigonometry, because I needed to do it with (16bits) integer arithmetic
(coded in FORTH indeed, on a BBQL)
Bye, POLKa

[stevepoole]

Hi Polka,

Yes, your forth code routine looks fine. But the QL seems to have always lacked Perspective animation programs in SuperBasic.

The 'text on a 3D sphere' image program was written back in the '80s, but the QL then was just too slow to encourage much further development.

But I did later write a 'perspective animator' for use with a ROM_disk on SGC, but again saving dozens of screens for replay took too long to be practical.

Rewritten in C++, they would have fairly zipped along, but I hate that language.... whereas QPC2 is an ideal prototyping interface.

So now with a decent fast laptop, I am taking a look again at the subject. The current version is aimed at wrapping textures onto 3D object surfaces, (cubes etc).

Work is currently held up by what may be possible toolkit bugs, which I am attempting to pin down. Regards, Steve.
_______________________

[stevepoole]

Hi Folks,

I tried mergeing two 3d programs, both of which work ok. Then I ensured there were no incompatibilities in the combined code.

If I run program one, the results are ok. Ditto for program two. then if I re-run program one, I get poor perspective pixel output definition.

After two days of searching, I find that RPIX% gets upset by the difference between a photon image and the #2 background graphics.

No joy reading the RPIX text file : I am stumped on this one ! ( The problem only seems to occur with certain merged progams).

Has anyone experienced such difficulties previously ? (The program uses Mode 32 & colour_native on QPC2).

Steve.
_____________

[pjw]

<>
If I run program one, the results are ok. Ditto for program two. then if I re-run program one, I get poor perspective pixel output definition.
<>

Whats "poor perspective pixel output definition" when it is at home? If you want my help, please either detail the circumstances and symptoms or send me a copy of the offending code. My contact details are on Knoware.no/Contacts. Or PM me.

[Derek_Stewart]

Hi

I wrote a SuperBasic program that displayed a rotating wire frame cube, on a QL with JS or Minerva roms.

See:viewtopic.php?f=3&t=2485&p=23910&hilit=cube#p23910

So there is mo recourse to C++ even if we had such a compiler on the QL

[stevepoole]

Hi Per,

Thanks for your offer of assistance. I shall indeed send you a PM.

Good perspective pixel output is when the projected image is finely detailed like the original #2 picture.

Poor output definition is when the projection is fuzzy and has 'moire' patterns in it.

I think the best policy is to let you run the prototype yourself, and see the output after running the second part of the code....

Here is a screen shot of the 'poor output', using a scale factor of 2.

Something is interfering during running of the second routines, causing incorrect pixel lookups, as can be seen at scale .5 !

Steve.

[pjw]

Hi Steve,

I received your program, thanks. I will take a closer look asap. However, let me reassure my many thousands of customers that RPIX% has nothing to do with it!

Steve, you can check this yourself: Add the following function to your code:

Code: Select all

2000 def fn RPX%(a, b, c)
2001 ret -33: rem mode 32 white
2002 enddef

Now replace all instances of RPIX% with RPX%. Of course it wont output the correct image, but after running your second program and then reverting to the first, the moire pattern is clearly visible in black and white. Ie, no RPIX% involved.

I agree something strange is going on, as the interpreter seems to get corrupted by something. I may have some time later or tomorrow to help you hunt it down. Let me know if you get there first, tho'!

[stevepoole]

Hi Per,

Many thanks for your rapid response. Glad to see that RPIX is not the cause of the corruption !

Tomorrow afternoon I will have time to spend trying to pin down the problem, during a major rewrite.

I never had problems like this before after mergeings. I doubt if there are any name-table problems, which can otherwise cause fatal errors.

It looks like it might be due to having too many global variables, as the program seems to be very heavy on memory usage. I will LOCALise all in due course.

Or, is photon moving blocks of memory around, as it converts or loads images ? At one instance, LIST showed the basic code had been truncated, after several runs...

I have written very much bigger programs, but never encountered this sort of corruption before !

Steve.