Home  
Login
Username:

Password:

Remember me



Lost Password?

Register now!
Sections
Who's Online
45 user(s) are online (29 user(s) are browsing Forums)

Members: 1
Guests: 44

Ten, more...
Support us!
Recent OS4 Files
OS4Depot.net



« 1 (2) 3 4 »


Re: SDL1 open issues
Home away from home
Joined:
2007/9/11 11:31
From Russia
Posts: 4349
@Capehill

I aslo made same kind of test case for SDL2, and it works fine an on win32, and on aos4. There is :

#include "SDL2/SDL.h"
#include <stdio.h>

int mousexmousey;


int main(int argccharargv[]) {

    
SDL_Window *window;                    // Declare a pointer

    
SDL_Init(SDL_INIT_VIDEO);              // Initialize SDL2

    // Create an application window with the following settings:
    
window SDL_CreateWindow(
        
"An SDL2 window",                  // window title
        
SDL_WINDOWPOS_UNDEFINED,           // initial x position
        
SDL_WINDOWPOS_UNDEFINED,           // initial y position
        
640,                               // width, in pixels
        
480,                               // height, in pixels
        
SDL_WINDOW_RESIZABLE                  // flags - see below
    
);

    
// Check that the window was successfully created
    
if (window == NULL) {
        
// In the case that the window could not be made...
        
printf("Could not create window: %sn"SDL_GetError());
        return 
1;
    }

    
    
    
// The window is open: could enter program loop here (see SDL_PollEvent())

    
SDL_Rendererrenderer;     
    
renderer SDL_CreateRenderer(window, -10);

    
// Select the color for drawing. It is set to red here.
    
SDL_SetRenderDrawColor(renderer25500255);

    
// Clear the entire screen to our selected color.
    
SDL_RenderClear(renderer);

    
// Up until now everything was drawn behind the scenes.
    // This will show the new, red contents of the window.
    
SDL_RenderPresent(renderer);
    
    static 
SDL_Cursorcur NULL;
    
    static 
uint8_t cursorData 0xaa// 4 dots.
    
static uint8_t cursorMask 0// for transparent cursor

    
SDL_FreeCursor(cur); 
    
cur SDL_CreateCursor(&cursorData, &cursorMask1,1,0,0);
    
    
SDL_bool done;
    
SDL_Event event;
    
done SDL_FALSE;
    while (!
done) {        
        while (!
done && SDL_PollEvent(&event))     {        
            switch(
event.type)
            {
                case 
SDL_MOUSEMOTION:
                    
mousex event.motion.x;
                    
mousey event.motion.y;
                    break;

                case 
SDL_QUIT:
                    
done SDL_TRUE;
                    break;
            }
        }

        if (
cur != NULL
        { 
            
SDL_SetCursor(cur); 
            
SDL_ShowCursor(SDL_ENABLE); // show the SDL 1 pixel transparent cursor 
        

        else 
        { 
            
//failed to create the 1 pixel transparent cursor 
            
SDL_ShowCursor(SDL_DISABLE); // Hide the SDL mouse cursor, we use our own internal one 
        

    
    }
    
//SDL_Delay(3000);
    
    
SDL_DestroyWindow(window);        // Close and destroy the window
    
SDL_Quit();           
    return 
0;
}


I.e. same kind of logic and code for set 1 pixel transapent cursor, and it works with sdl2 on both plaforms. Difference only that in SDL2 test case i fill whole window by red color (thore "render" parts), but that no related imho.

In other words problem only on os4 and only with SDL1..


Edited by kas1e on 2018/1/14 19:56:56
_________________
Join us to improve dopus5!
zerohero's mirror of os4/os3 crosscompiler suites
   Report Go to top

Re: SDL1 open issues
Not too shy to talk
Joined:
2007/7/14 20:30
From Lothric
Posts: 348
@kas1e

SDL2 uses true color pointers, a different way of creating them.

Found another bug in SDL1 backend: https://github.com/adtools/os4sdl/blob ... amigaos4/SDL_os4wm.c#L211 According to web documentation, height parameter comes before width and this is reversed in SDL1 code.

   Report Go to top

Re: SDL1 open issues
Home away from home
Joined:
2007/9/11 11:31
From Russia
Posts: 4349
@Capehill
Interesting.. Just swaped height with width, and it did fix garbage in the grafx (horray!), but, os4 test case from post#20 show nothing as well (while should show 4 dots). What mean there still something wrong can be .. Btw, even with original AllocVecTags(4*h+4 it is like this (i mean like those changes make no differences, not in grafx2, not in test case).

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

Re: SDL1 open issues
Home away from home
Joined:
2007/9/11 11:31
From Russia
Posts: 4349
@Capehill
While plaing around with another port where i can see distorted mouse, i found probably another major bug of SDL1. If you have time, maybe you can check if you can reproduce it as well

Problem is: latest SDL1 sources when builds with "make -f Makefile.amigaos4", build all the stuff with enabled pthreads support. Then, if we will make any kind of code which use Mix_OpenAudio from SDL_Mixer, let's say something like "Mix_OpenAudio(44100, MIX_DEFAULT_FORMAT, 2, 1024)"; then app just froze and nothing happens.

Last what can be seen from snoopy log, is that SDL thread starts, and OpenDevice("timer.device") doing ok and then nothing.

If i just grab sdl1 user archive from os4depot (which builded without pthreads, that can be seen in the libsdl.a itself, there almost no references to pthreads), then all works fine, Mix_OpenAudio didn't fail.

Also if i just re-configure latest SDL1 code, with --disable-pthreads, and compile libsdl.a , it also works fine on the same code.

For sake of tests, you may try for example or just this piece of code:

#include <SDL.h>
#include <SDL/SDL_mixer.h>
int main()
{
    
// start SDL with audio support
if(SDL_Init(SDL_INIT_AUDIO)==-1) {
    
printf("SDL_Init: %sn"SDL_GetError());
    exit(
1);
}
// open 44.1KHz, signed 16bit, system byte order,
//      stereo audio, using 1024 byte chunks
if(Mix_OpenAudio(44100MIX_DEFAULT_FORMAT21024)==-1) {
    
printf("Mix_OpenAudio: %sn"Mix_GetError());
    exit(
2);
}

SDL_Delay(300);

SDL_Quit;
}


Or, a bit more intersting one:
http://lazyfoo.net/downloads/index.php?file=SDLTut_lesson11

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

Re: SDL1 open issues
Not too shy to talk
Joined:
2007/7/14 20:30
From Lothric
Posts: 348
@kas1e

I don't remember even howto build SDL1 (it was 2015 last time). I didn't configure it, that much I recall.

But why do want to complicate matters by using pthreads? SDL1 has its native thread code and I was hoping to add similar thing into SDL2.

Does it work any better if you call Mix_CloseAudio before SDL_Quit?

   Report Go to top

Re: SDL1 open issues
Home away from home
Joined:
2007/9/11 11:31
From Russia
Posts: 4349
@Capehill

Quote:

I don't remember even howto build SDL1 (it was 2015 last time). I didn't configure it, that much I recall.


You can or just do "make -f Makefile.amigaos4" (and then it will build SDL1 with pthreads). Or, you can reconfigure it from scratch. On crosscompiler cygwin i do it like this:
./configure --build=i686-pc-cygwin --host=ppc-amigaos --disable-shared --enable-static --disable-pthread


Quote:

But why do want to complicate matters by using pthreads? SDL1 has its native thread code and I was hoping to add similar thing into SDL2.


Its not that i want to compilcate things, it just i point out that something wrong in SDL1, specially when you build it as intendent (i.e. with "make -f Makefile.amigaos4") :)

Quote:

Does it work any better if you call Mix_CloseAudio before SDL_Quit?


Its just hangs on Mix_Open, and nothing works after, i.e. you can't call any other functions. But once i recomplie SDL1 without pthread (i.e without wrong default), then it all works. I just want to point on that bug, as probably or we need to get rid of pthreads in default build for sdl1, or, that to be fixed (if :) ).

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

Re: SDL1 open issues
Not too shy to talk
Joined:
2007/7/14 20:30
From Lothric
Posts: 348
@kas1e

Makefile.amigaos4 fails for me, there is a compiler error related to thread code ("abstime" or something?). Have you modified the source?

Yesterday I tried to just "make" the project but in the linking phase there is a ton of warnings. SO is finished but it seems to crash on SDL_GetTicks() always. Strange. I'm pretty sure this worked in, er, 2015.

Now I'm trying configure + make route (natively).

   Report Go to top

Re: SDL1 open issues
Home away from home
Joined:
2007/9/11 11:31
From Russia
Posts: 4349
@Capehill
Quote:

Makefile.amigaos4 fails for me, there is a compiler error related to thread code ("abstime" or something?). Have you modified the source?

If you on native, you probably need to run all that "makefile.amgiaos4" from "sh" (same as those ./configure;make). If you don't already :)

I use both ways on crosscompiler.

Quote:

Yesterday I tried to just "make" the project but in the linking phase there is a ton of warnings. SO is finished but it seems to crash on SDL_GetTicks() always. Strange. I'm pretty sure this worked in, er, 2015.


Its because when you run "make" it just use basic makefile which looks more heavy and probably too old for.


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

Re: SDL1 open issues
Home away from home
Joined:
2007/9/11 11:31
From Russia
Posts: 4349
@Capehill
Should we commit your fix from post #22 to repo on adtools ? Visually fix from post #18 made no differences, but #22 did. At least in grafx2 and gigalomania_sdl1 your fix from #22 did the trick. And while my last test case show that there is still some differences with win32 in compare, it still better as it now.

Also, is any of us able to close tickets in adtools repo ?:) Many of them can be closed already.

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

Re: SDL1 open issues
Not too shy to talk
Joined:
2007/7/14 20:30
From Lothric
Posts: 348
@kas1e

I think the memory allocation bit is important too. If we allocate too little, AmigaOS might read/write invalid memory. But now I'm confused. Consider the example with 16 lines of data: http://wiki.amigaos.net/wiki/Intuition_Pointer

I can understand the 18 lines, the upper and lower parts are for the system. But what is this 4 more "control words" that make total amount of 40 words (20 lines!)? I am not seeing this in the coded example, and unfortunately there is no dynamic allocation. Quote:

"The pointer in the example, a standard busy pointer, is sixteen lines high and sixteen pixels wide. Currently, all sprites are two bit planes deep, with one word of data for each line of each plane. The example sprite image consists of 36 words (2 planes * 18 lines = 36 words). Add to this the four reserved words of control information for a total of 40 words of data. See the example below for the complete data definition."

***

One possibility would be to create pointer like SDL2 backend does.

   Report Go to top

Re: SDL1 open issues
Not too shy to talk
Joined:
2007/7/14 20:30
From Lothric
Posts: 348
@kas1e

I got finally a half-working .so built with makefile.amigaos4. There is a missing timespec definition in my SDK (same thing happened with SDL2). Makes me wonder how you have solved this? Are you using some modified SDK perhaps?

But there was a NULL pointer crash somewhere in backend during SDL_Delay(). Trying to investigate some day.

   Report Go to top

Re: SDL1 open issues
Home away from home
Joined:
2007/9/11 11:31
From Russia
Posts: 4349
@Capehil
Damn, missed somehow your answer in that topic yesterday !

Quote:

I got finally a half-working .so built with makefile.amigaos4. There is a missing timespec definition in my SDK (same thing happened with SDL2). Makes me wonder how you have solved this? Are you using some modified SDK perhaps?


I build and use only static version (for tests is much more better and easy than shared one), dunno through if it relevant, but ! What i found is that in the common/include/pthread.h, i have that:

//#ifdef CLIB2
struct timespec
{
    
unsigned int tv_sec;
    
unsigned int tv_nsec;
};
//#endif


Dunno when and for what i do so, maybe exactly because of issues you point out on.. That from other side can point out on issues i have when build it with enabled pthread (when makefile.amigaos4 is used).

Damn we need to sort all that crap out, and clean it a bit from all shit (there is even few very old tickets about). Probably better working on version which is placed on adtools page ?




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

Re: SDL1 open issues
Not too shy to talk
Joined:
2007/7/14 20:30
From Lothric
Posts: 348
@kas1e

I have pushed some fixes and hacks to my fork. I'm trying to figure out the DSI with .so, it surely didn't happen in 2015...

   Report Go to top

Re: SDL1 open issues
Home away from home
Joined:
2007/9/11 11:31
From Russia
Posts: 4349
@Capehill
If you build it with makefile.amigaos4 , then it mean "pthreads" in use, what mean that there is will be bugs about which i told in previous posts in some other thread (i.e. SDL_Mixer hangs, etc).

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

Re: SDL1 open issues
Not too shy to talk
Joined:
2007/7/14 20:30
From Lothric
Posts: 348
@kas1e

After debugging .so (built with provided Makefile), it doesn't seem to call library constructors which seem to explain DSIs. However, it calls destructors. Static library calls constructors. This is a strange issue, any idea what might block the constructors? _INIT* functions exist as T symbols, similar to destructors (_EXIT*). Compiler (GCC 4.2.4 used) should be placing the calls as far as I undertand it, but is there any other component playing a part here?

   Report Go to top

Re: SDL1 open issues
Home away from home
Joined:
2007/9/11 11:31
From Russia
Posts: 4349
@Capehill
Maybe something with PIC_CFLAGS = -fPIC -DPIC ?

You want firstly fix shared object's build ? It probably also will fail with pthreads on SDL_Mixer, same as static one, but to be seen..

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

Re: SDL1 open issues
Home away from home
Joined:
2007/9/11 11:31
From Russia
Posts: 4349
@Capehill
Btw, i am working on some huge port, which is use SDL1 as window manager, and can use renderers as OpenGL (so no go for limited minigl) and Ogles2. Sadly that project have no support for SDL2 at moment (when we have ogles2 support), but, maybe it possible to build SDL1 not with MiniGL, but with Ogles2 instead ?

I think its unpossible to build with both at the same time of course, but even if it possible to make version with ogles2 instead of minigl, that can give huge boost to all SDL1 apps.

Or maybe something like minigl as default (SDL_OPENGL flag a it was), but if user specify something like: SDL_OPEGLES2, then we can use it for OGLES renderer. I.e.:
screen = SDL_SetVideoMode( 0, 0, 16, SDL_OPENGLES | SDL_ FULLSCREEN );

Even some hack way, or whatever .. all i need just ability to have SDL1 window manager, and use ogles2 renderer to it. As you already add it to SDL2, maybe it will be not big problem to add to SDL1 it as well ? I will be very happy to test, to debug, and to help with. In end of all of this we may have some very good and fast ports.




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

Re: SDL1 open issues
Not too shy to talk
Joined:
2007/7/14 20:30
From Lothric
Posts: 348
@kas1e

It should be easier to port game code to SDL2, compared to adding OGLES support to SDL1.

Build scripts would need to be able to detect OGLES2 and then some logic for loading the correct library (no idea what is the way with SDL1), load the GL functions etc. It's true that some code could be reused from SDL2.

OpenGL 1.x and OGLES2 have a different set of features and functions. Legacy OpenGL renderer should be ported to OGLES2 as well.

   Report Go to top

Re: SDL1 open issues
Home away from home
Joined:
2007/9/11 11:31
From Russia
Posts: 4349
@Capehill
Quote:

It should be easier to port game code to SDL2, compared to adding OGLES support to SDL1.

Its not game , but engine, on which based lots of good games. And authors of engine sure someday will add SDL2 support, but just when... again waiting years :)

Quote:

Legacy OpenGL renderer should be ported to OGLES2 as well.


Not sure what you mean here , as OGLES2 can work without OpenGL at all (that why i think about adding it to SDL1, without that dated MiniGL). At least i do not know how it done on other platforms, maybe on windows opengles based on opengl as wrapper, but in our case Daniel done it as standalone, and not rely on OpenGL (but you know it of course:) )

Or you mean, that we need wrapper over Ogles2 , so to have full OpenGL2 ? Sure, that would be cool, but then, no one will write it and it huge job. All the opensource variants of such wrappers are unfinished, untested and buggy (at least that what i understand when checking those 2 variants, one was dropper eyars ago, another one in unfinished-buggy state). And even if we will have such wrapper, then it still mean to do changes in SDL1, again..

In other words, i trying to find a way, how i can use Ogles2 with sdl1, without involving of minigl. I read on google, that for some devices such port of SDL1 was done, i.e. where ogles2 only present, it was "harmattan port of SDL1.2", but at moment find no source of it to look at..


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

Re: SDL1 open issues
Home away from home
Joined:
2007/9/11 11:31
From Russia
Posts: 4349
@Capehill
After thinking a while, i think there can be few ways to archive what i want (to use that engine with ogles2):

a). waiting when then their engine will have SDL2 (can take years as usuall)
b). trying to add ogles2 support to our SDL1 (hard as you say).
c). trying to write my native-os manager for engine, so avoid anything SDL or co, just pure native manager, which will open intuition window, and to which rendering from ogles2 will happens.
d). myself rewrite their SDl1 to SDL2, in hope that there will be no issues in SDL2 in terms of ogles :) But even if, then it can be good test case.

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


« 1 (2) 3 4 »



[Advanced Search]


Powered by XOOPS 2.0 © 2001-2016 The XOOPS Project