I opened issues #16 and #17 that are still valid. Clarification (documentation) is required about the build (options, native build or using cross-compilation, used config file, ...).
#4 - (SGrab snapshot) - Fixed (at least i can't trigger it anymore) #10 - (Alt hotkey) - Still there (duplicated bug item in SDL2 tracker) #15 - (8pp screens on 32Bit WB) - Still there
Then its latest one. I see that before your commits there was last one from me, and if i remember right since then no one add anything, so your one is the latest with all latest commits, that good :)
Btw, composition code autodetects somehow, and when it available uses, and when not not uses, or, i need to specify something like SDL_OS4_COMPOSITE on init stage ?
As i see there is only initall 68k port commit, so currently no use for us.
Btw, to add to Raziels's post, maybe (if you will have any time for), you can add that os4 iconify functionality about which i wrote in #9 ? Such functionality will be good to have and for SDL1 and for SDL2.
Idea is just to have some sdl flag which we can call like SDL_AOS4_ICONIFY or whatever, and activate it with SDL_INIT() , which, when SDL app in the window mode, will attach iconify button, and when user will press on it call SDL_WM_Iconify function which will do all dirty work for us.
Currently all sdl based window apps can't be iconified, so if we can have it for sdl1 and for sdl2 that can be good. I am ready for any tests in any time, if you in interest in and have time for :)
First problem with SDL1 is that for unknown reason it only allows HWSURFACEs in fullscreen mode. Should be fixed.
Next problem is that many games and emulators don't really "blit". They "plot" pixels. At worst CPU is writing VRAM one pixel at time and then people say, "it's slow".
Third problem is that almost all SDL games are statically linked - so much for quick tests & profits. But I believe I have now ranted enough about this.
Once again, if your app is not blitting HWSURFACEs, then don't expect any speedups.
@Capehill Is it worth to post BZs about SDL1 issues ? We may found issue with a bit distored mouse pointer in the grafx2. I.e. cursor fine till main area of programm not under amiga cursor, but once we move it over, then shiny cursor a bit distored. Like, maybe not full area clears, or something.
If you in interest , i can provide more info about , etc
@Capehill Will continue here to not deral other topics if you doesnt mind:
Quote:
Yeah, please open a ticket so that thing don't get forgotten. I know that there is no active work on SDL1 but who knows...
Once i was about to create a ticket about grafx2 issue with distorted cursor, with images from win32 and os4, to show how good it looks on win32, and how distored on os4, i realize interesting stuff, which may have give an idea to where to look maybe:
if i run grafx2 on os4, see distored cursor , then press prnscr button on which i attach making a screenshot via sgrab, and check resulted screenshot, then, on screenshow cursor looks just fine ! Like this:
Taken by screengrab:
(press open in new tab for full size)
But in reality, it looks like this:
(press open in new tab for full size)
Dunno, i remember such kind of problems like visually you see one thing, but on screenhot different, when PIP or compoiting was involved. I tryied to disable compositing: all same.. Its like didn't hide fully original amiga cursor, and it overwrite programm's cursor.
@Capehill Swap 1,1 on 8,8, and it kind of make it better, but still have distortion inside. Less that before, but still it here (and only when we make app active, once we move our cursor away, we can see how cursor placed to the bounds of window in the app, start to be non-distored and good looking, its only when amiga cursor over the program's window its distored).
Tested win32 version btw, there is no such distortion with the same code..
@Capehill Made some more experiments, and found that they specially did that 1 pixel transparent cursor. As they write before in comment, that is trick "Showingthe SDL 1 pixel transparent cursor allows us to get absolute mouse coordinates, this means we can use tablet in fullscreen mode."
Then, their code looks like:
SDL_FreeCursor(cur);
cur = SDL_CreateCursor(&cursorData, &cursorData, 1,1,0,0);
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
}
}
Once i comment out part with SDL_SetCursor(cur); and SDL_ShowCursor(SDL_ENABLE); , and keep SDL_ShowCursor(SDL_DISABLE); (so to hide sdl mouse cursor , and user internal one), then all start to works as should, no distortion, all is fine.
What mean, imho, that something can be wrong with our SDL_SetCursor() and or SDL_ShowCursor() when it come to 1 pixel transpent one..
Please don't change height parameter. Code passes only one byte (8 bits of course) as cursor data. That's why 8 * 1 should be the correct dimension in this case, in my opinion.
There could be more issues in the backend side but I didn't check it yet. It should be easy to make a test case that opens only a window and sets cursor, to simplify testing.
Anyway, done simple test case with main code as in grafx, and while test case can be wrong , it show kind of same distortion as we have in the grafx.
I.e. it didn't show "the SDL 1 pixel transparent cursor" as intendent by code, but instead some garbled stuff of 16x16 area or so. On win32 that code works correctly,
#include <SDL/SDL.h>
int mousex, mousey;
static SDL_Cursor* cur = NULL;
static uint8_t cursorData = 0;
// Chopped down even function
int events()
{
SDL_Event event;
while(SDL_PollEvent(&event))
{
switch(event.type)
{
case SDL_MOUSEMOTION:
mousex = event.motion.x;
while(events())
{
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
}
}
exit_sdl(surf);
}
Compile as: pc-amigaos-gcc test.c -o test -lSDL -lpthread
Seems that backend allocates too little memory for the sprite. According to this http://wiki.amigaos.net/wiki/Intuition_Pointer , there should be 32-bit dummy data before and after actual graphics. But code allocates only "before" part (4 extra bytes):
Nope, didn't help sadly. Distortion change it looks, but still garbage here. Retested for sake of be sure again on win32 , and build it on mingw32 for now, there is no cursor (1pixel-transparent as intendent) and no garbage. So probably its indeed our sdl.
Quote:
By the way, do we still have to allocate from CHIP memory or?
Dunno, but as os4 works on classics too, maybe it relevant (?)
I made another test case, in which i just set CursorData to 0xaa (1010 1010 , so 4 dots), and mask to 0. So, it should just draw 4 dots over cursor. On win32 it is, but on aos4 it's draw garbage. There is:
// Chopped down even function
int events()
{
SDL_Event event;
while(SDL_PollEvent(&event))
{
switch(event.type)
{
case SDL_MOUSEMOTION:
mousex = event.motion.x;
while(events())
{
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
}
}
exit_sdl(surf);
}
Same as before : ppc-amigaos-gcc test.c -o test -lSDL -lpthread
Edited by kas1e on 2018/1/14 19:52:30 Edited by kas1e on 2018/1/14 19:54:21
News feed
OS4 Feedback forum
OS4Depot Feedback forum
Amigabounty forum
OpenAmiga forum
AmiCygnix forum
ABC shell forum
AmiKit forum
Cinnamon Writer forum
CodeBench forum
Digital Universe forum
Dopus 5 forum
E-UAE forum
Gnash forum
Ibrowse forum
JAmiga forum
Odyssey forum
OWB forum
Qt forum
SmartFileSystem forum
Timberwolf forum
TouchDevice forum
TuneNet forum
Unsatisfactory Software forum
Donate
