@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.

@kas1e

Tried it a few times from shell, works nicely, but leaks some VRAM. Game doesn't seem to call SDL_DestroyRenderer(). I checked the code and renderer is created here: https://sourceforge.net/p/gigalomania/ ... aster/tree/screen.cpp#l56

Thanks for the port, by the way.

@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).

@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?

@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.

@kas1e

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):

https://github.com/adtools/os4sdl/blob ... amigaos4/SDL_os4wm.c#L155

It could be fixed like this (didn't have chance to test yet):

cursor->Image = IExec->AllocVecTags(4 * (h + 2), AVT_ClearWithValue, 0, AVT_Type, MEMF_SHARED, TAG_DONE );

By the way, do we still have to allocate from CHIP memory or?

@Hedeon

You built a WarpOS version? Cool.

@kas1e

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.

@kas1e

I checked grafx2 source here: http://pulkomandy.tk/projects/GrafX2/ ... tlab/src/sdlscreen.c#L101

Cursor width is defined against SDL specs I would say. Instead of 1, it should be 8 (bits). https://www.libsdl.org/release/SDL-1.2 ... html/sdlcreatecursor.html

Maybe it doesn't solve the issue but worth checking.

@kas1e

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...

A new version is available:

***

2018-Jan-12
- Fixed radial blur in 640 * 480 (still some issues)
- Fixed some compiler warnings
- Added error print for file open failures
- Compiled 320 * 240 window mode binary
- Added SDL surface info logging

***

My Sam440 results:

GPmark improved, version: 2018 January 12
Surface dimensions: 320 * 240
Surface is located in RAM
Surface must be locked: false
Display mode: window
Blitting Test: 150.9
Plasma: 135.1
Rotozoomer: 135.1
Rotozoomer Near: 145.2
Rotozoomer Far: 108.9
Radial Blur: 63.1
3D Bunny: 8.3

GPmark improved, version: 2018 January 12
Surface dimensions: 640 * 480
Surface is located in RAM
Surface must be locked: false
Display mode: fullscreen
Blitting Test: 107.1
Plasma: 81.6
Rotozoomer: 79.4
Rotozoomer Near: 99.8
Rotozoomer Far: 53.7
Radial Blur: 18.0
3D Bunny: 8.1

@Tuxedo

I don't know what is resolution used for example in MOS port (you have to ask). If it's 320*240 then you are comparing different things because OS4depot version uses 640*480.

That's why I added a print in my build. No need to guess.

My version is comparable to OS4depot version, that's all I can say.

Since GPMark on OS4Depot seems to be a non-optimized build (?), I made my own using source codes from Aminet. Source code version uses windowed resolution 320*240 and I have doubled that to 640*480 fullscreen, to match the OS4Depot version. Now it also prints the screen resolution and results to the console.

This version was built with GCC 4.2.4 using -O2. It is faster on my Sam440EP than the original OS4Depot version.

Get the binary + sources here: http://capehill.kapsi.fi/gpmark/GPmark_OS4.lha

My results:

GPmark: width 640, height 480, flags 0x80000000
Blitting Test: 104.7
Plasma: 81.1
Rotozoomer: 78.4
Rotozoomer Near: 100.0
Rotozoomer Far: 52.0
Radial Blur: 17.9
3D Bunny: 7.9

@kas1e

Hmm.. Seems that I forgot to reply. Compositing fork checks graphics.library 53. Then it knows it can use CompositeTags.

http://www.amigans.net/modules/xforum ... id=100287#forumpost100287

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.

@Raziel

So we have 2 votes for GH and 0 for SF ;)

Let's wait til New Year.

@kas1e

Replied in SDL1 thread.

Continuing from:

http://www.amigans.net/modules/xforum ... id=108972#forumpost108972

@kas1e

My fork was based on this version: https://github.com/adtools/os4sdl

Also Marlon has started to collect various Amiga ports here: https://github.com/amigaports/

I don't know if anybody has done any OS4 work on SDL1 during the last 2 years.

Would anyone object if SDL2 project was moved from SourceForge to GitHub?

Personally I like GitHub more. SF seems to be full of ads and it feels quite messy and outdated when compared to GH.

GitHub would allow forks and pull requests and perhaps a more "social" open source development.

Is there any reason to keep the project on SF?

@sinisrus

Thanks, fix pushed to GitHub. Works by luck in little endian.

@Raziel

Saw your e-mail and replied. Please report it here: http://forum.hyperion-entertainment.biz/viewforum.php?f=26

You could also try to replace malloc + free with AllocVecTags + FreeVec for the fun and science.

@Raziel

This is somewhat off-topic but while I'm testing ScummVM and ResidualVM, can I ask what are your configure options?

I noticed today that if I run basic configure, there is no any default optimization flag enabled for compiler. I haven't tested any so far, but I'm sure that -O2 or even -O3 might give a nice performance boost for both engines.

I ran make with VERBOSE_BUILD=1 parameter to check it.