Sdl-1.2.15

[buggs]

Originally Posted by emufan

SDL_surface.go: undefined reference to `___memset64'
SDL_surface.go: undefined reference to `___memset64'
SDL_surface.go: undefined reference to `___memset64'
SDL_video.go: undefined reference to `___memset64'
SDL_pixels.go: undefined reference to `___memset64'
SDL_pixels.go: more undefined references to `___memset64' follow

where is this memset64 function?

This issue stems from your libnix build. I've noticed this, too when building bebbo's toolchain. GCC6 handles inlines differently in comparison to gcc2.95. I've ended up passing -fgnu89-inline to the libnix Makefile.

[buggs]

Originally Posted by emufan

I try to build the AMMX version --> Makefile.bax using gcc6:

video/amigaos/SDL_cgxvideo.c:34:23: error: expected identifier or
‘(’ before numeric constant
 #define Apollo_AMMXon 0

*ugh* That wasn't me.

If desired, the AMMX routines can be disabled entirely by disabling the Apollo_EnableAMMX() call. But in any case, the mentioned call does check whether the code is running on a machine that has the instructions available. Even the regular 68k blitting functions should be considerably faster than the generic C counterpart from SDL.

[emufan]

Originally Posted by Hedeon

This version identifies itself as 1.2.14 btw. See sdl_version.h

I didnt noticed, so there is still some room for improvements with updating to final 1.2.15

Originally Posted by buggs

I've ended up passing -fgnu89-inline to the libnix Makefile.

ok, I will try this in my next build.

Originally Posted by buggs

Even the regular 68k blitting functions should be considerably faster
than the generic C counterpart from SDL.

so the AMMX sdl functions are just a prove of concept for now - do not boost things on the vampire?

[buggs]

Originally Posted by emufan

so the AMMX sdl functions are just a prove of concept for now - do not boost things on the vampire?

When I rewrote the blitting functions, I did write two versions of each subroutine: one for 68020+ and one for AMMX. I consider both sets of routines ready for use. The code I've put to Github will auto-select the right ones (reflected in Apollo_AMMXon).

Whether one gets an actual boost by these blitting functions is a matter of the respective applications or games. Many programs I've seen don't use the SDL blitting functions but draw everything by themselves.

[emufan]

Originally Posted by buggs

Whether one gets an actual boost by these blitting functions is a matter of the respective applications or games. Many programs I've seen don't use the SDL blitting functions but draw everything by themselves.

so a game has to use SDL_BlitSurface function for example?

if that's right, which other functions will use AMMX if available?

#1) reading in blitapollo.h: ApolloCopyRect, ApolloARGBtoRGB565 ... are these the function one has to use in a game?

[buggs]

Originally Posted by emufan

so a game has to use SDL_BlitSurface function for example?

SDL_BlitSurface is the central hub in SDL to move pixel data around. It also covers implicit conversion betweeen different pixel formats. That's why I wrote a number of routines for typical conversion sources/destinations.

Arti asked me to help him out with an underperforming game he was porting. That's why I concentrated on faster blit functions.

Otherwise, there are two other places in SDL where I plan to put in some work (given some spare time). The audio mixer could be faster. Also, RectFill might warrant some attention.

Apart from these places where data conversion will be done, SDL in itself doesn't require too much CPU time by itself. It's mostly game logic and casual coding that makes recent titles slow on less potent hardware.

[emufan]

hmm, lotsa details.
but what are the exact sdl functions which will use the AMMX extension if available

[emufan]

I try to build GnNeo, which is almost done, but linking give some errors,
which makes no sense.
using my "old" libSDL.a which was ok for many things i build,
now I get these things:

libSDL.a(SDL_string.go) :SDL_string.go: undefined reference to `_ctype_'
libSDL.a(SDL_string.go) :SDL_string.go: undefined reference to `_ctype_'
libSDL.a(SDL_string.go) :SDL_string.go: undefined reference to `_ctype_'
libSDL.a(SDL_string.go) :SDL_string.go: undefined reference to `_ctype_'
libSDL.a(SDL_string.go) :SDL_string.go: undefined reference to `_ctype_'
libSDL.a(SDL_string.go) :SDL_string.go: more undefined references to `_ctype_' follow
libSDL.a(SDL_cgxvideo.go) :SDL_cgxvideo.go: undefined reference to `Delay'
libSDL.a(SDL_cgxvideo.go) :SDL_cgxvideo.go: undefined reference to `Delay'
libSDL.a(SDL_ahiaudio.go) :SDL_ahiaudio.go: undefined reference to `Delay'
libSDL.a(SDL_sysjoystick.go) :SDL_sysjoystick.go: undefined reference to `Delay'
libSDL.a(SDL_amigaevents.go) :SDL_amigaevents.go: undefined reference to `Open'
libSDL.a(SDL_amigaevents.go) :SDL_amigaevents.go: undefined reference to `MapRawKey'
libSDL.a(SDL_amigaevents.go) :SDL_amigaevents.go: undefined reference to `MapRawKey'
libSDL.a(SDL_amigaevents.go) :SDL_amigaevents.go: undefined reference to `MapRawKey'
libSDL.a(SDL_amigaevents.go) :SDL_amigaevents.go: undefined reference to `MapRawKey'
libSDL.a(SDL_amigaevents.go) :SDL_amigaevents.go: undefined reference to `Close'
libSDL.a(SDL_amigaevents.go) :SDL_amigaevents.go: undefined reference to `MapRawKey'
libSDL.a(SDL_amigaevents.go) :SDL_amigaevents.go: undefined reference to `MapRawKey'

using gcc6, maybe 3 month old:

CFLAGS="-DNDEBUG -D__AMIGA__ -I/cygdrive/d/SDL/include -mcrt=clib2 -O3 -m68020-40 -g"

$ m68k-amigaos-nm.exe /cygdrive/d/SDL/lib/libSDL.a | grep MapRawKey
m68k-amigaos-nm: SDL_cgxyuv.go: no symbols
m68k-amigaos-nm: SDL_cgxgl_wrapper.go: no symbols
m68k-amigaos-nm: SDL_stdlib.go: no symbols
m68k-amigaos-nm: SDL_malloc.go: no symbols
m68k-amigaos-nm: SDL_getenv.go: no symbols
         U _MapRawKey

any idea?

#1) playing with sdl 1.2.15, i found these warnings, which match some of the errors above:

video/amigaos/SDL_amigaevents.c:195: warning: implicit declaration of function ‘Open’ 
video/amigaos/SDL_amigaevents.c:200: warning: implicit declaration of function ‘Close’
video/amigaos/SDL_cgxvideo.c:1402: warning: implicit declaration of function ‘Delay’
video/amigaos/SDL_amigaevents.c:748: warning: implicit declaration of function ‘MapRawKey’

no such warning, building SDL_string.go, which above complains about "_ctype_" :/

what the heck is wrong here?

#2)
video/amigaos/SDL_amigaevents.c:

	#ifdef STORMC4_WOS
	if( (actual=MapRawKey(&event,buffer,5,NULL))>=0)

at least something to fix :/

this is the very same folder I build my libSDl couple weeks ago, not a bit changed,
now out of a sudden such errors, even with the one build many weeks ago.

the new player here is gcc6, but all this makes no sense. need a break :/

[Hedeon]

Need to add proto/dos.h for Open, Delay, Close and proto/keymap.h for maprawkey.

[arti]

Or link with -lauto and/or -lamiga

_ctype_ comes from clib2

[emufan]

Originally Posted by arti

Or link with -lauto and/or -lamiga

_ctype_ comes from clib2

I will try that.

Originally Posted by Hedeon

Need to add proto/dos.h for Open, Delay, Close and proto/keymap.h for maprawkey.

added dos.h proto to a gngeo/video.h and it did fix the delay, open, keymap errors,
but some new just pop up:

==> to make it even more confusing: the proto did not help,
but was fixed, because I was using "-noixemul" instead of my previous "-mcrt=clib2"
==> I try AmiDevCpp now

memory.o(.text+0xf96): undefined reference to `write_irq2pos'
memory.o(.text+0xfb4): undefined reference to `write_irq2pos'
memory.o(.text+0xf70): undefined reference to `write_neo_control'

i fixed by removing the __inline__ statement from the src:

// __inline__ void write_irq2pos(Uint32 data) {
void write_irq2pos(Uint32 data) {
...
// __inline__ void write_neo_control(Uint16 data) {
void write_neo_control(Uint16 data) {

but there is a gcc options for inline, IIRC, to "fix" or make the inline stuff work.

#2) now with gcc3 (AmiDevCpp) i get some asm errors:

m68k-amigaos-gcc.exe -DHAVE_CONFIG_H -I. -I..  -DDATA_DIRECTORY=\\"data\\"  
 -DNDEBUG -D__AMIGA__ -D_HAVE_STDINT_H -I/SDL/include  -m68020-40 -I/SDL/
 -D_GNU_SOURCE=1 -D_REENTRANT  -Wall -Wno-unused -funroll-loops -ffast-math
 -g -MT video.o -MD -MP -MF .deps/video.Tpo -c -o video.o video.c
.../Local/Temp/ccj9YFfJ.s: Assembler messages:
.../Local/Temp/ccj9YFfJ.s:6739: Error: parse error -- statement `moveb d3,(sr.3)' ignored
make.exe[3]: *** [video.o] Error 1

any idea how to debug this?

[bebbo]

instead of removing __inline__ you coud fix its definitions, I did not look into your code so I am guessing:

#if defined(__STDC_VERSION__) && (__STDC_VERSION__ >= 199901L)
#define __inline__ inline
#else
#define __inline__ extern inline
#endif

[emufan]

*OMG* finaly a binary, does start with tiny window, switches to full screen and does crash winuae.
done with gcc6, since I could not fix the damn gcc3 assembler.

I tried adding your lines in memory.c, but it makes no diff.
funny enough since other __inline__ functions seems just fine.

sdl stuff was gone, when I skiped clib2, now -noixemul
getopt related things I fixed with getopt_long source I found, build and added getopt_long.o.
furthermore removed some "external" from simple variables.

*now* I can look into the GnNeo fullscreen vs window mode problem

#1) not much progress. it does switch from tiny window to a black overlay,
I can move the "hidden" window, so it's visible again, but it does guru some moments later.

[arti]

inlines in memory.c are fine on gcc 2.95.3


BTW:

[ Show youtube player ]


I have also alredy ported snes9x before you :

[ Show youtube player ]

Lolz

[AMIGASYSTEM]

@arti
I would like to test the new version of GnGeo r1142 hoping it works up WinUAE, can you download it somewhere?

[arti]

http://netsurf.baderman.net/gngeo.svn.r1142.zip

It works, just set desktop to 15bit.

[AMIGASYSTEM]

Thank you Arti, GnGeo r1142 it works and is very fast on WinUAE, but the colors are bad, tested UAE-Gfx 15,16 and 32Bit the result does not change, also tried card Picasso IV with the same result.

[arti]

Try in window.

[AMIGASYSTEM]

Even in the window you can see badly, see screenshot !

[arti]

Fine here, make sure that game script runs proper gngeo.exe.
EDIT: Is screen set to 15bit not 15bit PC?