Forums - All Posts - The Amigans website

Forum Index

Board index » All Posts (DStastny)

Bottom

« 1 2 3 (4) 5 »

DStastny

Re: Regal: OpenGL over OpenGLES2 emulation - some tech. info and porting progress

Posted on: 2018/2/14 22:16 #61

Just popping in

@kas1e

Congratulations on getting this working!

Regard
Doug

Topic | Forum

DStastny

Re: Regal: OpenGL over OpenGLES2 emulation - some tech. info and porting progress

Posted on: 2018/2/13 23:24 #62

Just popping in

I take back what I said. Looking at the log this stands out about -1.

<code>
driver | glGetUniformLocation (256, "rglNormalMatrix") returned -1
driver | glGetUniformLocation (256, "rglModelViewMatrix") returned -1
driver | glGetUniformLocation (256, "rglProjectionMatrix") returned -1
driver | glGetUniformLocation (256, "rglModelViewProjectionMatrix") returned -1
</code>

This might be cause failure to transform the 2d triangle correctly and might be issue.

Do you have a platform to test Regal on so we can see if the sample I provide really works correctly or maybe we need a simple 3d transformed triangle.

Regards
Doug

Topic | Forum

DStastny

Re: Regal: OpenGL over OpenGLES2 emulation - some tech. info and porting progress

Posted on: 2018/2/13 23:15 #63

Just popping in

@Kas1e

This is great progress. glGetUniformLocation returned -1 when a uniform variable is not bound it looks like the driver is just checking all possibilities to manage states maybe just the way it works as the scripts don't appear to have those variables so it appears that failure is ok.

The logging that Regal produces is terrific.

Regards
Doug

Topic | Forum

DStastny

Re: Regal: OpenGL over OpenGLES2 emulation - some tech. info and porting progress

Posted on: 2018/2/13 18:45 #64

Just popping in

@Kas1e

That's not too bad as you have at moment glClear working. When I read the context.c code in Regal last night I would think there would still need to be some specific Amiga code in there but seeing glClear work it seems not. Does Regal expect something regarding default state management to setup that might not be correct. As that can mess up a simple triangle. I had issue with minigl defaulting depth testing on when it is supposed to be off according to documentation regarding OpenGL spec.

Good luck and hope this comes together.

As for explanations on X11 misread your undefine :)

Regard
Doug

Topic | Forum

DStastny

Re: Regal: OpenGL over OpenGLES2 emulation - some tech. info and porting progress

Posted on: 2018/2/13 1:41 #65

Just popping in

@kas1e and @Hans

Ok I did a quick read through this entire thread and a quick look at the Regal source specifically regarding the context.

First off there is no standard for setting up a OpenGL context. I am familiar with Windows,Linux and OSX and all of them are platform specific(some easier than others). ~~Based upon kas1e's defines for his build he is having Regal believe it is X11.~~ I misunderstood and thought that had been solved with a minigl context he wrote.

So if our OpenGLES mimics X11 it should in theory work or at least be not bad to finish. I did see some references to C++11 threads and I am not sure how mature our thread lib is but there is probably some risk there. To get this to work I think this library is going to require Amiga specific modifications. I am not seeing good abstraction of system dependencies at first glance but it might not be too bad. It should be around defining a context.

I have been working on a port that had a abstract graphics API that i whipped up to MiniGL as it was easy almost done and I was about to start a Nova driver. Maybe when I finish my MiniGL stuff I can put together a OpenGL context and glue this together instead but this is probably multi-month project. The Nova would be better for my use case and probably easier but I can see the community valuing the OpenGL more. I just suffer from what all Amiga programmers do which is not enough time.

Regards
Doug

Edit corrected misread on define about X11...

Edited by DStastny on 2018/2/13 4:31:31

Topic | Forum

DStastny

Re: Regal: OpenGL over OpenGLES2 emulation - some tech. info and porting progress

Posted on: 2018/2/13 1:01 #66

Just popping in

@Hans
I must have misunderstood he said he need without SDL/GLUT a simple window which MiniGL takes care of. I could create my own window but you wouldn't gain much as you would attach context to bitmap but you still need MiniGL. There is no raw OpenGL context example for Amiga as that does not exist.

@Kasie do you need a OpenGLES context for this library to use. Let me read this library a bit more and see how its supposed to glue to OpenGLES.

I am very interested in a solution that can easily port OpenGL 1.X and am willing to invest the time in make something like this work.

Regards
Doug

Topic | Forum

DStastny

Re: Regal: OpenGL over OpenGLES2 emulation - some tech. info and porting progress

Posted on: 2018/2/13 0:34 #67

Just popping in

I am very interested in what you are doing here. Here is about as simple of OpenGL as it gets.


// gcc -o test test.c -lauto -lgl





#include <GL/gl.h>

#include <stdlib.h>

#include <proto/intuition.h>

#include <proto/exec.h>



void display()

{

    glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT);

    glBegin(GL_TRIANGLES);

    glVertex2i(0,1); 

    glVertex2i(1,-1); 

    glVertex2i(-1,-1); 

    glEnd();

    glFlush();

    mglSwitchDisplay();

}



struct Interface *getInterface(char *libname)

{

    struct Library *lib;

    

    lib = IExec->OpenLibrary("minigl.library", 0);

    if (lib)

        return IExec->GetInterface(lib, "main", 1, NULL);

    

    return 0;

}



void dropInterface(struct Interface *iface)

{

    if (iface)

    {

        struct Library *lib = iface->Data.LibBase;

        IExec->DropInterface(iface);

        IExec->CloseLibrary(lib);

    }

}



int main()

{

    struct MiniGLIFace *IMiniGL = 0;

    IMiniGL = (struct MiniGLIFace *)getInterface("minigl.library");

    if (!IMiniGL)

        return 20;



    struct GLContextIFace *IGL = IMiniGL->CreateContextTags(

            MGLCC_Width,        640,

            MGLCC_Height,       480,

            MGLCC_Windowed,     TRUE,

            MGLCC_CloseGadget,  TRUE,           

            MGLCC_Buffers,      2,

            MGLCC_PixelDepth,   16,

            TAG_DONE);

    if (IGL)

    {

        mglMakeCurrent(IGL);

        int running = TRUE;

        

        struct Window *win = mglGetWindowHandle();

        if (!IIntuition->ModifyIDCMP(win, IDCMP_CLOSEWINDOW))

            running = FALSE;



        while (running)

        {

            display();

            struct IntuiMessage *imsg;

            while ((imsg = (struct IntuiMessage *)IExec->GetMsg(win->UserPort)))

            {

                if (imsg->Class == IDCMP_CLOSEWINDOW)

                    running = FALSE;

                IExec->ReplyMsg((struct Message *)imsg);

            }

        }       

        mglDeleteContext();

    }

    

    dropInterface((struct Interface *)IMiniGL);

    

    return 0;

}

Regards
Doug

Topic | Forum

DStastny

Re: Building Cross-Compiling adtools for Amiga OS4 PowerPC (ppc) with Cygwin/Bash on Ubuntu on Windows

Posted on: 2017/10/12 1:44 #68

Just popping in

@AmigaBlitter

Sorry I miss read your issue. When I had issue with part you mentioned it was due to Python3 being installed. You are correct the sudo is command for linux or uwin.

I dont use cgwin so sure what problem your having is.

Doug

Topic | Forum

DStastny

Re: Building Cross-Compiling adtools for Amiga OS4 PowerPC (ppc) with Cygwin/Bash on Ubuntu on Windows

Posted on: 2017/10/11 3:34 #69

Just popping in

@AmigaBlitter

This is missing

sudo apt-get install python-minimal

That should fix you up.

*edit*

sudo ln -s /usr/local/amiga/adtools-ppc-cyg64-20170623-404 /usr/local/amiga/adtools

is incorrect for the uwin make

it should be

sudo ln -s /usr/local/amiga/adtools-ppc-uwin-20170623-404 /usr/local/amiga/adtools

Doug

Topic | Forum

DStastny

Re: Cross-Compiling for Amiga OS4 PPC from Cygwin / Bash on Ubuntu on Windows 10+

Posted on: 2017/10/5 19:48 #70

Just popping in

@stonecracker

If you write up the Cygwin time permitting I will make equivalent version for UWin.

Doug

Topic | Forum

DStastny

Re: Cross-Compiling for Amiga OS4 PPC from Cygwin / Bash on Ubuntu on Windows 10+

Posted on: 2017/9/29 14:29 #71

Just popping in

@stonecracker

I got it to work!

The issue I had was due to a type-o in your exports path addition.

export PATH=:$PATH:~/adtools/bin:/usr/local/amiga/adtools-ppc-uwin-20170623-404/bin

should be

export PATH=$PATH:~/adtools/bin:/usr/local/amiga/adtools-ppc-uwin-20170623-404/bin

I figured it out when it dawned on my it was running the newly built as as opposed to the correct version from distro. That extra ":" causes the current working directory to become part of path and as is in the directory when gcc is being built.

After removing colon successfully built and ran Hello World.

This was running latest Ubuntu on Windows 10 from App-store

Doug

Topic | Forum

DStastny

Re: Cross-Compiling for Amiga OS4 PPC from Cygwin / Bash on Ubuntu on Windows 10+

Posted on: 2017/9/28 20:45 #72

Just popping in

@stonecracker

I had a chance to try and build it today under latest version of UWIN and unfortunately it still fails.

I think I understand the issue but not sure yet how to fix it. Looking at output the failure is when g++ invokes the assembler that has just been built. The newer versions of "g++" set the command line option of --64 to newly built "as" since it is a 64 bit environment. The version of "as" that is built does not support --64 and it kills the build.

So looks like we need a newer version of binutils?

Doug

Edited by DStastny on 2017/9/28 23:06:09

Topic | Forum

DStastny

Re: Cross-Compiling for Amiga OS4 PPC from Cygwin / Bash on Ubuntu on Windows 10+

Posted on: 2017/9/27 21:58 #73

Just popping in

@stonecracker

Thanks so much for this. I am starting to get some freetime and being able to cross compile would just be easier. For UWIN is that not this?

Windows Subystem for Linux

Topic | Forum

DStastny

Re: Sharing data with host system with Amiga Forever & AmigaOS 4.1

Posted on: 2017/4/7 2:34 #74

Just popping in

@Han
Before you launch from Amiga Forever look at the options under the menu Tools. Scroll through list and enable F12 for Runtime Options. Launch the session from Amiga Forever than you can hit F12 and save a config file in WinUAE.

Hope this helps
Doug

Topic | Forum

DStastny

Re: Ringhio Notifications ProgressBar Example Source code

Posted on: 2017/3/19 22:13 #75

Just popping in

@Amigakit

Thanks for quick reply. Should I email via AmigaDeveloper.com?

Doug

Topic | Forum

DStastny

Re: Ringhio Notifications ProgressBar Example Source code

Posted on: 2017/3/19 21:47 #76

Just popping in

@amigakit

I have noticed a lot of nice classes in the Enhancer package. Whats not clear is redistribution if I use them in a project. I am assuming any user of my software requires purchase of Enhancer. Is this correct or am I missing something in documentation?

Thanks
Doug

Topic | Forum

DStastny

Re: Application Naming

Posted on: 2017/2/18 15:55 #77

Just popping in

@broadblues

Thank you for clarifying you are correct.

@LiveForIt your real friendly fellow.

Thank you all for inputs sounds like just keeping the fork in GIT will be direction I take.

Regards
Doug

Topic | Forum

DStastny

Application Naming

Posted on: 2017/2/17 22:20 #78

Just popping in

I am in process of porting a compiler and am curious as to application naming. Since I don't see the Amiga changes merged back into the main repository what is considered the generally accepted naming.

I see a lot of AmiThis or AmiThat. Would that be best direction for a fork?

Thanks
Doug

Topic | Forum

DStastny

DSI Issue

Posted on: 2017/2/2 20:19 #79

Just popping in

Hi I am hoping someone might have some insights into some programming issues I am having.

I have been working on porting a PowerPC compiler back- end from 32bit MAC Mach-o to Amiga and have had a pretty easy time making the necessary changes. I have it spitting out assembly and able to Assemble and Link with GCC.

So whats my challenge...

My simple Hello World will work upon clean boot and I can run it multiple times but after running and closing reopening shell it appears that the static variables are not being properly relocated/initialized and the program starts to misbehave or I get a DSI. I load in GDB and run and trace and it looks good. Run again and crash with DSI on access to static variables.

From what I can see by examining the object files/executable the relocation information looks good. Using the verbose option I see "-q" passed to ld so that should indicate to retain link information.

I am protecting the registers as best as I can determine to the ABI.

Anybody have ideas?

Thanks
Doug

Topic | Forum

DStastny

Re: Returning...

Posted on: 2017/1/8 18:18 #80

Just popping in

Thanks @PJS. I try to configure my development environments to be as consistently as possible with keyboard short-cuts. Notepad++ on Windows is my favorite and one of best all purpose editor on any platform.

Thank you too for reply @Ringo, I see most issues of what I experience documented on the Codebench forum. Keymap and hard lockup with Search. Look forward to a 1.0.

Regards
Doug

Topic | Forum

Top

« 1 2 3 (4) 5 »