>Could not compile shader "varying vec2 texCoord;

Bad GLSL syntax for this version must be
out vec2 texCoord;

>'texture' : can't use function syntax on variable
texture seems to be a GLSL function name so rename it to (say) tex0

>cannot convert from 'const float'
very strange : I think it should works
Anyway change "const float adjustFactor" to "float adjustFactor"

@Hans
This not so important to add bool support
As we can use int as bool
As we can test bits with a AND operator
I mean slightly modifying a shader (that used bool) will allow it to works...

Hello

>boolean expression expected
I already had this error too with a boolean (converted to int) like this
if(FlatColor)
Colour=CurrentColor;
was fixed this way
if(FlatColor==1)
Colour=CurrentColor;

As kas1e said your shader is not the one that contain Bool flipY
Simply use a search tool for files containing flipY in your sources and change it from bool to int

@Raziel
Simply change
Bool flipy;
To
int flipy
In the shaders and in C sources (and .h headers if necessary)

There it not much demos that use it

http://thellier.free.fr/NovaOnda.lha

https://www.amiga-ng.org/viewtopic.php?topic=2444&forum=14

>At moment it is static link library, and it can be .so

Having a GL4ES.library would be more AmigaOS friendly (and evolutive...)
It can be as simple as having only 2 functions in the .library
OpenGL4ES();
CloseGL4ES();

something like

struct GL4ESIFace *IGL4ES
IGL4ES=OpenGL4ES();

IGL4ES->glCreateContext(blah,blah);
[...]
IGL4ES->glDrawArray(blah,blah);
[...]
CloseGL4ES(IGL4ES);

>If using the C library is not a problem, then you can replace it with system
OK I will give it a try

>SYS_Async tag defaults to FALSE
Seems that this tag despite his name dont do sync/async but close or not the input/ouput

Thanks

Hello

From my C program I start an external command with SystemTags() (say) "mycommand"

The context:
The C program generate a file (say) myfile.txt
Then I do a SystemTags() "mycommand myfile.txt mymodifiedfile.txt" to obtain (say) mymodifiedfile.txt
BUUUT SystemTags returns before the treatment is done so mymodifiedfile.txt is not here or not finished

So how to resolve that ?
Is there a synchronous mode for SystemTags ? or an other function to use ?


Many Thanks

@Daytona675x

You are absolutely right

@kas1e
There are only 2 cases in fact:

1) Object & VBO got exacly the same points formats so you can memcpy the whole XYZUVWRGBA list in one call = slow but cant be faster

2) Object & VBO dont have the same points formats so you must pick xyz at one place to copy it elwhere in the VBO, uvw ditto, etc.... and so become more slow

A partial glLockArrays is case 2) because even if XYZ is in a separate static VBO you will (certainly) have to pick the UVW RGBA in the original points list to copy them to their VBO

>We see the call to glLockArrays(...) and then the engine enable GL_TEXTURE_COORD_ARRAY and GL_COLOR_ARRAY. That means those 2 arrays are not Locked, but still used for drawing

What does it mean ? I mean what does the game want to do ?

Does it mean that the game want to no update the vertices but just update the texcoords and colors ?
Perhaps in this case the VBO will do the vertices transform GPU side but the lighting (colors) will be done by CPU ? and what about texcoords ?


It will looks more logical to have the whole array not updated and that light&transform is done GPU side , no ?

Anyway from my own experiments: updating a vbo is truly the bottleneck in Nova (so also in GL-ES and GL4ES)

Hello

OK many thanks for you answers

Hello

I am developping/compiling my own .Library
When a new build is done I want to remove the old .Library that is still loaded to test the new one

Is there a tool to "remove xxx.library" from memory ?

Many Thanks

@BSzili

>You can't change buffers


MiniGL/buffer.c/buf_SetFrontBuffer(GLcontext context, void *bitmap, GLboolean free);

Seems to set frontbuffer to a given bitmap
Then the(RGB or RGBA) bitmap can be used to update a texture...

bmHandle=LockBitMapTags(bm,LBMI_BASEADDRESS,(ULONG)&pixels, TAG_DONE);

glTexImage2D(GL_TEXTURE_2D, 0, 3, w, h, 0,GL_RGB,GL_UNSIGNED_BYTE, pixels);

UnLockBitMap(bmHandle);


Untested.... huhh..

>Somewhere in clearBuf with ABADCAFE in r2, but I can't check right now.

If you cant use a FBO as buffer then you cant clear it = normal.

>Damn, so still waiting for the driver

A workaround may (??) be to render in another RGB bitmap then convert this bitmap to the texture

glTexImage2D(GL_TEXTURE_2D, 0, 3, w, h, 0,GL_RGB,GL_UNSIGNED_BYTE, bitmaptr);

1) I dont know if MiniGL support changing the (rendering buffer) bitmap on the fly
2) Depending on what you render in your FBO(=bitmap) it may not works (z depth)

>sadly it means that serial debugs are not in sync with the freeze

This is some code that I use in GMAP to output debug to the screen bitmap. So there is no serial debugs or printf latency

It will need some adaptation but the idea is here


also adding some LL macros at beginning of litigious lines may help

#define LL {Libprintf("Line:%ld \n",(LONG)__LINE__);}




/*=================================================================*/
ULONG lastline=0;
struct GM_Game *GlobalG;
/*=================================================================*/
#ifdef OS3
#ifdef DOSCREENDEBUG

void OS_DrawText3(struct GM_Game *G,UBYTE *text)
{
struct OS_Screen *S;
struct RastPort *rp;
WORD x,y;

CHECK(text)
CHECK(G)
S=G->screen;
CHECK(S)
rp=S->drawrastport;
CHECK(rp)
x=S->T->rect.w/2; y=lastline;

if(lastline > (S->T->rect.h-10))
lastline=0;
lastline=lastline+10;

SetAPen(rp, 240) ;
RectFill(rp,x,y,S->T->rect.w,y+20);
SetAPen(rp, 241) ;
Move(rp,x,y);
Text(rp,(void*)text, strlen(text));
}
/*==================================================================================*/
#define PUTCHARFUNC (void (*))"\x16\xc0\x4e\x75"
void Libprintf(void *string,...)
{
va_list args;
UBYTE buffer[4096];

if(SysBase==0) return;
if(strlen(string)>1024)
return;

va_start(args, string);
RawDoFmt(string, args, PUTCHARFUNC, buffer);
va_end(args);

if(strlen(buffer)<1024)
OS_DrawText3(GlobalG,buffer);
}

#endif
#endif

@kas1e

Do you have in mind new progs or games that may now be ported to OS4 with a working GL4ES ?

Hello
The "quake3 mirror distorsion bug" happen with waZp3d too so certainly is a minigl bug
Next week I will try to find what cause it as wazp3d got lots of debugging features

>ptitSeb (gl4es author), works almost every day on improve gl4es

ptitSeb ? (=small Sebastian) so he is french

Found an article about him
"Meet an ODROIDIAN Sebastien Chevalier (@ptitseb)"
page 32
https://magazine.odroid.com/wp-content ... DROID-Magazine-201610.pdf

I fully agree about "Learning programming"

@salass00
Thanks for the info

@corto
My concern was to write to a VBO in GPU VRAM the more efficient way
>Did you notice low performance
Not especially : I was just hoping it exists "the more efficient memcpy in ppc asm" so I can exclude that part of my program as cause for eventual slowlyness

In fact Clib/memcpy do that so I got my answer

@Hans
I was meaning something like that
Src is in RAM
Dst is a VBO in GPU VRAM
If i set up a (fake) rastport/bitmap that point to Dst
then can WritePixelArray copy the data with DMA ?
I mean if pixel formats are same in Src and Dst(array=RGBA,bitmap=RGBA) WritePixelArray should copy transparently with no changes to data, no ?

Just an old hacker idea...