Unfortunately, I never wrote a bit of OGL, so my knowledge about it is just NULL.

I'm very surprised, MiniGL got a such function, W3D_ReadZPixel(). Sad MiniGL does not have an equivalent.

Since MGL use W3D for rendering, no way to get the context, to use this W3D function?

_________________
AmigaOne XE --- 7455A@1400 --- Radeon 9000 Pro --- RAM 2GB --- SSD 40GB

@Crisot
Quote:

I'm very surprised, MiniGL got a such function, W3D_ReadZPixel(). Sad MiniGL does not have an equivalent. Since MGL use W3D for rendering, no way to get the context, to use this W3D function?

I think its all not _that_ easy. MiniGL have all that functions, but looks like in term of glReadPixel its done the same way as on morphos. What the reasons for it - i do not know really .. I will try contact with Hanz, maybe he can help here. Maybe its some speed/overhead reassons, maybe drivers not support something, maybe warp3d do it already wrong.

From all the z-buffer tests over warp3d on classic amigas, and on ng amigas, i can say that z-buffer realization suck hard and very much. Pretty possible, that from the side of MiniGL all done fine, just warp3d suck something :)

Some time ago Alain (author of wazp3d) done a simply warp3d-based z-buffer example called "cow3d", and it have tons on problems and differences even between warp3d on classic with voodoo3, and warp3d on ng with radeons. Pretty possible that we have exactly that problem (or, maybe realisation of glReadPixel are the same incompilte as in morphos's TiniGL by some other reassons).

_________________
Join us to improve dopus5!
zerohero's mirror of os4/os3 crosscompiler suites

Quote:

@Crisot What about adding missing stuff to minigl (its opensource) ?:) I can help with all the info/tests/etc. You know warp3d/ogl too, so for sure you are right person for :)

Actually I think that Hans would be the best person to ask that.

Varthall

_________________
AmigaOne XE - AmigaOS 4.1 - Freescale 7457 1GHz - 1GB ram

@kas1e

Hmmm can't tell you. I found zbuffer works pretty well with Warp3D on our Radeon, at least on my custom engine. I was really surprised by its precision and reliability.

Maybe it's a depth range problem? Maybe there is a bug in MiniGL? Or maybe this Warp3D function doesn't work (I haven't tryed it).

Anyway that's very funny to see Cube use the 2D screen to calculate shoot trajectory

_________________
AmigaOne XE --- 7455A@1400 --- Radeon 9000 Pro --- RAM 2GB --- SSD 40GB

@ Varthall

Well said.

Cheers

_________________
Courtesy of SAM440Flex & Amiga OS4.1 only
Flex is 800mhz
A1000 with Classic 520 Amiga OS3.2.1
AmiKit 12
MorphOS PowerBook G4 (which can play youtube vids)

https://blitterwolf.blogspot.com

@Varthall

Trying to be smart ?:) You not know maybe, but Hanz works heavy on new drivers, on galium/mesa integration, and better if someone else will works on minigl as well. Hanz also say that he not in interest anymore to add to minigl anything, because all the time will spend on gallium/mesa.

In other words i know topic, and i know what i ask and from who, and who is better and for what, you can be sure :)

@Gebro
One more pointless comment from you as usual

_________________
Join us to improve dopus5!
zerohero's mirror of os4/os3 crosscompiler suites

Quote:

@Varthall Trying to be smart ?:) You not know maybe, but Hanz works heavy on new drivers, on galium/mesa integration, and better if someone else will works on minigl as well. Hanz also say that he not in interest anymore to add to minigl anything, because all the time will spend on gallium/mesa. In other words i know topic, and i know what i ask and from who, and who is better and for what, you can be sure :)

I was trying to be helpful. I'd like to see this problem in MiniGL fixed as well, if it will be possible (or if it will make sense). I didn't know that Hans has stopped working on MiniGL, makes sense since MiniGL was anyway a temporary solution for 3D acceleration.

Varthall

Last edited by Varthall on 08-Nov-2010 at 10:50 AM.

_________________
AmigaOne XE - AmigaOS 4.1 - Freescale 7457 1GHz - 1GB ram

Quote:

I'd like to see this problem in MiniGL fixed as well, if it will be possible (or if it will make sense). I didn't know that Hans has stopped working on MiniGL, makes sense since MiniGL was anyway a temporary solution for 3D acceleration.

Yep.. But still, gallium/mesa can take a big time (even 1-2 years maybe), and still old users (with old drivers and old card) will stack for all the times with minigl + warp3d (so it still make sense to fix minigl and warp3d as well).

Because galium/mesa for now will support normally only r300 and r600, and will not works on radeon9250/etc i think. So if someone will do some fixes in minigl its still will be good. I write mail to hanz yesterday after kiero's comments, but chances here are very small that hanz will expand glReadPixel (if problem in here exactly). Maybe its warp3d related problem , which not opensource, so it will be even more harder.

_________________
Join us to improve dopus5!
zerohero's mirror of os4/os3 crosscompiler suites

@kas1e

1 or 2 years?
you're sure?
if i remember correctly it didn't take that much on aros ?
(and kalamatee did it alone no ?)
i was under the impression it would take less than a year,
judging from what was said in recent reports and all ?
i understand it's a big task that will help amigaos a lot for modern 3d support but still i kinda hoped for 6months more or less for the first betas ..
about minigl compatibility, maybe it would be better to dump it altogether and reimplement it as a separate layer on top of mesa.. so minigl calls would be redirected to mesa ones ..
why keep both ..

anyway, nice work for porting cube1 !

Last edited by freeaks on 08-Nov-2010 at 09:12 AM.
Last edited by freeaks on 08-Nov-2010 at 09:10 AM.

@freaks
Quote:

1 or 2 years? you're sure? if i remember correctly it didn't take that much on aros ? (and kalamatee did it alone no ?) i was under the impression it would take less than a year, judging from what was said in recent reports and all ? i understand it's a big task that will help amigaos a lot for modern 3d support but still i kinda hoped for 6months more or less for the first betas .. about minigl compatibility, maybe it would be better to dump it altogether and reimplement it as a separate layer on top of mesa.. so minigl calls would be redirected to mesa ones .. why keep both ..

I only can speculate here of course , there is all in all a team will works, not one-two mans as for aros, but as far as i know, for AROS it was way long way too:

First port of mesa to Aros was done by Kalamatee, and this was based on the os3.x version of stormmesa (done by haage&parhtner if i remember right). So pretty old and on AROS was only in SW mode (slow and unusable for modern apps in other wordS). Dunno in what yeara it was done, i think all started somethere in the 2006-2007, but i can be wrong here. For long time it was only as static library (i.e. no mesa.libary or kind). Then , in the middle of 2008 DeadWood start to works on it , and with help of Kalamatee in august of 2008 they release mesa 7.0, as mesa.library , and thinks was HW accelerated at this point. Then, deadwood start to works on gallium. And in end of may 2010 , all this was done. And still, it was slow , and only in last weeks deadwood improve speed radically, and even now, he fix the bugs and trying to speed up the thinks.

So, in general, it take i think 3-5 years for all the mesa/galium way for AROS, but of course, some years was loose for nothing, and only 2009-2010 was really productive.

You can read the full story about how it all was done on aros3d.org.

By some expirience, and remembering how thinks develops on aos4, i think 1-2 year its way good :) Maybe even more, but that is a bit pessemistic of course.

Personally i hope, that we will se something done in the next year, and then, one more year for speedups/fixing bugs/etc.

_________________
Join us to improve dopus5!
zerohero's mirror of os4/os3 crosscompiler suites

Good work!

@People discussing depth buffer

glReadpixels depth buffer access is not implemented in MiniGL. I wrote code to attempt it when I was porting blender, however the underlying warp3d calls are not implemented for radeon cards (they may be for older voodoo etc) even if it was the process would be very slow. If I understand correctly radeon have very complex depth buffers with compressed data etc. which work well for depth comparisons during rendering but are not so easy to readback for this kind of depth comparison.

Even if the Warp3d code was working for radeons, the warp3d api returns a double float, which then needs converting to a single float for OGL slowing things down even more.

Last edited by broadblues on 08-Nov-2010 at 01:05 PM.

_________________
BroadBlues On Blues BroadBlues On Amiga Walker Broad

@broadblues
Quote:

Even if the Warp3d code was working for radeons, the warp3d api returns a double float, which then needs converting to a single float for OGL slowing things down even more.

Maybe even with converting it will be not very slow ? Maybe if you have some free time, we can test it exactly with that game ? (i mean warp3d call from minigl + conversion). To avoid writing that complex code for drivers from scratch

_________________
Join us to improve dopus5!
zerohero's mirror of os4/os3 crosscompiler suites

Thanx for this game is great! Now only what I need is icon set for Cube :)

_________________
--

Amiga x5000 ı o2o ı 4GB RAM ı RadeonRX580 | SBlaster Audigy Fx - AmigaOS4.1 FInal Edition

A1200 sandwich :)

Croatian Amiga portal

@VooDoo

See here...

http://www.amigans.net/modules/myalbum/photo.php?lid=338

That is what I need!

Where is link for download? dont see it!

_________________
--

Amiga x5000 ı o2o ı 4GB RAM ı RadeonRX580 | SBlaster Audigy Fx - AmigaOS4.1 FInal Edition

A1200 sandwich :)

Croatian Amiga portal

@kas1e
Great effort man!

_________________
SamFlex Complete 800Mhz System + AmigaOS 4.1 Update 4
Amiga 2000 DKB 2MB ChipRam GVP G-Force040 Picasso 2 OS3.9 BB2
AmigaCD 32

@VooDoo
This was only a very quick arrangement - I'm not completly happy with it and there's no "download link" yet ... While I'm working on my third icon release for 2010 I suppose I'll make some overhaul to the Cube icons - so they will be part of that 2010-3 release (sometime in december). In the meanwhile kas1e has time to find a solution to the depth buffer problem...

_________________
X1000|II/G4|440ep|2000/060|2000/040|1000

Uff,ok...again waiting...nothing new in Amiga world

_________________
--

Amiga x5000 ı o2o ı 4GB RAM ı RadeonRX580 | SBlaster Audigy Fx - AmigaOS4.1 FInal Edition

A1200 sandwich :)

Croatian Amiga portal

@crisot &kas1e
Quote:

I'm very surprised, MiniGL got a such function, W3D_ReadZPixel(). Sad MiniGL does not have an equivalent.

To implement this zbufferfunction there are 2 methods :
1) In minigl you modify glReadPixels to support also the zbuffer (DEPTH buffer) with a call to W3D_read zspan() then you rebuild minigl.library
Then you re-wrote (and patch) function W3D_read zspan() in Warp3D.library cause it dont works well for most current Warp3d drivers
With this method you fix minigl & warp3d

2) you modify directly the game source to use your W3D_read zspan() code but you need to get somewhere the Warp3D-context pointer to obtain the zbuffer pointer
With this method you fix only this game :-/

But implementing W3D_read zspan() (or W3D_writezspan ) is not easy cause the Warp3D-context dont describe the zbuffer format that this 3D card use
So you will need to find out yourself the zbuffer format:
float ? double ? UWORD ? WORD ? 24bit int ? in Intel or Motorola order ?
In fact you will need to write to zbuffer then check what kind of value has been wrote
Then it will be as easy as reading a line from an array


Alain Thellier