@Daytona675x
>VBO is just a package full of plain bytes
But will it avoid the "write from buffer to GPU vram" part ?
I mean perhaps Nova will proceed as usual : copy reordered data from a buffer to vram but only skip all reordering for each items

>RGBA8 data converted to RGBA float
Interesting too

Anyway we just need a new VBO mode (let it call W3DN_RAW_ACCESS) that dont copy GPU vram to/from a reordered buffer but only let it accesses the VBO data at their place in the GPU vram (so it is the cpu that will manage the reordering & copy)

> the same data ? I mean , if there is DMA to transfer bitmap to VRAM

Yes,For Wazp3D57 I have made some code that hack a bitmap transfer to be used to copy vertices to VBO.
(ouuh what a hack but it works )

It changed almost nothing to speed on Sam460 & X5000 but dont know if those machines use dma for that

>about BufferUnlock of warp3dnova, there is no mention about any big->little endian conversion

IMHO what I understood:
There are differents method for updating the VBO
but in fact Nova just read and/or write the data
When you lock it (can) read/reorder the VBO data to a buffer that you will access.
When you unlock it (can) write/reorder the buffer to the VBO data.
As reordering is done Nova side you never accesss to real data that are on the GPU VRAM but on a reordered buffer

You can also do write only (ie write all new vertices values from your buffer)
or read only (ie read some GPU datas)
or read/write (ie change some vertices)

Certainly let Nova do the reordering was not a good idea as datas are then acessed several times (vs a cpu that will write to real GPU vram directly the reordered datas)

See below Nova doc
// W3DN_STATIC_DRAW: Written:(CPU) once Read: rendered many times
// W3DN_STATIC_READ: Written:(GPU) once Read: CPU many times
// W3DN_STATIC_COPY: Written:(GPU) once Read: rendered many times
// W3DN_DYNAMIC_DRAW: Written:(CPU) occasionally Read: rendered many times
// W3DN_DYNAMIC_READ: Written:(GPU) occasionally Read: CPU many times
// W3DN_DYNAMIC_COPY: Written:(GPU) occasionally Read: rendered many times
// W3DN_STREAM_DRAW: Written:(CPU) frequently Read: rendered a few times
// W3DN_STREAM_READ: Written:(GPU) frequently Read: CPU a few times
// W3DN_STREAM_COPY: Written:(GPU) very often Read: rendered a few times

@kas1e
>not the VBO creation/handling it seems

Are you sure ?
(When I coded Wazp3D57 with Nova rendering) I have tried differents methods for updating a VBO but it seems to be slow

Perhaps having a patched MiniGL that will update (say) 11 times the VBO will allow to know how much time a VBO update is REALLY during in a REAL program
(delta time / 10)

I mean when I was testing Cow3D on Wazp3D57-> Nova it was (say) 80 % of a real waRp3D (massive VBO update but one time) so bandwith seems +- ok

But when I was testing Quake2 (real life test) it was 1-2 FPS ... weird

An other thing:
Also when I was testing a simple raymarching test i found that Nova GLSL seems to have very strange bugs: I mean all is fine when GLSL code is compiled but strange artefacts appears like the GLSL code was computing badly at some pixels (like a rounding fpu bug)in frag shader

Hello

The whole rezarchive need to be reordered
I whould do a file search containing "rootDirectory" to found the source whith his définition

Aldo the structure is read a part after a part
So must reorder all fields from .version in the 127 bytes range
Then all fields from .offset for 131 bytes
From .size for 135

Etc...

So it works too
Thanks

Hello

I was used to do that (on classic 68k) to obtain an asm source from a C sources that is mixed with the original C source

gcc -noixemul -O3 -S fillpoly.c
gcc -Wa,-adhln -g -noixemul -O3 -c fillpoly.c > fillpoly-mixed.c


So I can read the C instruction and how it was converted to asm

But this syntax dont seems to works for GCC/ppc/OS4
Do you know a gcc version that still support this ?

Thanks

For information it was giving a "mixed" source like that

271:fillpoly.c **** Frag[1].L.u=Frag->L.u + du;
1209 .stabd 68,0,271
1210 039a 2428 000C movel a0@(12),d2
1211 039e D48C addl a4,d2
1212 03a0 2142 003C movel d2,a0@(60)

272:fillpoly.c **** Frag[1].L.v=Frag->L.v + dv;
1213 .stabd 68,0,272
1214 03a4 2428 0010 movel a0@(16),d2
1215 03a8 D487 addl d7,d2
1216 03aa 2142 0040 movel d2,a0@(64)

@Crisot

We already discussed about a problem about secondary color (specular) If i remenber right it worked only with a float color not an RGBA32 one.
Apart this it seems that something no more worked with some recents Warp3D about multi-texturing:
for example on my Sam460
from my Aminet/Microbe3D package, start Demo-View-ppc, then load data/JulietStriped/JulietStriped.obj ==> now looks ugly . It should looks like this :
http://thellier.free.fr/Docs/Microbe3D.html

Hello

New Wazp3D 57 with Nova rendering thatfix problems with ChromiumBSU and NeverBall
http://thellier.free.fr/Wazp3D57c.zip

Alain Thellier

OK

I have a 32 bit cygwin cross-compiling environement too: is your gcc 32 bits ?

Alain

Hello

Nice

Kas1e, is your lto gcc available somewhere ?

Many Thanks

@mufa

OK i have fixed problems with ChromiumBSU and NeverBall
So expect a new Wazp3D57 release soon...
Badly I have found also an other bug in Quake3 that I will fix before any release
Also I am still not satisfied with speed...

The NeverBall bug was due to some code I implemented recently to speed up W3D_DrawArray but I forgot the "base" value
Nothing related to Nova renderer in fact... just a stupid typo

@mufa

Also I didnt said it but if you use programs that use or may use multi-texturing you need to have glslangvalidator installed as Wazp3D do "on the fly" GLSL compilations in this case.

I didnt test much programs with Wazp3D57:
Quake3-68k: demo works, game crash
Quake3 ioquake ppc: game & demo works (slow) but crash on exit
Cow3D: works
Microbe3D: works including multi-texturing and other effects
http://thellier.free.fr/Wazp3D-57-multi2.png
http://thellier.free.fr/Wazp3D-57-multi3.png
http://thellier.free.fr/Wazp3D-57-multi4.png
http://thellier.free.fr/Wazp3D-57-multi5.png

If I didnt test much programs it was because I was focused on a correct multi-texturing implementation and speed.
Removing bugs for all programs was not a goal at this stage...

@mufa

try
Perspective:No (fast)
or
Perspective:Simulated


>all games when closing cause the system to freeze.
Yes I know this bug this is also why it is an unfinished product not ready to release...
Not all programs freeze: seems to affect only the minigl ones (not the pure Warp3d progs)

@all

Please note that Wazp3D 57 is not a finished product in a ready to release format
It is only because Hans evocated it that I recompiled it today.

Anyway having 1-2 Fps let suspect that something goes wrong and that Wazp3D fall back to software rendering


Have you tried Cow3D ? because if you obtain less than 100fps with it then it is software rendering for sure

The correct way is
1) start your prog
2) set in Wazp3D-Prefs
"+Renderer:Nova3D"
"Hack Texs:RGBA (fast)"
3) close your prog (so a Wazp3D.cfg is saved)
4) restart your prog

>wazp3d is has too much settings

True but most of them are only here to "economize" the software rendering
When it use a fast hardware renderer then you can let the same (best) options for all the cases

Anyway I am not forcing anyone to use WaZp3D ;-P

Hello
I have not touched it recently but here are the latest sources of Wazp3D57 with Nova rendering compiled today.

Now manages multi-texturing and is a little faster: Cow3D 123 FPS vs. 142 on the true WaRp3D

http://thellier.free.fr/Wazp3D57b.zip

Still no interest for those who have the true WaRp3D that works

>edit Wazp3d prefs to activate the "Nova 3D"
Yes you absolutely need to set in Wazp3D-Prefs
"+Renderer:Nova3D"
"Hack Texs:RGBA (fast)"

or put the given Wazp3D.cfg in your game directory


Alain

@kas1e

>why it happens only with Q3[...] It should be in any game

From my own experience in debugging : never assume "It should be" but only check what really is/happen in the prog.


So in this case: have a look to what bitmap is currently used ... just to be sure.

Alain

Perhaps it draws in screen's bitmap not the window one. I mean as window is bigger it must have a separate bitmap (dont have a shared bitmap for dcreen and bitmap)
Search for "->bitmap" use in sources

Hello

>I'm converting the endianness and copying 16 KiB

Is this conversion stuff really a good thing in any case ?
I mean as in most case we must peek the data and read them manually to write them in the vbo then perhaps we can order them during the process

I mean if we read XYZ then copy it elsewhere in vbo then read UVW then copy it elsewhere in vbo then RGBA then perhaps can reorder them too...

I mean : disabling the auto-reorder feature can help in some case

For example I have declared that am using this version for GLSL syntax (that is recommended one for us Amiga users):

#version 310 es

then I must use the the "in" and "out" attributes
like this

// in parameters
in layout(location = 0) vec4 gl_Vertex;
in layout(location = 1) vec3 gl_MultiTexCoord0;

// out parameters
out vec4 Colour;
out vec3 TexCoord0